現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介する。今回は前回に続いて、マネジメントに関するセオリーを取り上げる。
セオリー4
品質を後付けしてもよい
モジュールを見極める
「品質は後から追加できない」というのはシステム開発の半ば常識となっている。そのため品質管理を徹底し、後工程で生じる手戻り作業を最小限にすべく開発を進める必要がある、とよく言われる。しかし、コストや期間に余裕がない暗闇プロジェクトでこのやり方を実践するのは不可能に近い。
品質に関してはメリハリを付けて考えたい。特に開発するモジュールの品質を「後付けしてもいいかどうか」の見極めが大切になる。品質を事前に十分確保する必要がある（品質を後付けしてはいけない）モジュールは要件定義と論理設計の段階で高い品質で仕上げるよう意識する。その他の部分は「品質は後付けでよい」と割り切る（図2）。これが四つめのセオリーである。
品質が低くても全体に大きな影響はなく、かつ他の機能と疎結合のモジュールは、品質を後付けしてもよい候補となる。こうしたモジュールはプロジェクトが切迫した際のバッファーとなる。これを実践したのがF社だ。
F社はプロジェクトで、品質を後付けしてもよいモジュールを作業量の「調整弁」とした。プロジェクトの繁忙期には、そのモジュールについては一時的な品質低下を認め、品質向上策は後回しでよいと決めたのである。
この方針により、F社のメンバーは「帰宅は毎日終電」「毎週土日出勤」という、プロジェクトのピーク時にありがちな事態を回避できた。
品質向上の取り組みは、開発プロセスの中に埋め込まれるべきものであり、システムのリリース後に品質を高めることはできない、と言われる。実際には、「後付けしてもよい品質」も存在する点を押さえておきたい。
