More than 3 years have passed since last update.

ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話

Last updated at 2021-02-18Posted at 2020-07-19

これは実話であり、公式記録、専門家の分析を元に構成しています。

TL;DR

ウォーターフォールは滝の様に上から下に工程が流れ、上には遡らないモデルとして知られています。
しかし、起源とされる1970年の論文においては上流への後戻りは避けられないものとされ、また基本設計の問題がいくつも工程を下ったテストで見つかるケースへの対策として、その場で上流工程に遡る代わりに基本設計〜テストを2セット繰り返し、1回目で見つかった問題の修正を２回目に反映する方式が提唱され、この方式は"Waterfall"という通称で呼ばれました。

この提案は発表から15年後に軍の納入仕様に取り込まれ、この時に反復回数はn回に拡張されました。
その9年後の改定の際、既存のものへの小変更向けに、反復なしの方式"Grand Design"も選べるようになりましたが、これが民間の国際標準 IEEE/EIA 12207.2-1997 に取り込まれた際に一般に通用しない軍隊用語と捉えられ "Waterfall" という名前が付けられました。

時代は移って2010年、軍は数々のソフトウェア開発プロジェクトの失敗を議会から問題視され、民間業界の手法であるアジャイルの導入を法律で義務付けられました。

年表

年	できごと	補足
1970	ウォーターフォールの原点の論文が発表	2回の反復型の提唱、後戻りの反映先は２回目
1985	DOD-STD-2167発行	反復回数のn回化、文書化・レビューの厳密化
1994	MIL-STD-498発行	反復なしの手法が選択肢に加わる
1998	民間のIEEE/EIA 12207による代替	反復なしの手法に"Waterfall"の名がつく
2010	国防権限法によりアジャイルが義務化	民間のアジャイル化の流れによる
現在	軍関連のプロジェクトの大半がアジャイル化	実態はまだ移行中

1970年：ウォーターフォールの原点の論文が世に出る

ウォーターフォールの原点とされているのは自動車・航空宇宙の部品メーカーTRW社のプロジェクトマネージャ Winston W. Royce氏による "MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS" という1970年の論文です[¹]。

Introductionに以下の文言がある事から、この論文は彼が９年間の間に味わった様々な苦い経験を元にしたためられた事が分かります[²]。

I have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs.

(投稿者訳)
私はこれまで稼働状態、納期、およびコストの面で、さまざまな成功の度合いに立ち会ってきた。

彼がこの論文の前半で提唱したのは、大規模ソフトウェア開発においてはトップダウンアプローチを用い、作業を7つの工程に分割せよという事です。
この論文に出てくる以下の図、人によっては親の顔よりも見た事でしょう。


Royce paper - Figure 2

しかし、こちらの論文で提案されている手法には現代知られているウォーターフォールとは異なる点が幾つかあります。ウォーターフォールの特徴と、それをRoyceが論文中で述べているかを比較しました。


要求,分析,設計,実装,テストの各工程に分割せよ	言ってる
前の工程の完了後に次の工程に進め	言ってる
工程ごとに別々の人員が担当するべき	言ってる
各工程の成果物をドキュメント化せよ	言ってる
前工程への後戻りは回避できる	明確に否定
要求仕様は早期に凍結できる	言ってない

まず、前工程への後戻りですが、Royce氏は起こりえる事だとしています。先ほどの図には前工程へのフィードバックが折りこまれた以下の図が続きます。


Royce paper - Figure 3

また、この図の説明においては理想的なケースにおいても1つ前の工程に戻る事が述べられています。

" Hopefully, the iterative interaction between the various phases is confined to successive steps. "

(投稿者訳)
理想的には、各段階において工程が前後する範囲は直近の工程に限られる。

理想的でない場合はどうかというと、テストから設計まで工程が戻りうると示唆しています。

"The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. "

(投稿者訳)
開発の終盤に位置するテスト工程は、タイミング、ストレージ、入出力転送などが分析工程での想定と異なったときに、それが初めて判明する工程である

彼はこの対策として "DO IT TWICE"として、現代の言葉でいう反復型開発のに近い手法を提唱しました。

