── その本質と誤解を超えた進化の系譜を探る　

第 1 部　ウォーターフォールとアジャイルの基礎

📖 第 1 章　イントロダクション

1.1 本書の目的

本書の目的は、「ウォーターフォールとアジャイルを正しく理解し、適切に使い分ける」ことにあります。

ソフトウェア開発の世界では、長らく「ウォーターフォール＝古い」「アジャイル＝新しい」といった単純な二項対立のイメージが語られてきました。 しかし、現実のプロジェクトに携わったことがある方なら、そんなに単純な話ではないことを知っているはずです。

ウォーターフォールにはウォーターフォールの強みがあり、アジャイルにはアジャイルの強みがあります。 本書では、その両方を歴史的背景、思想、実践的な違いから紐解き、読者が自分の現場に合わせて最適なプロセスを選べるようになることを目指します。

---

1.2 よくある誤解

ウォーターフォールとアジャイルを語るとき、よく聞かれるのは次のような言葉です。

• 「ウォーターフォールは失敗する」
• 「アジャイルならすべてうまくいく」
• 「ウォーターフォールは古い方法論」
• 「アジャイルこそ最新のベストプラクティス」

これらは、いずれも半分正しく、半分間違っていると言えます。 ウォーターフォールが「必ず失敗する」わけではなく、アジャイルが「魔法の杖」でもありません。 むしろ、誤解されたイメージによって、どちらのプロセスも本来の価値が見えにくくなっているのです。

---

1.3 読者への問いかけ

ここで読者の皆さんに問いかけたいのは、次の点です。

• あなたの現場では、本当に「ウォーターフォール＝悪、アジャイル＝善」と考えていませんか？
• 過去にウォーターフォールを経験し、「もう古い」と感じていませんか？
• あるいは、アジャイルを導入したものの、期待した効果が得られず困っていませんか？

本書は、このような問いに対する答えを一緒に探していく旅でもあります。 ウォーターフォールとアジャイルは決して敵対する概念ではなく、異なる思想と前提に立脚したプロセスです。 その違いを理解したうえで、現場ごとに最適な使い分けを見つけることができれば、私たちはより成功しやすいプロジェクトを作り出せるようになります。

---

1.4 本書の進め方

本書は大きく 2 部構成になっています。

• 第 1 部（第 2 章〜第 7 章）では、ウォーターフォールとアジャイルの基本的な考え方や実際の違いを整理します。 ここでは、両者を対比しながら「それぞれがどのような前提に基づき、どんな現場に適しているのか」を明らかにします。
• 第 2 部（第 8 章〜第 12 章）では、ウォーターフォールからアジャイルに至る「歴史と系譜」をたどります。 ロイスの論文、RUP、AUP といった過去のプロセスを振り返りながら、「アジャイルがどのように進化してきたのか」を解説します。

そして最後のまとめで、読者が自分の現場に適用できる「問い」を提示します。

---

✅ 第 1 章まとめ

• 本書は「ウォーターフォールとアジャイルを正しく理解し、使い分ける」ための本
• 「ウォーターフォール＝悪、アジャイル＝善」という誤解を問い直す
• 読者自身の現場に合わせた最適な判断を導くことを目指す

📖 第 2 章　ウォーターフォール開発とは何か

2.1 ウォーターフォールの定義と基本的な流れ

ウォーターフォール開発は、その名の通り「滝（Waterfall）」のように、工程が上から下へと一方向に流れていくプロセスモデルです。 典型的には、以下のような流れで進められます。

1. 要件定義：システムが満たすべき要求を明確化する
2. 設計：要求をもとにシステム全体の構造を設計する
3. 実装：設計に基づきプログラムを作成する
4. テスト：実装したプログラムを検証する
5. リリース：完成したシステムを納品・運用開始する

工程ごとに「完了」を確認して次へ進むため、**前工程の成果物（仕様書・設計書など）**がプロジェクトの基盤となります。

---

2.2 「滝の比喩」の意味と限界

「ウォーターフォール」という呼び名は、工程が滝の水のように下流へ流れていく様子を比喩しています。 一度流れ落ちた水が上に戻れないように、前工程に戻らないことが暗黙の前提として語られることが多くあります。

ただし、これはあくまで「比喩」であり、本来のウォーターフォールが“絶対に戻れない”ことを意味しているわけではありません。 後ほど触れるように、1970 年にウォーターフォールを提唱したロイスはむしろ「戻れるプロセス」の重要性を指摘していました。

