なぜいまだに日本では ウォーターフォールモデルが採用され続けるのか

「正しいただ一つの計画」の誤謬とその利点

今日本のソフトウェア開発の現場ではウォーターフォールモデルは人気があるとは言えないまでも,
いまだに多くのプロジェクトで採用されている開発手法です。特に大規模な開発に採用されることが多く、成功確率のとても低い開発手法でありながら、「正しく計画して、その計画通り正しく作れば必ず成功する」といったような思い込みから採用される状況が続いています。大規模になればなるほど、計画を立てる難易度は上がっていき、そしてその立てた計画通り実行する難易度もさらに高まります。

結果的に後から振り返ってみると、現実で起こった様々な出来事が事前の計画に盛り込まれていないということに誰もが気が付きます。そのように計画に盛り込まれていない状況では計画通りに実行しようとしても現実と計画の間にギャップがある限り,
計画通りに実行することはできなくなってきます。正しい計画を立てればよかったのでしょうか。いえ、問いをもう少し正確にするとすれば、「どの程度にまで正しい計画を立てればよかったのでしょうか?」 大規模になればなるほど、ほんの少しの事前の予測のずれが、プロジェクトの後半になっていくほど影響が連鎖して軌道修正ができなくなるほど現実と計画が乖離してきます。2年越しのプロジェクトの細部で何が起こるかまで事前に全てを見通せる人などいるでしょうか。ソフトウェア工学の世界ではプロジェクト管理のあり方として、いかに正しく予測をして、それらを詳細に計画に盛り込むか、というテクニックというものについて研究し、それらのテクニックを洗練させようと努力をしてきました。それらのテクニックについて考えること自体は学ぶことも多くあります。しかしそれらの多くのテクニックを学んだところで、プロジェクトの成功確率は大して上がらないのです。

ではなぜ未だにこのウォーターフォールモデルが採用され続けるという現実があるのでしょうか?

日本のIT産業の構造的な問題

日本のIT産業というのは、親会社が大企業のソフトウェア子会社が牽引してきました。これらの会社はもともとは親会社の中でソフトウェアを作る部門が、自社のために作るだけではなく他からもソフトウェア開発の仕事を受注するようになるために子会社として独立し、それによってコスト部門から利益部門への転換を図った結果でもあります。ソフトウェアを作るというのはそのほとんどが人件費です。自社のために専属で開発をし続けるソフトウェア開発部門というのは大きなコストを抱える部門になります。そこで他からもソフトウェア開発の仕事を請け負うことで人件費以上の売上を立て、利益を上げる組織に変わろうとしていったのです。

日本国内には親会社の名前がついた比較的大きなシステム開発会社、ソフトウェア開発会社が多くあります。そうなってくると何かのシステムを構築する、という一つの区切りで、仕事が発注されることになります。親会社が大企業ともなると上場していたりしますから、年間でどのぐらいの予算を使うのか、あらかじめ計画を立てて公表する必要があります。 そしてシステムを構築するために必要な諸々を、発注をする最初のタイミングで決める必要があります。これらのシステムを構築するのにかかる費用、期間を決める必要があるのです。

大抵、 大規模なシステムの構築の場合、事前に調査をし、要件をまとめあげて、 どのくらいの規模になるのかを概算で見積もります。そしてここで発注金額が決まると、後はその発注金額内で収まるように開発者が招集され開発スケジュールが決まります。

ここまでくるともうお分かりかもしれませんが、ウォーターフォールモデルはこうした日本のIT産業の構造の中でビジネスをしている上では、発注がしやすい仕組みなのです。長期間に渡って行われるプロジェクトの必要な費用を最初に決めてしまうのですから、発注を受けたソフトウェア開発側は予めまとまった開発資金が手に入ることになりますし、発注をする親会社側は、何度も何度もソフトウェア開発費用を修正して公表し直すという手間が省けます。

