ウォーターフォールとアジャイル 第2回

アジャイル

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

第 2 部　ウォーターフォールからアジャイルへの系譜

第 8 章　ウォーターフォールの誤解と真実

8.1 ロイスの論文に立ち返る

ウォーターフォール開発の起源は、1970 年に発表された Winston W. Royce の論文 「Managing the Development of Large Software Systems（大規模ソフトウェアシステムの開発管理）」にあります。

この論文には、今日「ウォーターフォールモデル」と呼ばれる、工程が直線的に並ぶ有名な図が登場します。 しかし、ここに大きな誤解があります。

  • あの図は「ウォーターフォールの正しい姿」を示したものではない
  • むしろ 「このやり方では失敗する」という反例 として示されていた

ロイス自身は「工程を直線的に一度だけ進めるやり方では、大規模ソフトウェア開発は必ず失敗する」と明確に書いています。

つまり、「戻れないウォーターフォール」というイメージは、ロイスの意図を真逆に受け取ったものなのです。

8.2 ロイスが本当に提案したこと

ロイスの論文を読み進めると、彼が強調しているのは 「戻れる仕組み」 と 「試作（プロトタイピング）」 です。

  • 各工程でドキュメントを作り、次工程に進む前にフィードバックを得る
  • 必要に応じて前の工程に戻り、修正を行う
  • 特にユーザー要求が曖昧な部分については、試作品（プロトタイプ）を作って確かめる

つまりロイスが目指していたのは、「計画を持ちながらも学習を繰り返すプロセス」 でした。 これは今日でいう「反復型開発」に近い考え方です。

8.3 「ウォーターフォール」という名前は誰が使い始めたのか？

ここで興味深い事実があります。 ロイス自身は「ウォーターフォール」という言葉を一度も使っていないのです。

この呼び名が広まったのは、後年の NASA や DoD（米国防総省）の文書文化 によるものです。 大規模開発の標準プロセスを定めるため、図表を使って「段階的な流れ」を示す際に「滝（ウォーターフォール）」という比喩が便利だったため、広まっていきました。

さらに 1980 年代には、Barry Boehm の論文でもこの言葉が使われ、学術的にも定着していきました。

8.4 なぜ“戻れないウォーターフォール”が定着したのか

それでは、ロイスの意図とは正反対の「戻れないウォーターフォール像」が、なぜ広く定着してしまったのでしょうか？ 理由は大きく 3 つあります。

  1. 文書主義 大規模開発では、契約や検収の根拠としてドキュメントが重視されました。 工程のアウトプットを形式的に次へ渡すことが強調され、戻ることが軽視されたのです。
  2. 契約構造 発注者と受注者の関係において、「要件定義が終わったら凍結」とする契約が一般化しました。 戻ることは「追加費用」とみなされ、現実的に難しかったのです。
  3. マネジメント上の都合 プロジェクトを「計画通りに進んでいる」と見せるため、直線的に進んでいることが望まれました。 「戻る」という表現は管理の失敗と見なされがちだったのです。

こうした背景から、「ウォーターフォール＝戻れない工程」というイメージが固定化されました。

8.5 誤解が与えた影響

この誤解は、ソフトウェア開発の現場に長く影響を与えてきました。

  • 開発途中での学習や修正が「計画逸脱」とされる
  • ユーザーの本当の要求が分からないまま、最後に「想定外の不一致」が爆発する
  • 本来ロイスが提案していた「戻り」と「試作」の重要性が忘れ去られる

結果として、ウォーターフォールは「堅苦しくて融通が利かない手法」と誤解され、アジャイルの台頭とともに「古い手法」「悪い手法」として批判の対象になってしまいました。

まとめ

ウォーターフォールの誤解を解きほぐすと、次のことが分かります。

  • ロイスの論文は「戻れないウォーターフォール」の危険性を警告していた
  • 本来は「戻れるプロセス」と「プロトタイピング」を重視していた
  • 「ウォーターフォール」という呼び名も、後世の文書文化と契約構造によって広まった

つまり、ウォーターフォールは「悪い手法」なのではなく、誤解と制度設計によって歪んで伝わってしまったのです。

第 9 章　アジャイルは対立ではなく進化だった

9.1 誤解されがちな構図