この「戻れない」という誤解が、後年「ウォーターフォール＝硬直的で失敗する」というイメージを強めることになります。

---

2.3 歴史的背景：ロイスの論文

ウォーターフォールという言葉が広まるきっかけは、1970 年に米国のコンピュータ科学者 ウィンストン・W・ロイス（Winston W. Royce） が発表した論文 **「Managing the Development of Large Software Systems」**です。

この論文でロイスは、当時急速に大型化していたソフトウェア開発の現状を分析し、 「工程を分けて進めること」の利点と限界を示しました。

有名な「ウォーターフォールの図」は、この論文に登場します。 ただし、重要なのは その図は「失敗するやり方の例」として提示されたものだった、という点です。 ロイス自身は、むしろ 「プロトタイピング」や「工程間の反復（戻り）」 を強調していました。

---

2.4 ウォーターフォールのメリット

それでもウォーターフォールが長年にわたり採用されてきたのは、次のようなメリットがあるからです。

2.4.1 計画性と管理しやすさ

工程が明確に区切られているため、プロジェクト計画を立てやすく、進捗管理もしやすい。 大規模組織での「見える化」に向いています。

2.4.2 大規模案件での強み

数百人規模の開発チームでも役割分担がしやすく、 「要件担当」「設計担当」「実装担当」といった専門分業を実現できます。

2.4.3 再現性のあるプロジェクトに強い

同じような要件で繰り返し作られるシステム（例：会計システム、基幹業務システム）では、 過去の成功パターンを流用でき、効率的に開発できます。

---

2.5 ウォーターフォールが生まれた時代背景

1970 年代当時、ソフトウェアは「巨大化」と「複雑化」が進んでいました。 航空宇宙産業や防衛産業、金融システムなどでは、数百人規模のチームで数年かけて開発するケースが一般的でした。

その中で、「ドキュメントを重視し、計画的に進める」ウォーターフォール型の手法は、 当時の企業や政府機関にとって非常に理にかなったアプローチだったのです。

---

✅ 第 2 章まとめ

• ウォーターフォールは「滝のように工程を流すモデル」
• ロイスの論文が出発点だが、本来は「戻れるプロセス」も重視していた
• メリットは「計画性」「大規模案件での強み」「再現性のある開発への適性」
• 誕生の背景は 1970 年代の大規模・複雑化したシステム開発

📖 第 3 章　アジャイル開発とは何か

---

3.1 アジャイル開発の定義

アジャイル（Agile）とは「俊敏」「すばやい」という意味を持ちます。 ソフトウェア開発におけるアジャイルは、変化に素早く対応するための開発アプローチを指します。

従来のウォーターフォールが「計画を立て、それを守る」ことを重視するのに対し、 アジャイルは「不確実な状況の中で、試しながら学び、適応していく」ことを重視します。

---

3.2 アジャイル宣言と 4 つの価値

2001 年に米国ユタ州スノーバードに 17 人の実践者が集まり、「アジャイルソフトウェア開発宣言（Agile Manifesto）」が発表されました。 そこでは次の4 つの価値が掲げられています。

1. プロセスやツールよりも、個人と対話を
2. 包括的なドキュメントよりも、動くソフトウェアを
3. 契約交渉よりも、顧客との協調を
4. 計画に従うことよりも、変化への対応を

この価値観の下、チームは顧客やユーザーと協力しながら、短いサイクルでソフトウェアを進化させていきます。

---

3.3 アジャイルの基本的な思想

アジャイルは次のような考え方に基づいています。

• 完璧に決めない：最初にすべての要件を決めるのではなく、必要なところから始める
• フィードバックを早く得る：実際に動くものを出して、ユーザーや顧客から反応を得る
• チームで学びながら進める：進めながら改善するプロセスを組み込む

つまり、「正解が最初から分からない」状況で前進する方法なのです。

---

3.4 アジャイルの強み

3.4.1 不確実性への適応

市場やユーザーのニーズは変わりやすい。 アジャイルは小さなサイクルで成果物を出すため、変化に素早く追従できます。

3.4.2 顧客との協働

顧客を「外部の要求者」ではなく「共に作る仲間」と捉え、 開発プロセスに積極的に参加してもらうことで、成果物のズレを減らします。

3.4.3 小さく・早く届けるメリット

