システム開発現場の活気を取戻そう（中）ウォーターフォールからの脱却ビジネス-次世代ＩＴ産業論考（浜口友一）:IT-PLUS

　前回に続き、開発現場の活気を取り戻すための方策を考えたい。このコラムの初回でも書いた通り、筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。

■日本のシステム開発はファクトリー型

　ウォーターフォール型とは、前工程の成果物に基づいて次の工程作業を行っていく流れ作業的な開発スタイルで、わが国では最もポピュラーなものである。製造工場と同じように整然としたラインや規則に従って進めていくので、マサチューセッツ工科大学（ＭＩＴ）のクスマノ教授はそれをファクトリー型とも呼んでいる。

　長年の様々なノウハウも蓄積されてきており、また多くの技術者が集まるようなプロジェクトでは、誰もが理解している共通の方法論として有効に機能してきた。だが時代とともに、個人の能力や特性を発揮しにくい傾向が強まってきているのではないだろうか。

　例えば、品質要求の高まりや納期の短期化に応えるため、より細かい管理単位でのマネジメントが行われ、またプロセス管理やセキュリティー規定の強化も進んでいる。その結果、個人の自由裁量の余地は縮小している。

　加えてシステムの複雑化が要件定義や設計を難しくし、工程ごとに決めるべき事項を確定しきれない割合が増えてきている。前工程で変更や訂正が発生すると、追加作業として後工程に伝播し、心理的なモチベーションを低下させてしまうのだ。

　そしてよく考えてみると、ソフトウエアは製造工場で同じ形の製品を繰り返し大量生産するようなものとは違い、製品設計それ自体が生産物であり、２つと同じものを作ることはない。果たして、このような工場型の方式が向いているのかどうかという疑問もわいてくる。

■ウォーターフォール型 vs. 同期安定化型

　では、どういう開発スタイルに向かっていくべきなのか。ソフトウエア開発の方法を大別すると、ウォーターフォール型と反復型に分類できる。ここでは、反復型の一例として、マイクロソフトが開発した同期安定化型（ＭＩＴのクスマノ教授の著書「ソフトウエア企業の競争戦略」より）を取り上げる。

　ウォーターフォール型は、工程ごとに仕様（成果物ドキュメント）を確定しながら作業を進めていく開発方法で、企業向けの個別開発によく採用される。品質を高めやすい半面、変更には柔軟に対応しにくい。

　また、プログラマーの自由な振る舞いが制限されがちだ。これは本来ウォーターフォールという方法論に起因するのではなく、日本流に進化させた結果ではないかと思う。コンピューターが非常に高価であった時代には、プログラマーが端末に向かって頭をひねり、ずっとマシンを占有しているわけにはいかなかった。プログラムの設計も極力机上で行い、何度もレビューを重ねたうえで、実際にコンピューターに入力して動かしてみるといった具合だった。

　この作業を工場生産的に細分していくと、最後にコンピューターに向かい作業をする人は、プログラムをデザインするのではなく、完成した設計書をプログラムコードに変換する役割を担うことになる。必要なスキルは、プログラムの構造をデザインするよりも、プログラミング言語の文法知識になる。日本でプログラマーの地位が低く見られがちなのは、こうした経緯からではないか。

　一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３～８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。

　同期安定化型は、マイクロソフトが考案したことからも分かる通り、開発する側で仕様の意思決定をしやすいパソコン向けのパッケージソフト製品の開発などによく採用される。ウォーターフォール型に比べ品質の確保が難しくなるが、変更には柔軟に対応でき、また優秀なプログラマーを集めて創意・工夫を発揮させることができる。逆に優秀なプログラマーが集まっているからこそ、コントロール単位を大きくすることもできるといえるだろう。

　さて、結局どちらがいいのだろうか。２つの開発方法は両極端にあり、恐らく解はこの間にあるのだろうが、様々な要素が複雑に作用するので一般的な正解というものはない。しかし、今のウォーターフォール型、ファクトリー型を突き詰めて成熟させていくことだけが最良の道なのだろうか。

■ハイブリッド型を目指すには条件が必要

　わが国の市場の大半を占める企業向けの個別システムに対して、最初から同期安定化型で開発を行うことは難しいが、ある工程以降で同期安定化型を適用することはできるのではないだろうか。だだし、それには条件が必要だ。企業システムである限り、基本的な要求仕様はその企業に決めてもらわねばならない。後工程で大きな変更がないように要件定義はできるだけきちんと行っておく必要がある。

　どの時点で同期安定化型を採用できるか、分割単位をどれくらいの大きさにするかは、開発メンバーの能力にもよると思われるが、ウォーターフォール型と比べても相当能力の高い人材が必要になる。理想的には、彼らには詳細設計からテスト、完成まで一気通貫で担当できるようになってほしい。

　このような試みが少しずつでも進めば、エンジニアのモチベーションは向上し、業界イメージを悪化させるような要因は解消する。創意・工夫の余地が拡がれば、自己のアイデンティティーを発揮することができるようになるはずだ。

　これに欠かせないのが人材育成である。今現在も、こうした資質を備える優秀なエンジニアは沢山いる。しかし、スキルや適性に欠ける他のメンバーを補うことに時間を割かれているのが実態だろう。

　人材育成は次回に詳しく考えるが、一点だけ触れておきたい。1968年に公表された「ソフトウエア工学の諸問題に関するＮＡＴＯ報告書」というものがある。ソフトウエア開発についての問題点が明確に述べられており、それがまた今と全く変わっていないのに愕然とする。40年の間、色々な工夫がされて来たのにも拘わらず、ソフトウエアの持っている本質的問題が深いことを改めて痛感せざるを得ない。

　たかだか数十年の歴史だが、そろそろ「経験だけから学ぶ」ことからは脱却し、少なくともこの仕事に就く時点で40年の歴史からの学びを備えている、そうした人材育成のあり方を産学で一緒に考えていく必要がある。

更新：2008年7月28日 09:00ビジネス：連載・コラム

次世代ＩＴ産業論考（浜口友一）

システム開発現場の活気を取戻そう（中）ウォーターフォールからの脱却

-筆者紹介-

略歴

● 関連記事

● 関連リンク

● 記事一覧