一般的に語られるソフトウェア開発史は、しばしば単純化されます。

  • 古い手法（ウォーターフォール） は時代遅れで硬直的
  • 新しい手法（アジャイル） は柔軟で優れている

こうした「旧 vs 新」「悪 vs 善」という二項対立の構図は理解しやすい一方、歴史を正しく表してはいません。

実際には、アジャイルは突然現れた「革命」ではなく、ウォーターフォールから徐々に学びと試行を重ねた「進化の系譜」 の一部なのです。

9.2 架け橋となった RUP

ウォーターフォールとアジャイルの間をつなぐ存在として、Rational Unified Process（RUP） を欠かすことはできません。

Three Amigos と UML

1990 年代、Rational Software 社には「Three Amigos」と呼ばれた 3 人のソフトウェア技術者がいました。

  • Ivar Jacobson：ユースケース駆動開発
  • Grady Booch：オブジェクト指向設計
  • James Rumbaugh：オブジェクトモデリング手法（OMT）

彼らが協力して生み出したのが UML（統一モデリング言語） であり、その実践的なプロセスとして位置づけられたのが RUP でした。

RUP の特徴

  • 「反復型開発」を正式にプロセスとして取り込んだ
  • ユースケースを起点にユーザー視点でシステムを捉える
  • 計画性と柔軟性のバランスを取ろうとした

RUP は、ウォーターフォールの計画性と、アジャイル的な学習サイクルを融合させた「架け橋」として機能しました。

9.3 AUP とアジャイルへの接続

その後、RUP は「重すぎる」と批判されるようになります。 これを軽量化し、アジャイル的な方向へ進めたのが Agile Unified Process（AUP） です。

AUP の背景

  • 提唱者は Scott Ambler
  • 背景には Craig Larman の「Iterative & Incremental Development」思想の影響がある
  • RUP をシンプルにし、アジャイルの価値観を取り込んだ

AUP では、ドキュメントや手続きの形式よりも、動くソフトウェアとチームの協働 に重点が置かれました。

これはまさに、後に 2001 年に発表される「アジャイルソフトウェア開発宣言」につながる流れでした。

9.4 「進化」としてのアジャイル

この流れを整理すると、次のような進化の系譜が見えてきます。

  1. ロイスの論文（1970 年）
    • 反復とプロトタイピングの重要性を指摘
  2. ウォーターフォールの定着（1970〜80 年代）
    • 契約や文書文化により「戻れないプロセス」として制度化
  3. RUP（1990 年代）
    • UML と反復型開発を取り込み、両者の橋渡しを試みる
  4. AUP（2000 年前後）
    • RUP を軽量化し、アジャイル思想を統合
  5. アジャイル宣言（2001 年）
    • ソフトウェア開発の思想的な結実

こうして見ると、アジャイルはウォーターフォールと対立する「敵」ではなく、歴史の中で進化して生まれた「子孫」 と言えるのです。

まとめ

  • 「ウォーターフォール vs アジャイル」という単純な対立構図は誤解である
  • RUP と AUP が両者の間をつなぐ重要な「進化のステップ」だった
  • アジャイルは突然の革命ではなく、長い歴史の中で培われた進化の成果

アジャイルを正しく理解するには、ウォーターフォールを「否定する対象」ではなく、自分たちの出発点 として見る必要があります。

第 10 章　ウォーターフォールとアジャイルに共通する本質

10.1 共通点 1：価値を届ける

ウォーターフォールもアジャイルも、最終的な目的は顧客や利用者に価値を届けることです。

  • ウォーターフォール 計画を立て、要件を整理し、抜け漏れなく作り込むことで価値を提供しようとする。 → 「作り忘れない」「信頼性を保証する」アプローチ。
  • アジャイル 小さな価値を素早く届け、利用者の反応を確認しながら方向性を修正することで価値を提供しようとする。 → 「外さない」「顧客と一緒に作る」アプローチ。

どちらも 価値を届けたい という根本は同じ。 違うのは「確実に届ける」のか「正しく届ける」のかという手段です。

10.2 共通点 2：フィードバックを回す

もう一つの共通点は、フィードバックを重視することです。

  • ウォーターフォールのフィードバック
    • テスト工程で不具合を検出
    • 評価会議やレビューで承認を得る
    • 文書を通じた段階的な合意
  • アジャイルのフィードバック
    • 短いスプリントごとに動くソフトウェアを見せる
    • ユーザーや顧客から直接意見をもらう
    • 毎日のスクラムでチーム内の気づきを即座に反映