リリースまで半年や 1 年待たされるのではなく、数週間ごとに価値を届けることが可能です。 これにより、顧客は早期に効果を得られ、チームは改善のためのフィードバックをすぐに取り込めます。

---

3.5 アジャイルの方法論の例

アジャイルは一つの方法論ではなく、思想に基づいたさまざまな実践手法があります。代表的なものは以下です。

• スクラム：役割とイベントを定義し、チームの自己組織化を促進する
• XP（エクストリーム・プログラミング）：テスト駆動開発やペアプログラミングを重視
• カンバン：作業の流れを「見える化」し、継続的改善を行う

いずれも「小さく作って、早くフィードバックを得る」という思想を共有しています。

---

✅ 第 3 章まとめ

• アジャイルは「俊敏に変化へ対応する開発アプローチ」
• 2001 年のアジャイル宣言が基盤となっている
• 核心は「完璧を目指すより、素早く動いて学ぶ」思想
• 強みは 不確実性への適応・顧客との協働・小さく早い価値提供
• スクラム・XP・カンバンなど、多様な実践手法がある

第 4 章　ウォーターフォールとアジャイルの比較

---

4.1 比較の観点

ウォーターフォールとアジャイルは、単に「古い手法 vs 新しい手法」ではなく、 前提となる思想や環境への適応の仕方が異なる手法です。 ここでは以下の観点で比較します。

• 開発の進め方
• 要件の扱い方
• フィードバックの得方
• 顧客の関与の度合い
• リスク対応のタイミング

---

4.2 比較表

観点	ウォーターフォール	アジャイル
開発の進め方	一方向に流れる工程（要件 → 設計 → 実装 → テスト → リリース）	短いサイクルを繰り返し、都度リリース可能な成果を積み上げる
要件の扱い	初期に詳細まで確定し、固定化	必要最低限を決め、実際の利用を見ながら更新
フィードバック	テスト工程の後半で得られる	毎イテレーションごとに得られる
顧客の関与	要件定義の初期に集中	開発の全期間を通じて参加
リスク対応	問題は後半で顕在化しやすい	小さなリスクを前倒しで検出して対応

---

4.3 問題が顕在化するタイミングの違い

• ウォーターフォールの場合 ある企業が基幹システムをウォーターフォールで刷新。半年かけて要件定義を固め、さらに半年で設計と実装を終えた後、テスト工程に入って初めて「顧客の想定と違う操作性」「処理速度が現場に合わない」といった問題が露見。 → 修正は大規模な手戻りとなり、コスト・スケジュールは大幅に膨らむ。
• アジャイルの場合 同じ案件をアジャイルで進めた場合、1〜2 週間ごとに顧客へ動く画面を提示。 「検索結果の並び順が使いにくい」といった指摘が早期に出て、次のイテレーションで修正可能。 → 問題を小さな段階で顕在化させ、修正コストを最小化できる。

まとめると： ウォーターフォールは「後半で一気に問題が出る」傾向、 アジャイルは「前半から小さな問題を解消できる」仕組みになっています。

---

4.4 建築の比喩

• ウォーターフォールは「高層マンション建設」に近い。 設計が完成してからでないと工事に入れないし、後から間取りを変えることは難しい。
• アジャイルは「自分の家を DIY でつくる」ようなもの。 まずは住める最低限の部屋をつくり、住みながら使いやすさを見て改修を繰り返す。

---

4.5 不確実性マトリクス（プロジェクト適性の整理）

プロジェクトの「要件の明確さ」と「環境変化の大きさ」で適した手法を分類できます。

要件の明確さ	変化の大きさ	適した手法	具体例
明確	小さい	ウォーターフォール	銀行の会計処理システム、航空管制システム
明確	大きい	段階的ウォーターフォール＋レビュー強化	法改正対応の年金管理システム
曖昧	小さい	反復型開発 / プロトタイピング	パッケージソフトの UI 設計
曖昧	大きい	アジャイル	新規 Web サービス、スタートアップのアプリ

• 左上（明確 × 小さい）：ウォーターフォールで効率的に完成できる。
• 右下（曖昧 × 大きい）：アジャイルでなければ対応不能。
• その他の領域：ハイブリッドや段階的適用で柔軟に対応。

---

4.6 小括

ウォーターフォールとアジャイルは単純な「良し悪し」ではなく、 どの領域で効果を発揮するかが違う手法です。