私もこうした場面に居合わせたことがありますが、 まだ誰が開発するのか、実際の開発者が決まっていない状況なのにも関わらず、発注金額が決まってしまったことで自ずとその他の要素である、開発の成果物である製品の機能や開発したシステムが使えるようになるまでの納入日・稼働する日、などがなぜか決まってしまい、そのまま進んでいくという雰囲気になっていきます。

概算で見積もった規模が元となり、合意が形成されていくのです。受注をした時は楽観的ですが、実際に開発プロジェクトが始まって計画通りにいかないということがわかり軌道修正も困難となると、とても悲観的な雰囲気になってしまいます。

ウォーターフォールモデルは始めるのは簡単で終わるのが難しい

実際にプロジェクトも後半に差し掛かり納期までに開発が終わらないということが分かると、親会社にそのことを伝え追加の費用の請求をします。プロジェクトが延長されるわけです。そして追加の人員も増員されていきます。プロジェクトの規模がさらに大きくなります。さらに複雑になってきます。開発効率は著しく落ちていきます。そしてまた追加の請求をする、ということを何度かやり、実装する機能を最終的に削ったりしながら、なんとかプロジェクトを終わらせます。予算オーバーをしたら、おかわりをするわけです。
こうした追加の請求、おかわりができる状況にある子会社ソフトウェア会社はウォーターフォールモデルでもなんとかやっていけるわけです。もしおかわりを認めなければシステムは完成せず、今まで投じた資金が泡となって消えてしまいます。となると、おかわりに応じないという選択肢はないと言っても過言ではないです。

これが親会社とソフトウェア子会社の間だけの問題ならいいのですが、 開発するのに投じたコストに見合っただけの価値のあるシステムが出来上がらないとなると、そのシステムを使う親会社は競争力を失います。そして何より開発現場の開発者達は疲弊していきます。それでも また次のシステムを構築する際には、同じような事が繰り返されるわけです。
ウォーターフォールモデルで作られたシステムに大した価値がないという意味ではなく、システムが出す価値以上に開発コストがかかりすぎているということです。

それに対してアジャイルモデルは、始めるのが難しく終わるのは簡単という特徴があります。
始めるのが難しいという理由ですが、アジャイルモデルではシステム全体の規模や、最終的に必要となる機能などを洗い出してそれらを必要となる費用の見積もりに使うという事はしません。 将来的にどのようなシステムになるのかというビジョンとして用いることはあっても、実際に開発してみてユーザーが使える状態にならないとシステム自体の価値は分からないし、それを作るのにいったいどれぐらいの時間がかかるのか、というのは実際に開発してみないとわからない、というスタンスです。とても現実的です。

開発するシステムが同じでも、開発する開発者が違うだけで開発にかかる期間も違えば、開発者の人件費も変わってきます。となると最初に合意を形成するのが難しく、ウォーターフォールモデルでの受注に慣れている人達からすると、何も決めずに始めようとする、という風に見えるのです。
何も決めてないので始められない、どう始めていいかわからない、となるわけです。ですので、最初からいきなり大規模なプロジェクトにしてしまうのではなく、最終的には大規模なプロジェクトになったとしても、スタートはスモールで始める、資金も少額で始める、開発する人員も少人数で始める、という形を取ることによって、スタートしやすくする必要があります。」

書籍:「成功するアジャイル開発」に大規模アジャイル開発の真髄が満載です!

関連記事

  1. 1人でやろうとするな!チームを組め:アジャイルメソッド

  2. 書籍「成功するアジャイル開発」を出版いたしました

  3. 計画駆動とアジャイルの違い -成功するアジャイル開発(1)-

  4. 失敗するプロジェクトは現実逃避から始まる -アジャイル開発を成功させよ…

  5. 失敗するプロジェクトは現実逃避から始まる -アジャイル開発を成功させよ…

  6. 【初心者でも挑戦してみよう】VALU便利ツールの作り方で学ぶWEB技術…

  7. アジャイル開発についての本を書いてみての感想

  8. なぜスクラムマスターが必要なのか

最近の記事