汎用のフレームワークがあれば業務アプリ実装にオブジェクト指向は不要という考え方は適切でないと思う

前回のエントリいまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味についてのブクマのコメントで、

すごく今さら感がｗ 最近の開発はフレームワーク使うことが多いようだから知らなくても作れちゃうと思ってたけど違うのかなあ。

という感想をいただきました。実際に、SI業界で多くの方々、特に、アプリケーション開発の下流工程を担当しない層の方でこのように考えている方はほんとうに多いのではないかと思います。確かに最近ではSalesforceなどの製品もありますし、CRUD処理を行うような見栄えの良い業務アプリケーションは非常に簡単に開発できるようになっているということはあります。また、Visual BasicやMS Accessなど気軽にアプリケーションを開発できるツール類は昔からありました。そして、業界構造などの理由からやむを得ない側面があるとはいえ、SIerの提供する多くのフレームワークでは、アプリケーション開発を行うPGができるかぎり頭を使わず単純作業でアプリケーションを開発できるようなツールやフレームワークを必要以上に尊重する傾向があります。（Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して）
そして、大規模案件ではSOAやデータ統合などの名目で上流の工程に莫大な予算をつぎ込んで長期間「分析」「設計」をし、Excel方眼紙などの成果物を山のように作成する一方で、肝心のプログラムは自動生成だったり、コピペだらけだったり、まったく目も当てられないようなひどいコードを大量に作成するようなことが今でも日常行われているようです。
業務アプリケーション開発といっても、マスタデータの管理など単純な案件もあり、そういった業務では確かにツールで自動生成してしまえば、あえてオブジェクト指向設計する必要のない場合もあるでしょう。しかし、一般的に何百億円をかけて開発するような、大規模な基幹業務システムの業務ロジックは、想像を絶するほどきわめて複雑なものとなっているという事実を忘れてはならないと思います。実際、金融のシステムで一つの注文取引を投入する際には、残高の確認やインサイダー取引のチェックなど様々なチェックロジックが何万ステップにもわたってスパゲッティーのように入り組んで呼び出されているということがありますが、話はそれだけでは全然終わらないのです。金融の注文といっても、株も債券もあり、それも外国株とか国債とか多岐にわたった種類があります。一つの商品の注文を扱うだけでも相当複雑なチェックが必要なのに、それが各商品ごとにまったく同じではないけれども少しずつ違う処理が存在しているということです。
金融にかかわらず製造や流通などさまざまな業務で、このような複雑な処理が必要なのですが、こうした複雑なドメインを上手に扱うときにこそ本来はオブジェクト指向の設計が威力を発揮するところだと思います。残念ながら私が見たほとんどの大規模基幹システムでは、Java言語を使っていても、オブジェクト指向ということは全くと言っていいほど考慮されておらず、商品ごとにほとんど同じようなロジックが何十か所にもわたってコピペされているという状況になっていました。
確かに、

• 画面部品
• データベースアクセス
• ワークフロー
• 通信

など、汎用的なところではオブジェクト指向のフレームワークが使われているのですが、肝心の業務ロジックの部分でオブジェクト指向が活用されているというケースが少なすぎるのではないかと思うのです。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

の503ページに以下の記述があります。

素人にもわかるフレームワークを作成してはならない。
設計ができるほどには賢くない人も開発者の中にいると想定したチーム分割は、失敗する可能性が高い。これはアプリケーション開発の難しさを過小評価しているからである。設計ができるほどには賢くないなら、ソフトウェア開発を担当させてはならない。逆に十分に賢いのであれば、大事に面倒を見ようとすると、かえって担当者が必要とするツールとの間に障壁を作り出すだけである。

これは、単価の低いPGを大量に雇って品質の低いプログラムを労働集約的に量産させると考えている従来のSIerの考え方とまったく逆の主張です。もちろん、オブジェクト指向設計のできる上級プログラマーの人数には限りがあるというところも考慮すべきですが、従来何万行のロジック＋コピペで作成していたような複雑なドメインロジックの開発を大量の人月をかけて労働集約で開発するのではなく、少ない人数のコアのプログラマーが中心となって慎重に設計しながら開発するというモデルにシフトすれば、全体として開発費用を大幅に削減できるでしょう。そして、できたプログラムの機能拡張やバグ修正も容易となり、長期にわたったメンテナンスコストは大きく削減できると思うのです。
もちろん、3か月だけ稼動して後は捨てるといったシステムを短期間に作成するといった場合は、とにかく大人数で作るというモデルが適合しているケースもあるのですが、少なくとも何十年にもわたってメンテナンスするような基幹業務のシステムでは、もっと品質の高いプログラムを作成して維持するという方式にいいかげん切り替えていくべきなのではないでしょうか。
なお、同じような考え方はプログラム内部の設計より大きなシステムの設計や調達といった大きな粒度にも当てはまると思います。実際、DDDの4部では、本来のEA的、SOA的な考え方にもつながるような考え方が書かれています。こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指してで書いたこととも関連しますが、既存のレガシーシステムを活用しながらも、戦略的・段階的に企業のシステムのアーキテクチャを発展させていくような考え方が説明されています。これなどは粒度は異なるところがあるとはいえ、プログラムの段階的なリファクタリングという考え方に通じるところがあります。EA、SOA、クラウドなどキーワード上はこうした考え方を取り入れている（つもりになっている）大企業はたくさんあると思いますが、実際にはベンダの言われるままにハードやミドルにお金をかけているだけで考え方が全然理解されていないのではないかというところがあります。これは、Javaを使っているけれどCOBOLと同じような設計になっているというところと似ています。
今後、あるべき姿に発展させていくためには、業界構造の変革を通して、SIer自身が変わっていかなくてはならないだけでなく、システムを調達するユーザー企業の側もプログラムやシステムの設計の品質に対する考え方*1を変革していくことが大切であると思います。

*1:むしろ、ささいなバグを一つでも出してはいけないなど、アーキテクチャによらない細かいところの品質には必要以上にこだわっているところがあります。