J2EE関係のプロジェクトを２つ終えて、次に担当した仕事は、J2EE製品の営業活動でした。J2EE製品をお客さんに買ってもらうために、メリットをしゃべりまくる。買ってくれたお客さんには、その後の開発をサポートしてまわる。そういう仕事です。関東ではソコソコ売れ、大阪や名古屋にも飛び火し、けっこうなスピードで普及していく感じがしました。

その中で、よく出てくる話題が「オブジェクト指向って何？」という素朴な疑問でした。理解が進まないうちに、「Javaはオブジェクト指向だから簡単に早く安くシステムを作ることができる」という神話が、どんどんひとり歩きを始めます。最近では「サービス指向（SOA）」もそうですね・・・それと同じような感じ。

「オブジェクト指向」を説明するのは、大変でした。言葉そのものの意味はとても単純なのですが、Javaや企業システムと関連づけると、「オブジェクト指向」の意味するところが、とても広くなってしまいます。

オブジェクト指向を分類してみると（コレもおかしな話ですが）、こんな階層になるのではないでしょうか。

• Javaの言語仕様（クラスとインスタンス）
• デザインパターン（設計手法と名称の体系）
• ＵＭＬ（実世界のモデリング手法）
• コードの再利用（パッケージ・ライブラリ・フレームワーク）
• ランタイムの再利用（ＥＪＢ）

これら全てを、「オブジェクト指向」という言葉でごまかしてしまいがちなのです。まずはこの階層を示して、あとはお客さんの興味がそそられるところを念入りに説明する。というやり方で、営業まわりをしていました。

そうしていくと、お客さんの興味は、ほぼ１００％、「再利用」という言葉にひっかかります。そして次は、「どういうふうに作れば、再利用できるの？」という質問が多くなる。

私の場合は、こんな風に答えてました。

イチ技術者がエラそうに、お客さんの体制のことまでクチをはさむのはどうかと思ったのですが、本気でそう思っていたし、会議室で細かい技術の議論をしてもムダなので、しょうがありません（？）でした。
この漠然とした説明は、最近になって、エンタープライズアーキテクチャやサービス指向アーキテクチャとして体系化が進んでいます。

言ってはみたものの、私には実行できません。コンサル会社がやってくれるでしょう。

じゃあ、再利用を進めるために、技術的にできることはないのか？と言われれば、このころ日本で一気に普及していた「デザインパターン」があります。

しかし、「デザインパターンを駆使することによって工数が減る」、とは、あまりに短絡的。

次回に続く。