つまり「どこで・どのくらい早く・どのようにフィードバックを得るか」が異なるだけで、フィードバックを回して改善する思想は共通しています。

10.3 共通点 3：リスクの低減

ウォーターフォールもアジャイルも、それぞれの方法で リスクを管理する工夫 を持っています。

  • ウォーターフォール
    • 前段階でのレビューや文書化でリスクを潰す
    • 大規模開発における「抜け漏れリスク」を低減
  • アジャイル
    • 不確実性の高い領域に小さく挑戦することでリスクを局所化
    • 「作りすぎリスク」「顧客不一致リスク」を低減

共通の目的は「失敗を小さくすること」であり、手段が異なるだけです。

10.4 なぜ共通点が見えにくいのか

ウォーターフォールとアジャイルは、本来は共通する思想を持ちながら、しばしば「正反対」として語られます。

理由は次の通りです：

  1. 誤解されたイメージの固定化
    • ウォーターフォール → 「硬直的」「戻れない」
    • アジャイル → 「行き当たりばったり」「計画しない」
  2. 現場の失敗体験の記憶
    • 多くの人は「失敗したプロジェクト」で手法を語るため、偏った印象が強まる
  3. 思想よりも手段の違いに注目されがち
    • 本来は「価値を届ける」という目的は同じなのに、工程や儀式の違いが強調されてしまう

こうした要因により、両者は「対立する概念」と誤って認識されてきたのです。

まとめ

  • ウォーターフォールとアジャイルの本質的な目的は 同じ（価値を届けること）
  • どちらも フィードバックを回してリスクを減らす 仕組みを持っている
  • 違いは「どのタイミングで、どの規模で」それを行うかにすぎない
  • 誤解されたイメージのせいで「対立」として語られてしまった

つまり両者は「正反対の敵」ではなく、同じゴールを目指す兄弟のような存在なのです。

第 11 章　アジャイルは人間中心のプロセス

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

ここまでウォーターフォールについて話してきました、ここでもう一度アジャイルについて振り返ってみましょう。
2001 年に発表されたアジャイルソフトウェア開発宣言は、人と人の関わりを中心に据えるというメッセージでした。

4 つの価値を具体的な現場イメージに置き換えると：

  1. プロセスやツールよりも、個人と対話を
    • Jenkins や Jira は便利だが、それだけでは問題は解決しない
    • 隣の席のメンバーに「これで合ってる？」と聞ける文化の方が価値がある
  2. 包括的なドキュメントよりも、動くソフトウェアを
    • 分厚い要件定義書より、動く試作画面を見せる方が顧客は理解しやすい
    • 「動くものを触る」ことが会話を活性化する
  3. 契約交渉よりも、顧客との協調を
    • 「仕様変更は契約違反です」ではなく「一緒に最適解を探しましょう」と動く
    • ベンダーと発注者という立場を超えて「同じチーム」として協働する
  4. 計画に従うことよりも、変化への対応を
    • 市場環境や規制の変更は避けられない
    • 計画を守ることに固執せず、変化を学習と成長の機会に変える

これらは 「何を優先するか？」の問いに対する答え です。 つまり、アジャイルの本質は「人間のやり取りを最優先にする」ことにあります。

11.2 「人間の関わり方」に焦点を当てる

チーム内部

  • 朝会で顔を合わせることにより「誰が困っているか」がすぐ分かる
  • コードレビューは「間違い探し」ではなく「学び合い」
  • チームが自律的に意思決定することで、責任感とモチベーションが生まれる

顧客との関わり

  • プロトタイプを早期に提示し、「これじゃない感」をすぐに修正できる
  • 顧客は「承認者」ではなく「共同設計者」になる
  • 成果物を見せるたびに顧客の期待が具体化され、信頼関係が強まる

経営・マネジメントとの関わり

  • 経営陣は進捗をレポートでなく「動くシステム」で確認できる
  • KPI より「現場の学び」をどう意思決定に活かすかが重要
  • 指示命令ではなく「障害を取り除く役割」にシフトする

これらはすべて、「人がどう関わるか」こそが成功の鍵であることを示しています。

11.3 誤解されたウォーターフォールとの対比

