■ 1. 概要
- ソフトウェア開発方法論は「ウォーターフォールかアジャイルか」の二択で語られることが多いが、解像度が低い
- 実際には別々に決めるべき4つの論点が存在する
- 開発ライフサイクル（予測型 / 適応型）
- 固定するプロジェクト変数（スコープ固定 / コスト固定）
- デリバリーケイデンス（単一 / 複数 / 定期）
- 効率パラダイム（リソース効率 / フロー効率）
- 「ウォーターフォール」「アジャイル」という手法名は、4つの論点をまとめて選んだ結果のラベルでしかない
- 決めるべきは手法名ではなく、4つの論点それぞれに自分のプロジェクトでどう答えるかである
■ 2. 手法名は複数の判断をまとめてしまう
- ウォーターフォールは典型的には予測型の開発ライフサイクルであり、スコープを定義し、スケジュールやコストを見積もり、計画に対するズレを管理する
- アジャイルは典型的には適応型の開発ライフサイクルであり、短いサイクルで作り、検査し、学習し、次の計画を調整する
- 反復しているから適応型とは限らない
- 機能セットを固定し最初に決めたスコープの完了率だけを追っているなら、それは短い周期で進めている予測型計画である
- Dave Nicoletteはこれを「イージーライダー」と呼び、予測型と適応型の都合のよい部分だけを切り貼りしてどちらの規律も持たない状態を批判している
- 「ウォーターフォール vs アジャイル」という対比では、何を固定し、何を可変にし、どの周期で学習し、何を最適化しているのかが見えない
■ 3. 論点1: 開発ライフサイクル
- 予測型と適応型の対比はMartin Fowlerによる区別である
- 予測型:
- 作るものが予測可能であることを前提にする
- 不確実性の量を見積もり、計画にバッファとして織り込む
- 目標と実績のズレを検知し、計画へ近づけるように是正する
- PMBOKのContingency ReserveとManagement Reserveの階層はこの発想の延長にある
- 適応型:
- 最終的に作られるものを正確には予測できないことを前提にする
- 大きな方針やビジネスゴールはあるが、具体的な成果物は変わりうる
- 近い目標を置き、短い周期で検査しながら進む
- ソフトウェア開発の不確実性は要件・技術・市場のいずれの方向にも漏れるため、サイクルで吸収する設計になる
■ 4. 論点2: 固定するプロジェクト変数
- プロジェクトには品質、コスト、期間、スコープといった変数があり、全てを同時に固定することはできない
- 品質は制御変数にはならない:
- 内部品質をコスト・スコープ・速度とトレード可能な変数として扱うと、内部品質に投資する理由が消える（Fowler: Tradable Quality Hypothesis）
- 内部品質が落ちれば数週間で開発速度が落ち、トレードで稼げる余地はほとんどない（Design Stamina Hypothesis）
- 可用性、性能、セキュリティといった外部品質特性も一定閾値を下回るとサービスとして成立しないため、調整弁にはできない
- 期間はコストの構成要素として扱える:
- ソフトウェア開発では人月が主原価であるため、期間を延ばせば人件費が積み上がる
- 人を増やしてもBrooks流の摩擦で線形には短縮しない
- スコープ固定（コスト可変）は予測型と相性がよい:
- 契約、投資判断、予算承認、外部調整などの場面でスコープを約束する必要がある
- 不確実性が顕在化すればコストに転化する
- コスト固定（スコープ可変）は適応型と相性がよい:
- 限られた期間とチームで、最も価値のあるものから作る
- 作るものの詳細は学習によって更新される
- スコープ可変には「ここまで満たせば出せる」という最小条件（Definition of Done）が必要であり、これがなければ可変スコープは未完成項目を増やすだけになる
■ 5. 論点3: デリバリーケイデンス
- デリバリーサイクルには3つの選択肢がある:
- 単一デリバリー: プロジェクトの最後に一度だけ届ける。価値の検査が終盤に寄るため、計画精度・リスク管理・変更管理の重みが増す。予測型と組み合わさりやすい
- 複数デリバリー: 期間中に複数回届ける。回数は決め打ちで、間隔は固定しない
- 定期デリバリー: 固定された周期で届ける
- 複数・定期デリバリーは途中で価値を届けながら学習できる点で適応型と組み合わさりやすい
- デリバリーケイデンスの選択は、不確実性をどの周期で観測し、どの周期で意思決定を更新するかを決める
- ここでのデリバリーは本番リリース一歩手前まで持っていくことを指し、デプロイやリリースとは異なる概念である
■ 6. 論点4: 効率パラダイム
- リソース効率とフロー効率の区別はNiklas Modig & Pär Åhlström「This is Lean」が提示した概念である
- リソース効率: 各人の稼働率を高めることを重視し、人が遊んでいない状態をよしとする
- フロー効率: タスクがどれだけ短いリードタイムで流れるかを重視する
- この2つはよく衝突する:
- 全員の稼働率を最大化するとWIPが増え、コンテキストスイッチが増え、コラボレーションが減り、サイクルタイムが長くなる
- リトルの法則から、平均WIPが増えれば平均サイクルタイムが伸びる
- 各人は忙しいのに、価値の流れは遅くなる
- 定期デリバリーや適応型プロセスではフロー効率が要になる:
- 短い周期で検査・学習・計画更新するには、タスクが流れていなければならない
- KanbanがWIP制限を中心メカニズムに据えているのはこのためである
- 単一デリバリーの予測型プロジェクトではリソース効率を優先する設計が採用されやすい:
- 固定スコープ・固定予算の枠で外部と合意するとき、稼働率管理は会計上扱いやすい
- フロー効率が常に上位の概念というわけではなく、前提条件が異なる
■ 7. 4つの論点の組み合わせ
- 基本となる組み合わせは2つあり、両者は並列ではない
- 第一の基本形（予測型 + コスト可変 + 単一デリバリー + リソース効率）:
- SI契約、規制対応、ハードウェア同梱のソフトウェアなど外部に「何を、いつまでに、いくらで」を確約する案件が採る
- 運用にはリスク管理・変更管理・バッファ管理が必要
- 前提条件は「作るものが事前に予測可能」であること。これが満たせなければ、どれだけ計画を作り込んでも実装中にスコープが動き、コストが外れる
- 第二の基本形（適応型 + スコープ可変 + 定期デリバリー + フロー効率）:
- 運用にはDoneの定義・本番投入可能性・WIP制限・メトリクスが必要
- 例外的な組み合わせも存在する:
- 予測型 + スコープ固定 + 複数デリバリー + リソース効率: 年度予算の上限などで複数年度に分割して届ける案件。フェーズごとに要員を割り当てて稼働率を管理する
- 適応型 + スコープ固定 + 複数デリバリー + フロー効率: 受託開発で発注側との契約はスコープ固定だが、内部ではアジャイルプラクティスを適用するスタイル（中菱エンジニアリングの事例）。外向きには予測型に見せ、内向きには適応型で運用する二層構造
- 適応型 + コスト固定 + 定期デリバリー + リソース効率: Leanを伴わずにアジャイルを運用する場合。WIP制限を採用せず稼働率管理を最適化の論点に置く
■ 8. まとめ
- 「ウォーターフォールか、アジャイルか」という問いは、開発ライフサイクル一つの差を過大に見せる
- プロジェクト運営の設計は少なくとも4つの論点で考える必要がある:
- 開発ライフサイクル: 予測型か、適応型か
- 固定するプロジェクト変数: スコープを固定するか、コストを固定するか
- デリバリーケイデンス: 単一か、複数か、定期か
- 効率パラダイム: リソース効率か、フロー効率か
- これらは独立した好みではなく、不確実性をどこに押し込み、どの周期で観測し、何を最適化するかというひとつの設計問題の4つの側面である
- 自分たちのプロジェクトでこの4つにどう答えるかを明示するところから、プロジェクト設計は始まる