受付中 大規模開発でオブジェクト指向は本当に変更に強いのか？

近い未来に変更予定の仕様を想定して設計してあれば強いと思いますが、何でもかんでも変更に強いかというとそうではないとおもいます。
オブジェクト指向の最大のポイントは"プログラムの再利用"だと思います。コード量を減らすにはいいかもしれませんが、変更には弱いと思います。
変更したことによって、それを使っているモジュールが正しく動くかどうかは未知数です。オブジェクト指向が逆に足かせになってしまうのではないかと思います。

前述のとおり、ちゃんとあらかじめ変更を想定して入出力を設計してあれば最小の手間で変更が可能だとは思いますが、高いスキルと計画性が必要だと思います。

２～４は開発手法などの問題ではなく、日本の受発注における諸問題のせいだと思います。

技術を知らない文系営業が適当に見積もって受注した案件を、プログラムが書けないSEがこねくり回して、頓珍漢な仕様で孫請けひ孫請けの単価もレベルの低いプログラマに作らせる…。
この構造が何とかならない限り改善しないと思います。

日本の電子産業が比較的強い(強かった(涙))のは、無意味な孫請けひ孫請けが少なかったからだと私は思っています。

スーパーハッカーを雇えばいい、という意見ですが、確かにそういうプロジェクトもあると思いますが、銀行や官公庁の大規模プロジェクトといった仕事は、彼らにとっては"つまらない仕事"と思っているとおもいます。もっと稼げて、クリエイティブな仕事がたくさんありますし、そういう人たちは自分で仕事を生み出す人たちです。仮に単価が高かったとしてもやりたがらないでしょうし、そもそも日本の多くの経営者にはそういう人材に高給を出そうという発想すらありません。

こんにちは。

まず比較対象を明確にした方が良いです。性能比較は常に相対的なものですから。
銀行の事例を上げられているので、COBOLと比較した方がよいでしょうか。

1.オブジェクト指向は本当に変更に強いのか？

COBOLが得意とするような単純だが大規模な帳票処理を実装するにはあまり向いていないと思います。
COBOLのようにひな形も充実していないでしょうし。
では、COBOLが想定していない処理、例えば新しいWEB技術との連携はやはりJava等の方が向いているように思います。

変更に強いかどうかは対象のアプリで変わるでしょう。特化されたものほど想定内の変更には強く、しかし、想定外の変更には事実上対応できません。
OOPはCOBOLに比べて常に変更に強いとは言えないと思います。でも、COBOLに比べて対応範囲は広く、COBOLが苦手とする分野では決定的に変更に強いでしょう。

2.なぜOOP開発での失敗例が多発するのか？

OOP開発を習得するにはCOBOLを習得するより時間がかかると思います。
結果、使える人材が少なくなり失敗のリスクが増えるているのだと思います。
極端な話COBOLはプログラミングを習っていない人でもある程度興味を持っている人なら比較的短期間で使えるようになると思います。OOPはなかなかそうはいかないでしょう。なんとしても習得したいと言う強い意思を持っている人でないとなかなかマスターするのは難しいかと。

ちょっと古いですがCOBOL 言語の評価と展望という資料がありました。この分析には納得できます。

3.失敗例の教訓、改善法はあるのか？

最近の状況を把握していませんが、日経群の中にはきっと分析しているものが多数あるのでは？
昔は本当にたくさんありました。

4.なぜ少数精鋭チームで開発しないのか？

優秀な人の割合が少ないのだと思います。
平均の5倍の生産性を維持できる人はプログラマ100人に一人もいないと思います。
例えば平均レベルのプログラマ1000人の中に5倍の生産性を出せる人は10人いないでしょう。
トータルの生産能力は平均1000人に比べて優秀な人10人では1/20以下の生産能力に下がってしまいます。

生産性を平均の5倍や2倍に下げていったとしてもこの関係が逆転するポイントはないように感じます。
平均の2倍の人は10人に1人とか。

