アジャイル開発の名前や手法は、Kent BeckやJeff Sutherlandらの「アジャイルソフトウェア開発宣言」（2001年）によって世に知られるようになったことをご存じの方も多いと思います。
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。「アジャイルソフトウェア開発宣言（2001年）」
最近ではソフトウェアやシステム開発現場だけでなく、組織開発や教育分野など経営全般にも拡がるアジャイル手法ですが、一般のビジネスパースンだけでなく、アジャイル開発を実践している人であっても陥りやすい間違いに、次の２つがあると感じています。
１．今までのシステム開発ではウォーターフォールが主流であった。
２．アジャイル開発は上記の「アジャイル宣言」（あるいはXPやスクラムなどの手法の開発）に始まる新しいシステム開発手法である。
アジャイル宣言やそれに基づいた本「だけ」を読むと、このように誤解するのは無理がないことかもしれません。しかしこのような誤解が広がっているために、「アジャイルは（まだ確立されていない）新しい手法」「うちのような大企業は伝統的なウォーターフォールが向いている」と経営陣が誤った判断の根拠としまっていることも少なくないと考えます。
ここでは、今までのシステム開発の簡単な振り返りと、「システムズエンジニアリング標準」を参照しながら、システムエンジニアリング（SE:Systems Engineering）の視点から見たアジャイル開発について書いてみたいと思います。
システム開発に限ったことではありませんが、正しい概念を知ることで、初めて自社にあった手法を採用できるものだと思うからです。
アジャイル（反復進化型）開発は1960年代から行われていた。
今出版されている様々なアジャイル関連の本を読んで勉強をしてきた人は、この手法は90年代になって初めて、XPやスクラム等の創設者によって「アンチ・ウォーターフォール」の意図を持って開発されたと思っている人も少なくないかもしれません。
私が先日受講した「認定スクラムマスター」の講習会においても、そのような（少なくともそのように解釈できる）表現が頻繁に聞かれました。
しかし実はこの「アジャイル手法」は少なくとも1960年代から米国を中心に多くのシステム開発の現場で行われていました。（もちろん当時「アジャイル開発」という言葉は存在していないので、ここでは反復進化型開発(Iterative and Incremental Development:IID)という用語を使用します。）
例えばこのIIDの手法を体系化した一人にTom Gilbがいます。彼が60年代から行っていた手法は、Evo（Evolutionary Project Management）と名付られ、1976年に出版された「Software Metrics」で手法が公開されています。
また、大規模開発の分野でも、1958年に始まったNASAの有人人工衛星プロジェクト「マーキュリー計画」では、IIDの手法が採用されていました。マーキュリー計画では、半日ごとのイテレーション、「継続的インテグレーション」や「テスト駆動開発」など、今のアジャイル開発手法と変わらない手法が既に実現されていたと言われています。
このマーキュリー計画のソフトウェア開発を担ったのはIBMのチームでしたが、当時のオペレーティング・システム開発マネージャーが、ソフトウェア工学の先駆者として知られ、「プログラミングの心理学」や「一般システム思考入門」など多くの著書を持つGerald Weinbergです。
Weinbergは後に「我々はマーキュリー計画のシステムをインクリメンタル（進化型・漸進型）に構築し、大きな成功を収めることができた。マーキュリー計画が養成所の役割となって、IBMの政府関連システム部門ができた。そのためこの部門はインクリメンタルな開発の歴史と伝統とともに開始したということができる。私が覚えている限りでは、我々全員が、巨大プロジェクトにウォーターフォールを適用することなどかなり愚かで、少なくとも現実を認識できていないことだと考えていた。」と書いています。
「Systems Engineering handbook 4th Edition」
ウォーターフォールについての誤解の歴史
ウォーターフォールがシステム開発の主流の手法と言われるようになったのは1970年代からです。しかしこれは決して必然ではなく偶然と誤解に基づいたものでした。
システムズエンジニアリングの標準団体であるINCOSE（The International council on Systems Engineering）が発行している「Systems Engineering Handbook」など多くの書籍や論文では、「ウォーターフォールモデル」の起源はWinston W. Royceの論文「Managing the Development of Large Software Systems」（1970年）であると書かれています。
しかしこの論文を読んでみると、どこにも「Waterfall」の用語がないばかりか、実際には反復型の開発が推奨されていて、下図のように、「The iterative interaction between the various phases is confined to success.」（様々なフェーズの間で反復を行うことが成功に繋がります。）、「Attenpt to do the job twice, the first result provides an early simulation of the final product. 」 （2回試行すれば、最初の製品（プロトタイプ）のシミュレーション結果に基づいて、最終製品を製造することができます。）とRoyceは主張しているのです。
「Managing the Development of Large Software Systems（Winston W. Royce 1970）」
実は「ウォーターフォール」という言葉が初めて使用されたのは、Bell and Thayerの論文「Software requirements: Are they really a problem? 」（1976年）です。彼らが「ウォーターフォール」の説明でRoyceの論文を引用したことから、ウォーターフォールの元祖はRoyceであり、彼の論文でも反復進化型（IID）ではなくウォーターフォールモデルを推奨しているという誤解が拡がることになりました。
その後、世界最大のシステム発注者である米国防総省によって定められたシステム標準の「DOD-STD-2167」が、ウォーターフォールモデルを採用したことから、国防総省にシステムを納入するすべての企業がこのモデルを採用してシステム開発を実施しなければならなくなりました。
その理由として、この2167標準が、文書を基に要求レビューを行うための標準である「MIL-STD-1521B」とセットで運用されることが多いため、工程ごとに一つ一つドキュメントを作成して次の工程へと受け渡す「ウォーターフォールモデル」が管理しやすいと思われたからのようです。（お役所仕事でいちいち文書が求められるのは、どの国も同じようです。）
1995年の国防総省の報告書では、プロジェクトの75％は失敗したか使われずに終わり、大規模な変更なしに使われたのは2％に過ぎないとされています。
結局「DOD-STD-2167」は1994年に廃止され、「MIL-STD-498」に引き継がれました。
「MIL-STD-498」では、ウォーターフォールモデルや、開発中の文書によるレビューが廃止され、今後は「Grand Design」「Incremental（漸進的）」「Evolutional（進化的）」「Reengineering（製品中心から顧客志向、プロセス思考への再構築）」「Reverse Engineering（製造を先に行ってから後に設計を行う）」などの現在のアジャイルで行われている手法で開発を進めていくことが決められました。
「MIL-STD-498：Software Development and Documentation」（Perry R DeWeese 1994年）
しかし米国防総省が定めた「DOD-STD-2167」は他の米国省庁だけでなく、英国やドイツなど他国の防衛産業を始めとする国家プロジェクトの「標準仕様」となったため、世界中に「ウォーターフォールモデル」が拡散することとなりました。
1994年に米国でこの標準が廃止された後も、各国ではいまだ採用され続けていて、21世紀に入ってようやく見直しが広がっているのが現状です。
スパイラルモデル・UP（統一プロセス）からアジャイルへ
反復進化型（IID）の手法は80年代以降も進化を続け、1988年にはBarry Boehmが、トップダウン設計とボトムアップ設計の長所を生かしたソフトウェア開発工程のモデルであり、設計とプロトタイピングを繰り返して開発していく手法であるスパイラルモデルを発表します。これはその後Vモデルなどの要素を組み入れたICSM（Incremental Commitment Spiral Model）へと発展していきます。
またスパイラルモデルと同じように、開発工程全体を管理するためのプロセスとシステムを徐々に繰り返して構築していくプロセスの統一を目指した手法が、Unified Process（UP：統一プロセス）です。このUPを基にして、Rational Software Corporationが開発したフレームワークがラショナル統一プロセス（RUP）で、Rational社がこの仕様をオープンソース化したため、民間でのシステム開発手法としてRUPは広く採用されるようになりました。
アジャイル宣言が出された2000年ごろは、比較的小規模な開発でXPやスクラムなどの「アジャイル開発」が適用され、大規模開発ではスパイラルモデルやRUPが採用されることが多かったようです。
しかし2003年にRational社がIBMに買収され、RUPは単独の開発プロセスからIBMの所有する「モデルベース開発のライブラリ」という位置づけになっていきました。そしてアジャイル開発、特に「スクラム」が大企業のプロジェクト現場でも拡がるようになりました。
システムズエンジニアリングの視点からのアジャイル開発
かつて「アジャイル手法は反復進化型開発（IID）のサブセット（部分集合）である」と言われてきましたが、現在ではスクラムやSAFe等を中心に「メインの手法」となってきていると思います。
しかしながら今でも特に日本の大企業の経営層からは、「アジャイルは傍流」「新しい手法のため導入にリスクがある」というイメージが抜けきれていません。
これは、一つには米国では25年以上も前に「効果がない」と廃止されたウォーターフォールモデルを「システム開発の基本形」と教えてきた日本の「システム教育」「ソフトウェア教育」の問題であるとともに、アジャイル開発を「数十年に渡るシステム開発の歴史とともに発展してきた、反復進化型開発（IID）の最新手法」というよりも、「ウォーターフォールという既存の開発手法に対抗する新しいアプローチ」と自らを喧伝してきた、アジャイル開発側の問題でもあるように思えます。
先の読めないVUCAの時代と言われ、このような時代のソリューションとしてアジャイルに注目が集まっている今だからこそ、システムエンジニアリング（SE:Systems Enngineering）の視点から、アジャイルをきちんと捉え直すことが必要なのではないかと考えています、