ウォーターフォールも本来は「人を排除する」思想ではありません。 しかし現場では以下のような形で「人間軽視」に傾いてしまったのです：

  • 本来の意図：ロイスは「フィードバックとプロトタイピングの重要性」を強調していた
  • 現場の運用：文書と契約を重視する文化に飲み込まれ、「人は手続きに従う存在」に矮小化

結果として、

  • ウォーターフォールは「文書と手順が中心」
  • アジャイルは「人と会話が中心」 という単純な対立構造が広まりました。

実際には両者とも人間の協働が不可欠です。 ただし、アジャイルは明確に 「プロセスより人間」 を旗印にしたことで、現場の行動変革を促しました。

11.4 具体的な失敗と成功の対比

  • 失敗例（ウォーターフォール型の思考に偏った場合）
    • 顧客「この画面、やっぱり項目を減らしたい」
    • ベンダー「契約書に書いていないので追加費用です」
    • → 顧客は不満、開発側も防御姿勢。両者の関係は消耗戦に。
  • 成功例（アジャイル的な関わり方）
    • 顧客「この画面、やっぱり項目を減らしたい」
    • 開発者「すぐ修正できます。実際に触ってみて判断しましょう」
    • → 顧客は「助かった」と安心し、チームは信頼を獲得。結果的に次の案件にもつながる。

この違いを生むのは 「関わり方を人間中心に設計しているか」 どうかです。

まとめ

  • アジャイルの核心は「人間の関わりを最優先にすること」
  • チーム・顧客・経営、それぞれの関係性を再設計することで成果が生まれる
  • ウォーターフォールも本来は人を重視していたが、運用で形式優先に傾いた
  • アジャイルは「人間中心」を明確に打ち出すことで、従来の文書主義から脱却した

つまりアジャイルは、ソフトウェア開発を「技術課題」から「人間の協働課題」へと再定義したといえるでしょう。

第 12 章　まとめと問いかけ

12.1 本書のまとめ ― 4 つの要点

本書では、ウォーターフォールとアジャイルを単なる「古い／新しい」という対立ではなく、歴史と思想の流れとして捉えてきました。 振り返ると、以下の 4 つのポイントが浮かび上がります。

  1. ウォーターフォールは誤解されてきた
    • ロイスは「戻れない工程」を推奨したわけではなかった
    • 本来は「反復」「試作」「柔軟なフィードバック」を重視していた
  2. アジャイルは「対立」ではなく「進化」だった
    • RUP や AUP といった中間的なプロセスを経て進化してきた
    • 「人間中心」「変化対応」という思想が鮮明になった
  3. ウォーターフォールとアジャイルは適材適所
    • 法規制遵守や大規模基盤 → ウォーターフォールが強い
    • 不確実性が高く学びが必要な領域 → アジャイルが有効
    • クネビンフレームワークで整理すると理解が進む
  4. 共通する本質は「価値を届ける」こと
    • 文書中心か対話中心かの違いはあっても、最終目的は同じ
    • 顧客に価値を届け、社会にインパクトを与えることがゴール

12.2 あなたのプロセスは「戻れるか？」

ここで改めて問いかけます。 あなたが今取り組んでいるプロジェクトは、本当に「戻れる」プロセスになっているでしょうか？

  • 要件を誤解しても修正できる仕組みがあるか？
  • 顧客やユーザーからフィードバックをもらう仕組みがあるか？
  • 文書ではなく「動くもの」で検証できるか？

もし「戻れない」「気づくのが遅れる」と感じるなら、手法そのものを見直すべきタイミングかもしれません。

12.3 あなたの現場に合わせた選択を

アジャイルは万能ではありません。 ウォーターフォールが不要になることもありません。

大切なのは「どちらが正しいか」ではなく、 「今のプロジェクトにとって、どの考え方が適しているか？」です。

  • 顧客が「確定した仕様」を求めているならウォーターフォール的な進め方が有効
  • 顧客自身が「何が欲しいか分からない」ならアジャイル的な探索が必須

つまり、あなた自身が 状況を読み解き、手法を選び取る目 を持つことが肝心です。

12.4 次世代への問いかけ

最後にもう一つ、未来に向けた問いを投げかけます。

  • AI が仕様を自動生成する時代になったら、アジャイルはどう変わるでしょうか？
  • 国際的な規制がさらに強化されたとき、ウォーターフォールは復権するでしょうか？
  • あるいは、まったく新しい「第 3 のプロセス」が登場するでしょうか？