• 確定した要件に基づく大規模・安定型 → ウォーターフォール
• 変化の大きい環境での探索型開発 → アジャイル

重要なのは「自分のプロジェクトはどの象限に位置しているのか」を冷静に見極めることです。

5.1 ウォーターフォールのアンチパターン

ウォーターフォールは、計画を立てて順序通りに進めることで、大規模で複雑なプロジェクトを管理しやすくする方法です。 しかし現実には、理想どおりに進むことは少なく、多くの現場で「アンチパターン」と呼ばれる失敗例が繰り返されています。 ここでは代表的なものを紹介し、その背景と問題点を考えていきましょう。

---

見積もり外れ

ウォーターフォールでは、最初に出した見積もりがプロジェクトの枠組みを決定します。 契約金額、期間、体制などが見積もりを基準に組み立てられるため、初期見積もりの誤差がそのまま全体のリスクとなります。

典型的な現場では、顧客もベンダーも要件を完全には理解していない段階で、納期やコストを「確定的」に提示しなければなりません。 実際に開発が始まると、想定外の仕様や技術的な難しさが表面化し、見積もりは簡単に崩れてしまいます。 結果として「赤字覚悟で納品する」か「顧客と交渉して関係が悪化する」かの二択に追い込まれるのです。

---

要件変更への弱さ

ビジネスの環境は常に変化しています。法改正、競合の新機能、経営方針の転換など、プロジェクト中の要件変更は必然です。

ところがウォーターフォールは、要件を固定してから進める手法であるため、変更を受け入れるのが非常に苦手です。 変更は追加契約や納期調整を伴うため、現場は「変更を嫌がる文化」に染まりがちです。 その結果、ユーザーのニーズと乖離したシステムが完成し、導入後に利用されない、という悲劇を招きます。

---

認識ズレ（顧客と開発のギャップ）

ウォーターフォールでは、要件定義書や設計書といった文書を通じて顧客と合意を取ります。 しかし、同じ文章を読んでいても、顧客と開発者が思い描くシステム像はしばしば異なるのです。

例えば、顧客は「ワンクリックで処理できる」と想像していたのに、完成したシステムでは「3 画面を遷移して入力が必要」だった。 顧客から見れば「約束と違う」、開発側からすれば「仕様通りに作った」となり、双方が不満を抱えることになります。 文書による合意は重要ですが、イメージをすり合わせる仕組みが弱いのがウォーターフォールの盲点です。

---

テストの遅れと大量のバグ

ウォーターフォールでは、テスト工程が最後にまとめて行われます。 数ヶ月、あるいは数年分の成果物を一気に検証するため、重大な問題が「最後になってから」噴出します。

実際の現場では、システムテストに入った直後に「基本機能が動かない」ことが発覚することも珍しくありません。 テスト中に 100 件以上の重大バグが報告され、修正と再テストの繰り返しで納期は崩壊寸前。 最悪の場合、テスト項目を削減して強行リリースされ、リリース後に障害が多発することもあります。

---

マネジメントと現場の乖離

ウォーターフォール型プロジェクトでは、進捗は「設計書の完成率」や「コード量」といった数値で管理されることが多いです。 これにより、上層部は「進捗率 80％」と聞いて安心しますが、現場では品質も顧客満足も不透明なままという状況が起こります。

たとえば、設計書が完成していても、それがユーザーにとって価値のある機能につながるかは保証されません。 このように、形式的な進捗と実際の価値の間に乖離が生じ、最終段階で大きなギャップとして噴出するのです。

---

計画重視の罠

これらのアンチパターンに共通する根本要因は、「最初に決めた計画を最後まで守ろうとする」構造です。 計画自体が誤っていても、途中で修正する仕組みが弱いため、ズレが積み重なり、最後に一気に崩壊します。

ウォーターフォールそのものは「悪」ではありません。 ただし、現場では「文書主義」「変更を嫌う文化」「計画優先のマネジメント」といった運用が重なり、アンチパターンを生みやすいのです。

---

👉 以上が、現場で繰り返し見られるウォーターフォールのアンチパターンです。 次の節では、このような問題がアジャイルではどのように現れるのか、そして何が違うのかを見ていきます。

5.2 アジャイルにおける落とし穴

アジャイルは「変化に強い」「早く価値を届けられる」という点で、多くの現場に導入されています。 しかし、アジャイルを導入すればすべてが解決するわけではありません。 実際の現場では、アジャイル特有の失敗パターンも数多く報告されています。

