質問: オブジェクト指向(OOP)は変更に強い、と一般に言われます。 カプセル化とかいろいろな機能のおかげで、あとから仕様変更する場合などに他に影響が及びにくい、と。 しかし実際には銀行や官公庁の大規模プロジェクトで、システム開発の失敗や遅延、頓挫などをしばしば見聞きします。 それらはおそらくJavaでOOPで開発されているはずです。 失敗や遅延などする理由は、発注元の曖昧な要求や後出しの仕様変更の多発などが想像されます。 でもOOPであれば、少なくとも仕様変更には強いはず。 なのに、なぜ失敗しまくるのでしょうか? なぜ仕様変更のたびに膨大な影響範囲の調査・テストが必要なのか? ある一部分の機能を変更するだけなら、そのクラスの単体テストだけでいいんじゃないの? 「OOPは設計が大事。最初の設計がダメだった」という意見が想定されます。 しかし数百億円・数千億円規模のプロジェクトに関わるレベルの人ですら上手な設計が出来ないのであれば、じゃあ一体誰なら上手に出来るのでしょうか? そう考えるとOOPって机上の空論というか、現実的に「仕様変更に強い」という夢のようなことは期待できないのではないでしょうか? あと、もしOOPが理論どおりに機能する概念だとしても、開発に延べ何千人も関われば結局グズグズになっていくのではないでしょうか? 少数精鋭でやったほうが速く安く正確に開発できるのでは? そもそもなぜ延べ数千人・数万人もの開発者が必要なのか? 規模がデカいだけで、機能個々のプログラムの内容自体はそんなに難しいものではないでしょう? 初心者に毛が生えたようなSEやプログラマ数千人かき集めるよりも、スーパーハカークラスを超高給で数十人雇ったほうがいいのでは? 質問を整理します。 1. オブジェクト指向は本当に変更に強いのか? 2. なぜOOP開発での失敗例が多発するのか? 3. 失敗例の教訓、改善法はあるのか? 4. なぜ少数精鋭チームで開発しないのか? その他OOP開発や大規模プロジェクトの失敗等について思うところあればなんでもご意見ください。
回答: 大規模プロジェクトにおいてコーディング・プログラミングが占める割合は小さいのでOOPとは関係ない箇所で遅延しているんだと思いますよ。 大規模なシステム開発でコードを書く時間はごくわずかです。要件定義から始まって、設計、影響調査、レビュー、顧客の承認、コーディング、テスト、リリースまで作業が沢山ありますし、利害関係者の会議日程調整、チーム間の調整など無駄に時間が過ぎ去る要因もあります。 仮に全体の期間が100だとして、コーディングの割合が20だとします。ここで夢のような技術が開発されて、期間が半分に削減されて10になりました。人も費用も50%削減できました!でも、全体としては1割しか削減されてないんですよね。 よって技術的な部分を解決しても意味はないと思います。原因はそこにはないのですから。