私たちの役割は「今ある手法に従うこと」ではなく、 時代に合わせてプロセスを進化させることです。

12.5 結びに

ウォーターフォールとアジャイルの歴史と思想を学ぶことは、 単に「開発手法を知ること」ではなく、人間がどう協働し、どう価値を生み出すかを問い直す作業です。

本書が、あなたの現場における「より良い選択」のきっかけになれば幸いです。

あとがき

ソフトウェア開発の歴史を振り返ると、私たちは常に 「正しい進め方とは何か？」 を模索してきました。 ウォーターフォールとアジャイルは、その問いに対する 2 つの大きな答えです。

しかし、本書を通じて強調してきたように、どちらも「絶対に正しい方法」ではありません。 むしろ、どちらも時代背景と課題に応じて生まれた、人類の知恵の産物です。

私自身が本書を書きながら強く感じたのは、プロセスや手法に「従う」ことではなく、 「考え続ける」ことこそが、私たちの責任であり創造性であるという点でした。

AI がコードを書き、世界がますます不確実になるこれからの時代、 ウォーターフォールやアジャイルの「枠」を超えた、新しい実践が生まれていくでしょう。

読者のみなさん一人ひとりが、この歴史の続きを紡ぐ存在です。 どうか、自分の現場にあった最善の方法を問い直し、進化させてください。

用語集（抜粋）

  • ウォーターフォールモデル ソフトウェア開発を「要件定義 → 設計 → 実装 → テスト → 運用」と直線的に進める手法。1970 年のロイスの論文で広まったが、もともとは「戻れる前提」を含んでいた。
  • アジャイル開発 2001 年に「アジャイルソフトウェア開発宣言」としてまとめられた価値観と原則に基づく手法群。小さな反復と顧客との協働を重視する。
  • RUP (Rational Unified Process) Rational Software 社が提唱した統合プロセス。反復型を採用し、ウォーターフォールとアジャイルの中間に位置づけられる。
  • AUP (Agile Unified Process) Scott Ambler らによって提案された、RUP をアジャイル指向に軽量化したプロセス。
  • クネビンフレームワーク (Cynefin Framework) Dave Snowden によって提唱された意思決定フレーム。問題を「単純」「複雑」「複雑適応系」「混沌」に分類し、状況に応じたアプローチを導く。
  • アジャイルソフトウェア開発宣言 2001 年、Snowbird（米国ユタ州）で 17 人の実践者が合宿しまとめた宣言。 「プロセスやツールよりも人と対話を」「包括的なドキュメントよりも動くソフトウェアを」など 4 つの価値を示した。

登場人物解説

  • ウィンストン・ロイス (Winston W. Royce) 1970 年の論文で「ウォーターフォールモデル」と誤解される図を提示した人物。実際には「反復」「試作」を強調していたが、歴史の中で誤って「直線型プロセスの提唱者」とされてきた。
  • バリー・ベーム (Barry Boehm) Spiral Model（1986）を提案。リスク駆動で反復的に開発を進める手法を提示し、ウォーターフォールからアジャイルへの橋渡しをした。
  • グラディ・ブーチ (Grady Booch) オブジェクト指向設計法を開発。Three Amigos の一人で、Rational 社の中心人物。
  • ジェームズ・ランボー (James Rumbaugh) OMT（Object Modeling Technique）の提唱者。Three Amigos の一人。
  • イヴァー・ヤコブソン (Ivar Jacobson) Use Case（ユースケース）の提唱者。Three Amigos の一人で、RUP の基盤を築いた。
  • スコット・アンブラー (Scott Ambler) Agile Modeling の提唱者であり、AUP を整備。アジャイルとモデリングの両立を追求した。
  • クレイグ・ラーマン (Craig Larman) 「実践 UML」「アジャイル開発の本質」などの著者。AUP の発展に影響を与え、アジャイル思想の普及に貢献した。
  • 17 人のアジャイル宣言署名者たち Kent Beck, Martin Fowler, Ward Cunningham らを中心に、極端な実践（XP, Scrum, Crystal, DSDM など）の経験を持つ実践者たち。 彼らが集まり「アジャイルソフトウェア開発宣言」を生み出した。

コメント

タイトルとURLをコピーしました