ここでは、代表的なアンチパターンを紹介し、なぜ起こるのかを考えていきます。

---

「なんちゃってアジャイル」

最もよくある失敗は、アジャイルの形だけを真似て中身が伴わないケースです。 毎日スタンドアップミーティングを行い、ボードに付箋を貼り、スプリントレビューをやっている。 しかし実際には「顧客への価値提供」や「フィードバックによる学習」が全く行われていない。

これは、ウォーターフォール的な文化を持つ組織が「ラベルだけ」変えた場合によく起こります。 結果として「前より儀式が増えて面倒になっただけ」とメンバーが感じ、チームの士気が下がります。

---

フィードバック不足

アジャイルの強みは、短いサイクルで成果を出し、ユーザーや顧客からのフィードバックを取り込める点にあります。 ところが、実際には「レビューの場に顧客が来ない」「ステークホルダーが参加しない」というケースが少なくありません。

成果物を見せても誰もコメントせず、「まあいいんじゃない？」で終わる。 こうした状態では、改善のための学習サイクルが回らず、結局はウォーターフォールと同じになってしまいます。

---

タスク分割の誤り

アジャイルでは「動くソフトウェアを小さく作る」ことが基本です。 しかし、現場では「作業単位でタスクを割る」ケースが多く見られます。

例：

• フロントエンド設計 → フロント実装 → API 設計 → API 実装 → DB 設計 → DB 実装

これは一見効率的に見えますが、スプリントが終わっても「ユーザーにとって価値のある機能」が完成しません。 レビュー時に「画面だけできている」「裏側だけできている」となり、顧客は何も確認できないのです。 結果として、完成まで数スプリントかかり、フィードバックが遅れるという本末転倒が起こります。

---

チームの疲弊とバーンダウンの誤用

アジャイルでは、進捗をバーンダウンチャートで可視化することが多いです。 ところが、マネジメントがこれを「監視ツール」として使い、進捗遅延を詰める材料にしてしまうことがあります。

「あと 3 日でバーンダウンしきれないじゃないか！」と叱責されれば、チームはタスクを細かく分割して数字を合わせに行きます。 しかしそれは、ユーザーにとっての価値には結びつきません。 アジャイルが「管理ツール」に変質した瞬間、現場はウォーターフォール以上に疲弊していきます。

---

スプリントレビューが形骸化する

アジャイルでは、スプリントごとに成果をデモし、関係者と学びを共有します。 ところが現実には「デモ資料をパワーポイントで作り、レビュー会は一方的な報告会」になっているケースも少なくありません。

これはウォーターフォールの「進捗会議」と本質的に変わりません。 成果物を触れる形で見せること、そこから議論を引き出すことが欠けると、アジャイルの意味は失われます。

---

まとめ：アジャイルにも罠はある

ウォーターフォールと同様、アジャイルにもアンチパターンがあります。

• 「形だけ導入して形骸化」
• 「フィードバックが得られない」
• 「価値単位でなく作業単位で区切る」
• 「進捗管理ツールに堕する」

これらはすべて、アジャイルの思想を正しく理解していないことから生じています。 大事なのは、儀式やツールを導入することではなく、顧客価値を中心に学習を繰り返す文化を育むことです。

---

👉 ここまでで、ウォーターフォールとアジャイルそれぞれの「落とし穴」を見てきました。 次節では、両者に共通する罠――「ハイブリッド型の幻想」について取り上げます。

5.3 ハイブリッド型の幻想と現実

ウォーターフォールとアジャイルにはそれぞれの強みがあります。 すると現場ではよく、 「上流はウォーターフォールでしっかり固め、下流はアジャイルで柔軟に進めれば最強では？」 という発想が出てきます。

これは一見すると合理的に思えますが、実際には多くのプロジェクトで失敗してきた“幻想”でもあります。

---

「上流ウォーターフォール＋下流アジャイル」の典型例

典型的なハイブリッドの姿はこうです。

1. 要件定義は従来どおり詳細に文書化し、契約書に落とし込む。
2. 設計もある程度まで確定させる。
3. 実装・テストの段階に入ったらスプリントを回し、アジャイル的に進める。

この方式は、特に大企業や官公庁システムで「アジャイル導入」と称して取り入れられることが多いです。

しかし現場でよく起こるのは、**「要件変更への柔軟性が全く担保されていない」**という矛盾です。