IT土方等の言葉が示すように中々悲惨な職場環境の話が有名になったので、興味がちょっとあるだけで特にやりたいわけではない人は参入してこなくなった。Javaを学んだ人たちが今更COBOLに手を出したくない等の社会情勢的な問題もあるかも知れません。

まず、前提として、Javaを使ったからと言って無条件にオブジェクト指向になるわけではないと思います。Javaを使ったらオブジェクト指向になるのではなく、オブジェクト指向を実現するための言語としてJavaがあると考えてください。

1-オブジェクト指向は本当に変更に強いのか？
変更には強いですが、程度に寄るし限度もあります。

2-なぜOOP開発での失敗例が多発するのか？
オブジェクト指向で開発されているプロジェクトの母数が多い上に、他の言語をラッピングして再利用するので一番外側の言語に問題が発生しているように見える。

3-失敗例の教訓、改善法はあるのか？
PMBOKではプロジェクトを振り返るフェイズがあります、ここが機能していたらもしかしたら同じ失敗は減るかもしれませんね。

4-なぜ少数精鋭チームで開発しないのか？
1人幾らでお金を貰っていて、作業している人の技術レベルでお金が増減することはないから、利益にならないんじゃないかと思います。

大規模案件に参画経験はないので、
ある程度想像の入った話となりますので、参考までに。

開発モデルの問題

大規模案件では基本的にウォーターフォール開発モデルが利用されると聞きます。

恐らくはそれ単体ではなく、
一部スパイラル開発モデルも利用されているとは思いますが・・・。

この開発モデルの1番の問題点は手戻りが発生した時の差し戻しがとんでもなく手間がかかることです。

でも普通に考えると要求仕様は生き物のように変わり得るので、
開発当初と言ってたことが違うやんみたいなことが簡単に発生し、
結果その部分の元々の設計と大きく食い違うと大幅な遅延を招きます。

じゃあスパイラルモデルとか、
今流行りのアジャイルを採用すればいいじゃんと言われかねないですが、こちらはこちらで問題があります。

それは全体としての見積を取るのが容易ではないことです。

大体大型のプロジェクトとなると、
最初の時点である程度見積を出して、顧客がそれに対して採否を決める形がほとんどだと思われます。

仮にスパイラルモデルとかアジャイルとかを採用してプロジェクトを進めた場合、
それこそ先行きが読めず規模が膨らみまくって破綻するということが予想されます。
またアジャイルとかとなると、
顧客も開発・仕様決定に積極的に関与してくれないとこれも破綻しやすいです。

そのため結局はウォーターフォールベースの開発に落ち着いているというのが現状かもしれません。

産業モデルの問題

IT産業では請負元から、下請け発注をかけて開発を投げるというのがお家芸となっているので、
構造上どうしても色々な企業や多くの人員が関わってきます。

これによって、組織間のコミュニケーションはどうしても発生するのですが、正直この部分でうまく伝達が行えていないパターンも多いように思えます。

少なくても中規模な案件ですら、
伝達ミス、思い違いなどによる実装漏れや実装ミスが生まれるのですから、
大規模案件ではその辺りを徹底的に管理してないとすぐにそのような事態が発生すると思われます。

でもそれでも今のIT産業が冒頭のような構造で成り立っているので、
抜本的に変わらない限りここの変化はまずあり得ないでしょうね。

人員確保の問題

Javaとかではよく言われてますが、
割と良い人材は囲い込まれていますし、
スーパーハッカークラスになると、
案件自体に興味すら持たないことも多そうなのと、
どうやって本当にそのクラスの人材であると判断するのかといった別の課題が発生します。

そうなると結局は大規模案件は、
ある程度信頼のできる実績のある大企業に発注をかけ、
ITの産業モデルに従いずるずるととなるのかなと思います。

最後に

あくまで個人的な意見ですが、
設計スキルや実装技術云々よりも、
管理面とか産業構造によって起こっている遅延とかが起こる側面が強いのかなと思ってます・・・。

オブジェクト指向は本当に変更に強いのか？