If the computer program in question is being developed for the first time, arrange
matters so that the version finally delivered to the customer for operational deployment is actually the second
version insofar as critical design/operations areas are concerned.

(投稿者訳)
プログラムについての疑問点が初めて持ち上がった場合、設計やオペレーションについての深刻な問題が懸念されるなら
最終的に顧客に納品するのは2番目のバージョンにするよう働きかけるべきである。

それを図に表したのがこちら、左下が最初のバージョンです。前工程へのフィードバックを表す矢印が消え、２番目のバージョンの各工程へのフィードバックを示す矢印に変わりました。


Royce paper - Figure 7

これがどの程度のタイムスケールを想定しているかというと、例としてあげられているのがプロジェクト全体が30ヶ月、そのうち10ヶ月を最初のバージョンに充てるというものです。

なお、この図をよく見ると、2回行うのは基本設計以降で要求定義は含まれていません。彼は要求定義については以下の表現で言及しています。

For some reason what a software design is going to do is subject to wide interpretation even after
previous agreement. It is important to involve the customer in a formal way so that he has committed
himself at earlier points before final delivery.

(投稿者訳)
いくつかの理由により、あるソフトウェアが何をするものかについての解釈は、合意があって以降も大きく変わり得る。
最終納品よりも前の段階で正式な手段で顧客からの約束を取り付ける事は重要である。

要求仕様の凍結は最終納品前とし、要求が変わった場合どのようにすべきかについては特に触れていません。

論文を通してRoyce氏は過去の経験を元に以下の悲観的な見方をしています。

どうせソフトウェアは想定した通りには動かない
どうせ顧客は要求をコロコロ変える

上記から分かる通り、Royce氏の主張は現代知られているウォーターフォールとは大きく異なります。なお、ウォーターフォールという呼称もRoyce氏の提唱ではなく、この論文内にはwaterという単語すらありません。

語源とされているのは同じTRW社のT.E.Bell氏とT.A.Thayer氏が1976年に発表した論文 "SOFTWARE REQUIREMENTS: ARE THEY REALLY A PROBLEM?" においてです[³]。

The same top-down approach
to a series of requirements statements is explained,
without the specialized military jargon, in an ex-
cellent paper by Royce [5]; he introduced the concept
of the "waterfall" of development activities.

(投稿者訳)
一連の要求に対しての同様のトップダウンアプローチはRoyce氏の素晴らしい論文中で特殊な軍事用語無しで説明されている。彼は開発作業におけるウォーターフォールのコンセプトを提唱した。

この時代における"Waterfall"という言葉は反復を行うか否かに依らなかった様です。

1985年：DOD-STD-2167発行

DOD-STD-○○、MIL-STD-○○ とはDoD(Department of Defense = アメリカ国防総省)が発行する納入仕様書です、MILスペックという言葉であれば聞いたことがあるでしょうか。
元々、ボルトやネジのサイズなどの標準を発行していたものが、この時代にはソフトウェアの開発プロセスについても発行されるようになっていました[⁴]。

この DoD-STD-2167 はRoyce氏の影響を色濃く受けていますが、Royce氏の論文が11ページで大まかに概要を提案したのに対してこちらは95ページにも及び、各工程において何を行うか、どのようなドキュメントを残すか、どのようなレビューを行うか定めています[⁵]。

このDOD-STD-2167において以下の4つのSoftware Life cycleのphase(以後「段階」と訳)が定義されています。

Concept Exploration
Demonstration and Validation
Full scale development
Production and Deployment

上記４つのphaseはそれぞれ以下6つのSoftware Developmentのphase(以後、「工程」と訳)から成ります。
a. Software Requirements Analysis
b. Preliminary Design
c. Detailed Design
d. Coding and Unit Testing
e. CSC(Computer Software Component) Integration and Testing
f. CSCI Testing

各段階でどの工程を行うかを以下の表にまとめました。Yesは明記があった工程、Maybeは明記は無くとも文脈的に必要そうな工程です。

	1. Concept Exploration	2. Demonstration and Validation	3. Full scale development	4. Production and Deployment