---

失敗する理由 1：前提思想の衝突

ウォーターフォールの思想は「正解がある前提で進める」ことです。 アジャイルの思想は「正解は分からない前提で進める」ことです。

両者は真逆です。 上流で「正解を決め切る」アプローチを取った時点で、下流で「学習しながら調整する」余地は失われます。 結局、アジャイルの場で見つかったフィードバックは「仕様変更」として扱われ、契約や予算の壁に突き当たるのです。

---

失敗する理由 2：無駄の増幅

ウォーターフォールは「すべて作る」ことを前提にします。 顧客が本当に使うかどうかに関わらず、最初に決めた要件は全部作り切る。 結果として、誰も使わない機能や余分な仕様が大量に生まれます。

一方、アジャイルは「やらないことを見つける」ことに価値を置きます。 スプリントごとのレビューで「これは不要だ」と判断できれば、その時点で開発をやめられる。 だからこそ、本当に価値のある部分だけに集中できるのです。

ハイブリッド型はこの思想を両立できません。 上流で「全部作る」と決めてしまった時点で、下流で「やらない」という選択肢は消えてしまうからです。

---

失敗する理由 3：顧客との関与が分断される

アジャイルでは顧客やユーザーとの対話が必須ですが、上流をウォーターフォールにすると、顧客の関与は「要件定義の最初だけ」になります。 その後、アジャイル開発のスプリントレビューに顧客が出ても、 「もう要件は決まっているはずだよね？」 という空気が流れ、意見を出しにくくなります。

結果として、レビューは単なる確認作業に陥り、アジャイルの強みが失われます。

---

現実的なアプローチ：混ぜるのではなく「切り分ける」

では、ハイブリッド型は常に失敗するのか？ 必ずしもそうではありません。 重要なのは「混ぜる」のではなく、**「プロジェクト単位で切り分ける」**ことです。

例：

• 金融システムの勘定系（法律遵守・高信頼性が必要）：ウォーターフォールで進める
• そのシステムと連携する営業担当アプリ（顧客体験を重視し、不確実性が大きい）：アジャイルで進める

つまり、「ひとつのプロジェクトの中で上下流を分ける」のではなく、領域ごとに適切なプロセスを選択するのです。

---

幻想を超えるための教訓

• 「上流ウォーターフォール＋下流アジャイル」は思想が衝突しやすく、失敗の温床になる
• ウォーターフォールは「全部作る」ことで無駄を生みやすい
• アジャイルは「やらないこと」を発見できることで本質に集中できる
• 成功するには、混ぜるのではなく、プロジェクトや領域を切り分ける発想が必要
  

5.4 「次はもっと上手にやろう」症候群

ウォーターフォール開発のプロジェクトが失敗すると、現場やマネジメントはよくこう言います。

「次はもっと上手にやろう」 「今度は気を引き締めて取り組もう」 「人員を増やせば大丈夫だ」

一見すると前向きな言葉ですが、これは大きな誤解を含んでいます。 失敗の原因は「人が下手だから」ではなく、プロセスそのものが現実に合っていないからです。

ウォーターフォールは「要件が最初から明確で、途中で変化しない」ことを前提としています。 しかし実際のソフトウェア開発では、要件は途中で揺れ動き、顧客の理解もプロジェクトの進行とともに深まっていきます。 つまり「変化が必然」である世界に、「変化がない」という仮定で挑んでいるのです。

それにもかかわらず、失敗すると「次はもっと注意すれば大丈夫だ」と思い込んでしまう。 これはまさに、カジノで負け続けたギャンブラーが「次こそは勝てる」と信じて賭け金を増やすのと同じです。

---

💡 エピソード：Uncle Bob の指摘

Robert C. Martin（Uncle Bob）は『Clean Agile』の中で、この現象を鋭く指摘しています。

彼はこう述べています。 「ウォーターフォールで失敗した組織は、次も同じウォーターフォールで“もっと上手くやろう”とする。 しかし問題は人ではなく、プロセスそのものにある。 だから繰り返しても、同じ失敗をするだけだ。」

---

📝 教訓

この「次はもっと上手にやろう」症候群から抜け出すには、

• 個人やチームの努力不足に原因を求めるのではなく、
• プロセスそのものが適切かどうかを疑うことが必要です。

