システムの設計と施工を分離する

　２４歳で太平洋をヨットで単独横断した堀江健一氏は、今も現役の冒険家として活躍している。１９６２年の最初の快挙を綴った「太平洋ひとりぼっち」にあるのだが、彼が初代「マーメイド号」を建造したとき、現場から目を離せなかったという。目を離すと造船業者は、ヨットの設計家が工夫をこらした図面に従わずすぐに手を抜いたからだ。つきっきりで監視したにも関わらず、航海中に施工上の不手際に悩まされたという。

　ヨットや家といった複雑な建造物を手に入れるために、発注者は東奔西走しなければならない。その中でも、設計業者と施工業者を分離させて、両者の専門性を拮抗させることは基本中の基本である。ディベロッパーが両者を掌握している建売物件のリスクの大きさも、欠陥住宅や耐震偽造問題を通して広く知られるようになった。

　ところが、現在のシステム開発案件の多くで設計と施工が同一業者によってまかなわれていることは、ほとんど疑問視されていない。まあ、わからないではない。分離したら発注者は、設計と施工を結ぶ架け橋の役目を果たさねばならない。ほとんどのユーザはコンピュータだのネットワークなんてチンプンカンプンなので、そんなメンドウなことには関わらずに済ませたいはずだ。

　しかしそのやり方だと、コストや建造物の質に関する大きな部分が発注者から見えなくなる。ひとつの業者が設計と施工の双方をコントロールできるのであれば、総コストを抑えるための自由裁量をたっぷりとれる。「使いやすさ」やよりも「作りやすさ」を優先した設計にすれば、施工コストを抑えられる。また、自分たちしか理解できないハチャメチャな設計をすれば、改修フェーズで顧客を囲い込める。ことさら悪意がなくても、業者が利益確保のために暴走してしまうことはあり得る。

　どちらが正しい発注方式であるかという問題ではない。建売住宅と注文住宅の両方があるように、発注者がそれぞれのリスクを理解したうえで「一括発注」か「分離発注」のいずれかを自己責任で選択すればいいことだ。

　お気づきだと思うが、発注方式は発注者がリスクやリソースを勘案したうえで選ぶことなので、プロジェクトを「ウォーターフォール方式」で進めるか「アンチ・ウォーターフォール方式」で進めるかを業者はコントロールできない。「分離発注」で依頼されたとたん、プロジェクトは遠目にはウォーターフォール方式にならざるを得ない。開発側がウォーターフォールを批判して切り捨てればオシマイという話ではないのである。むしろ、大規模で複雑なモノの建造委託における基本が「分離発注」であることを考えれば、ウォーターフォールは企業システム開発の宿命ではないだろうか。

　じっさい、ウォーターフォールを批判するのは簡単だ。筆者自身、９０年代の初め頃にそのやり方をセミナーで「非現実的な机上の空論」と大批判していたものだ。しかし、そこで偉そうに語って実践した「現実的な手法」はうまくいかなかった。要するに、走りながら考えるやり方ではコストや工期のコントロールが難しすぎたためだ。

　我々が目指すべきは、他の工学系業界と同様に「宿命としてのウォーターフォール」を受け入れ、適応することだ。「ソフトウエアは特にわかりにくいからなあ」と嘆く暇があるなら、それをわかりやすく示すための努力をすべきだし、その余地はまだまだある。