強いです。

しかしそれは、OO以前の構造化技法に対する相対的な強さで、
絶対失敗しない「銀の弾丸」ではないです。

なぜOOP開発での失敗例が多発するのか？

OOが普及して母数が多くなったから、失敗例も増えたのでしょう。
しかし、OO採用と非採用で比較する必要があります。
OOを採用していなかったら、もっと失敗が増えていたでしょう。

また、ご質問はOOが実施できている前提になっています。

しかし、本当は関数型言語と同じくらい難しいが、
OOPは関数型プログラミングより制約が緩いため、
本当はできていない場合が見分けづらいと考えます。

失敗例の教訓、改善法はあるのか？

あるでしょうが、それはOOのような開発技法ではなく、
組織管理の話になるかと思います。

なぜ少数精鋭チームで開発しないのか？

そもそも、大規模開発は企業間での巨額の契約ですから、
そうなるはずだ、という希望的観測で事を進めるわけにはいかないでしょう。

かりに「ウチの会社は千人分の仕事を十人でこなせます」といったところで、
本当にできるかどうかを検証するのが難しいです。だからリスクがあります。

要するに人月的な発想があるのでしょうが、
しかし、それを捨てたら上手くいくとも限りません。

平凡な人材と精鋭とで、本当に10倍も100倍も差が開くかは疑問です。
精鋭との差は量より質の差に出ると、個人的には考えています。
たとえば機械学習のようなジャンルだと行数より精度が問題になります。

しかし、「銀行や官公庁の大規模プロジェクト」は規模は超巨大だが、
極端に難しい処理が固まっているわけでもないので、
少数精鋭のプロジェクトに向かないのではないかと思います。

いろいろ書いては消し、書いては消ししましたが、結論としては仕様書を書く人の多くがオブジェクト指向を理解していないのでソースコードレベルでオブジェクト指向にするのに限度があるということが大きいです。

大規模開発は政治に渡り歩く能力が求められ、ある種の専門性が高いので、コーディングやオブジェクト指向などのプログラミング方面の専門性の優先順位が低くなります。

少数精鋭にすれば解決するかもしれませんが、銀行ではOOPやドメインモデルを使ったとしても過去から積み上げられた大量のロジックがあり、発注側に大量の仕様書を渡す必要があるため、少数では回らないでしょう。（発注側がソースを読むつもりになれば話は変わりますが・・・）

恐らく公官庁では、発注側の技術的な能力不足のためにUMLなどであっても受け入れるのは難しいと思います。

テスト結果に関しても、発注側として許容される報告書の作成が必要であり、それなりの工数となることが予想されます。

そういったわけで、私は恐らくOOPと言ってもモデリングをキチンとしたものでやられている可能性はほとんど無いと考えています。仕様書を書く工数があまりにも大きいのです。

OOPがまともに機能していないし、仕様変更を人数でカバーできる体制をくんであるので、技術的な問題でプロジェクトが失敗する可能性を回避しています。違和感を感じない訳には行きませんが・・・

ただし、大規模開発にオブジェクト指向が向かないわけではないです。Webやアプリケーション分野では当たり前に使われている技術なので、かなり有効な技術だと思います。

受注開発の場合に問題がおこる場合が多いと考えています。

改善方法としては、発注側に技術責任者をおいて、仕様書を減らしアジャイルな開発方法を採用できれば、真にOOPの恩恵があるでしょう。しかし、技術責任者に権力が集中するので、専任以外に委員会を設けるなど細かい配慮が必要かなとも思います。

追記

優秀な技術者についてのイメージが回答者によってまちまちなので、私のイメージを書きます。

・おおむねタイプ速度は速いですが、２倍も速いということはないと思います。
・コードが短いので早く仕上がります。
・手順がしっかりしているので手戻りが少ないです。もしくは自動化をしています。
・バグフィックスが早いです。
・テストの回数は多いですが、テストを実行する時間は短いです。
・バグは早期につぶされます。
・潜在的なバグが少ないです。

