2021年1月5日
【システム企画～情報活用力を上げる仕組み作り】
～ウォーターフォールとアジャイル～
ウォーターフォールモデルは計画駆動型、アジャイルは価値駆動型または変化駆動型といわれています。
両者の特徴を大まかに述べると以下のようになります
▷ウォーターフォール
開発スコープ全体を一つの全体計画で実現するように計画し、要件定義からリリースまでの各フェーズを、先行フェーズの完了を受けて後続フェーズを開始する方法で行う。一次開発、二次開発という区切りで段階的リリースを計画することはあるが、その場合でも各次開発ではそこで実現する機能全部を対象として開発してリリースする。計画通りに行けば、要件定義時に対象とした全機能が、一気にリリースされる。
▷アジャイル
開発スコープ全体を機能単位に分割して、優先順位の高い機能から開発して適時にリリースしていくことを繰り返す、優先順位は原則として「価値の大きさ」と「早くできる程度」（期間の長短だけでなく時期的に早くできると価値が大きいかも考慮する）で考え、定期的に見直す。単位期間（スプリント）あたりの小さな成功を積み重ねる。使った時間の累積が価値の累積となる。
このことを「プロジェクトマネジメントの鉄のトライアングル」や「プロジェクトマネジメントにおける3つの制約」といわれる、スコープ、スケジュール、コストで表すと以下のようになります
▷ウォーターフォール
スコープを固定して、スケジュールとコストを可変とする。（実際には、スコープ変更があった場合には変更管理を行って、スケジュールとコストは許容できる限り固定のままを目指す）
▷アジャイル
スケジュールとコストを固定して、スコープを可変（トレードオフ）とする（スコープやリリース優先順位の変更があった場合、その影響によりある機能が当初計画したスケジュールとコストに収まらないとなれば当該機能は開発しないことがある）
（クリックで拡大）
（https://www.acqnotes.com/Attachments/MITRE-Defense-Agile-Acquisition-Guide.pdf）
ウォーターフォールでは要件定義で合意したすべての機能を開発しようとしますが、アジャイルでは一定のリソース（期間とコスト）で、変化に対応しながらできるだけ多くの要求を実現（価値を提供）しようとします。アジャイルでもプロジェクト開始前に一定のリソースでどれだけの要求が実現できそうかという見積もりは行います。発注者と受注者の関係がある場合には契約も必要です。但し、プロジェクト期間中にステークスホルダーと開発側で相談して、実現範囲や順序が変動するということです。
アジャイルの見積もりの例として、以前（2020/6/8）に記したScrum Inc. Japanのクライムマスター研修で解説されていたところから大きな特徴を3つ挙げます。
▷いきなり時間で見積もらず、まずはサイズで見積もる
所要時間は走者や環境によって変わり、人間にとって推量が難しい。
―フルマラソンの距離は一定だが、走破タイムは走者や環境によって異なる。
―人間は時間の長短よりも対象の大きさの方が認識しやすい。（「時計なしで何分走ったかを測る」よりも「ランニングウェアのSMLを見分ける」方がやりやすい）
時間はサイズを出した後で、サイズを実際に作業する人（複数人の場合はチーム）の単位期間あたりの期待処理能力で割って出す。期待処理能力は単位期間が終了する度に実績を見て修正する。
▷実際に作業をする人だけで見積もる。作業を完了させたいだけの人は見積もらない。
▷人やチーム間で見積もりを標準化しない。
アジャイルの特徴として「小さな成功を積み重ねる」と記しましたが、プロジェクト全体としてお成功率について、アメリカの調査会社「The Standish Group」による「Chaos Report」では、ウォーターフォールとアジャイルの実績が以下のように報告されています。
【2011-2015】
（https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf）
【2013-2017】
（クリックで拡大）
（https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/）
successful – the project was delivered on time, on budget and with all features.
challenged – the project was eventually delivered but either over budget, not on time or not fully completed.
failed – nothing was delivered.
このことからそのままアジャイルが方法として無条件に優れているとまでは見られないかもしれませんが、環境や条件に変化の速さ（＝それに応じた要求変化）への対応力が優れているようだとの見方は有力になりつつあるように思います。
前回のコラム（2020/11/09）でアメリカ国防総省の2010年の文書での記述を紹介しましたが、2013年には「すべての国防総省のITプロジェクトはアジャイル型のプロセスで行われなければならない」という法律が可決され、2014年にはMitre社（国防総省出資のNPO）から「Defense Agile Acquisition Guide」が出版されました。イギリスでも2016年に政府調達マニュアルに「You must use the agile approach to project management to build and run government digital services」と記されました。
日本では2019年に各府省情報化統括責任者（CIO）連絡会議決定として公表された「デジタル・ガバメント推進標準ガイドライン」に「利用者が多岐にわたり、要件定義等の関係者に対して綿密な調整が必要となる場合は、開発手法としてアジャイル型を導入することで、利用者の利便性を向上させるよう考慮する」と記述されています。
2021年1月
▶関連コラム｜ウォーターフォールモデル①（2020/7/27）