「次こそ上手くやれる」という気合いではなく、 「このプロセスは本当にこの状況に合っているのか？」という問いを立てること。 これが、ウォーターフォールとアジャイルを正しく使い分けるための第一歩なのです。

📝 第 5 章 まとめ

本章では、ウォーターフォールとアジャイル、それぞれの現場で起こりがちな落とし穴を見てきました。 ウォーターフォールでは、

• 見積もり外れ
• 要件変更の対応難
• 認識ズレによる大規模な手戻り
• 大量のバグが後半に噴出する といった典型的な問題が発生します。

一方でアジャイルでも課題はゼロではなく、

• 小さな成果物に分解できない
• 顧客の協力が得られない
• イテレーションのリズムが乱れる といった失敗は起こります。

しかし大きな違いは、アジャイルは問題に早く気づける点です。 ウォーターフォールは「最後にまとめて爆発」しますが、アジャイルは「小さな爆発を何度も経験する」ことで学び直すことができます。

さらに重要なのは、失敗の原因を「人の努力不足」にすり替えてしまう危険です。 ウォーターフォールで失敗すると、現場はつい「次はもっと上手にやろう」と考えてしまいます。 しかし、根本の原因は「プロセスが現実に合っていないこと」にあるのです。 努力や根性で解決できる問題ではなく、プロセスの前提そのものを問い直す必要があります。

---

💡 次章への橋渡し

落とし穴の事例を整理すると、結局は「プロセスの思想そのもの」が問われていることが見えてきます。 つまり、ウォーターフォールは「正解がある世界」を前提にしているのに対し、アジャイルは「正解が分からない世界」を前提にしています。 この思想の違いを理解しないまま「ハイブリッド型」を選んでしまうと、両方の欠点を引き継ぐ危険性があります。

第 6 章　思想の違いとその本質

ウォーターフォールとアジャイルは、単なる手法の違いではありません。 根本にある 「前提となる思想」 がまったく異なっています。 そして、この思想を理解しないまま両者を混ぜようとすると、プロジェクトは迷走します。

---

6.1 なぜ思想が混ざると危険なのか？

現場ではよく、 「ウォーターフォールの計画性と、アジャイルの柔軟性を両立できないか？」 という問いが出てきます。

しかし、思想が違うものを中途半端に混ぜると、次のような矛盾が生まれます。

• 「最初にすべて決めたい」 vs 「やりながら学習する」
• 「計画を守ることが成功」 vs 「変化に応じることが成功」
• 「全部作り切る」 vs 「やらないことを選ぶ」

つまり、両者の思想は直交関係にあるのです。 混ぜればいいと単純に考えると、どちらの良さも失われ、悪い部分だけが強調される結果になります。

---

6.2 ウォーターフォール：正解がある前提

ウォーターフォールは「正解が分かっている世界」で力を発揮します。

• 要件は明確に定義できる
• 技術や解法は既知である
• 設計通りに進めれば完成する

たとえば、橋を架ける、銀行の勘定系システムを作る、法令対応のシステムを開発する――こうした「正解が存在する世界」では、ウォーターフォールは非常に合理的です。

言い換えると、**「一度きちんと決めれば、あとは計画通りに作ればよい」**という思想の上に立っています。

---

6.3 アジャイル：正解が分からない前提

一方、アジャイルは「正解が分からない世界」を前提としています。

• 顧客が本当に求めているものはやってみないと分からない
• 技術的に実現可能かは実験してみないと分からない
• 市場や顧客の期待は常に変化している

このような不確実性の高い領域では、最初に「正解」を決めること自体が無理です。 アジャイルはここで 「小さく作って試し、フィードバックから学ぶ」 という思想を採ります。

つまり、ウォーターフォールが「計画に従う世界」に立っているのに対し、アジャイルは「学習して正解に近づく世界」に立っているのです。

---

6.4 「やらないこと」を選ぶアジャイルの思想

もうひとつ重要な思想の違いがあります。

ウォーターフォールは「決めたことは全部やる」前提で進みます。 一度要件定義で合意したら、それを漏れなく作り切ることがプロジェクトのゴールです。

対してアジャイルは、**「やらないことを選ぶ」**ことを重視します。

• スプリントごとに本当に必要かを見極める
• 不要だと分かったものは潔く捨てる
• 有限の時間とリソースを、価値の高い部分に集中する

この「やらないことを決める」力こそ、アジャイルが無駄を減らし、変化に強い理由です。

---

