アジャイルって受託開発との相性が最悪な気がする

全くもって、その通りだなぁと思った。

初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え ? Publickey

｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。

滝

｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフトウェアで担保する機能が確認でき、抜け漏れがないと双方が合意できたことを意味します。この段階で問題になるのはフォントの大きさと罫線のズレとカッコよく見える絵とスペル間違いと日本語が正しいかどうかです。行間が空いていると要件漏れになりますからね。

｢仕様変更｣の４文字に大変弱く、ひとたびそれが発生すると(以下略

アジャイル

｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れを100になるまでやるのではなく、分割できる単位に落として、要件からテストまで一気に進めてしまい最終的に100になるというやり方だと認識しています。ソフトウェア開発は｢初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れる｣のが真理なので、コードを早い段階で書いてしまって問題点を早期に潰していくほうがいいに決まってるのは完全に同意。最初は小さな芽でも、時間の蓄積によって大木になりますからねぇ・・・。仕様変更があっても俊敏だから大丈夫、と。この仮定がだいたい正しいとすると、ソフトの作り方としてアジャイル開発のほうが合理的なのは間違いないでしょう。

でもアジャイルって

工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。

要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。

滝には色々問題があるけれど、滝は契約体系としてはわかりやすいし、お金の積み方が合理的に説明しやすいという点はあると思う。リスクマネーが利益の源泉になることが多いしリスク取るからおカネを請求できるわけで、そこが不明瞭で不確かだろうが｢○○円でいつまでにやります｣とコミットするから契約を結ぶ価値が出てくるわけなんだけど、アジャイル開発のやり方だとどう説明するの？

受託開発との相性が悪そうな理由

アジャイルが上述のやり方だと仮定すると、僕が顧客側にいたらこういう質問をすると思う。