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