「現状のソフトウェア開発は間違っていないか？」（プロセス編）：ソフトウェア開発の匠（3）（3/3 ページ）

» 2009年01月28日 00時00分公開

なぜウォーターフォール開発は捨てられないのか

　上記に挙げたような欠陥があるウォーターフォール開発であるが、捨てられないのには、次のようなわけ（仕組み？）がある。

●ウォーターフォール開発には裏プロセスが存在する

　オープン系の開発でウォーターフォール開発をし、それなりに成果を出しているように見えるプロジェクトには、いままで挙げたようなリスクをヘッジするための裏プロセスが存在する。

　その裏プロセスを表プロセス化すると、それはもはやウォーターフォール開発ではない。筆者の感覚でいうと、反復プロセスとも違う。一般的な裏プロセスを含むウォーターフォール開発は、並行開発プロセスのようなものに近い。

　つまり、ユーザーにはウォーターフォール開発でやっていると見せて、裏では先に挙げた要求の検証とアーキテクチャの検証のためのプロトタイプ開発などを並行で走らせているわけである（図3）。なぜ裏プロセスかというと、あえてやり方が公表されていない、つまり、プロセスが「見える化」されていないからである。

　オープン系の開発でウォーターフォール開発を行い、それなりに成果を出しているように見えるプロジェクトのマネージャあるいはリーダーは、この裏プロセスを持っていると考えてよい（注2）。ただ、それをプロセスとして定義していなかったり、言葉にしていえなかったりする。従って、筆者は裏プロセスと呼ぶ。裏プロセスを持たないウォーターフォールによるシステム開発は、非常にリスクの高いプロジェクトといえる。

　ただ、裏プロセスを持つ開発がよいものかというと、「それなりに成果を出しているように見える」と書いたように、表面上はうまくいっているように見えても、実際は多大なコストを使って開発しており、それが明らかにされていない場合も多い。なぜなら、裏プロセスを表に出し「見える化」しない限り、プロセスの改善は進まないからである。

（注2）筆者もウォーターフォール開発の裏プロセスを表プロセス化した（開発プロセスを含む）方法論を1996～1998年に作成したことがある。その名はDrop。オブジェクト指向開発に対応するために、プロトタイプと並行プロセスを組み合わせたものとした。

図3　裏プロセス付き、ウォーターフォール開発

●ビジネスがそれで成立していた

　ウォーターフォール開発は、マネジメント的にもビジネス的にも楽なのである。計画的に人を積み、要件定義を（価値がなくとも）しっかりやり、それに基づき（必要なくとも）開発要員をどっぷり投入し、誰にも疑問を抱かせず、最初に定義された要求の実現だけを滝の流れに逆らわず行うだけで開発を終えられる。これほど、楽観的なマネジメント手法はない。

　実はこの方法は、ユーザー企業からも歓迎される傾向にある。なぜなら、契約面から考えても、ウォーターフォール開発は、最初に決まっていないリスクを排除できるように見えてしまうからだ。ユーザー企業とITベンダ双方ともリスクを取りたくないという逃げの姿勢の中で成立している開発プロセスなのであるが、実際には、そのリスクが高まっている事実に気が付かないでいるのだろう。あるいは、気が付いていてもこのビジネス形態を壊すのが怖いのかもしれない。

　ウォーターフォール開発がうまくいかないことを見える化できていない状況の中、いまもメジャーな開発プロセスとして残り続けている。IT企業の仕事術は、果たしてこれでよいのだろうか。

　ユーザー企業からは、「提案しないIT企業」というレッテルを貼られている。3K（「きつい」「帰れない」「給料が安い」）という屈辱的な言葉で語られるようになったITの仕事。これらのことを、IT業界の仕事術と絡めて真剣に考えなければならない時期がすでにきている。

　IT企業の仕事術が変わらなければならないのは明白だ。その変革すべき主テーマとしてウォーターフォール開発からの脱却がある。すでに遅いかもしれないが、IT企業がこのことに気が付き、ウォーターフォール開発に代わるべき開発の在り方を見つけ出さなければならない。

●まだまだ未熟な、反復開発、アジャイル開発

　IT変革を行うべきところ、残念ながら裏プロセス付きウォーターフォール開発に代わるべきプロセスが存在しないのも事実。ウォーターフォール開発に代わると思われている反復開発やアジャイル開発も、未熟である。

　さて、次回は、反復開発やアジャイル開発にフォーカスを当て、それらの有効性と問題点を考えてみよう。

筆者紹介

株式会社　匠Lab 代表取締役社長
リコーソフトウエア株式会社技術顧問
ケペル株式会社フェロー
株式会社ニッポンダイナミックシステムズフェロー
要求開発アライアンス理事

萩本順三（はぎもとじゅんぞう）

2000年、ソフトウェアを人の思考に近い「もの」という単位で考えることで、分かりやすいソフトウェア開発を行えるというオブジェクト指向技術の企業、豆蔵を立ち上げ、ITアーキテクト、メソドロジィストとして経験を積む。現在は、ビジネスとITの可視化を行うための要求開発方法論を要求開発アライアンスメンバーとともに作成し、自らユーザー企業で実践しながら後進の指導に当たる。2008年7月、匠Labを設立し、IT業界のさらなる価値向上を目指す。

「次回」へ

「ソフトウェア開発の匠」バックナンバー