フロントローディングの重要性

　製品、システムやサービスといったものを開発するプロジェクトにおいて、計画通りに進めていったつもりでも、必ずと言ってよいぐらいプロジェクト終盤に品質面の問題が発生しバタバタ対応しながら息絶え絶えにゴールテープを切る、といった経験をしていないでしょうか。

　プロジェクトの目標に向かう道筋をWBSに落とし、プロセスに沿って個々のタスクの完了を積み上げていったはずです。しかし、計画通りにタスクを完了したということは、計画工程を維持した、計画コスト内に抑えたことではあっても、必ずしも品質を確保することができたということではありません。

　プロジェクトの進行過程では、どうしても工程の進捗やコストオーバーしていないかということにフォーカスが当たってしまうものです。その結果、順調に工程を消化してきたはずが、終盤になって品質の確保が疎かになっていたことに気がつくことになるのです。

　品質の確保については、作業項目と工数及び期間、そして成果物を定めた表層的なWBSを作るだけでは実現できません。そもそも何を持って品質の確保とするかに言及するには、品質目標がなければなりません。プロジェクトが目標とするものはあっても、その品質を語る目標がなかったりします。あるいは、あったとしてもソフトウェア開発プロセスの終盤における検証フェーズでのバグ密度の様なものであり、この段階でのバグ密度はそれまでの作業の結果を表すものに過ぎず、結果が出た時点では手遅れです。

　ここで必要なのは”フロントローディング”という考え方です。文字通り捉えれば、初めの段階で負荷を掛ける、日本語でいわれる”先憂後楽”に近いものです。特に開発案件では有効な考え方で、プロジェクトにおいてはできるだけ上流の工程のあいだに品質を作り込むということになります。そのためには、上流工程における品質目標を定める必要があります。

　私が目にしてきた多くの開発プロジェクトは、決して設計をおざなりにしているわけではありませんが、設計作業の”消化”に重きを置き、問題があれば検証段階で見つけて修正すれば良いという考え方が暗黙的に了承されていました。品質は成果物ができあがる最終段階まで目に見えませんが工程は常に目に見えるので、やはり現場は工程の維持、消化を優先させてしまうのです。

　それを、強い意志を持って品質の作り込みを優先させる、という考え方に転換しなければなりません。”Nature or Nurture?” (生まれか育ちか？)という論争は必ずしも結論が得られるものではありませんが、優れたシステム、製品及びサービスのためには生まれ方が育ち方より大切であると強調したいと思います。生まれ方－すなわち設計に問題があり、育ち方－すなわち検証段階で欠陥を修正しながら作り上げていくということは、どうしても継ぎ接ぎだらけになり、思想の統一の取れないモノができあがってしまうのです。PM及び上位管理者は、特にプロジェクト前半においては、工程の維持だけに目を向けず、その陰で品質がしっかり作り込まれているかについても同様に確認を怠らない姿勢を持ってほしいと考えます。

 

関連提言：問題を先送りしてしまっていないか