ウォーターフォールモデルの限界と“PoC貧乏”が起こる理由【第2回】

　多くの企業情報システムは、「ウォーターフォールモデル」と呼ばれる手法でソフトウェアを発注し開発してきました。ウォーターフォールとは「水が高いところから低いところを流れ落ちていく様子」という意味で、システム開発においては、決めなければならない内容を徐々に詳細化していく方法を指します（図1）。

図1：ソフトウェア開発における「ウォーターフォールモデル」の概念

　具体的には、開発プロジェクトを（1）要件定義（どんなシステムを作るか）、（2）基本設計（機能の概要や画面のデザイン）、（3）詳細設計（開発するプログラムの細かな機能の定義）、（4）プログラミングといった段階（工程と呼びます）の順に、だんだんと細かい内容に落とし込んでいきます。前の段階（上流工程と呼ぶ）が完了してから次の段階（下流工程と呼ぶ）へ進んでいくわけです。

ウォーターフォールは大規模プロジェクトを失敗しないためのモデル

　ウォーターフォールモデルは元々、土木や建築、プラントなどの巨大な工事を正しく進めるために生み出された方法です。それが1960年代に、メインフレームと呼ぶ大型コンピューター上で動作するソフトウェアが大規模、かつ著しく高価になった頃、開発プロジェクトを科学的アプローチによって正しく進めるために、ソフトウェア開発にも適用されるようになりました。

　しかし、ウォーターフォールモデルについては、20年ほど前からすでに、次のような問題点が指摘されています。

・前工程の誤りによって手戻り作業が発生すると、大幅に工数が増える
・テストなどの下流工程になればなるほど手戻りが深刻になる

　さらに近年は、米国を中心にウォーターフォールモデル離れが進んでいます。「海外におけるソフトウェア開発において、ウォーターフォールモデルが採用されている率は1割にも満たない」との調査結果もあります。にもかかわらず日本では、多くの企業がウォーターフォールモデルでソフトウェア開発を続けているのが現状です。

　当社に来られた、ある金融系企業の事業部門の方からも最近、こう打ち明けられました。

「社内の情報システム部門や、付き合ってきたシステムインテグレーターに機能追加を依頼したのだが、高額な見積書と6カ月といった開発スケジュールを提示されるような反応ばかりで困っている」

　まだまだウォーターフォールモデルしか経験したことがない、それ以外の進め方を知らない企業が多いことは驚きです。そこには以下のような日本のIT業界特有の構造上の問題があります。

・技術者のほとんどがユーザー企業ではなく、システムインテグレーターに所属しており、文書化された要件がないと開発ができない
・工程がきれいに分離されるほど技術者を外部から調達しやすい

　これらは根深い問題ですが、本連載のテーマからはずれてしまいますので、今回は深掘りしません。

デジタルシフト開発では当初から「正しい要求」は確定できない

　日本のIT業界の構造問題を別にしても、ウォーターフォールモデルのプロジェクト成功の鍵は、「できる限り早い段階で“正しい要求”を確定する」ことが握っています。であれば発注側は、正しい要件に基づいて見積もりを依頼し、それに沿って発注しなければなりません。受注者側にしても、顧客から提示された要件（仕様）通りにソフトウェアを開発することが自らの責任範囲になります。

　当然、最初の要件が間違っていれば、間違ったソフトウェアが完成します。それでもベンダーにすれば要件通りに開発しただけですから、「要件通りです」と胸を張って答えるといった事態すら起きてしまうのです。ベンダーが無責任といったことではなく、ウォーターフォールモデル自体が、発注者に正しい要件定義を求めていることに原因があります。

　デジタルシフトのための開発において、このウォーターフォールモデルの最大の問題は「変更を前提としていない」という点です。デジタルシフトに向けた開発では、初期段階では何が正しい要求かは分からないことがほとんどです。そのため、間違いを修正しながらプロジェクトを進めなければなりません。