4つの開発モデルとビジネスの生存戦略

基礎を10mずらしてほしい？ソフトウェア開発の宿命

想像してみてください。2年の歳月と50億円の予算をかけて、巨大な超高層ビルを建てているとします。ついに最上階の屋根が完成したその瞬間、クライアント（発注者）が現場にやってきて、こう言います。「やっぱり、建物の基礎を左に10mずらしてもらえませんか」。建設の世界なら大騒ぎですし、物理的にも不可能です。ところが動画は、ソフトウェアの世界ではこれとよく似た要求が毎日のように飛び交っている、と続けます。

あとからひっくり返される、という現実とどう戦うか。その試行錯誤の歴史が、今回のテーマ「ソフトウェア開発モデル」の正体だ、というのが動画の切り口です。取り上げるのは、次の4つです。

• ウォーターフォールモデル：要件定義、設計、実装を順番に進め、原則として前の工程には戻らない。
• プロトタイプモデル：早い段階で動く試作品を作り、ユーザーに確認してもらいながら進める。
• スパイラルモデル：システムを複数の部分に分け、機能ごとに設計やプログラミングを繰り返して完成度を高める。
• ラウンドトリップモデル：分析・設計・プログラミングなど、各フェーズの間を反復的に行き来し、試行錯誤でシステムを構築する。

動画は、これを丸暗記するのではなく、「なぜ生まれたのか」という物語として覚えよう、と呼びかけます。このページも、その順番に進めます。

ウォーターフォールモデル：滝のように、後戻りしない

最初は、すべての原点ともいえる古典的なモデルです。ウォーターフォールは「滝」のこと。水が高いところから低いところへ流れるように、要件定義、設計、実装の順に、原則として前の工程には戻らずに進めます。まず「どんなシステムを作るか」を決め（要件定義）、次に設計図を書き（設計）、実際にプログラムを書く（実装）。この一方通行が特徴です。

（補足：動画が挙げる工程は3つですが、実際にはこのあとテストや運用が続きます。工程の呼び名は資料により異なります。）

動画が「絶対に外せない」というのが、後戻りしないという点です。後戻りしないので、いまどの段階にいるのかが明確になります。「いまは設計図を書いています」「いまはプログラミング中です」と、クライアントにも経営陣にも説明しやすい。つまり進捗の管理が容易、というのが最大のメリットです。

その代わり、致命的な弱点もあります。途中で仕様変更が起きたときの修正が難しく、柔軟な対応がしにくいことです。

開発側が最も恐れるのは、クライアントの思いつきによる際限のない機能追加です。「あれも欲しい、これも追加して」と言われ続けては、予算も納期も守れません。そこで「ここから先は後戻りしません」と厳格なルールを敷き、予算とスケジュールの確実性を担保する、というわけです。

ただし、厳しい前提があります。クライアントが最初から、欲しいシステムを完璧に言葉にできていること。聞き手が言うとおり、家が建ってみて初めて「この部屋、思ったより暗い」「ここにコンセントが欲しかった」と気づくのが人間です。完成品を見るまで本当の要望は分からない。これが最大の壁でした。

プロトタイプモデル：動く試作品で「味見」する

この矛盾を解くために編み出されたのがプロトタイプモデルです。早い段階で動く試作品を作り、ユーザーに確認してもらいながら開発を進めます。実際に動くものを見せるので、初期の段階でユーザーの要望を反映しやすいのが特徴です。「画面のボタンはここじゃないほうがいいな」といったずれを、取り返しのつく段階で直せます。

早い段階で確認してリスクを下げる、という本来の目的が崩れてしまい、ただの予算の無駄遣いになる。だから動画は、プロトタイプモデルは小規模なプロジェクトに向くと整理しています。数字で考えると、イメージしやすくなります。

（以下は、このページのために作った設例です。金額は説明用の仮定で、実在のプロジェクトの数字ではありません。試作で見つかるずれを、完成後に直すと想定した費用と比べます。）

	小さな業務アプリ	全国規模のネットワーク
試作の費用	50万円	3,000万円
試作で防げる手戻りの費用	400万円	2,000万円
差し引き	+350万円	−1,000万円

小さなアプリなら試作が「安い保険」になりますが、巨大なシステムでは試作の費用のほうが大きくなってしまう場面がある、ということです。動画が言う「規模の壁」は、こうした費用対効果の話として読むと理解しやすいでしょう。

