戦闘機開発もAgileでいこう

Agile JournalのCASE STUDY: War Stories - Fighter Jets and Agile Development at Lockheed Martinという記事が興味深い。大企業・ハードとソフト両方・飛行機（それもF-35 Lightning II）という品質重視分野・世界各地に分散した開発チームという条件下でのAgile適用事例だ。
長いので全部は訳さないけど、ポイントをいくつか。

企業の規模は、従業員１４万人、４５カ国４５７都市に分散。米国だけで９３９施設。

いわゆるウォーターフォール式で開発をしてきた。
製品の投入周期は年一度かそれ以下のペースで、製品投入直前の数ヶ月はいわゆるデスマーチに近い状態（原文では「Fire Drill」）だった。
開発チームは作業項目単位で結成された。そして、ある作業がうまくいったという「前提で」次の作業が計画された。ある工程での不具合は、次の工程を止めてしまうという問題があった。
各チーム間の意思疎通はほとんどなかった。四半期毎に状況が集約分析され、場合によってはその四半期の作業がチャラになることもあった。

「製品をちゃんと作る」と「ちゃんとした製品」の違い。（原文はRight ProductとProduct Right）　開発側は仕様通りに正しく作ったつもり(Product Right)でも、発注側の求める製品(Right Product)ではないことが多々あった。　
発注側は「顧客の視点」で製品がちゃんとできているかどうかを確認する。（原文：validation）
開発側は「仕様を満たしているか」でちゃんと作ったかどうかを確認する。（原文：verification)
この溝を埋めつつ、製品をより短期間・低コストで開発する必要があった。

製品開発ラインをなんとかするように圧力がかかりだしたのは３年前。
事例を調査し、SCRUMプロジェクト管理＋様々なAgile手法(XP, Crysal, Lean...)の良い所を組み合わせてみようということに。
Agileを選んだ理由は「要件変更への対応」「生産性の向上」「ソフトウェア品質向上」「製品投入期間の短縮」
Agile導入に反対する声もあった。「仕事のやり方を変えたくない」「経験がない」「管理できない」「顧客との協業がいや」「契約体系の問題」など。
よって一気に全部をAgile化せず、全部で３フェーズに分けることにした。「パイロット」「部門」「全社」。
パイロットフェーズでは、選別されたいくつかのチームに対してAgile手法を教育し、実践。半年〜９ヶ月。この段階で従来は半年かかっていた開発が４ヶ月以内に終わることを確認。（しかも週４３時間労働）
部門フェーズは、いくつかの部門をAgile対応させて開発を実施。今はこのフェーズ。二年ちょっと続く。「生産性向上」「ソフトウェア品質向上」「製品投入期間短縮」「コスト削減」などの効果を確認。

兵士を訓練せずにいきなり戦場に出しても、それほどの役には立たない。Agile開発でも同じで、訓練と本番とを分けることが重要と実感。OJTに頼りがちな日本企業はここでも苦しいか？

masayang's diary