a. Software Requirements Analysis	Yes	Yes	Yes	Yes
b. Preliminary Design		Yes	Yes	Yes
c. Detailed Design		Maybe	Yes	Yes
d. Coding and Unit Testing	Yes	Yes	Yes	Yes
e. CSC Integration and Testing		Maybe	Yes	Yes
f. CSCI Testing		Maybe	Yes	Yes

Royce氏論文の件の図と同様のものはここで Figure 1 として登場しますが以下のとおり前工程へのフィードバックを表す矢印がありません。


DOD-STD-2167 - Figure 1

しかし、こちらについては文章で補足されており、Royce氏の"DO IT TWICE"の発展形である事が分かります。

20.4.2. Full Scale Development.
...
It includes one or more major iterations of the software development cycle.

(投稿者訳)
これは１つまたは複数の主要なSoftware Development cylceのイテレーションを含む

4.1.2
...
　　　　　　　　　Figure 2 reflects the sequential
phases of a software development cycle, as well as the
documentation which typically exists prior to initiating an
iteration. During software development, more than one iteration
of the software development cycle may be in progress at the same time.
Each iteration represents a different version of the
software. This process may be described as an “evolutionary
acquisition” or “incremental build” approach.

(投稿者訳)
Figure 2 はソフトウェア開発サイクルにおける一連の工程とドキュメント(典型的には"iteration"開始前に作成する)を反映したものである。
ソフトウェア開発においては、同時に複数のイテレーションが進められる。
各"iteration"は個別のソフトウェアバージョンを表す。
このプロセスは進化的調達方式またはインクリメンタルビルドと呼ばれるであろう。

この話を先ほどのFigure 1に反映させると、以下のようになります。


DOD-STD-2167 - Figure 1改

さらには、以下の表現で工程が前後しうる事についても言及しています。

20.4.5.1
The phases in the software development cycle may involve
iterations back to previous phases. For example, design may
reveal problems which lead to the revision of requirements and
reinstitution of certain analyses; checkout may reveal errors in
design, which in turn may lead to redesign or requirements revision; etc.

(投稿者訳)
ソフトウェア開発サイクル中の工程は前の工程に戻る場合がある。
例を挙げると、設計では要求定義と分析の修正を要する問題点が、評価では設計や要求定義の問題点がそれぞれ発見され得る。

ここまでの話だと現代にも普通に通用しそうに思えるのですが、問題は各工程で作成すべき成果物と行うべきレビューをまとめたFigure 2です。


DOD-STD-2167 - Figure 2 (2ページを連結)

各工程ごとに多種多様なドキュメントを残す事が求められ、これだけでかなりの労力を要する事が分かります。

また、レビューについては各工程につき以下の2種類を行うことが求められています。

Internal reviews
- 開発企業社内のレビュー
Formal reviews
- 発注元への説明

後者のFormal Reviewで説明をする相手はおそらく軍の背広組で、スケジュール調整なども含めてかなり大変に思えますが、こちらも毎工程ごとに行う必要があります。

これらから見てわかる通り、"iteration" という現代の反復型開発モデルと同じ単語を使ってはいますが、1つのあたりの期間は現代の数週間という単位ではなく、Royce氏の提案と同様の相当長い期間の様です。
この "iteration" 1つの期間が分かる文献は見つかりませんでしたが、開発全体の期間が分かるものは見つかり、そちらによればHWも含めて13〜15年とありました(後述)。

2年後の1987年、国防総省の科学技術に関する調査・助言を行う連邦政府の諮問委員会DSB(Defense Science Board)は軍のソフトウェア調達プロセスについて調査するため、「人月の神話」で知られるFrederick P. Brooks氏をチェアマンとするタスクフォースを立ち上げました。このタスクフォースは報告書の中で DoD-STD-2167が時代遅れであると以下の言葉で指摘しています[⁶]。

DoD Directive 5000.29 and STD 2167 codify the best 1975 thinking
about software, including a so-called "waterfall" model

(投稿者訳)
DoD Directive 5000.29 と DOD-STD-2167 は"waterfall"と呼ばれるモデルを含め1975年当時の最善と思われたソフトウェアに関する手法を成文化している。

