大規模開発は大規模ってだけでクソって誰かが言ってた

けどまあ、大規模開発と言うものが存在していることは厳然たる事実で、撲滅するわけにも行かない世の中です。
大規模開発の最大の問題点は「予算」ってやつで、海のものとも山のものとも付かない新システムの開発をどう計画してどう予算を取っていくかが大規模システムの担当者のもっとも大きな悩みなわけです。どうやったらちゃんとシステムが作れるか、ということを考えるのはもちろんですけど、とても大変なのは、どう人を回していくかを考えること。予算を確保するための予備検討のための予算を確保するための事前検討から始まってリリースまでの人員を計画して行かなければならないし、システム子会社であれば、この果てしない、並行に何本も走っている開発サイクルに上手く人をアサインして親会社も幸せ、子会社も幸せ、という状況を造らなくてはなりません。もはや必要なスキルはシステム開発ではなく経営戦略…
ま、そんなわけで、枯れてきたといえなくもないシステム開発の世界では、きちんとした計画の元に開発を進める必要のあるプロジェクトは多々あります。をーたーほーる型開発にならざるを得ませんな。悲しいかな、ある程度堅い見積もり技法が定着しているホストの世界は廃れつつあり、様々な開発手法や見積もりづらい新技術がどんどん生まれるオープンの世界にシフトしつつあり、担当者を悩ませます。
アジャイルなんかよく例えられる建築業界であれば、「サンプル作っては壊しどんどんよくしていく設計技法？アホか？」となるところですが、幸いなことに、システムは過程におけるスクラップ＆ビルドのコストは現実の建築物に比べて極小です。もっとも、出来上がったものを壊して作り直すのは同じくらい難しい。もう他のところにくっついてしまっているものを他に影響を与えないようにする、ということが至上命題である場合は特に。システム間の結合を出来るだけ疎にしておきましょう、というのが現実的に行われているのはわりと最近でありますしね。
というわけで、

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

ってのはそのとおりだし、更に言うと、多数のサブシステムが同時に開発されていく大規模システムだと、I/Fの取り決めがしっかり出来ないとどうしようもなかったりする。I/Fなんて外向けの部分の設計だから最初からきちんと定義すれば良いじゃん、なんて思うかもしれないけど、SOAにおけるサービスの粒度の決定にしたってかなりの繰り返し作業の元で行われたりするよね。

これってヒトを選ぶ難しいやり方のわりに、だったら初めから納期と予算が決まってる滝のほうが顧客にとってはいいって言う話になるんじゃないだろうか？そうだとすれば、要件定義が一番のコストなんだからその手法を高度化して滝のままで精度を高めましょうという方向を向くことになるし、｢要件が決まれば実装は自動生成で可能な限り効率化｣ということになりそう。リクツの上ではね。
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance

本当は、要件が決まれば実装はどうなっててもいい、ってのが理想なんだけど、実はシステムの設計は非機能要件にひきづられるところが多い。逆に言うと、厚い非機能要件がないシステムだと、ここで指摘されている｢要件が決まれば実装は自動生成で可能な限り効率化｣のほうにシフトしているだろうし、ここ最近かなり現実的なツールが出始めている。

でも、最大の問題は、システムを作る責任者自身が本当に責任をもってことを進められるか、だと思うね。大規模システムになるともはや利害関係者が多すぎて責任の所在を一元化することが難しかったりして、問題になることが多いわけで。明確なコンセプトをもって進めた結果、よさげなシステムになりそうなところが予算削減のせいでたくさん妥協した結果、予定通りの納期でシステムは稼動したものの、将来に繋がらなかったりしてね。

その辺考えると「実装としてのよりよい開発手法作り」という点ではアジャイルはとても有効なんだろうけど、結局のところ、「企業の経営プロセスに対して有効なシステム作り」という点では予算のかけ方含め結局のところ計画と要件定義が全てであって、そこから先の開発は全てその帰結でしかなくて、綿密な計画が出来ない設計開発手法であればそれはあまり望まれない、ということになってしまうわけだ。
であるならば、上流のエンジニアが行っていくべきは、いかに要件定義とそれ以降の工程を切り離す形(規模)で要件定義してシステムの粒度を決めていくかであって、設計開発工程の全てを一括で受注できるようにしていくことで、大規模システムにとってそれを実現する一つの手段がSOA(なんていうとちょっと違うかも知れんけど)であったりするんだろうね。