動ける人は、動けない人に合わせないといけない？
「SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して」を拝見させていただいて、ひとつ思うところがありましたので書いてみます。
私自身、７〜８年ほど、オブジェクト指向分析・設計を業務で使用しています。
しかし、実務を継続していると、「本当に自分はオブジェクト指向を理解して活用できているのか？」と自問自答することが多いです。
というのも、「オブジェクト指向でないもの」に合わせて仕事をしなければならないことが多いためです。
例えば、ここ数年、コンサル上がりの「シニア」エンジニアと一緒に仕事をすることが多いです。
この人たちに基本設計書を作成してもらうと、どうしても次のような設計書が出来上がってきます。
- COBOL 的な手続きが順番に記されている「だけ」。
- 機能追加は、IF 文やパラメータ追加のオンパレード。
- 継承などの概念の記載は皆無。
要は、非オブジェクト指向の、COBOL のような手続き型言語のやり方に沿った設計書しか出てこないんですね。
たとえシステムが Java や C# で構築するものであったとしても。
一方で、実装以下を考えると、当然そのままではよろしくない。
ですので、詳細設計−実装・UT−IT については、非オブジェクト指向の基本設計書を無理やりオブジェクト指向設計や Java のフレームワーク構成に落としていくということをしていかないといけない。
ここで私は、次の２つのジレンマを感じるのです。
（１）設計と実装との間の思考断絶
基本設計レベルは非オブジェクト指向で、詳細設計〜実装レベルはブジェクト指向でと、フェーズによって考え方・会話レベルを変えないといけないということです。
会話レベルが違うということは、語彙も違う、双方の会話が成立し辛くなるということになり、コミュニケーションに余計なオーバーヘッドがかかることになります。
ここでミスコミュニケーションが発生し、バグが発生することは、容易に想像できますよね。
（２）非オブジェクト指向への「妥協」
上記（１）でのコミュニケーションギャップを埋めるために、詳細設計〜実装側が基本設計側に「妥協」しなければならないことが、どうしても出てきます。
その程度のコミュニケーションギャップぐらい埋めろ！と、よく実務を担当したことのない人は言いがちですが、プロジェクトは有限リソース内での活動です。
リソースの有限性から、非オブジェクト指向側へ「妥協」することが短・中期的に「正解」になる時が、どうしてもあるのです。
（もちろん長期的にはマイナスになることが多いですから、極力妥協しないようにはしていますが。）
結局のところ…オブジェクト指向を知っている側が、オブジェクト指向を知らない側に合わせてあげないといけないんですよね。
このことが、「自分は本当にオブジェクト指向が分かっているのか？」という自問自答に繋がるのです…
先日、『週刊プロレス』の武藤敬司選手と CIMA 選手の対談を読んだら、「動ける選手と動けない選手が試合をしたら、動ける選手が動けない選手に合わせてあげないと試合にならない」という趣旨のコメントがありました。
プロレスも同じなんですね。
動ける側の人が、動けない側の人に合わせてあげないといけないんです。
このジレンマは、おそらく今後数十年は変わることがないでしょう。
しかし私は、このジレンマと戦いながらも、常動ける側に立ち続けたいと思います。
