« システム開発にもセカンドオピニオンを | トップページ | システム要件を捉えるために必要な「疑り深さ」 »

2006.02.18

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

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

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

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

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

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

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

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

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

|

« システム開発にもセカンドオピニオンを | トップページ | システム要件を捉えるために必要な「疑り深さ」 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: システムの設計と施工を分離する:

» [ソフトウェア開発]システムの施工って? [酔狂人の異説]
「システムの設計と施工を分離する」というエントリがあった。タイトルだけで頭が痛くなりそうなエントリである。 工学的な設計文書と呼べるのはソースコードだけ ソフトウェア・システムの開発において、建設における施工に相当するフェーズは通常存在しない。建設において設計と施工とが分離できるのは、あるレベル以上の技術を持つ者であれば誰が作っても同じ物が作れる設計文書が存在するからである。だが、ソフトウェア・システムの開発においては、通常そのような文書はソースコードだけである。「工学的な設計基準を本当に満足して... [続きを読む]

受信: 2006.02.19 07:20

» ソフトウェア工学化の前提を語ってほしい [ratio - rational - irrational]
ソフトウェアの「設計」と「製造」のアナロジーに対する古典的批判について、回答が欲しい。 [続きを読む]

受信: 2006.02.19 09:07

» [開発]システムの設計と施工を分離する [カレーなる辛口Javaな転職日記]
http://watanabek.cocolog-nifty.com/blog/2006/02/post_2a9a.html メモ. やあ,これは「是非突っ込んでください」という記事ですね. 「使いやすさ」やよりも「作りやすさ」を優先した設計にすれば、施工コストを抑えられる。 「作り易さ」よりも「設計のし易さ」を優先した設計にすれば,トータルのコストは文字通り桁違いに増大する.しかも作りにくいソフトというのは往々にしてスパゲッティプログラムになりやすく,機能追加もパフォーマンスチューニングも... [続きを読む]

受信: 2006.02.21 00:46

» システムの設計と施工を分離する [akonの<よっぱらい>の戯言]
20年くらい前にIBMで成功したからと大手SIerでやったんだけど、柔軟性に欠けてビジネスとしてはやっていけず、組織は1年で解体した。では、実際に行われていないかというと、零細な外注は施工を担当し、稚拙な設計の後始末おわれていたりする。で、この記事の 大切なことは、 「分離したら発注者は、設計と施工を結ぶ架け橋の役目を果たさねばならない」 ということだと思う。壁から投っぱしだったり、管理するだけじゃぁダメなんだよね。 これって難しいなぁ。でも、セカンドオピニオン方式より現実味はある。でもでも、... [続きを読む]

受信: 2006.02.24 12:03

« システム開発にもセカンドオピニオンを | トップページ | システム要件を捉えるために必要な「疑り深さ」 »