たぶん、この時点で２～４倍程度の生産性の差が出ます。
バグフィックスにかかる時間は思いのほか大きいものです。
それでも、このレベルの優秀さであれば、大量に人を集めても変わらないと判断する人も多いと思います。

さらに優秀な技術者はプロセスにも精通しています。

・テストの管理・変更管理・デプロイなどの定型業務のあるべき姿を知っていて改善することができます。
・不要なプロセスを指摘することができます。
・チェックポイントをまとめ上げ、可能ならば自動化します。

開発チーム全員の生産性を上げることができるので、寄与した生産性は１０人分を超えます。
ただし、そうすることが許されればの話で、個別の作業にEXCELの資料を求められたら意味がありません。

さらに、ほとんどが優秀な技術者のチームとなるとこのような効果があります。
（書いてから気が付きましたが、まんまアジャイル開発ですね・・・）
・設計段階からきちんとしたモデリングをすることができます。
・モデリングされたコードを書くことができます。
・開発段階でリファクタリングを行い設計変更による影響を減らせます。
・設計資料は最小限に抑えられます。
・テストを大規模に自動化できます。
・細かいリリースで、ユーザーテストに十分な時間をかけられます。

これができれば生産性は一人当たりの生産性は１００倍になっても不思議ではないかと考えています。
もちろんこれを受託開発で行うにはかなりのハードルがあると思われます。

しかし、これは大規模なソフトウェア開発では普通に行われていても不思議ではありません。
（google・Facebook・Microsoft・LINE・楽天　などを思い浮かべてください。）

大規模プロジェクトにおいてコーディング・プログラミングが占める割合は小さいのでOOPとは関係ない箇所で遅延しているんだと思いますよ。
大規模なシステム開発でコードを書く時間はごくわずかです。要件定義から始まって、設計、影響調査、レビュー、顧客の承認、コーディング、テスト、リリースまで作業が沢山ありますし、利害関係者の会議日程調整、チーム間の調整など無駄に時間が過ぎ去る要因もあります。

仮に全体の期間が100だとして、コーディングの割合が20だとします。ここで夢のような技術が開発されて、期間が半分に削減されて10になりました。人も費用も50%削減できました！でも、全体としては1割しか削減されてないんですよね。

よって技術的な部分を解決しても意味はないと思います。原因はそこにはないのですから。

面白そうな議論だったので、大規模プロジェクト視点で私の思うところを。

なお、もし質問者さんが大規模プロジェクトの関係者であれば、
1000人以上のエンジニアが身近にいると思うので、
現場で聞いた方が確実かと思います。
（立場によっては聞けないかもしれませんが）

でもOOPであれば、少なくとも仕様変更には強いはず。
なのに、なぜ失敗しまくるのでしょうか？
なぜ仕様変更のたびに膨大な影響範囲の調査・テストが必要なのか？
ある一部分の機能を変更するだけなら、そのクラスの単体テストだけでいいんじゃないの？

⇒仕様変更内容にもよりますが、
例えば、
「○○画面で出力される△△の帳票のこの項目の出力する仕様を
□から☆にする」ような内容であれば、
最初から影響調査が限定されている、と思うかもしれませんが、
これはこれで、単体試験で済むレベルでは収まらない影響調査が必要です。

たとえば、
「□から☆する部分は本当にこの帳票・この画面だけか」
「□の部分は他に参照していないのか」
「□から☆にするには、情報が十分そろっているのか」
「設計の内容・修正内容で、他への影響は本当にないかどうか」
etc...
上記以外にも、全くのど素人相手でも
「どう説明すれば、影響調査で問題ないと証明できるか」
という内容も考えなくてはならないので、
大規模であればあるほど影響調査には時間がかかります。

小規模であれば、「事前の結果がこれで、事後の結果がこれです」と言えば済む話かもしれませんが、
画面や帳票が500以上あるようなプロジェクトでは、
同じ項目がある他の画面や他の帳票等の事前と事後は？という確認が入るでしょうね。
確認する立場の人（品質を担保する人）はどんな作りをしているかなんて、関係ないですから。