このDOD-STD-2167には明らかに反復型の要素が取り込まれているので、この時代において"waterfall"という言葉には、反復の有無は関係なかったことが伺えます。
また、Royce氏のアイデアは1970年当時としては先進的だったのは間違いないでしょう。しかし、17年後のBrooks氏らの目には古く非効率なやり方として映った様です。

さらにこの報告書は後継のDoD-STD-2167A についても触れ、代わり映えがないとすっぱりと切り捨てています。

DoD-STD-2167 likewise needs a radical overhaul to reflect best modern practice. Draft
DoD-STD-2167A is a step, but it does not go nearly far enough. As drafted, it continues to
reinforce exactly the document-driven, specify-then-build approach that lies at the heart
of so many DoD software problems.

(投稿者訳)
DoD-STD-2167 には現代のプラクティスを反映した大変更を行う必要があると思われる。
DoD-STD-2167A のドラフト版はその一歩ではあるが十分とは言い難い。
ドラフトに書かれたように、今の国防総省の多くのソフトウェアの問題の原因であるドキュメント駆動、仕様を固め終えてから開発という傾向はより強固になっている。

1994年：MIL-STD-498 発行

DOD-STD-2167発行から9年後の1994年6月、先述のDSB(Defense Science Board)は軍のソフトウェア調達に関する調査をまた行い、以下の問題点を指摘しました[⁷]。

High Life Cycle Cost in Time and Dollars

Software Development Cycle Tied to Weapon System Developments

Incredibly Long, Typically 13 to 15 Years from Concept to Fielding

Encourages Excessive Acquisition Agent Involvement in Design Detail and Process

Based on Mistrust vs. Mutual Trust

Excessive Documentation

Excessive Formal Review

Excessive Testing of Non-Critical Systems

Poor Communication Between Vendor, Acquisition Agent and User

No Requirements Addressing Cost and Schedule

Traditional Approach Used: Design it All and Then Build it

Little or No Requirements Relaxation for High Cost Items

Inadequate Beta Testing in Early Phase

Little Focus on Designing in Reusability

(投稿者訳)

金額、期間両方の面で高いライフサイクルコスト

ソフトウェア開発サイクルが武器システム開発に縛られている

典型例でコンセプトから配備まで13～15年という驚くべき長さ

調達部門による設計の詳細や工程への不必要な関与を求めている

不信用 vs 相互信用

過剰なドキュメント化

過剰なFormal Review (訳注：契約先の政府機関によるレビュー)

過剰な非クリティカル系へのテスト

乏しいベンダ-調達部門-使用者の間のコミュニケーション

コスト、スケジュールについての要求が無い

古い手法が用いられている：設計が全て終わってから実装に着手

高コストアイテムに対する要求の緩和が僅かか全くない

早期段階でのベータテストの欠如

再使用性の観点での設計について考慮が足りない

同じ年の11月、先述の DOD-STD-2167A を始めとした幾つかのソフトウェア開発に関する規定が廃止され、新しく発行されたMIL-STD-498よって代替されました[⁸]。

MIL-STD-498 の分かりやすい違いは、図表が全て複数回の"Build"に分けて開発できる事がはっきり分るよう書かれている点です。


MIL-STD-498 - Figure 1

なお、この"Build"という言葉の定義は以下の通りです。

3.7 Build. (1) A version of software that meets a specified subset of the requirements that
the completed software will meet. (2) The period of time during which such a version is
developed.

(投稿者訳)
Build : (1) 完成したソフトウェアの満たす要求の特定の一部を満たしたバージョンのソフトウェア。(2) そのバージョンの開発期間。

また、1987年にBrooks氏らによって "document-driven" と批判された大量のドキュメントは整理され、以下の22種類になりました。これらのドキュメントはDID(Data Item Description)と呼ばれ、全てテンプレートが用意されていました。

