適応型ライフサイクル（敢えてアジャイルとは呼ばない）は、世間一般では、受託以降の開発プロセスと思ってる人が多い印象がありますが、当たり前のことですが、プロジェクトの全体像は、案件の受注より前の発注側が起点となっており、昨今、ビジネス・サイドとの繋がりが重視されているので、「アジャイル、アジャイル」言われるようになったんだと思います（∴ 受注側だけでアジャイルやっても無意味です）。

　自分は、立ち上げプロセス自体を企画しているので、（ビジネスの）シーズもベネフィットも、ステークホルダーを監視しながら、開発中に行う技術的リサーチ & フィジスタの結果次第でスコープ、スケジュールをかなり頻繁にコントロール（変更）します。「変更が多発した方が、結果として品質が向上する。」と言う話は過去にも書かせて頂いた通りです。

　適応型ライフサイクルをホントに効果的だと思う点は、テクノロジーと、ビジネスのシーズ・ベネフィット間の帯域幅を大幅に広げられる点だと思います。適応型ライフサイクルが出てくる以前は、立ち上げプロセスと計画プロセス以降が分離されていて、PMアサインは立ち上げプロセスの中で行われていて、今ほど、ビジネス面の理解が求められていませんでした。

　しかし、昨今、そういう開発では競争力が産まれず、結果が出なくなってきています。自分が言うのもなんですが、技術者的な何某かは、もうチョット、所属する組織のミッションと連動した開発をしたらイイんじゃないかと思います。

　例えば...

　「下手すると、殆どの人員がミッション関係なく技術的な何かをちょっとリサーチして、それを脳内に仕舞い、一部を文書化してファイルサーバーに捨てています。」

　...と言う仕事の仕方では、

　そもそも、自分の仕事に対する監視・コントロールが無い訳ですから、仕事の品質も上がっていかないので、当然、結果も出難くなっていきます。

　チョット前に、以下の様な情報を識者に教えて頂いたのですが、現在は、これより遥かに高度化しており、昨今、技術開発をするなら「OSSコントリビュート＋アジャイル開発」ぐらいやらないと、色々と難しい気がします。「クローズド＋ウォータフォール」は、割と本気で無い気がします。

＜参考＞