しかし数百億円・数千億円規模のプロジェクトに関わるレベルの人ですら
上手な設計が出来ないのであれば、じゃあ一体誰なら上手に出来るのでしょうか？ 
現実的に「仕様変更に強い」という夢のようなことは期待できないのではないでしょうか？

⇒何を持って「上手な設計」とするか分かりませんが、
質問者さんの言う「上手な設計」が
『1画面・1帳票・1項目の修正があると分かっていない、かつ、予測も無理な時点で、
1画面・1帳票・1項目の修正の導入を1ヶ所修正して単体試験で終わらせて
リリースできるような設計になっている事』
を指すようであれば、誰にもできないでしょうね。

このレベルの要求になると、OOPは飛び越えて、
設計・製造・試験・リリース・運用・保守を全て人工知能化するとかでしょうか。
それだけで、莫大な費用と工数がかかりそうですが、
（最近流行の）人工知能を活用する場合でも、ビッグデータが必要ですから、
「仕様変更のビッグデータ」を作るとなると、当分、無理でしょうね。
（ここで触れてる実現の可否はあくまで簡単な机上の話です。）

また、大規模プロジェクトの中でも、仮に完全独立していて、
「単体試験してOKならリリースしてOK」という場所があったとしても、
「すぐ対応できた分、安くなります」ではなく、
「上手な設計」をした関係者（顧客含む）の単価を上げて欲しいなぁ、
と個人的には思います。

もしOOPが理論どおりに機能する概念だとしても、
開発に延べ何千人も関われば結局グズグズになっていくのではないでしょうか？

⇒そんなプロジェクトもありましたね。何社つぶれたことか。。。
とはいえ、何千人居てもうまく回ってる（大事なニュースにならない）
プロジェクトは表に出ないだけで、存在しているので、何とも言えないです。

少数精鋭でやったほうが速く安く正確に開発できるのでは？

⇒パレートの法則は無視されますが、机上はそうなります。
ただ、集める段階でうまく行かないと思われます。
100人に1人居るか居ないかのレベルの人は、
既に参加している現場が手放したくない状態でしょうから。
お金チラつかせて既に参加している現場を無視して、
ヒョイヒョイ乗っかってくれれば楽でしょうが、
人間には人情もありますので、
人探しだけで数ヶ月～数年かかるでしょうね。

また、少数精鋭の場合、誰か１人でも体調を崩す等で欠けたら、
スケジュールに大きく影響するため、顧客側が
リスク（スケジュール・追加費用等）に寛容にならないといけませんが、
納期絶対の官公庁系では無理でしょうね。

それと、開発をする上で、
「優秀な人がわざわざやらなくても良い作業」
「優秀な人でなくても出来る作業」
「優秀な人でも普通の人でも作業スピードの差が少ない」
というのが必ず存在します。
こういう作業をわざわざ超高給の人にやってもらうのは、
逆に費用対効果が悪いと思います。

また、保守性について、
ずっと続くような官公庁システムの場合、
いつまでもその優秀な人たちだけにやってもらうわけにもいかないので、
100人に1人居るか居ないかの「卵」を育てるor見つける必要があります。
その優秀な卵も途中でリタイアするかもしれませんが、
今後も安定したシステムを提供し続けるには、数千人のうちの数十人が必要不可欠と思われます。

数千人規模のエンジニアと言っても、
優秀でない人の中身はコロコロ変わっているので、
超優秀な人材数十人を雇う≒数千人規模の開発であることは割と理にかなってる気はします。

最後に半分ボヤキですが、数千人規模の開発において、
優秀な人材は他に行ってしまうリスクが大きいので、
所属している会社側でワークライフバランスをどうにかするか、
受注側で給料の配分はどうにかするか、
発注側で個別支給とかがあると良いのかもしれませんね。

オブジェクト指向は本当に変更に強いのか？

