TL;DR
前回の記事「ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話」 が長すぎたので要点をまとめました。
Wikipedia(日本語版 , 英語版 ) や過去の文献などにおいては、ウォーターフォールの元とされるRoyce氏の論文の存在や、それが米軍のMILスペックに取り入れられた事などに触れていますが、どのようにして現在知られる形に変わったかまでは書かれていません。
そこで、 米国防総省 の公開資料や、 Defense Science Boardという国家機関の報告書などを調査したところ、以下の事が分かりました。
- 軍の通称「ウォーターフォール」は2種類
| 正式名称 | 概要 | 反復型か | プロトタイプ |
|---|---|---|---|
| Incremental Build | Royce氏手法の発展形 | YES | あり |
| Grand Design | 小規模開発むけ簡易版 | NO | なし |
- ISO/IEEEの国際標準に採用された「ウォーターフォール」は小規模向けの方
| 軍正式名称 | 民間名称 |
|---|---|
| Incremental Build | Incremental Build |
| Grand Design | Once-Through(Waterfall) |
軍のウォーターフォールモデル
軍のDOD-STD-2167で規定されたIncremental Buildのライフサイクルモデルを図に起こしました。
Lockheed、Boeingなどの軍需企業はこれに従ってソフトウェアを開発する必要がありました。
要求分析～システムテストの流れ1つはIncrementと呼ばれ、システムのライフサイクルは4つのフェーズに分かれ、各フェーズは1～N Incrementから成り立っています。
"CONCEPT EXPLORATION"などのフェーズの数や名前は時代によって変遷していますが2010年頃まではおおよそ同じような方式だった様です。
Grand Designは小規模な差分開発などを対象とした、ライフサイクルのフェーズ分割が無く、Incrementも全体で1回だけで済ませる簡易版です。
Incremental Buildは一見良くできたモデルに見えますが、 人月の神話 の著者で知られる Frederick Brooks 氏らはこれをウォーターフォールだとし、以下の問題点を指摘しました。
- 開発プロセスがドキュメント駆動である
- 要求が決まってから開発に進んでる
Brooks氏の不満を説明するために、各開発モデルを比較します。
開発モデルの比較
ここでは Karl Scotland氏の提案する分類 に従って説明します。作図の都合上、工程が色々と省かれていますがご了承ください。
Incremental
工程が100%完了してから次の工程に入り、システムテスト工程まで終わったら顧客(軍ではどこかの部隊)のからのフィードバックを受けて次の機能に取り掛かります。米軍においてはIncrement間はオーバーラップしないため、現在のIncrementが完了してから次のIncrementに進みます(2010年以前の話)。
Big Bang (米軍：Grand Design)
1つのIncrementで全てを済ませるため、最初に全ての要求を出し切ります。軍での想定用途は既存装備の小改修だった模様です。
Iterative
要求を100%定義し切らず開発に移ります。これの良い説明を見つけたのでリンクを貼っておきます。
https://ubiteku.oinker.me/2016/07/25/iterating-and-incrementing/
この方式は軍では用いられず民間で発達したようです。Brooksが軍のIncremental Buildを扱き下ろしたのは、このIterative性の欠如だと考えられます。
Incremental + Iterative (Agile)
IncrementalとIncrementalの合わせ技です。
非常に有名なモデルなので説明は省略します。
Q&A
なぜウォーターフォールに前工程への後戻りが無いのか
ウォーターフォールの元となったRoyce氏の論文において、1つだけ戻る事(例：設計←実装)は特に否定されていません。
問題は1工程だけでは済まないケースで、例えば分析時点の想定が外れて性能等の問題が生じる場合、その発覚は工程を幾つも下ったテストとなるため、Royce氏はその場で分析工程に戻ってやり直すよりも最初をプロトタイプ開発とし、その知見を元に１から作り直した第二版を客先にリリースすることを推奨しています。
実はBrooks氏も「人間の神話」の中で同様の主張をしています。
 |
|---|
| Royce paper - Figure 7 |
設計と実装は別の人がやるべきか
Royce氏は論文中でそう主張しています。
They must be planned and staffed differently for best utilization of program resources.
ただし、現代の米国のIT企業においてはSWEが上流から下流まで面倒を見るのが一般的なようです。
なぜ米軍はウォーターフォールをやめたか
法律(NDAA 2010)でアジャイル化が義務化されたためです。
きっかけは米国の会計監査院である GAO による勧告です。GAOは同様の勧告を様々な省庁に対して行っています( 国土安全保障省の例 )。
おわりに
同じ「ウォーターフォール」という単語でも米軍と民間とでは指す範囲が異なり、軍関係ではIncrementであろうがIterative性が無ければ「ウォーターフォール」扱いであろうというのは自分でも意外でした。
| Iterative | Incremental | 民間呼び名 | 米軍呼び名 | |
|---|---|---|---|---|
| No | No | ウォーターフォール | ウォーターフォール | |
| No | Yes | - | ウォーターフォール | |
| Yes | No | - | - | |
| Yes | Yes | - | - |
もともとはF-35の制御ソフトウェア開発がアジャイルになったという話を書こうとして米国政府の公式資料を調べていたら"So called Waterfall"などと記載された開発モデルが何故か反復型なのを見つけたところから始まり、脱線に脱線を重ねてソフトウェア開発の歴史を調べてしまっていました。
タイトルの最後に「かも」と付いているのは、IEEE関係なしに当時すでにそういう名称が広まっていた可能性があるためです。
こういった分野を調べている人はかなり少数の様なので、他にも興味を持ってくれる人が出てくれたら嬉しいなと思います。