（補足：動画は「小規模なプロジェクトに適用と定義されている」と言いますが、IPAの応用情報技術者試験シラバス（Ver.7.2）には、プロトタイプは「外部仕様の有効性、仕様の漏れ、実現可能性などの評価を行い、手戻りを防ぐために」作ることがある、と書かれているだけで、規模による限定は見当たりませんでした。規模の話は、動画の整理として押さえてください。）

スパイラルモデル：小さく分けて、本番用を積み上げる

そこで次の問いが出ます。「大規模なプロジェクトだが、柔軟性もほしい」。ウォーターフォールのようにガチガチに固めるのは怖い。かといって、プロトタイプを作るには規模が大きすぎる。この行き止まりを破るのがスパイラルモデルです（スパイラルは「螺旋状」の意味）。

スパイラルモデルは、システムを複数の部分に分け、それぞれの機能ごとに設計やプログラミングなどを繰り返しながら、徐々に完成度を高めていきます。巨大なシステムを一度に作ろうとするから、後戻りできなくなったり、試作費用が膨れ上がったりする。だったら小さな機能の単位に分けてしまおう、という発想です。

ITの現場でも、まず商品の検索機能だけを作ってリリースし、次の周回でポイント機能を追加する、といった形で使われます。これなら大規模でもビジネスの変化に柔軟に対応できます。ウォーターフォールの硬さから逃れるためにプロトタイプが生まれ、プロトタイプの規模の限界を越えるためにスパイラルが生まれた。動画はそう、歴史の進化として語ります。

（補足：原典はバリー・ベーム（Barry Boehm）の論文「A Spiral Model of Software Development and Enhancement」とされ、書誌はACM SIGSOFT Software Engineering Notes 11巻4号（1986年）とIEEE Computer 21巻5号（1988年）で確認できました。ただし論文の本文は読めておらず、原論文の定義は確認できていません。プロトタイピングを含めてスパイラルを説明する解説書もあり、境目の説明は資料により異なります。上の対比は動画の整理として読んでください。）

ラウンドトリップモデル：行き来を、最初から計画に入れる

これで開発モデルは完成か、と思いきや、動画には続きがあります。現代のビジネス環境はさらにスピードを増し、最初から機能ごとにきれいに分けて計画することすら難しい場面が増えてきました。そこで登場する最後のモデルがラウンドトリップモデルです。分析、設計、プログラミングといった各フェーズの間を反復的に移動し、試行錯誤を通じてシステムを構築していきます。

従来のモデルでは、プログラミングの段階で問題に気づいても、前の工程に戻るには分厚い壁がありました。ラウンドトリップモデルは、そのフェーズの壁を最初から取り払っています。各フェーズの間を行き来することを、例外的なトラブルではなく、当たり前のプロセスとして最初から計画に組み込んでいるのです。行ったり来たりを最初から許可することで、カオスではなく、意図的な改善のループが生まれます。

（補足：IPAのシラバス（ITパスポート Ver.6.5、基本情報 Ver.9.2、応用情報 Ver.7.2）の本文に「ラウンドトリップ」という語は見当たりませんでした。ITパスポートが「主なソフトウェア開発モデル」に挙げるのは、ウォーターフォール、スパイラル、プロトタイピング、RADです。ラウンドトリップモデルの定義は一次資料で確かめられなかったため、動画の説明に沿って書いています。資料により説明が異なる可能性があります。）

4つのモデルを一つの物語として並べる

動画のまとめは、こうでした。4つのモデルは、ただの暗記用語ではなく、人間の認識の変化や試行錯誤を前提に、柔軟な手法へと進化していくストーリーだった。

モデル	生まれた背景（動画）	動画での特徴
ウォーターフォール	予算と契約の確実性を守りたい	後戻りしない。進捗管理が容易。仕様変更に弱い
プロトタイプ	完成品を見るまで要望が分からない	動く試作品で確認。小規模向けと説明
スパイラル	大規模でも柔軟性がほしい	機能ごとに分け、本番用の設計とプログラミングを反復
ラウンドトリップ	きれいに分割する計画すら難しい	フェーズ間を行き来し、試行錯誤で構築

まとめ：開発モデルは「経営のレンズ」にもなる

動画は最後に、視点を広げます。将来、中小企業診断士として企業の経営戦略を考えるとき、その会社は「後戻りしないウォーターフォール型」の経営をしているのか、それとも「試行錯誤を繰り返すラウンドトリップ型」なのか。ITの用語が、経営戦略を練るための強力なレンズになる、という問いかけです。