オブジェクト指向という道具を適切に使用することが出来れば、オブジェクト指向が出る以前に比べ、変更に強くしやすくなった、と言えます。

何故、このように歯切れが悪いかと言うと「オブジェクト指向」というもの自体は、あくまでツールの一つであり、使わない場合における「万人がよく陥りやすい問題」を、このツールの使用によって少なくする事は可能ではあるものの、同時に、このツールの使用によって新たに生まれた独特な複雑性も存在します。

毒の部分が強調されてしまうか、薬の部分が強調できるかまでは「オブジェクト指向」というツールは関与しない為「変更に強い」という言葉の文脈に応じ、そうとも言えるし、一概にそうとも言えない、とも言えてしまいます。

なぜOOP開発での失敗例が多発するのか？

このご質問の前提とし「でもOOPであれば、少なくとも仕様変更には強いはず。」という思い込みがあるように感じられますが、前述の通り、OOPであってもそうでなくても「仕様変更」というものは要求から設計に落としてコードに落とした過程そのものを覆す、上位の出来事です。（要求の変化、または設計ミスによる辻褄合わせ）

仕様変更の度合い次第では、OOPが適切に使用されていて助かったという局面もあれば、その仕様変更は勘弁…という仕様変更もあります。
しかし、どちらにしても、手を付ければ付けるほど乾燥した砂の城のように意図しない所からボロボロ崩れていく状態になりがちな可能性のある方法と、少しは水分を含んだ砂の城に手を入れるのと、どちらがマシかといったら後者でしょう。

変更に対する強度は、OOPを全く使用しないよりは多少マシというものです。

失敗例の教訓、改善法はあるのか？

それらの教訓から、模索しつつ進んでいる過程と考えます。
OOPの抱える問題点や、開発手法（今回の場合、大規模開発、ウォーターフォールモデルに絞ったほうがイイのかな…）が抱える問題点などを解消する為、OOP＋αの何かだったり、様々な開発手法が生まれています。
ただしここにおいても、やはり万能の銀の弾丸は存在せず、宇宙のしがらみによったり、今回はこれでよかれと思ったものがフィットしなかった、という不幸は付きまといます。
むずかしいですね…。

なぜ少数精鋭チームで開発しないのか？

・他社との差別化を要求するが故に共通パッケージのようなものでは済まない
・既存のシステムを完全置換できない、あるいは最低限連携できないと困る為、接合部は共通化できない
とか考えてみましたが、弱いですね。

流石に実績が無ければ任せづらい、という事実はあるにせよ、例えば歴戦のSIerで、いわゆる本当にデキる「公的システムや金融機関システムを開発する人たちの中でスペシャルに能力が高い人」達が結託し、過去のノウハウを集約し、パッケージ化した金融・公的システムに絞って作成・販売する集団が、自前で銀行作って運用し始めちゃうくらいの所から実績もひっさげつつ出てきたりしてもおかしくはないような気がしますが、それが出てこない理由が何かあるのでしょうね…。

なんか「面白そうな話題だったので～」みたいな事言ってる人いますが、
全然おもしろくもなんともない話題ですよ、これ。

なのに、なんでみんな、本当のこと教えてあげないんですか？

・なぜOOP開発での失敗例が多発するのか？
・なぜ少数精鋭チームで開発しないのか？ 

答えは、ゼネコン体質だからですよ。
Nなんちゃらとか、Hなんちゃらとか、Fなんちゃらとか、Tなんちゃらみたいな「名の通った馬鹿デカイ会社」が仕事を請けるけど、基本的にそいつらは何にもしなくて下請け会社に丸投げします。

その下請け会社もさらに下請け会社に丸投げします。それを何回か繰り返して、
４次請けとか５次請けとか、場合によってはさらにその下の会社に来ている、ほとんどがマトモなコードさえ書けないレベルのやつがプログラムつくるからですよ。

そうすっと、その階層構造で伝言ゲームしまくることになって、無駄なドキュメント作成や連絡の時間が膨れ上がっていきます。伝言ゲームやった事あるでしょう？最初と最後で全然違う物になること、しってるでしょう？

