そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。
ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少ないだろう。しかし、そこで実践した手法は、組織ごとにカスタマイズされていたり、見よう見まねで実践されたものが多いのではないか。そして、ウォーターフォールを当たり前に利用する組織では、その採用理由について考えることもあまりない。
本稿は、歴史的側面からウォーターフォールの理解を深め、組織が現在採用している開発手法にその学びを活かせるようになることをテーマとしている。
- ソフトウェア危機とボトムアップ・アプローチ
- ボトムアップ・アプローチからトップダウン・アプローチへ
- トップダウン・アプローチを説明するためのウォーターフォールという概念
- 誤った理解に基づくウォーターフォール
- ウォーターフォールの手戻り問題
- 本来想定されていたウォーターフォール（ロイスのソフトウェア開発モデル）
- IEEE/EIA 12207が挙げる3つの開発戦略とウォーターフォールの関係
- 修正版ウォーターフォール
- リレー方式（ウォーターフォール）からサシミ方式（修正版ウォーターフォール）、ラグビー方式へ
- 軽量級プロセス（アジャイル系開発プロセス）と重量級プロセス（ウォーターフォール）
- まとめ
- 参考文献
ソフトウェア危機とボトムアップ・アプローチ
NATOソフトウェア工学会議がドイツのガーミッシュで開催された1968年当時は、「ソフトウェア危機」に瀕した時代だった。拡大を続けるソフトウェアの需要に対し、まだまだ未熟な分野であったソフトウェア開発の生産性が追いつかなかったのだ。「ソフトウェア工学（software engineering）」という用語も、この会議によってようやく広まった時代である3。
ソフトウェア危機は、ソフトウェア開発プロジェクトを進めるうえで、次のような症状として現れる4。
これらを見ると分かるように、残念ながらソフトウェア危機は今なお続いている。現在のソフトウェア業界でも、このようなプロジェクトを見聞きすることなど珍しくもない。
しかし、当時は今より状況が酷かったようだ。ロバート・C・マーチン（Robert C. Martin）は、18歳だった1970年当時を振り返り、ソフトウェア開発の実情を次のように述べている。疲弊していた様子が伝わってくる。
我々はどのようなプロセスを使っていたのだろうか？ ウォーターフォールではなかったことは確実だ。詳細な計画に従うという概念など持っていなかった。毎日のように、ハックして、コンパイルして、テストして、バグを修正していただけだ。構造を持たない無限ループだった。アジャイルでもない。プレ・アジャイルでもなかった。我々の仕事のやり方に規律はなかった。テストスイートもなかった。決められた時間間隔もなかった。毎日のようにコードを書いて修正して、毎月のようにコードを書いて修正していた。
Robert C. Martin (著), 角 征典 (翻訳), 角谷 信太郎 (翻訳), "Clean Agile 基本に立ち戻れ", KADOKAWA, 2020, 第1章 より引用5
1960年代頃はまだ、「ボトムアップ・アプローチ」によるソフトウェア開発が行われていた。当時のその手法の詳細は不明であるが、一般的には、小さな部品をまず設計・実装し、それらを組み合わせて徐々にシステム全体を構築する手法だろう。このやり方だけでは、全体像が最初に見えにくく、後から統合する際に不整合が生じやすい。この言葉は、トーマス・E・ベル（Thomas E. Bell）とT・A・セイヤー（T. A. Thayer）による1976年の論文 "Software requirements: Are they really a problem?" 6に、過去のやり方として登場する。後述するが、この論文は、ウォーターフォールとも関連が深いものだ。
ボトムアップ・アプローチからトップダウン・アプローチへ
それまでのボトムアップ・アプローチよりトップダウン・アプローチの方が優れている、1970年前後の開発現場の多くでそう結論付けられた。ベルとセイヤーによる先述の論文で、そう述べられている。
彼らが「トップダウン・アプローチ」と呼んだソフトウェア開発は、システム全体の要件定義から始め、段階的に詳細化していくものだ。各フェーズの成果物はドキュメントとしてアウトプットされ、次のフェーズのインプットとなる。そうして実装・デバッグフェーズやテストフェーズへと続いていく。ベルとセイヤーは、それをFigure 1として次のような図であらわした。
出典: T. E. Bell, T. A. Thayer, "Software requirements: Are they really a problem?", 1976, Figure 1
フェーズは次のように分けられている。
1. システム要件 2. ソフトウェア要件 3. 予備設計と詳細設計 5. 実装とデバッグ 6. 開発テスト 7. 公式テスト 8. 運用と保守
このアプローチが優れているとされたのは、はじめに全体像を描き、何をどう作るかについて、順を追って明らかにしようとする点だ。それ以前の主流であったボトムアップ・アプローチと違い、これなら不整合を生じさせにくい。理にかなっている、誰もがそう信じられるほどの説得力があった。
トップダウン・アプローチは、ソフトウェア危機への対策となり得た。ボトムアップだけに頼った行き当たりばったりなやり方では駄目だと、皆が気づいたのだ。
トップダウン・アプローチを説明するためのウォーターフォールという概念
トップダウン・アプローチは、開発活動をウォーターフォール（滝）にたとえることでシンプルに説明できる。それを図として示したのが、ウィンストン・W・ロイス（Winston W. Royce）による1970年の論文だった7。それが次の図であり、論文内ではFigure 2として登場する。フェーズの階層を水が落ちていくようにプロジェクトが進んでいくさまが、滝のように見えるのだ。
出典: Winston W. Royce, "Managing the development of large software systems", 1970, Figure 2
ただし、この様子を「ウォーターフォール（waterfall）」にたとえたのは、ベルとセイヤーだ。当のロイスの論文内にその単語は出てこない。彼らが1976年に書かれた先述の論文内で、参考文献として挙げたロイスの論文に対して使われた言葉であった。ロイスの論文の6年後のことである。ベルとセイヤーのFigure 1が、ロイスのFigure 2とそっくりなのはそのためだろう。なお、フェーズ分けは異なっており、ロイス版は次のように並んでいる。
1. システム要件 2. ソフトウェア要件 3. 分析 5. プログラム設計 6. 実装 7. テスト 8. 運用
ウォーターフォールという言葉は、ベルとセイヤーによるこの1976年の論文が初出ではないかとも言われているが8、その真偽は定かではない。マーチンは、それより4年早い1972年頃に、当時の業界誌でウォーターフォールをはじめて目にしたと述べている5。
誤った理解に基づくウォーターフォール
マーチンによれば、当時広まり始めたウォーターフォールモデルは、誤った理解に基づくものだと言う1。ロイスの論文2ページめに現れるFigure 2だけを見て内容を推測した人たちの誤解によるものだと言うのだ。
それは、どのようなモデルとして理解され、ウォーターフォールという言葉と紐づけられて広まったのだろうか。
1996年に出版された書籍『Rapid Development』の中で、マコネルがウォーターフォールの特徴を説明している1。彼はこれを「純粋なウォーターフォール（pure waterfall）」と呼んだ。それを整理して要約すると次のようになる。これが、当時から今もなお続く、一般的なウォーターフォールの理解だろう。ドキュメントを駆使することでプロセスを動かす前提であることがうかがえる。
- 段階的進行: ソフトウェアコンセプトからシステムテストまで、各フェーズを順番に進める
- フェーズ完結型: 現フェーズのすべてのタスクが完了したとみなされるまで、次フェーズに進めない
- ドキュメント駆動: 各フェーズのアウトプットはドキュメントであり、それが次フェーズのインプットとして引き継がれる
- ドキュメントによる進捗管理: ドキュメントが全体の進捗を示す指標として機能する
- 人員が不連続: フェーズごとに担当者が異なり、プロセス全体を通して人員の連続性がない（ドキュメントによってそれを繋いでいる）
なお、ここでのウォーターフォールの流れは、次のようにフェーズが分解されていることが前提とされている。
1. ソフトウェアコンセプト 2. 要求分析 3. アーキテクチャ設計 4. 詳細設計 5. 実装とデバッグ 6. システムテスト
マコネルはまた、ウォーターフォールが適しているプロジェクトについても述べている。それを整理・要約したものが次の内容だ。最後の項目以外は総じて、不確実性が低く、予測可能性が高いプロジェクトに向いているということだろう。
- 要件が安定しているプロジェクト: プロジェクトの初期段階で要件が明確で変わることが少ないのであれば、計画的に進められる
- 既存システムのメンテナンスリリースプロジェクト: 既存システムの改修であれば、不確実性が低く、要件のぬけもれなどによる手戻りが生じにくい
- 別のプラットフォームへの移行プロジェクト: 既存システムを別のプラットフォームに移行する場合、要件が明確であるため、比較的に計画通り進めやすい
- よく理解している技術的方法論を利用するプロジェクト: チームが十分に理解している技術や手法を用いるプロジェクトでは、比較的に精度の高い計画と設計で進められる
- よく理解しているが複雑なプロジェクト: 複雑であっても要件が明確であるなら、その複雑性をフェーズごとに段階的に詳細化して進められる
- 未熟なメンバーがいるプロジェクト: 技術的に弱いスタッフや経験の浅いスタッフがいても、明確なフェーズと手順により、メンバーが作業しやすくなる
- 品質が最優先のプロジェクト: 品質が優先されるのであれば、コストや納期を超過しても、フェーズごとに十分な品質を担保しながら進められる
マーチンは、当時を振り返り、ウォーターフォールをはじめて目にした時に、「天の恵み」だと感じたと言う5。しかし、実践したものの、このようなウォーターフォールはうまくいかなかったようだ。
それでは、ロイスが本来示そうとしたソフトウェア開発モデルとはどういったものだったのだろうか。それについて詳しく見る前に、ロイスも指摘するウォーターフォール的なソフトウェア開発に関する問題点について見てみることにする。
ウォーターフォールの手戻り問題
ウォーターフォールの代表的な問題点の1つは、下流のフェーズから上流のフェーズへの手戻りリスクが大きくなることだ。ウォーターフォールでのそれぞれのフェーズは、先行フェーズのアウトプットをインプットとして進められる。そこに欠陥があれば、原因を作ったフェーズまで差し戻して修正しなければならない。上流でのその修正の影響によって、下流で既に着手したり完了していた作業を台無しにするかもしれないのだ。この問題は、ロイスの論文でも指摘されている。
これは、メタファとされる「滝」とは少々印象が異なる。滝というものは、下段に落ちた水が上段に戻ることがない。しかし、実際のトップダウン・アプローチでのソフトウェア開発では、どうしても上流のフェーズに戻ることがあるのだ。マーチンは、「天の恵み」であるはずのウォーターフォールがうまくいなかった様子を、次のように述べている5。
だが、ウォーターフォールはうまくいかなかった。それから30年間、私と同僚たちは、そして世界中のプログラマーたちは、分析や設計が正しくできるように、何度も何度も何度も試行錯誤を重ねた。だが、どれだけ正しくやったと思っても、実装フェーズになると指の間からこぼれ落ちていく。マネージャーや顧客から厳しい眼差しを向けられるため、何か月もかけて慎重に計画を立ててみるが、それでも大幅に遅れてしまう。
Robert C. Martin (著), 角 征典 (翻訳), 角谷 信太郎 (翻訳),『Clean Agile 基本に立ち戻れ』, KADOKAWA, 2020, 第1章 より引用
「それから30年間」と言うのは、彼がウォーターフォールを知った1972年から数えるとおおよそ2000年頃にあたる。1980年代後半から1990年代初頭にアジャイル改革が始まったが、アジャイルソフトウェア開発宣言が2001年だ9。おそらく、30年間というのは、そこまでの期間を指しているのではないか。
ウォーターフォールの手戻りについて、ロイスの論文内ではFigure 3として、次のような図が描かれている。隣り合うフェーズの間で反復が生じている様子が分かる。いったん次のフェーズに進んでも、そこで気付いた問題によって、前のフェーズで見直しが入ることを示しているのだ。
出典: Winston W. Royce, "Managing the development of large software systems", 1970, Figure 3
この図のように1つ前のフェーズに戻るだけなら理想的だ。影響は最小限にとどまる。
しかし、実際には2つ以上前のフェーズに戻るリスクがあるとロイスは断言している。こうなると話は違ってくる。それが、Figure 4だ。
出典: Winston W. Royce, "Managing the development of large software systems", 1970, Figure 4
これについて、ロイスは次のように述べている。テストによって発見された問題が、設計変更を生じさせ、それが要件の変更にまで遡る可能性を示唆しているのだ。
The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
必要な設計変更は、設計のベースでありすべての根拠となるソフトウェア要件に違反するほど破壊的になる可能性がある。要件の修正か、設計の大幅変更が求められる。事実上、開発プロセスははじめに戻り、スケジュールやコストは100％超過することが予想される。
Winston W. Royce, "Managing the development of large software systems", 1970 より引用（日本語訳は筆者によるもの）
マコネルは、ウォーターフォールにおける手戻りを、「命がけ」での鮭の滝登りにたとえているが1、ロイスの指摘はまさにそれを説明したものだ。
ベルとセイヤーの論文でも、特に要件の間違いを問題視している。初期に定義された要件は、不正確であったり、曖昧、矛盾、欠落することがある。それが、設計や実装の段階になって問題を生じさせるのだ。彼らの調査では、要件には以下のような欠陥のタイプがみられ、いずれのプロジェクトであってもその相対的な発生頻度は似通っていた。特に、4系のRequirement Incorrectや、3系のMissing/Incomplete/Inadequate, 7系のRequirement Unclearが多い。また、設計する段階になって初めて、これらの要件の欠陥を検出することが多かったようだ。
実装を進める前に、完璧な要件や分析、設計を見出すことは難しい。それを実行するのがドメインの専門家であっても、ソフトウェア開発の専門家でもだ。単純な要件項目であっても、実際に動くソフトウェアを見るまでは、気付かないことも多い。膨大な時間をかけて要件をかため、分析し、設計したところで、おそらく状況は大きく変わらない。むしろ、要件や分析、設計が1度で完全になることなどない前提で、プロセスを組み立てた方が現実的なのだろう。
本来想定されていたウォーターフォール（ロイスのソフトウェア開発モデル）
前節の問題に対して、ロイスは論文内で5つの対策を提案している。これが、本来、彼が提示していたソフトウェア開発モデルだ。
- プログラム設計を先に実施する: 分析に先だってプログラム設計者が予備的なプログラム設計を行い、その結果を分析に対する技術的制約として分析者に引き継ぐ
- 設計をドキュメント化する: ソフトウェアの管理は、非常に高度なドキュメントなしには不可能であり、徹底したドキュメント化が重要。それを関係者や顧客とのコミュニケーションの基盤とし、エビデンスとして利用する。納品時は、予備設計に関するドキュメント以外はすべて最新の状態にすること
- 2回実施する（do it twice）: 要件が固まった段階でパイロットプロジェクトを走らせ、初期バージョンのシステムを作って潜在的な問題を洗い出す。顧客に引き渡すシステムは、その結果を反映して開発したバージョンとする
- テストを計画、管理、監視する: 1~3までで品質を十分に確保したうえで、テストの専門家による網羅的で明確な基準を持ったテストを計画・実施し、その進捗を管理する
- 顧客を巻き込む: ソフトウェア設計で何をやるかは事前の合意後も解釈に幅があるため、最終的な納品前の早い段階で顧客がコミットするよう、彼らを巻き込むことが重要である
（1の予備的プログラム設計は3番目のフェーズとして分析フェーズの前に挿入されている / 2のドキュメントは、図中に置かれた本のような図形を指す / 3のパイロットプロジェクトは図の中央上段にある6つのフェーズのことであり、最後のusageフェーズは「試用」や「評価」を指す / 4は特にプログラム設計フェーズとテストフェーズから伸びているテスト仕様書への線付近を指す / 5での顧客の関与は図中の丸い画像でのレビューなど）
出典: Winston W. Royce, "Managing the development of large software systems", 1970, Figure 10
1で分析より先にプログラム設計を実施することで、プロセスが部分的にボトムアップ・アプローチになる。こうすれば、ウォーターフォール（トップダウン・アプローチ）の弱点を補うことができる。
3の「2回実施する（do it twice）」は、フレデリック・P・ブルックス Jr.（Frederick P. Brooks, Jr.）の「一つは捨石にするつもりで（throw one away）」に似たアイデアだ10。最初に完成したシステムは使い物にならないから、先にパイロットシステムを作ってみる。そしてそれを破棄し、再度デザインして問題が解決したバージョンを正規版として提供する。これが、ブルックスの主張だ。考えてみれば、これが書かれた書籍『人月の神話』の初版本の出版が1975年だから、時期的にはロイスの論文と同じ頃のものである。
注意が必要なのは、ロイスの言うパイロットプロジェクトは、要件が固まり、予備的設計が終わったあとに開始される点だ。そこから、技術的な問題点を洗い出して、洗練させることがその主目的であると思われる。そこに割く時間は、本来のプロジェクト期間の4分の1から3分の1程度としている。
5の「顧客を巻き込む」の必要性について、ロイスは次のように述べている。要件や設計は、顧客との間でどれだけ精緻に言語化して事前合意していても、それだけでは不十分なのだ。
For some reason what a software design is going to do is subject to wide interpretation even after previous agreement.
ソフトウェア設計が何をしようとしているかに対しては、事前に合意を得ていても、解釈が大きく分かれることがある。
Winston W. Royce, "Managing the development of large software systems", 1970 より引用（日本語訳は筆者によるもの）
なお、顧客とプロジェクトマネージャーを除くと、ロイスの論文内には少なくとも次の役割が登場する。各フェーズごとに担当者が分かれていることを前提としているということだろう。2でドキュメント化を重視する理由には、フェーズ間での引き継ぎで利用する意図もあるのだ。
- 分析者: 分析フェーズを担当
- プログラム設計者: 予備的プログラム設計とプログラム設計を担当
- プログラマ: 実装を担当
- テスト専門家: テストを担当
- 運用指向の人材: 運用を担当（ただし、優れたドキュメントがないなら、ソフトウェアを構築した人が運用も担当する方がましだとの記述あり）
ロイスの改善案は、あくまでも1970年頃に書かれたものだという点を忘れてはならない。そのまま鵜呑みにせず、当時のソフトウェア開発環境を考慮すべきだろう。当然、ビルド、テスト、デプロイの自動化などの技術はまだ進んでいない。おそらく、テストを実施すること自体にも、計算機リソースを気にする必要もあっただろう。彼が極端にドキュメントに頼っているように感じるのも、そういった背景もあるのではないか。マーチンの書籍にもあるが、コーディング用紙に鉛筆でコードを書き、キーパンチオペレーターがそれをカードにパンチしていた時代である。
IEEE/EIA 12207が挙げる3つの開発戦略とウォーターフォールの関係
1998年に発行されたソフトウェア開発のプロセス標準であるIEEE/EIA 12207の中で、ウォーターフォールという名が正式に登場した11。そこに至るまでの経緯は、次のブログ記事で既に詳しく解説されている。アメリカ国防総省が1985年に発行したDOD-STD-2167や、その後継の2167Aからの変遷がよく分かるだろう。それらの文書がロイスの論文に強く影響を受けていることも感じられる。
IEEE/EIA 12207.2の付録Iの中では、次の3つの開発戦略が比較されている12。プロジェクトの性質に合った開発戦略を選択しようという話だ。
- Once-through: 開発サイクルを一回だけ実施する戦略。ユーザーニーズを把握し、要件を定義した後、設計、実装、テストを行い、修正を加えつつ最終的に納品する
- Incremental: 最初にユーザーニーズとシステム全体の要件を定義した後、開発を段階的に進める戦略。最初の段階で一部の機能を実装し、次の段階でさらに機能を追加していき、最終的に全体を完成させる
- Evolutionary: 初期の不完全なユーザーニーズや要件に基づいて開発を始め、段階的にシステムを洗練させていく戦略。各段階でユーザーニーズや要件を評価・調整しながら、完成形に向かって進化させる
文書内では、開発サイクルを1回だけ実施するonce-through戦略の別名が「ウォーターフォール」モデルだとしている。このことからも、当時のウォーターフォールには、ロイスの開発モデルの特徴の1つである「2回実施する」が含まれていないことが分かる。
「2回実施する」を発展させたものがincremental戦略に見えるかもしれないが、そうではないだろう。ロイスの開発モデルでは、先にプロトタイプを作ることで不確実性を削減し、そこで得た学びと経験によって最終プロダクトをあらためて確実に作るものであった。しかし、incrementalは、完成させるソフトウェアをいくつかに分け、それを段階的に積み上げながら全体を作り上げていくものだ。
evolutionary戦略もincrementalと同様に開発サイクルを任意の回数繰り返すものだが、最初にすべての要件を定義しない点が大きく異なる。さらに、最終的なソフトウェアを完成させるまでのアプローチも違う。incrementalでは開発サイクルを繰り返すことで段階的に機能を追加していく。しかし、evolutionaryではユーザーニーズと要件をより明確にし、ソフトウェアシステムを洗練させていくことに主眼が置かれている。
ところで、スクラムをはじめとするアジャイルソフトウェア開発のフレームワークは、incrementalとevolutionaryの特徴をかけ合わせた戦略とは言えないだろうか。スプリント（イテレーション）をまわしながらソフトウェアを段階的に作りあげる点ではincrementalだ。最初に要件をすべて定義せず、徐々に洗練・進化させていく点ではevolutionaryである。つまり、アジャイルソフトウェア開発は、once-throughであるウォーターフォールと明確に異なる特徴を持つということだろう。
なお、同文書の中では、3つの開発戦略をどのようなケースで利用すべきであるか、その例をリスク項目と機会項目分け、Figure I.2 として示している。
その内容を見ると、once-through戦略、つまりウォーターフォールは、要件が明らかで不確実性が低く、規模が大きすぎず、予算や人員に対する制限が厳しくないプロジェクトに向いているとされている。それはやはり、手戻りリスクを案じてのことではないだろうか。
これだけを見るとウォーターフォールの用途が限定的に見えてしまうが、本当にそうなのか。実際にウォーターフォール開発を実践する現場を見ると、プロジェクトを数回に分けて実施することも多い。「フェーズ・ワン」「フェーズ・ツー」などと呼んで分けるのがそれだ。そうすれば、個々のプロジェクトは小さくなり、扱いやすくなる。また、同付録I内にも、要求分析とシステムアーキテクチャ設計の後に、プロジェクトを複数のサブプロジェクトに分けて開発を進めるアイデアも載せられている。
つまり、開発現場では、プロジェクトが置かれる実情に合わせ、ウォーターフォールに改良が加えられているのだ。次の節では、ウォーターフォールの弱点を改善した修正版ウォーターフォールをいくつか見てみることにする。
修正版ウォーターフォール
マコネルが自著の中で3つの修正版ウォーターフォール（modified waterfalls）について解説している1。これらはウォーターフォールの問題点を補うために発展したものだろう。
それぞれの修正版モデルを見ると分かるが、いずれも現在はそれと知らずに開発手法に取り込まれているものではないだろうか。
Sashimi (Waterfall with Overlapping Phases)
このモデルでは、1つのフェーズが開始すると、それが完了する前に次のフェーズも開始する。2つ以上のフェーズの実施時期がオーバーラップするようにして進行するのだ。これが、サシミと命名された理由である。フェーズが重なり合うさまが、サシミの盛り付けに似ている。富士ゼロックスの新製品開発で用いられた。
たとえば、要求分析フェーズを進めている最中に、次フェーズであるアーキテクチャ設計が開始され、詳細設計も始まっているかもしれない。こうすることで、より詳細なフェーズで気付いた問題点や学びを、並行して進行中の上位フェーズに反映しやすくなる。ウォーターフォールが抱えていた、段階的に詳細化していくことの難しさを考えると、これは合理的なモデルである。
純粋なウォーターフォールモデルでは、フェーズの重複をできる限り避け、段階的に詳細化を進めるので対称的だ。フェーズの完了や、アウトプットであるドキュメントの完成状況で進捗を測ることができなくなるという欠点もあるだろう。
しかし、このモデルでは、そもそも作成すべきドキュメントの数が削減される。ウォーターフォールでのドキュメントの存在意義のひとつは、フェーズ間での仕様や設計の引き継ぎであった。先行フェーズと後続フェーズで担当者が異なることが想定されているからだ。しかし、フェーズをオーバーラップさせてフィードバックサイクルを回すなら、担当者に連続性を持たせる方が合理的だろう。そうすれば引き継ぎの必要すらない。
Waterfall with Subprojects
詳細設計がすべて終わるまですべての実装を待つ必要はない、というのが、このモデルのコンセプトである。アーキテクチャ設計が完了したら、各サブシステムごとに詳細設計からテストまでを並行して進める。そして、最後にすべてをつなぎ合わせてシステムテストを実施するのだ。
このモデルでは、アーキテクチャ設計の時点でサブシステム間の依存関係をうまく整理した上でサブプロジェクトにスピンオフできなければ、プロジェクトが混乱をきたすリスクがあるだろう。
Waterfall with Risk Reduction
要件やアーキテクチャが抱える不確実性に起因するリスクをプロジェクトの最初に低減することが、このモデルの特徴だ。そのため、要求分析より前に、それらを検証するためのスパイラルを配置する。例として、マコネルは次のような活動を通して学びを得ることを挙げている。
- ユーザーインターフェイスのプロトタイプを開発
- システムストーリーボーディングを使用
- ユーザーインタビューを実施
- ユーザーが古いシステムを操作しているところを撮影
リレー方式（ウォーターフォール）からサシミ方式（修正版ウォーターフォール）、ラグビー方式へ
ロイスの論文がウォーターフォールの起源と呼ばれることに対し、竹内弘高と野中郁次郎が書いた1986年の論文は、スクラムの原点と言われる。それが、"The New New Product Development Game" だ。この中で、1970年代から1980年代にかけて、新規プロダクトの開発に新手法を取り入れた日本およびアメリカの企業6社の開発プロセスを分析している。
竹内と野中は、開発プロセスを従来の「リレー方式」と、新たな手法とする「サシミ方式」「ラグビー方式」の3つに分類した。リレー方式は、ウォーターフォールのようにフェーズからフェーズと順番に進む「昔ながらの逐次型」とされている。サシミ方式は修正版ウォーターフォールでも挙げた富士ゼロックスが用いたモデルだ。ラグビー方式も、サシミ方式と同様にフェーズをオーバーラップさせながら進めるもので、本田技研工業やキャノンに見られるモデルである。
ラグビー方式がサシミ方式と区別されているのは、前者のオーバーラップの多重度が後者より高いからだ。それは、リレー方式と比較する形で次のように述べられ、素早く柔軟に新規プロダクトを開発したい企業にとって「絶対に必要である」とされている。
一方、ラグビー方式だと、各部門から選び出されたメンバーが最初から最後まで一つのチームを構成し、製品開発プロセスは、こうしたチームの絶え間ない相互作用から生まれてくる。そのプロセスは、きちんと境界線のある高度に構造化された段階を進んでいくのではなく、チームメンバー同士の相互作用から生じるのだ。
リレー方式を用いるリスクは、競争の激しい市場の中で抜きん出るための「スピードと柔軟性」という目標と相容れないおそれがあることとされる。専門化された個々のフェーズで分業体制を取り、段階的に進めるより、一体型のラグビー方式の方が激しい競争環境により対応しやすいからだ。たとえば、リレー方式では、1つのフェーズで遅れが生じると、それが後続プロセスすべてに波及するリスクもある。しかし、ラグビー方式なら、1つのフェーズが遅れても、オーバーラップする他のフェーズも何とか進めていくことができる。
さらに、竹内と野中は、最先端企業の新規プロダクト開発プロセスには、フェーズのオーバーラップも含め、次の6つの特徴が見られると言う14。
- 内在する不確定性: 経営陣が示すのは戦略的方向性と極めて難易度の高い目標であり、何をどうやるのかは開発担当チームに任せる
- 自己組織化する開発担当チーム: 情報ゼロの状況から、開発プロセスが独自の動的秩序を形成し、チームが次第にスタートアップのような動きになる。そして自律性、自己超越、異種共創という特徴を持つに至る
- 開発フェーズのオーバーラップ: 開発プロセスの各フェーズを重複して進める、分業という昔ながらの概念を捨てた方式。チームメンバーが開発プロセスのあらゆる側面に責任感を持つ
- 多重学習: 幅広い知識と多様なスキルを獲得するために、社内の各階層（個人、グループ、会社）を超えた学びと、専門を超えた学びの2つの次元で学びが生じる
- さりげない管理: 自己管理とピアプレッシャーによる管理、愛による管理の3つでチームを管理する
- 学びの組織的な伝達: プロジェクトを通して得た学びや、成功事例から得られた教訓を、次のプロジェクトに活かせるよう伝達する。また、過去の成功事例に囚われすぎないよう、アンラーニングにも努める
これら6つの特徴を見ると、そこにアジャイルやDevOpsに通じるものがある。また、分業制のウォーターフォールとは違い、開発プロセス全体を、1つの「チーム」という単位で活動することが強調されている点も興味深い。ここが、フェーズのオーバーラップがもたらすものなのだろう。
チーム立ち上げ時点では「情報ゼロ」状態だが、そのうち市場に関する知識や技術者界隈の知識をメンバー間で共有するようになる。こうしてチーム全体が一つの単位として動き始める。同時に、個々のメンバーとチーム全体とが不可分になる。個人のリズムとチーム全体のリズムが重なり始め、まったく新しい鼓動が生まれる。この鼓動が推進力となり、チームを前進させる。
なお、この論文とスクラムの関係については、野中自身が登壇した下記イベントで述べられている。
軽量級プロセス（アジャイル系開発プロセス）と重量級プロセス（ウォーターフォール）
アジャイルソフトウェア開発宣言が公開されたのは、2001年だ。同年2月にユタ州スノーバードに集まった17名のソフトウェアの専門家によって原案が作成された。そこには、ロバート・C・マーチンも名を連ねている。また、スクラムの生みの親であるケン・シュウェイバー（Ken Schwaber）とジェフ・サザーランド（Jeff Sutherland）もだ。9
このスノーバードでの会合は、「軽量級プロセスのサミット（Light Weight Process Sumit）」と名付けられた点が興味深い。軽量級プロセスとはもちろん、アジャイルソフトウェア開発を指す。では重量級プロセスはと言うと、ウォーターフォールがその代表であった。アジャイル以前に主流であった、事前計画型でプロセス重視なやり方でのプロジェクト失敗の経験を積み重ねた人々が、軽量級プロセスに惹きつけられていったのだろう。5
宣言の冒頭は次のとおりだ。重量級プロセスと軽量級プロセスを比較するような形で、4つの中核価値が表現されている。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
引用: 『アジャイルソフトウェア開発宣言 - agilemanifesto.org』, https://agilemanifesto.org/iso/ja/manifesto.html （引用内の強調は筆者によるもの）
前節までで、"純粋な" ウォーターフォールは、作り上げるソフトウェアシステムがプロジェクトの初期段階で明らかにできる場合に適していることが分かった。計画通りに作り上げれば、それが誰かに価値になるということだ。そして、計画通りに作るためには、プロジェクトの初期段階から不確実性が低いことが条件となる。この条件が成立しないままウォーターフォールで進めると、計画通りにプロジェクトが進まないか、作り上げたソフトウェアシステムが誰の価値にもならないかのいずれかなのだ。
アジャイルソフトウェア開発では逆に、不確実性が高く、計画通りに進めても、作り上げたソフトウェアシステムが誰かの価値にならないかもしれないことを前提としている。ここに、純粋なウォーターフォールとアジャイルソフトウェア開発が目指すものに対する違いが読み取れる。その違いこそが、両者の開発プロセスに大きな違いを生んでいるのだ。
アジャイル側の視点にたって、両者を比較してみよう。
ウォーターフォールでは、顧客が実際にソフトウェアに触れられるのがプロジェクトの最後だ。ドキュメントであればプロジェクトの途中段階で確認できるものの、それは中間成果物でしかない。それだけでは価値とは言えず、最終成果物たるソフトウェアを待っている。顧客にとっては、待たされる間、ずっと不安だろう。本当にソフトウェアシステムができあがるのか、それが想定通りのものになっているのか分からないからだ。
アジャイルソフトウェア開発は、動くソフトウェアを重視する。スクラムを実践するプロジェクトであれば、プロジェクトの途中であっても、スプリントの度に、顧客は動くソフトウェアを目にできる。それを実際に触ってみることで、本当に価値のあるものになっているかどうかを見極められる。想定通りになっていなかったり、想定通りであってもそれが間違っていたと気付いたなら、その修正を以降の計画に組み込むことも可能だ。
プロジェクト途中でのそのような計画変更は、ウォーターフォールなら死活問題となる。たとえば要件が変わってしまったら、最上流の要件定義からやり直しとなるからだ。その変更が、要件定義より下流に影響する。そうなれば、変更前に作り上げた成果物は台無しになる。そして、想定していたコストや期日までにプロジェクトが終わらなくなってしまう。だから、できる限り変化を受け入れたくないという心理が働く。
アジャイルであれば変化を受け入れる。計画通りにプロジェクトが終わらなくなる点はウォーターフォールと変わらない。では、なぜ変化を受け入れるのか。その理由は2つあるのではないか。1つは、プロジェクト初期段階ですべての要件を決めきらないこと。それが、変化を柔軟に受け入れやすい素地となる。もう1つは、計画通りに作りあげることが価値になると考えないこと。変化することが価値になるのであれば、計画を変えることもいとわない。
変化を受け入れるという点で障壁となるのが顧客との契約だろう。変化によって、予算、期日、要件のいずれかが、契約違反となるかもしれない。これが、受託開発業務においてアジャイルソフトウェア開発手法を導入しにくい理由ではないだろうか。顧客と協調し、プロジェクトを進めながら繰り返し計画を見直すアジャイルなアプローチは、従来型の契約では実践が困難なのだ。
まとめ
ウォーターフォールモデルは、1960年代頃のボトムアップ・アプローチに代わって用いられたトップダウン・アプローチであった。トップダウン・アプローチを説明する簡易な図が滝に見えることで、そこから連想される一方向に進む開発モデルとして、世の中に広く知れ渡ることとなる。
ロイスが本来伝えようとした開発プロセスモデルは、手戻りリスクを最小化しようとするものだ。はじめにすべての要件を決定し、そこから段階的に詳細化していく進め方は、手戻りが生じやすい。それは特に、要件定義に関する問題が顕著であり、下流のフェーズで不正確であったり、曖昧、矛盾、欠落が見つけられることが多い。これが、ウォーターフォールと呼ばれるモデルが抱える代表的な問題点である。
IEEE/EIA 12207での開発戦略の比較では、不確実性が高いプロジェクトには、once-through戦略、すなわちウォーターフォールモデルが不向きであるとしている。それは、上述の通り、手戻りリスクが大きくなるからだろう。
また、竹内と野中は、ウォーターフォールのように各フェーズをリレー方式で繋ぐ開発プロセスよりも、フェーズをオーバーラップさせるサシミ方式やラグビー方式のほうが、スピードと柔軟性に優れていると述べている。これは、ウォーターフォールとは対照的に、オーバーラップ方式が不確実性の高いプロジェクトに適していることを示している。それは、彼らの論文を原点とするスクラムにも言え、アジャイルソフトウェア開発全般にも当てはまる考え方だろう。
ここで思い出すのは、クネビンフレームワークだ。ウォーターフォールは「煩雑（complicated）」な領域で役立ち、アジャイルソフトウェア開発は「複雑（complex）」な領域で役立つ。前者は事前分析によって正しい答えが導きだせる領域である。後者は、探索的なアプローチがなければ何が正しいか不明な領域だ。
ウォーターフォールが対象とするプロジェクトは、計画通りにソフトウェアシステムを作り上げれば、それが誰かの価値になる場合ということになる。逆に、アジャイルソフトウェア開発が対象とするのは、計画通りに作り上げても、それが誰の価値にもならないかもしれないことを前提としている。ここが大きく違うのだ。
しかし、純粋なウォーターフォールを諦めてアジャイルソフトウェア開発のプロセスフレームワークが作り上げられていったように、ウォーターフォールも工夫を重ねて使いこなされている。実際、私もこれまで、様々な領域で、ウォーターフォールを使って成功したプロジェクトをみてきた。それらはいずれも、純粋なウォーターフォールではなく、マコネルが紹介した修正版ウォーターフォールに近いものだった。
プロジェクトの性質によって開発プロセスを使い分けるべきとは言うが、それはなかなかに難しい。同じ組織が、複数の開発プロセスを起用に使い分け、使いこなすことなど本当に可能なのだろうか。1つの開発プロセスでさえ、なじませ、改善を重ねることに苦労する。結局のところ、なにか1つに定めて、それを組織の目的に合わせて調整し、改良し続けるのが一番なのではないだろうか。
参考文献
- Steve McConnell (著), "Rapid Development", 日経BP, 1996, Chapter 7↩↩↩↩↩
- SDLC とは: ソフトウェア開発ライフ サイクルの概要 - GitHub Resources↩
- NATO Software Engineering Conference 1968 - The NATO Software Engineering Conferences↩
- Software crisis - Wikipedia↩
- Robert C. Martin (著), 角 征典 (翻訳), 角谷 信太郎 (翻訳),"Clean Agile 基本に立ち戻れ", KADOKAWA, 2020, 第1章↩↩↩↩↩
- T. E. Bell, T. A. Thayer, "Software requirements: Are they really a problem?", 1976↩
- Winston W. Royce, "Managing the development of large software systems", 1970↩
- 小椋 俊秀, "ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤解を解く", 2013↩
- アジャイルソフトウェア開発宣言↩↩
- Jr FrederickP.Brooks (著), Frederick P. Brooks,Jr. (原名), 滝沢 徹 (翻訳), 牧野 祐子 (翻訳), 富澤 昇 (翻訳), "人月の神話【新装版】", 丸善出版, 2010, 第11章↩
- IEEE, "12207.0-1996 - IEEE/EIA Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations", 1998↩
- IEEE, "12207.2-1997 - IEEE/EIA Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations", 1998↩
- Hirotaka Takeuchi, Ikujiro Nonaka, "The New New Product Development Game", 1986
- 竹内 弘高 (著), 野中 郁次郎 (著), DIAMONDハーバード・ビジネス・レビュー編集部 (編集), "新たなる新製品開発の方法（DIAMOND ハーバード・ビジネス・レビュー論文）", ダイヤモンド社, 2023↩