Software Development Plan (SDP)
Software Test Plan ISTP)
Software Installation Plan (SIP)
Software Transition Plan (STrP)
Operational Concept Description (OCD)
System/Subsystem Specification (SSS)
Interface Requirements Specification (IRS)
System/Subsystem Design Description (SSDD)
Interface Design Description IIDD)
Software Requirements Specification (SRS)
Software Design Description (SDD)
Database Design Description (DBDD)
Software Test Description {STD)
Software Test Report (STR)
Software Product Specification (SPS)
Software Version Description (SVD)
Software User Manual (SUM)
Software Input/Output Manual (SIOM)
Software Center Operator Manual (SCOM)
Computer Operation Manual (COM)
Computer Programming Manual (CPM)
Firmware Suppofl Manual (FSM)

また、レビューについても、発注元への説明を行うレビューは簡素化され、各"Build"につき1回の"Joint review"になりました。

さらには、各工程の説明に以下の説明が加えられ、例えば要求定義の説明においては要求分析が全て完了してから次のシステム設計に進む事は必ずしも必要ではないとされています。

5.3 System requirements analysis.
...
Note: If a system is developed in multiple builds, its requirements may not be fully defined
until the final build. The developer’s planning should identify the subset of system
requirements to be defined in each build and the subset to be implemented in each build.

(投稿者訳)
注意：システムが複数の"Build"に分けて開発される場合、要求は最終ビルドまで完全に定義されていなくても構わない。
デベロッパは各ビルドにおいて実装するシステム要求の一部を計画的に決める必要がある。

これを読んで「１つの"Build"だけで済ませるケースもあるのか？」と感じた方もいるかも知れません。実はその通りで、開発手法は以下の３つのうちの１つを選ぶ方式になっていました。


MIL-STD-498 - Figure 7

最初の "Grand Design" が１つの"Build"だけで済ませるケースです。この名前は以下の文章より DODI 8120.2 という国防総省の別の文書から来ている事が分かります。

G.3 Candidate program strategies. DODI 8120.2 describes three basic program strategies
...
a. Grand design. ...

DODI 8120.2 を調べると、Grand Designについて以下の記述がありました[⁹]。

a. Grand Design program strategies are
characterized by acquisition, development, and deployment of the
total functional capability in a single increment. The required
functional capability can be clearly defined and further enhancement
is not foreseen to be necessary. A grand design program strategy is
most appropriate when the user requirements are well understood,
supported by precedent, easily defined, and assessment of other
considerations (e.g., risks, funding, schedule, size of program,
early realization of benefits) indicates a phased approach is not
required.

(投稿者訳)
Grand Design方式は全ての機能の調達、開発そして配備を一度の
インクリメントで行うのが特徴である。要求された機能は明確に定義でき、追加の改良の必要は無いと考えられる。
Grand Design方式が最も適しているのはユーザの要求が深く理解され、前例があり、さらにその他の要因(例：リスク、資金、スケジュール、プログラムのサイズ、早期の実現による恩恵)により段階分けした手法が不要な場合である。

確かに、既存のものの小変更などであれば段階に分けたリリースなどせず最初から最後まで通しで行った方が早いので、それ用の方式が用意されるのも納得できます。

1998年：民間のIEEE/EIA 12207による代替

MIL-STD-498 は登場してすぐ民間の国際標準であるIEEE/EIA 12207.2-1997に取り込まれたのち廃止されました[¹⁰]。ただし、システムのライフサイクルについて定めた DODI 5000.2 等は現代に至るまで引き続き発行されています。
MIL-STD-498 と IEEE/EIA 12207の関係については米海軍SPAWAR(Space and Naval Warfare Command) Systems Centerの資料が分かりやすかったので引用します[¹¹]。


SPAWAR presentation page 9

IEEE/EIA 12207 は MIL-STD-498にあった数々の軍隊用語が置き換えられ、先ほどの表はSPAWAR資料によれば以下に変わったとあります。