6.5 計画重視 vs 学習重視の根本的な違い

思想の違いを一言で表すなら、こうなります。

• ウォーターフォール：計画重視 → すべてを見通し、管理し、正確に実行する
• アジャイル：学習重視 → 不確実性を受け入れ、試行錯誤を通じて正解に近づく

どちらが優れている、という話ではありません。 ただし、プロジェクトの性質や文脈によって、どちらの思想が適しているかが決まります。

そして、この根本思想を理解していないと、手法だけを真似しても成果は出ないのです。

第 7 章　どう選ぶべきか？

---

7.1 適材適所の考え方

ウォーターフォールとアジャイルは、どちらが優れている・劣っているというものではありません。 それぞれが異なる前提条件に基づいて設計されているため、適用すべき領域が違うのです。

ウォーターフォールは「要件が明確で変更が少ない」環境で力を発揮します。 アジャイルは「不確実性が高く、変化が頻繁に起きる」環境に適しています。

プロジェクトが直面する問題の性質を見極め、状況に応じて使い分けることが重要です。

---

7.2 クネビンフレームワークによる整理

この考えを分かりやすくするために、「クネビンフレームワーク（Cynefin Framework）」を紹介します。 これは、問題や課題の性質を 4 つの領域に分類し、それぞれに適したアプローチを示すフレームワークです。

• 単純領域（Obvious） 原因と結果が明確で、手順を踏めば必ず成功する領域。 👉 例：給与計算、規制に基づくシステム
• 複雑領域（Complicated） 専門家の分析が必要だが、正解は存在する領域。 👉 例：金融基盤システム、航空管制システム
• 複雑系領域（Complex） 正解が事前には分からず、試行錯誤やフィードバックで学んでいく領域。 👉 例：新サービス開発、ユーザー体験設計
• カオス領域（Chaotic） 原因すら分からず、即応が求められる領域。 👉 例：大規模障害対応、セキュリティインシデント

---

7.3 適用領域のまとめ

ウォーターフォールに向いている領域

ウォーターフォールは、**「最初に決めた通りに作れば正解にたどり着ける領域」**に強いです。 特に、法令遵守や大規模基幹システムのように 要件が明確で変更が少ない領域では、工程ごとに確実に進めるウォーターフォールが有効です。

👉 例：給与計算システム（税率や保険料率は明確で、仕様はほとんど変わらない）

---

アジャイルに向いている領域

アジャイルは、**「正解が分からない領域」**に強みを発揮します。 ユーザーが求めるものが不確実で、市場の変化も激しい場合は、短いサイクルでフィードバックを得て改善するアジャイルが有効です。

👉 例：新しいスマホアプリ機能開発（便利そうに見えても、実際に使われるとは限らない。試して学ぶ必要がある）

---

どちらも使えない領域（カオス）

大規模障害対応やセキュリティ事故のようなカオス領域では、ウォーターフォールもアジャイルも役立ちません。 まずは 即応と安定化 が優先されます。落ち着いた後に初めて、ウォーターフォール的に調査したり、アジャイル的に改善策を試したりすることができます。

👉 例：銀行 ATM が全国で停止 → まずは止血。その後に分析や改善。

---

7.4 ハイブリッドを選ぶ場合の注意点

現場では「ウォーターフォールとアジャイルを組み合わせれば良いのでは？」という発想もよく見られます。 たとえば「要件定義まではウォーターフォール、設計以降はアジャイル」といったやり方です。

しかし、これは単なる工程分割であり、思想が混ざってしまうと失敗の原因になります。 ウォーターフォールは「最初に正解を決める」思想、アジャイルは「正解は分からないから試す」思想です。 両者をつなぎ合わせるのではなく、**「この領域はウォーターフォール」「この領域はアジャイル」**と切り分けることが大切です。

---

7.5 事例での使い分け

• 金融基幹システム：法律・規則に基づき要件が明確 → ウォーターフォール適用
• 顧客接点の新サービス：不確実性が高く、市場適応が必要 → アジャイル適用
• 障害対応：まずはカオスへの即応、その後ウォーターフォールやアジャイルへ移行

---

まとめ

ウォーターフォールとアジャイルは、どちらも強みを持つ方法論です。 重要なのは「手法の優劣」ではなく、問題の性質に応じて適切な手法を選ぶことです。

クネビンフレームワークを活用すると、問題の性質を客観的に判断し、より適切に手法を選びやすくなります。