で、プロジェクトが遅れ始めると、「やばい、もっと人増やせ！」ってなって、どんどん人員規模がでかくなってくんです。予算だけは無駄に膨大に確保してありますからね。

人員規模がでかくなると、さらに伝言ゲームがむずかしくなっていって、統制がとれなくなっていきます。人を増やせば増やすほど、開発が難しくなるんです。こうなったらもう、手遅れですね。どうしようもありません。

・失敗例の教訓、改善法はあるのか？

教訓はもう、最近、あちこちから声が上がっています。
3,4年前の「特許庁の56億円プロジェクト大失敗」の顛末を読んでみて下さい。
あれが特別な例なのではなく、あれがこの国の本質なのです。

上記が原因なので、つまり、その一番最初のところを改善する以外に方法はないですよ。

要するに、OOPがどうしたとか、そんなのとは全く関係無い低次元なところで失敗しているんです。

だからこの質問は、全く関係ない２つの事を結びつけようとしている、頓珍漢な質問だということです。

ちなみに、最近の例の「みずほ銀行のプロジェクトがヤバイ」という話は、さらに話がややこしくなってます。
銀行の大統合のせいで、今のみずほ銀行のシステムは元あった複数の銀行のシステムをつなぎ合わせたハリボテみたいな状態みたいです。
だから、「これは統合しなければ」ってなったみたいですが、元々別銀行で別の手続きで行っていたものですからね、そう簡単には行きません。
全部の仕組みがわかってる人が何人かいれば簡単なんでしょうが、多分、一人も居ないんじゃないでしょうかね？
そこに前述のすばらしきゼネコン文化開発を持ち込むんですから、うまくいくわけ無いですよ。

現場で働いていた末端のプログラマの声とかも探せばみつかりますが、もはや、人間の働く場所ですら無かったみたいな感じですね。

そんなところに、スーパーハッカーな人がくるわけないですね。
寧ろ、絶対に避けるでしょう。

そういうことです。

面白そうな話題なので、私も回答してみようと思います。

 オブジェクト指向は本当に変更に強いのか？

本当です。きちんと設計されていれば。
理由は簡単です。オブジェクト指向設計では「変更可能性を織り込んで」設計をする事ができるからです。

ここはこんな風に変更するんだよ。と明示されているわけです。

そのような設計が変更に強いのはむしろ当然のことではありませんか？

 なぜOOP開発での失敗例が多発するのか？

OOPだから失敗した、というわけではないのではないですか？

 失敗例の教訓、改善法はあるのか？

それがわかっていたら大金持ちになれます。

 なぜ少数精鋭チームで開発しないのか？

属人性をなくしたいからだと思います。
SIerはSIの工業化という夢を見ています。
だれがやっても同じものができる。というものです。
そうすれば、工場で流れ作業のようにプロジェクトができます。
優秀なエンジニアに頼ると、その人間がいなくなるとどうにもならないし、それはエンジニアの価値
であって、SIerの価値ではなくなってしまいます。
SIerの価値とは、だれがやっても一定水準のシステムを作れる方法論を持っているということだ。
そう彼らは考えます。
だから、彼らは少数精鋭など絶対にしないのです。

強力なツールであることは間違いはないですが、完全なものではありませんし使う人間にも依ります。また、規模が大きい話ならば技術要素でない経営上の要素も当然絡みますし一概には言えません。

ちなみに、「仕様の変更に強い」といっても、これを安直に実施するようでは人間として信頼されません。ましてや「契約」が絡む話であれば「双方の合意」なく変更を行えば信頼問題となります。

（OOPではないですが）私が以前携わったプロジェクトにおいてこんなことがありました。当時の責任者は「仕様変更に強い作業手順を発明した」とか言ってこれを活用すべく仕事をもらってきておりました。私も一作業者としてこれに従事しましたが、責任者のアイディアは「消せるボールペン」レベルのものでした。契約企業の担当者に相談したら怒って仕事を打ち切られました。仕様変更のリスクは技術面だけでないことを留意してください。

