この記事はポエム記事です（汗
　個人的な偏見と恐らくは不正確な事実認識から書かれています。その点に注意して読み進めてください。

• 前提
  • SI 案件 (=受託開発) の現場を想定
  • アジャイル開発の対義はウォーターフォール開発であると仮定
• 結論

  　モノを買う以上「機能と予算と期間」はセットであり、これらが強固に結びついている以上、(受託開発では) アジャイル開発は成り立たない。

• 考察

  　所謂受託開発や SI と呼ばれているものは、前述の「機能と予算と期間」が全て固定されたうえで契約されることがほとんどであり、また多少の細分化やフェーズ分けは行われたとしても、分けた単位ではやはり固定される。この点でアジャイル開発は適さないと考えている。
  　こう書くと「それは契約の問題であり開発手法の問題ではない」という話になりがちなのだが、実際その指摘は一面的には真であると思う。しかし契約の形態が開発手法に影響を与えるのは当然であることに加え、開発手法の都合から契約を変更することはほぼ絶望的である。従って開発手法は契約に対して一方向的に従属する関係にあると言える。このため、開発手法の選択によって契約のありかたを考えないといけないなら「それは契約の問題であり開発手法の問題ではない」ということにはならない。ところがアジャイル開発が語られるうえで契約の問題はあまり話題に上ることはなく、そのあたりが齟齬や欺瞞、誤解や適合のむずかしさを生み出してしまっている源泉なのではないかと思っている。

  　では逆にアジャイル開発が有効である場合は何か。それは開発チームが「機能と予算と期間」を可変させる権限を持っている場合ではないかと考えている。つまり開発を外部に委託するのではなく、内部で開発を行うケースである。これは「比較的小規模なベンチャーのようなチームが自己が提供するサービスを開発するケース」などが該当するのではないかと思う。
  　しかし自己のサービスを開発する場合でも、規模が大きくなると組織の壁によって阻まれる。例えばリリース予定の機能がリリース予定の期日にリリースされることが確約できないと営業活動がむずかしいという問題がある。営業の視点では、予定された機能のリリースの期日がずれる、あるいはなくなるといったことは顧客に説明がつかなくなるので好まれない。従ってこのような力が働くとき、開発チームに対して「機能と期間」は確実に固定される。予算だけはその気になれば変動可能、というか嫌でも変動するが、しかし多くの場合は良い意味で変動することはない。

  　結局は外部に向けてはウォーターフォール的な表現、内部においては許容できる範囲でアジャイル的な取り組み、というのが現状の精一杯ではないかと思う。
  　また、この場合の「アジャイル的な取り組み」というのは、例えば 3 つのモジュールを作る場合に、純粋なウォーターフォール的な計画だと「設計→設計→設計→製造→製造→製造→テスト→テスト→テスト」みたいになるものを「設計→製造→テスト」× 3、みたいな感じにすることだと思ってる。つまり「動くソフトウェアを作る」ことを重視する。ただ、これも「許容できる範囲」と述べたように全てではなく、前半に設計だけで固めないとならない領域(DBの設計とか)はあるし、前述の「設計→製造→テスト」も「設計は上位のスキルが必要だ」「製造は打ち込み要素が大きくスキルが低くても構わない」「テストは当該の製造者ではない人あるいはそもそもプログラマではない人にやらせたい」などの要件、つまり人員配置の問題が絡むと、どうしてもアジャイル的なものにならない。

  　この大枠ウォーターフォールなものに、ところどころ「アジャイル」的な何かを持ち込むめること、それがアジャイルのメリットだ、というならそれはメリットかもしれない。しかし実際のところ、そのレベルではアジャイル開発の登場以前からアジャイル的なものはやっていた。ただそれは「その部分はその方法が適当だったのでそうした」というだけの話である。例えばプロトタイプ開発はアジャイル開発よりも前からあり、必要があればその手法を用いることはあった。プロトタイプ開発とアジャイルは現在は違うとされているけれども「必要なものから優先的に、動くものをリリースしていく」という観点からは類似している。違うことは「顧客（特にそのサービスを使うエンドユーザー）のところまで供給されているかどうか」であって、プロトタイプ開発だって開発チーム内や顧客（元請や発注主）に対しては見せていた。だから手法としての差はあまりないと思う。それがプロトタイプコードがリリースコードであり供給相手がエンドユーザーまで延びたからアジャイルだ、といわれるのは個人的には違和感がある。

  　また、アジャイルは雇用的なアプローチという見方もできる。つまり負荷の変動に弱い。時間あたりの処理量を固定して負荷を平準化し、総処理量の増加は時間方向に延ばす手法なのでそうなるのは当然ではある。
  　これは例えば「初期開発では多くのリソースが必要だが、保守フェーズにはいると初期開発ほどのリソースは必要ない」というケースに対応し辛い。下手すると保守フェーズに入っても初期開発で抱えたリソース（つまり人）の雇用を維持し続ける必要がでてしまう。この問題に対する解が「受託開発」である以上、初期開発と保守フェーズの負荷を均すという対策はありえない。
  　海外のことはまるで知らないが、恐らく海外では初期開発を行うに必要なリソースを雇用の後、初期開発が終了すると不要になるリソース分の雇用を切っているはずである。そうすれば「内部で開発」しつつ「必要な負荷」のコントロールができる。しかし現在の日本の雇用法制でこれができるか？というと疑問である。
  　この点も、一般にアジャイル開発の説明では「チームの人数」に言及はあっても「プロジェクト全体におけるチームの数（や総人口）」に言及されることが少ない点が、誤謬を生み出している原因の一つだと思っている。

  　というのが私の足りない頭で考えた現状であり、ウォーターフォールの「全ての WBS はプロジェクト開始前に計画されてなくてはならない」的な課題に対して脳内ドン・キホーテをやらかして百戦百敗した結果なのである。
  　アジャイル開発のメリットに目を奪われそれを適用しようとしても、そうすると全体のバランスを崩してしまい結局はウォーターフォール的な安定に戻る。その繰り返しである。かつてメリットに見えたものはまやかしでしかないように感じている。

  　ではウォーターフォールだと前述が解決できるのかというと出来ない。しかしウォーターフォールがアジャイル開発と大きく違い、かつ絶対的な利点は少なくとも「機能と予算と期間」にコミットできるという点にある。この差は大きい。それが例え「夢の計画」であっても・・・(汗

  　つまりこの「機能と予算と期間」にどうコミットするか、この最初にして相当に高いハードルを超えないことには、アジャイル開発のメリットなど何一つ考えられない状況なのである。
  　なので、誰かその方法を教えてください。もっともこれを超えられたとしても他にも問題は山積みだと思ってはいるが…（汗