Program Strategy	Define All Requirements First?	Multiple Development Cycles	Distribute Interim Software?
Once-Through(Waterfall)	Yes	No	No
Incremental(Preplannned Product Improvement	Yes	Yes	Maybe
Evolutionary	No	Yes	Yes

MIL-STD-498 にあった "Field"(動詞形) という単語は "Distribute" という馴染み深い言葉に置き換えられていますが、それと共に "Grand Design" は "Once-Through(Waterfall)"に変わっています。

先ほど述べた通り、"Grand Design" は DODI 8120.2 においては小規模な差分開発用の方式でしたが、それに大規模なフルスクラッチ開発用の手法の通称だった"Waterfall"の名前が着けられました。今までに"Waterfall"と呼ばれた手法を比較してみます。

年	"Waterfall"と呼ばれた手法	呼んだ人	全ての要求定義を最初にする？	開発サイクル数	暫定SWの供給
1976	Royce氏の "DO IT TWICE"	Bell氏,Thayer氏	Yes	2回	No
1987	DOD-STD-2167 の "incremental build"	Brooks氏ら	Maybe	n回	Maybe
1998	IEEE/EIA 12207.2-1997 の Once-Through	-	Yes	1回	No

これまでの2つと異なり、IEEE/EIA 12207.2-1997の "Once-Through(Waterfall)" は現在知られるウォーターフォールと特徴が一致します。また、これまで"Waterfall"という言葉はあくまで通称だったのに対し、ここでは正式な文書の中で明確に定義されている点も異なります。

もしかしたら、この90年代にはすでに"Grand Design"の事を"Waterfall"と呼ぶ風潮があったのかも知れません。しかし、投稿者の個人的な感想ではありますが、IEEEの国際標準ほどの影響力を持った個人・団体は殆ど無いため、反復なしの開発手法が "Waterfall" として広まった決定打はこの IEEE/EIA 12207.2-1997 ではないかと考えています。

2010年：国防権限法によりアジャイルが義務化

2009年3月、DSBは議会の要請により行ったITシステムの調達に関する調査結果を報告しました[¹²]。その中で数々の問題点が指摘されていますが、特にChapter 5で挙げられているのは以下の例です。

開発期間の長さ
- 32の主要なITシステムの調達事例において、最初の配備まで平均91ヶ月。
コストの超過
- 例：Joint Tactical Radio System (JTRS)プロジェクト
  - 計画：32億ドル
  - 実際：83億ドル
性能未達
- 例：Electronic Data Systems (EDS)プロジェクト
  - 20の性能目標のうち3つのみ達成
  - ドキュメント１つ開くのに45分

DSBはこの問題の原因の一つが既存の調達方式が"Waterfall"である事とし、Chapter 6においてアジャイル式の調達手順を法制化するよう提言しました。


March 2009 DSB Report - Figure 14 (既存方式)


March 2009 DSB Report - Figure 20 (アジャイル化)

用語説明

略語	正式名称	説明
IOC	Initial Operatiing Capability	一部の部隊において配備され使用可能になった事
FOC	Full Operating Capability	全部隊への配備予定となりメンテナンス可能になった事

ここで、「アジャイルは軍で行う様な大規模プロジェクトには向かないのでは？」という疑問を持った方も多いかもしれません。かくいう投稿者も大学時代はソフトウェア工学のテストに「アジャイルは小規模プロジェクト向け」と解答した記憶があります。

しかし、2000年代後半あたりからアメリカの民間企業の間では大規模プロジェクトにアジャイルを適応させる取り組みを進んでいた様で、「欧米の企業名 + agile transformation」で検索すると、大抵アジャイル導入事例が見つかります[¹³]。

例えばソフトウェア業界の老舗Microsoft社も大規模プロジェクトをアジャイル化した企業の一つで、特に約800人からなるVSTS(Visual Studio Team Services)事業をアジャイル化したケースでは、アジャイル化の理由やチームの編成方法などが一般に公開されています[¹⁴]。

DSBが主張したのはこのような民間のアジャイル化の流れに軍も乗るべきだという提案です。この提案は議会に認められ、NDAA(National Defense Authorization Act：国防権限法or国防授権法)に盛り込まれました。これはその年の国防予算の大枠や調達方法について定めた法律であり、当時のオバマ大統領により署名された2010年版NDAAのSEC.804で以下の規定がされました[¹⁵]。

SEC. 804. IMPLEMENTATION OF NEW ACQUISITION PROCESS FOR INFORMATION TECHNOLOGY SYSTEMS.
(a) NEW ACQUISITION PROCESS REQUIRED. —The Secretary of Defense shall
develop and implement a new acquisition process for information technology systems.
The acquisition process developed and implemented pursuant to this subsection shall,
to the extent determined appropriate by the Secretary—
- (1) be based on the recommendations in chapter 6 of the March 2009 report of
  the Defense Science Board Task Force on Department of Defense Policies and Procedures
  for the Acquisition of Information Technology; and
- (2) be designed to include —
  - (A) early and continual involvement of the user;
  - (B) multiple, rapidly executed increments or releases of capability;
  - (C) early, successive prototyping to support an evolutionary approach; and
  - (D) a modular, open-systems approach.

(投稿者訳)

セクション. 804. 新たなITシステム調達方式の導入

(a) 新たな調達手順を要する. —国防総省長官はITシステムの新たな調達手順を立案および実施しなければならない。
このサブセクションに従って立案および実施される調達手順は長官が適切と判断した範囲で—

(1) DSBの2009年3月のレポート chapter 6の提案(訳注：上述のアジャイル化の提案のこと)に基づくこと; また

(2) 以下を含める様に立案すること —

(A) 早期かつ継続的なユーザの参加;

(B) 複数回, 迅速に行われる機能のリリースまたは増加;

(C) 革新的アプローチをサポートする早期, 継続的なプロトタイピング; また

(D) 部品化, オープンシステムアプローチ.

簡単に言えば、義務を課せられたのは企業ではなく国防総省の方で、アジャイルベースの調達手法を導入せよというものです。むろん軍にITシステムを収める各種軍需企業も大きな影響を受けました。NDIA(National Defense Industrial Association) は各企業が新基準下でどんな対応が必要かまとめたガイダンス資料を公開しています[¹⁶]。

現在:アジャイル化が進行中

アメリカ軍のソフトウェア開発のアジャイル化の最も大きな例としてはステルス戦闘機F-35のソフトウェア開発プロジェクトがC2D2 (Continuous Capability Development and Delivery) と呼ばれるアジャイルベース方式に移行した事が挙げられます[¹⁷][¹⁸]。

||
|:---:||
| 航空自衛隊公式サイトより F-35A |

また、これに伴ってかF-35の主契約企業Lockheed Martin社のアジャイル導入事例が報告されており[¹⁹]、Northrop Grumman[²⁰], Raytheon[²¹]といった他の主要軍需企業も続いています。

他にも多くの軍のSW開発プロジェクトがアジャイルに移行したものの問題は多い様で、名目だけアジャイルなケースが多いことがDSBとは別に立ち上げられた独立委員会DIB(Defense Innovation Board)の2018年の文書 "Detecting Agile BS" の中で触れられています[²²]。

Agile is a buzzword of software development, and so all DoD software development projects
are, almost by default, now declared to be “agile.” The purpose of this document is to provide
guidance to DoD program executives and acquisition professionals on how to detect software
projects that are really using agile development versus those that are simply waterfall or spiral
development in agile clothing (“agile-scrum-fall”).

(投稿者訳)
アジャイルとはソフトウェア開発におけるバズワードであり、そのため国防総省のSW開発プロジェクトはその全てが殆ど当然の事として名目上はアジャイルとなっている。
この文書の目的は国防総省のプログラムエグゼクティブと調達担当者に対してSWプロジェクトが本当にアジャイルなのか、
それともアジャイルを装ったウォーターフォールやスパイラル(agile-scrum-fall)なのか見分ける方法を提供する事である。

しかし、これは米軍だけの問題では無い様で、英語圏のSWEの間ではアジャイル失敗あるある集だと話題になっていました[²³]。なお、BSとは "Bullshit" の略で、直訳すると「牛のフン」ですが、スラングで「嘘」などの意味になる様です。これを踏まえると、Agile BSとは「似非アジャイル」という意味でしょうか(非ネイティブの投稿者にスラングは厳しい・・・)。

この中で特に判定図が評判だったので、翻訳してみました。