オブジェクト指向は人類を救わない

10年来のつきあいになるうちの部長と最後の晩餐をしたときに、言語に依存する詳細設計寄りの基本設計、いわゆるソフトウェア構造の策定の話になった。これまで、テクノロジーというか、アーキテクチャというか、エンジニアリングの話をあえて避けていたが、どうやら、話を振ればしてくれたようである。このような業務要件と性能要件が求められるアプリケーションにおいて、最適なソフトウェア構造はどういったものか、という類の議論だが、もっともっとすればよかった。

2008年現在では、ＩＴ業界の管理職は、おおむね、メインフレームパラダイムの人が多いので、燃え上がっているプロジェクトの原因を究明するとき、テクノロジの細かい話に踏み込めない。プロジェクトリーダーは、オープンパラダイムの人が多いので、OOP開発にオブジェクトベースで関数型な考え方を持ち込もうとする。プロになったときに、OOPしか目の前になかったエンジニアは彼らに話をわかってもらうことが困難だ。
3 年くらい前に名古屋でサブリーダーをやったときも、僕は非常に苦労した。なぜクラスをnew する必要があるのか。関数がメソッドとして構造化されているだけで、オブジェクト指向は構造化プログラミングとなんら変わらないのではないかと、当時35歳以上の人には、何もわかってもらえなかった。
new する必要は、アプリケーションがスタンドアロンではなく、Webであるときは、複数のスレッドからクラスが呼び出されているので、static であってはいけない、という理由があるが、オブジェクト指向が構造化プログラミングと変わらないということについては、どうしても、今でも納得がいく説明ができない。
ゆえに、部長との最後の晩餐では「ITは人類を救うが、オブジェクト指向は人類を救わない。」という結論に至った。確かに救わない。いわゆる、EJBとか、Hibernateとかは、データベースをクラスにマッピングする技術であって、これらは突き詰めると、ノンコーディングでアプリケーションが構築できることを目指しているとしか思えない。Structs に至っては、それを目標としてあげている始末だ。

それでいくとこういうことか。OOPのO/Rマッピングにより、B/Lが汎用化されることにより、アプリケーションの業種別のテンプレートないしはスケルトンが整備され、これまで決定的な解がないとされてきたソフトウェアの見積が定型化し、さらには、開発手法も平易となることで、ソフトウェア開発全体のコストが抑えられる、ということかね。。。うーむ。

これだと確かにITは人類を救うが、エンジニアはよりいっそうつまらなくなるね。いまでさえ、いつかどこかで書いたようなSQL文を書いていることがエンジニアの悩みなのに、エンジニアに求められるスキルはどんどん下がっていくね。長い目で見て、オブジェクト指向はエンジニアの仕事を減らす技術であろうことは明らかであるっぽいな。（とても長文）