オブジェクト指向やら言語を選定したら、勝手に仕様通りのコードが出来上がるわけではないですからね。
結局のところ、実装や設計の作業者のレベルによるってことです。

物は物、道具は道具で、手にした人間が正しく扱えるかどうかは別ですからね。

大規模、小規模、あまり関係ないと思います。
プログラミング言語の問題も、さほどないと思います。
仕様がキチンとしていれば、数年現場でプログラマやってればある程度人と同じぐらいに書けるでしょう。
エリートプログラマに任せば。。。なんて話も上がってますが、間違いだらけの仕様書で組んだ物は、誰がやっても間違いだらけです。

私は「発注側にプロがいないための、仕様の不安定さ」という事が諸悪の根源だと思います。

超小規模開発の現場で、それこそエクセルのVBAでこーゆーことをやってくれ、
という程度の仕事ですら、発注する側にエクセルVBAが多少でも使える人が担当についてくれるのと、
事務のおばちゃんが担当するのでは、全然かかる時間が違います。
同じ人間がプログラムをしても、相手の担当が多少物事をわかってるかどうかで、最終的にかかる時間は２倍、３倍となってしまうことはよくあります。たかだかそんな物ですら、です。
これが銀行などの「担当者も全容を把握しきれていない、よくわからないプロセスが複雑に絡み合って凄く面倒な案件」だったら、どうでしょう。何百倍、何千倍に悪影響が出ます。

面倒なシステムほど、しっかりと細かい部分までわかっている人が少ないのも事実です。
大規模な案件では、イの一番に実力のあるSEチームを送り込み、仕様のあいまいな部分を開発に入る前段階で潰していく事が、現実的には一番効果があり、工期を短縮できるのかもしれません。

相対的な強さはあるんじゃないですかね。
仮に下記のようなシステムがあった場合、きちんとMVC分離されたシステムと比べてどちらが変更に強いかと言われたら、このサンプルの方が強いと主張する人はほぼいないと思います。

<html>
<body>
<?php
    if($_POST['data']) {
        echo $_POST['data']['name'].PHP_EOL;
    } else {
        echo '<input type="name">'.PHP_EOL;
    }
?>

1. オブジェクト指向は本当に変更に強いのか？
   上記のサンプルのようなシステムに比べてとても強いと思います。
   が、限度はありますし、仮に「人間」Modelに「100mを5秒で走る」機能を実装せよと言われてもとても難しいでしょう。
   どうしても実装する場合、「車に乗る」と言うような進化が必要になり、その場合は車の実装も必要になります。
   そしてこの車は変更要件から生まれたモノであっても、新規で開発したモノになる為、人間が車に乗った時の挙動その他についてはイチから設計し、開発し、テストを行う必要があります。

2. なぜOOP開発での失敗例が多発するのか？
   多くのプロジェクトは成功裏に終了しています。
   だからこそ失敗した時に大きく取り上げられ、問題となるわけです。
   そして、失敗しないために当然のようにOOA開発選択されていたので、それがOOA開発の失敗だ！と取り上げる方がいるわけです。

3. 失敗例の教訓、改善法はあるのか？
   ありますが、それはOOAという問題ではなくPMOの問題ですね。
   そして大きなプロジェクトの場合、PMOよりも権限の強い、契約条件という問題が大きくなっています。
   安心安全な国産無農薬素材100%で無菌室で調理された料理を提供する手法は多くの料理人が知っていて、実践する事も出来ますが、そんなことをやっていたら店の従業員に安定して給料を払えない事も併せて知っているわけですね。

4. なぜ少数精鋭チームで開発しないのか？
   1000人月のプロジェクトを10人で開発すると、100か月かかりますが。
   iPhoneが発表されたのでそれに対抗しようと開発を始めていたら、出来上がったころにはiPhone7が出来ていたという事になりますので。