システム開発に関わる人であればプロジェクト管理そのものには一家言あるものですが、そこで使われている様々なプロジェクト管理手法がどのような歴史を経て今の形に至ったのか、ほとんどの人は知らないのではと思います。
もちろん、重要なのはプロジェクト管理手法そのものであり、その歴史自体は重要ではありません。しかし、手法が生まれた背景がわかると概念の理解も深まるのではないでしょうか。
プロジェクトの歴史は人類の歴史と共に
プロジェクト管理の歴史をどこから始めるかというのはなかなかの難問です。
プロジェクト管理の前には当然プロジェクトがあり、大きなプロジェクトは紀元前から存在しました。大規模プロジェクトとして最も有名な例は紀元前2500年頃に建てられたと言われるギザの大ピラミッド群です。建設に関わった労働者が書いたと思われる落書きがクフ王のピラミッドの中に残されており、ここから労働環境を知ることができます。
ピラミッドの建設には、食糧の生産・提供といった補助的な仕事をしていた人々を除いてすら、2000人からなる部隊があり、その部隊は、サァと呼ばれる200人規模の中隊、さらにその下には10以上の小隊があるという、少なくとも3階層以上の組織階層から構成されていたと考えられています。
数十年前の知識では、これらの労働者は奴隷労働により従事していたと考えられていましたが、現在では技術を持った労働者集団であったことがわかっています。彼らには給料として定期的なパンの支給が行われ、出退勤の管理も行われていたようです。
このように現代の企業でも採用されているような組織管理手法が紀元前から存在していたことには本当に驚かされますが、現代で行われているようなスケジュールベースのプロジェクト管理が発明されるまでには長い時間が必要でした。
現代的プロジェクト管理の始祖としてのガントチャート
現代的なプロジェクト管理はいつ始まるのでしょうか。1890年にヘンリー・ガントが発明したガントチャートがはじまりだとされています。
ガントチャートは、プロジェクトを小さなタスクに分割し、開始、終了を棒グラフで視覚的に表現することでスケジュール管理を行う手法で、MS Project や Jira、Asana といった多くのタスク管理ツールに搭載され、今でも広く使われています。
この時代にはコンピューターはありませんから、当然ソフトウェア開発のために作られたものではありません。ソフトウェア業界にいると忘れがちですが、PMBOK を始めとする「プロジェクト管理」の手法は、建設業、製造業など業種業態に関係なくあらゆるプロジェクトに適用する前提で構築されています。アジャイル開発の源流にトヨタ生産方式があることからもわかるように、むしろ建設業、製造業で生まれた方法論がソフトウェア開発に転用されていくという流れがあります。
ガントは、科学的管理法の父と呼ばれるフレデリック・テイラーの下で彼の理論を支援するために働いており、テイラーの代表的な「ショップ・マネジメント」論文と同じ雑誌内で、彼の理論を補強するものとしてガントチャートの原型を発表しました。当時の生産管理はせいぜい局所的最適化しか行われておらず、全体最適化という発想がありませんでした。ガントは、ガントチャートによって工場全体の最適化することを考えていました。残念なことにこの論文は、その後にテイラーが発表した同名の書籍に収録されなかったため、話題になりませんでした。
ガントチャートの普及のきっかけは、1914年に始まった第一次世界大戦や1930年に始まったフーバー・ダム建設といった大規模建設プロジェクトだったと言われています。ガントが発明した当時のガントチャートは我々が知っているグラフィカルなものではなく数値ベースの表でしたし、プロジェクトの管理に使うことを目的としたものではありませんでしたが、普及する中で徐々に現在使われる形に変わってきたようです。
ガントチャートのプロジェクトをタスクに分割するという発想は、WBS（ワーク・ブレイクダウン・ストラクチャー）の基礎にもなっています。
余談ですが、ガントチャートを最初に発明したのはガントではなく、ポーランドの経済学者キャロル・アダメスキーだとされています。キャロルは、1896年に同様の技法を発明し「ハーモノグラム」という名前で発表しました。しかし、ポーランド語とロシア語でしか発表されなかったため、西欧ではまったく認知されていなかったため、ガントの名で広まることになってしまいました。新しい発見をしたらとりあえず英語で発表しておけ、とはよく言われますが、その典型のような結果になってしまいました。
プロジェクト管理＝スケジュール管理だった時代
プロジェクト管理が建築業、製造業から始まったことも起因していますが、当時の問題意識は「プロジェクトが失敗するのは、タスクが効率よくスケジューリングされないことにより、資源の無駄遣いが生じてしまう」というものでした。OS が命令の処理順序をスケジューリングするのと同じ発想です。
ガントチャートはあくまでタスクの視覚表現に過ぎず、そこに依存関係は考慮されていませんでした。1950年代に入り、ほぼ同時期にタスクの時間と関係性からプロジェクトが完了するまでの時間を推定する CPM と PERT という２つの方法が発明されました。
1957年デュポン社ののモーガン・R・ウォーカー率いるチームは、複雑な製造プロジェクトを制御するためのシステムを開発するため、世界最初の大型コンピューター ENIAC の発明者としても知られる UNIVAC社のジョン・モークリー博士に依頼したことがきっかけでした。モークリーは、与えられた課題をあらゆるプロジェクトに適用できるように拡張するよう J. E. ケリー Jr. をチームリーダーに任命しました。
彼らがその経験を元に発表した論文は、1958年にアメリカ国防総省のアメリカ海軍特別プロジェクト局が、冷戦時代の移動式潜水艦発射弾道ミサイル「ポラリス」プロジェクトに影響を与え PERT （Program Evaluation and Review Technique）の発明に繋がります。これは、各タスクにかかる時間と依存関係からプロジェクト完了までの時間を確率的に推定するというもので、その後アポロ計画でも使われるなど広く普及しました。ツールの機能として採用されていることは少ないですが、ネットワーク構造のPERT図はタスクの依存関係を表現する手法として使われます。
ウォーカーとケリーJr.は PERT から生まれたクリティカル・パスという用語を援用しつつ自身の手法を洗練させ CPM を生み出します。基本的な考え方はPERT と同じですが、時間だけではなく費用の最適化も考慮されていること、確率的ではなく決定論的だという点に違いがあります。現在でもガントチャートに付随する機能としてクリティカル・パスの名前とともに使われています。
1962 年には前述の「ポラリス」プロジェクトの中で生まれたもうひとつの概念 WBS （Work Breakdown Structure）がアメリカ国防総省などからサービス規格のためのガイドとして公開されました。WBS はプロジェクトで必要な成果物とそれを作成するタスクを網羅的に一覧化して階層的に整理したものです。
WBS、CPMはガントチャートの延長として使えるという利点もあいまって、最も一般的なプロジェクトのスケジュール管理手法として使われていることはご存知の通りです。これらの手法は 1980年代後半に一般化してきた進捗度を金銭価値に換算して管理する「アーンド・バリュー・マネジメント（EVM）」の考えが加わり、現在の形に至っています。
もうひとつのスケジューリング手法 CCPM
主流ではない、もうひとつの有名な手法として、制約理論に基づいたスケジューリング手法 CCPM（Critical Chain Project Management）があります。制約理論（TOC/Theory of Constraints）は、1984年にエリヤフ・ゴールドラットが書いたベストセラー小説「ザ・ゴール」にて発表されましたが、その後経営学に取り込まれサプライチェーン・マネジメント（SCM）の基礎となりました。ゴールドラットはその概念をタスク管理にまで拡張し、CCPMとして発表しました。
CCPM では、各タスクの期間を見積り、その半分の期間をスケジュールします。そして残りの半分はバッファとして確保しておき遅延発生時にはそこから割り当てるようにします。また、マルチタスクは禁止されます。CCPMの発想は、人間は時間的余裕があると怠けてしまうであったり、マルチタスクは人間には難しいといったヒューリスティクスに基づいており、この人間に基礎を置く考え方はアジャイル開発に通底するところがあります。
また、制約理論が主張する「ボトルネックがシステム全体の性能を決定する」という考え方は、トラブル発生時の行動指針として有用かもしれません。この考えに従えば、データベース・サーバーがボトルネックになっているのにアプリケーション・サーバーの数を増やしてしまうなどといったことは避けられるかもしれません。
プロジェクト管理の専門化とコンピューターの登場
1950年代以降、プロジェクト管理が場当たり的なものから専門的な技法に基づくものに変わるに従い、専門知識の普及が求められるようになりました。この時代に後に PMBOK を提供することになる PMI など複数の団体が設立されています。
- 1956年 プロジェクト管理や計画、スケジューリング、コスト見積りを行うコスト・エンジニアのための団体 AACE（The American Association of Cost Engineers／現 AACE International）が設立
- 1965年 国内外の約50のプロジェクトマネジメント協会の連合体として IPMA（The International Project Management Association）が設立
- 1969年 プロジェクトマネジメントの実践、科学、専門性の向上を目的とした非営利の専門組織として PMI （Project Management Institute）が設立
一方、1970年代になるとコンピューターが普及し始め、プロジェクト管理という概念は大きな壁に直面します。情報システムの開発プロジェクトにおいて、大幅な遅延やコストオーバーが多く発生したのです。
建設業や製造業でも問題は起こるものですが、ソフトウェア開発のプロジェクト管理は特に難しく、業種間でのプロジェクト管理レベルを調査した研究でも、比較的管理レベルが高いにも関わらず、プロジェクトの失敗率は高いという結果が報告されています。
このような背景もあり、この頃からプロジェクト管理に関するガイドラインを整備する動きが始まります。
1975年 Simpact Systems Limited はプロジェクトの遅延や予算超過に対応するため、進行の流れを PROMPTII（Project Resource Organisation Management and Planning Techniques）というガイドラインに整理しました。このガイドラインは 1979年にイギリス 中央電算電気通信局（CCTA）の情報システム開発プロジェクトに適用される標準として採用されます。
この PROMPTIIは、1989年にイギリス政府のプロジェクト管理標準 PRINCE（Projects in controlled environments） に発展し、1996年の PRINCE2 に繋がっていきます。PRINCE2 は 1998年、2002年、2005年、2009年、2017年の改訂を経て、2018年にはアジャイル開発対応版もリリースされています。
ヨーロッパや国連では PRINCE2 が標準として用いられていますが、アメリカや日本においては、PMBOK が一般的に利用されます。PMBOK は1987年にPMIがホワイトペーパーとして発表したのがはじまりです。1998年には アメリカ規格協会（ANSI）、電気・情報工学分野の標準化団体 IEEE において標準規格としても承認されています。PRINCE2 がプロセスに焦点を当てているのに対し、PMBOK はプロジェクト管理に関する知識を標準化することに焦点があてられているというところに違いがあります。PMBOK も 2000年、2004年、2008年、2012年、2017年、2021年の改訂を経て、現時点では第７版が発行されています。第７版ではアジャイル開発による変化を踏まえ大幅に内容が変更されたことで話題となりました。
2012年には、PMBOK や PRINCE2 など乱立するプロジェクト管理規格をとりまとめ国際標準化する目的でISO21500 が策定されました。こちらも 2021年に改訂されています。
誤解を受けがちではありますが、PRINCE2、PMBOK、ISO21500 いずれも「プロジェクト管理」の標準であり、ソフトウェア開発のためだけに向けて作られているわけではありませんし、ましてや、ウォーターフォール開発を前提として作られていません。原理的に言えば、従来からアジャイル開発の手法と組み合わせて使えなかったわけではありません。昨今の改訂は最新の流行に装いを合わせただけとも言えます。
ソフトウェア開発に特化したものではないという意味では、製品やサービスの品質を管理するプロセスを定めた ISO 9001 もあります。1970年代に各国で品質管理に関する標準が作られていましたが、その違いが国際貿易の障壁になる可能性があったため、1987年イギリスとアメリカの標準をベースに標準化が行われました。多くのソフトウェア開発企業が ISO 9001 認証を取得していますが、その要件として、要求事項の明確化、その確認作業の文書化が求められることから、重厚なプロセスや文書の作りすぎの原因となっているとの批判に繋がっていきます。
ソフトウェア危機と開発プロセスの標準化
プロジェクト管理標準とソフトウェア開発分野の溝を埋めるため、他にも様々な標準が定義されています。有名なものとしては、1995年にソフトウェアのライフサイクルを定義した ISO/IEC 12207 が、1989年にイギリス中央電算電気通信局（CCTA）がITサービス運用のベストプラクティスをまとめたITIL（Information Technology Infrastructure Library）があります。この ITIL （およびその認証規格である BS15000）は、その後 2005 年に国際標準規格として ISO/ETC 20000 へと発展しました。ISO/ETC 20000 は 2018年に改訂、ITIL 自体も 2001年、2011年、2019年に改訂が行われ、現在の最新 ITIL 4 ではアジャイル開発や DevOps にも対応しています。
日本においても、1994年に情報処理推進機構（IPA）がソフトウェア取引を円滑に行うために企画から廃棄までのライフサイクルや用語の定義を行う共通フレームが公開されました。共通フレームは、ISO/IEC 12207 と整合性を取りながら、2007年、2013年に改訂されています。
なお、こちらも誤解しやすいのですが、これらの標準も必ずしもウォーターフォールモデルやV字モデルを前提としているわけではないことには注意が必要です。これらの標準で規定された各プロセスの採用可否、実施順序には自由度があり、必ずしもアジャイル開発の手法と矛盾するものではありません。しかしながら、ここで定義される各プロセスがウォーターフォールモデルのプロセスを下敷きにしていることには相違ありません。
ウォーターフォールモデルはいつ生まれたのか
伝統的ソフトウェア管理と呼ばれるとき、多くの人が思い浮かべるのがウォーターフォールモデルであるにも関わらず、多くの標準がそれを前提としていないのは面白い現象です。標準によって広がったわけではないのならば、ウォーターフォールモデルはいつ発明され普及していったのでしょう。
一般に、ウォーターフォールモデルはウィンストン・ルイスが1970年に発表した論文から始まったとされています。しかし、実はこれはまったくの勘違いだということが最近ではわかっています。
ウォーターフォールモデルはルイスが発表するはるか以前から存在していました。
最初にウォーターフォールモデルと同型の直線的なモデルが発表されたのは、1956年に書かれたハーバート・ベニントンによる論文「Production of Large Computer Programs」の中においてです。
最初にこのモデルをウォーターフォールと呼んだのもルイスではありません。1976年に書かれたベルらの論文ではじめてウォーターフォール（滝）と呼ばれました。そもそも、ルイスのモデルでは設計と開発のフェイズを繰り返すことが推奨されており、純粋なウォーターフォールモデルですらありません。
経緯ははっきりしないところがありますが、時系列を見る限りウォーターフォールモデルは誰かが発明し広がったというよりは、経験的に有用であると考えられていた自然発生的なモデルである可能性の方が高そうです。アメリカの軍事標準規格で採用するにあたり、ウォーターフォールの根拠を明確化するためにさかのぼってルイスの論文が再発見され、それが様々な著者の間で誤解された形で引用されていったというのが実際のところでしょう。
さらにややこしいことが起こります。このルイスの論文は2000年代に入りアジャイル推進者の間で「ルイスは実際にはウォーターフォールモデルを推奨していたわけではなく、反復的で増分的な開発モデルを推奨していた」という誤読に基づく再解釈が広まりました。
ルイスはたしかに論文の中で「危険であり、失敗を招く」と言っていますが、正確には「私はこの概念を信じていますが、上記の実装は危険であり、失敗を招く」とし、次の段落では「図示されたアプローチは根本的に健全であると信じています。この後の説明では、開発リスクの大部分を排除するために、この基本的なアプローチに追加する必要がある 5 つの追加機能を紹介する」と続け、そのひとつとして部分的な反復手法を提示しています。これは明らかに直線的なプロセスモデルの中にプロトタイピングを組み込むような状況を意図したもので、アジャイル推進者が言うような意味ではありません。
ウォーターフォールモデルとほぼ同じものとして使われているV字モデル（別名 Validation & Verification model）は要件定義とシステムテスト、基本設計と結合テストなどウォーターフォールの各工程の関係をマッピングすることで工程の目的を明確化したものです。工程をV字型に配置し「正しいものが作られているか（Validation）」と「正しく作られているか（Verification）」を区別し対応付けることで、機能が要求を満たしているか、機能が設計どおりに作られているか、という２つの事柄を切り分けて検証します。
このV字モデルは1980年代後半にドイツとアメリカで独立して開発されました。ドイツのVモデルは1986年にIABGによりドイツ連邦国防省ために作成され、その後1997年に「V-Modell」という公的なソフトウェア開発プロジェクトの管理標準の一部として公開されました。V-Modell は 2005年 V-Modell XT に置き換えられ、その後も数度の改訂が行われています。アメリカのV字モデルは、1986年にポール・ルークによって書かれた「Controlling software projects」というガイドラインの中で最初に紹介されました。しかし、さも当たり前のことのように書かれているので、当時すでに知識としては知られていたのかもしれません。
プロセスの評価と改善
プロセスが定義されても、組織の中で適切に機能しているかはわかりません。発注者は、発注先の組織がプロセスを定義するだけでなく、その定義に従い行動しているのかを評価する必要がありますし、受注側の組織にしても、プロセスを改善し生産性を上げるためには評価基準が必要になります。
この観点から CMM（能力成熟度モデル）という組織のプロセス管理能力の成熟度をが開発されます。このモデルは、元々米国空軍が下請業者を客観的に評価する目的でカーネギーメロン大学のソフトウェア工学研究所（SEI）に資金を提供したことからはじまりました。
この成果は1989年に「Managing the software process（日本語版：ソフトウェアプロセス成熟度の改善）」として発表され、1991年には SW-CMM（ソフトウェア能力成熟度モデル） v1.0 という形で正式に定義されます。その後、適用範囲の異なるSECM（システムエンジニアリング能力モデル）、IPD-CMM（統合成果物開発能力成熟度モデル）と統合され、2000年にはCMMI（CMM統合）v1.02 に発展します。
CMMI v1.2 以降は、ソフトウェア開発以外にも適用範囲を広げ、従来あった開発のための CMMI は CMMI-DEV へと変わり、 調達のための CMMI（CMMI-ACQ）、サービスのためのCMMI（CMMI-SVR）などが追加されます。さらに 2018年に発行された CMMI v2 ではこれらのモデルがひとつに統合され、必要な部分を選択的に適用する形に変更されています。
CMMI では5段階で成熟度の評価を行います。このため、「CMMI 成熟度レベル5を取得している」といった形でその組織のソフトウェア開発の管理能力を表現することができます。
多くの論文で CMMI の導入と生産性には関係があるとされており、効果はあるとされています。その一方で Google を始めとする多くの先進的なソフトウェア企業が CMMI の認定を受けておらず、本当に CMMI は必要なのか、という疑問が呈されています。この矛盾は、CMMI の有効性に疑問があるというというよりは、きちんとソフトウェア開発プロセスが定義され運用されていることが重要であり、認定を受けること自体は重要ではないという査証のように思われます。
アジャイル前史
一般に、新しい概念は誰かが発明し、それがだんだんと広まっていくものだと思われていますが、必ずしもそうではないようです。アジャイル開発が何であって何でないか定義されたのは、間違いなく2001年のアジャイルソフトウェア開発宣言ですが、この宣言は1990年代に個々に発表された軽量ソフトウェア開発手法の提唱者が集まり、中心とすべき教義を合意することで成立しました。すなわち、その時点ではアジャイル開発手法は存在していたということです。
アジャイル開発は新しい手法であると思われがちですが、その源流は 1950 年代にまでさかのぼることができます。ルイスが製造～テストの工程を２回繰り返すよう推奨したように、ウォーターフォールモデルの硬直性はその当時から認識されていました。
アジャイル開発手法に共通して導入されている「反復的・漸進的開発（IID: Iterative and Incremental Development）」は、1950年代に行われた極超音速実験機 X-15 開発やNASAのマーキュリー計画の中で実際に使用され成果が出たという記録が残っています。マーキュリー計画ではテストファーストに類似した手法も導入されており、ほとんど現代のエクストリーム・プログラミングと区別がつかなかったという話もあります。
反復的手法と斬進的手法は専門的には異なるもので、反復的（Iterative）とはタスクを一定の区切りで分割して直線的に実行すること、斬進的（Incremental）とは少しずつ成果物を改善していくことを意味しています。しかし、このふたつには密接な関わりがあり、実際的にはあまり意味のある分類ではありません。
反復型開発に関する最も古い文献は、1968年にIBM T.J.ワトソン研究センターのブライアン・ランデルとF.W.チェルシーが発表した「Iterative Multi-Level Modeling - A Methodology for Computer System Design」ですが、この論文で説明されるものは抽象度の異なるモデルを階層化し徐々に詳細化するもので、現在我々が知っている手法とは大きく異なります。
顧客のフィードバックとイテレーションを組み合わせた現代的な反復的・漸進的開の実例としては、1972年にIBM社の連邦システム部門（FSD）により実施されたトライデント潜水艦の指揮統制システムやTRW社により実施された弾道ミサイル防衛プロジェクトが挙げられます。これらのプロジェクトでは、６ヶ月ごとの長めのイテレーションでプロジェクトが進められました。
1985年には、ソフトウェア見積技法COCOMOでも知られるバリー・ベームが「A Spiral Model of Software Development and Enhancement」の中でスパイラル・モデルを提案しました。アジャイル開発とスパイラル・モデルの違いはしばしば議論となりますが、大きな違いはスパイラルモデルにはプロセスがいまだ存在する点です。スパイラル・モデルではミニウォーターフォールが繰り返されるのに対し、アジャイル開発では各プロセスは細かく分割され「ブレンド」された状態で実行されます。
その翌年の1986年にはフレデリック・P・ブルックスJr.による有名な書籍「人月の神話―狼人間を撃つ銀の弾はない」が発売されます。ブルックスJr.は、この本の中で、ウォーターフォール開発の問題点を明確に示し、斬進的開発の導入を推奨しました。この本は何度か改訂され参照されていますが、最新版ではアジャイル開発にも触れ、そのすばらしさを絶賛しています。
この辺りからウォーターフォールモデルに対する不満を解決しようという動きが活発になります。アメリカ国防総省では、反復的・漸進的開発を推奨する動きが起こり、1991年には「ラピッド・アプリケーション開発（RAD）」と「クリスタルメソッド」が、1995年には「スクラム」と「ラショナル統一プロセス（RUP）」が、1999年には「エクストリーム・プログラミング（XP）」と「ユーザー機能駆動開発（FDD）」が発表されました。ラピッド・アプリケーション開発は1994年に拡張され「動的システム開発手法（DSDM）」に発展します。なお、RAD と言うと Microsoft 社の VisualStduio を代表とする GUI 作成ツールを想起しますが、本来はプロトタイピングを含む開発手法を指します。
この間も主流はあくまでウォーターフォール・モデルです。反復型開発にもとづくラショナル統一プロセスは、開発していたラショナル・ソフトウェア社が IBM 社に買収されたこともあり、UMLやオブジェクト指向方法論（OMT）、手法を支援するRADツールとともに強力に商用展開されたものの、その重すぎるプロセスから広く普及するには至りませんでした。
アジャイル革命
2001年2月、自ら「組織的アナーキスト」と呼ぶ17人の開発者がユタ州のザ・ロッジ・アット・スノーバード・スキーリゾートに彼らの考えの共通項を見出すために集まりました。参加者には、スクラムの発明者ジェフ・サザーランド、エクストリーム・プログラミングの発明者ケント・ベック、クリスタルメソッドの発明者アリスター・コバーン、リファクタリングやアナリシスパターンの著書でも有名なマーティン・ファウラー、Wiki の発明者としても知られるウォード・カニンガム、「適応型ソフトウェア開発」を書いたジム・ハイスミスなどが含まれていました。彼らは、その共通項を12の行動原則とともにまとめ「アジャイルソフトウェア開発宣言」として発表しました。
この宣言以降、この価値観と原則に沿った開発手法はすべて「アジャイル開発」と呼ばれるようになりました。この宣言がキャッチーだったからなのかは不明ですが、ソフトウェア産業の中心が受託開発やパッケージ開発からWeb上のサービスモデルへの転換するという社会の変化もあり、アジャイル開発はウォーターフォール・モデルを凌ぐ勢いで広がりつつあります。
このアジャイルという用語ですが、最初にそう名付けたのは日本人なのではないかという話があります。答えを先に言ってしまうと、これは半分事実で半分間違いです。富士通でソフトウェア開発の管理業務に従事していた青山幹雄は、新潟工科大学に移籍後、それまでの経験を元に反復的・漸進的開発に関する数本の論文を書きました。そのうち 1998年の論文「Agile software process and its experience」にて要件や周辺環境の変化に素早く対応するアジリティという概念を導入し、アジリティにもとづく開発手法としてアジャイル・ソフトウェア・プロセス（ASP）を提唱しました。この開発手法は現代的な意味でもアジャイル開発と呼べる内容でした。そういう意味で、世界で一番最初に適応的な反復的・漸進的開発手法をアジャイルと称したのは日本人である、というのは事実と言えます。
ただし、これはアジャイルソフトウェア開発宣言における「アジャイル」の由来とは関係ありません。「The Secret History of Agile Innovation」によれば当初「軽量」と呼ぶ案もあったようですが違和感を持つ者もいたたため、最終的には参加者のひとりが読んでいた書籍「Agile Competitors and Virtual Organizations（日本語版 アジルコンペティション : 「速い経営」が企業を変える）」から「アジャイル」という名前を提案され採用されたというのが真相のようです。この本は、いわゆるビジネス書でソフトウェア開発管理の本ではありませんが、激動する市場に適応する方法を生み出した様々な企業の事例が紹介されています。
とはいえ、同書が1960年代の日本から始まったリーン生産方式を下敷きにしているという意味で、アジャイル開発の源流が日本にあると解釈するのは決して間違ったものではありません。昭和も遠くなりだんだんと忘れられつつありますが、1970～90年代前半「ジャパン・アズ・ナンバーワン」と呼ばれていた時代がありました。バブル景気の印象も強いですが、その背景には日本で起こった生産技術革命がありました。それ以前はアメリカを中心に少品種大量生産が基本でしたが、オイルショックを契機とした高度経済成長の終わりにより需要が一方的に伸びていく時代が終わりを迎えました。時代が多品種少量生産の生産の時代に変わって行く中で、日本企業はジャスト・イン・タイムなど在庫を極力減らすことで、受給の変化に柔軟に対応する方法論を生み出していきました。そして、この考え方は変化に対応するアジャイル開発というアイデアに繋がっていきます。
現在、最も普及したアジャイル開発管理手法となっているスクラムは、1986年に竹内弘高と野中郁次郎が発表した論文「The New New Product Development Game」の概念をソフトウェア開発に適用したものです。この論文は、当時世界を席巻していた日本企業を中心とした製造業での新製品開発を分析したもので、変化の激しい状況においては組み込みの不安定性、自己組織化プロジェクトチーム、重複する開発フェーズ、マルチラーニング、微妙な制御、学習の組織的移転という６つの特徴が重要であるとするものです。スクラムという名前は、チームがユニットとして距離を移動し、ボールを前後に通過させようとアプローチが「ラグビー」に似ていることに由来します。
有名なアジャイル開発の方法論「カンバン」や「リーン開発方式」も、トヨタ自動車で大野耐一が開発した「トヨタ生産方式」から生まれたものです。サザーランドも「スクラム 仕事が４倍速くなる“世界標準”のチーム戦術」にてその影響について何度も言及しています。ちなみに、真の原因を追究して再発防止策を立てる手法として有名な「なぜなぜ分析」もこの「トヨタ生産方式」が起源です。大野の著書「トヨタ生産方式―脱規模の経営をめざして」は、単なる手法の紹介に留まらず、カイゼンのために創意工夫する姿がにじみ出ており、今読んでも感銘を受ける人が多いと思います。直接ソフトウェア開発に関係する内容ではありませんが、ぜひお勧めしたい一冊です。