前回は，オブジェクト指向開発方法論の現状をご報告いたしました。その報告内容は，通常プログラミング作業に従事しない“普通の人々”の視点から整理しました。

　連載第3回目の今回は，オブジェクト指向開発方法論では避けて通ることができないといわれる“クラス”を取り上げます。ここでも考察する上での視点が重要な意味を持ちますが，前回同様，次のような視点を設定することにします。

“オブジェクト指向開発方法論において不可欠といわれるクラスは，私たち“普通の人々”にどのようなメリットをもたらすのか？”

それではまず，前回も紹介した次の文章をじっくり眺めてみましょう。

An object has state，behavior，and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable.

この文章は次の3点を主張していると思われます。

・オブジェクトというのものは，状態，振る舞い，アイデンティティを持っている
・類似したオブジェクトの構造と振る舞いは共通クラス内に定義できる
・インスタンスとオブジェクトという用語は相互置換可能である

　皆さんはこの情報を前にして，どのような感想を持つでしょう？　おそらく，開発作業に従事していない“普通の人々”とオブジェクト指向開発方法論に精通した現役開発者では相当異なる見解を持つのではないかと思われます。ご覧のように，第2文章には今回取り上げるクラスという用語が含まれています。現役開発者は，“構造と振る舞い”というペア用語に着目し，構造はデータ・メンバー，振る舞いは関数メンバーを意味すると解釈し，「構造と振る舞いの一体化こそががC言語の構造体とC++のクラスの最大の違いである」と，笑みを浮かべることでしょう。オブジェクト指向開発方法論に関する入門文献を初めて手にした開発者は，「インスタンスとオブジェクトの意味は同じなんだ！」，と叫ぶかもしれません。それでは，プログラム開発業務に縁のない“普通の人々”の取る反応はどのようなものでしょう。千差万別であることは間違いありませんが，一般には次のような反応を示すでしょう。

“なんかとても難しそうで，私にはチンプンカンプンです。”

　“普通の人々”が発注者になっている場合，経験の有無を問わず，開発者は会話の糸口を探す必要があります。例えば，納品後何らかの不都合が発生したとしましょう。開発者側は当然その対策が必要になりますが，対策の打ち合わせ会議の席で「オブジェクト指向開発方法論を採用して開発していますから，信頼性と安定性は万全であり，将来の拡張も容易のはずなのですが…」という発言が可能でしょうか。当然不可能でしょう。発注者の最大の関心事はインターネット上に多数存在する顧客へのすばやい対応だけです。システムの早期回復以外の何ものでもありません。発注者にとっては営業収益にかかわる問題であり，企業そのものへの信頼性の問題が発生しています。ここで信頼性という言葉が出てきましたが，この信頼性への疑問は，そのまま開発を担当したソフトウエア開発会社に向けられることでしょう。発注者が“普通の人々”の場合，対策打ち合わせ会議後，次のようにヒソヒソ話を始める可能性があります。

“今度頼んだソフト会社は駄目だね！”

図1

　この例え話は極論ですが，ビジネスでは信頼性を勝ち得ることが重要であることをはっきり示しています。ソフトウエアにはエラーはつきものであるという表現もあります。かなり乱暴な表現ですが，経験を積んだ開発者でもこの表現に正面から異議を唱えることはないでしょう。デバッグの専門家であるJohn Robbin氏は「Windowsプログラマのためのデバッグテクニック徹底解説」（日経BPソフトプレス発行）という自著の中で，次のようなことを述べています。

「ユーザーにとっては素晴らしい時代の到来ですが，私たちには失職の時代の幕開けです。確実にいえることは，より高い品質のソフトウエア製品のニーズが高まるということです。バグを含んだ製品の出荷は，即失業という時代が到来しました」

図2

　Javaプログラマの中には，「それはWindowsの世界の話だから，私たちには関係ない。言語使用が異なるのだから」と発言する人がいるかもしれません。しかし，図1[拡大表示]が示すように，ソフトウエアに完全ということはないのが現実ではないでしょうか。

　結論としては，すべてのビジネス・シーンに当てはまることですが，顧客（ソフト開発の場合は発注者）の信頼を勝ち取るための姿勢と努力が何よりも重要ではないでしょうか。具体的には，わかりやすい説明であり，高度なコミュニケーション・テクニックを身に付ける必要があることが，より一層重要になってきているのではないかと思います。前回紹介した，オブジェクト指向開発分野では先頭を行く会社「豆蔵」は，開発者のコミュニケーション・スキルの重要性を指摘し，発注者とのコミュニケーションを通して，技術移転も進める作業も企業活動に組み入れています。これは，オブジェクト指向開発方法論の重要な特徴であり，成果ではないかと私には思えます。

図3

　それでは，以降では具体的な例を紹介しながら，クラスの役割を考えてみます。まず，図2[拡大表示]の画面を見ていただきましょう。この画面は，Distributed Management Task Force（DMTF）という業界団体が策定を進めているCommon Information Model（CIM：共通情報モデル）のチュートリアルから取っています。ちなみにこの団体には，図3[拡大表示]に示すようなさまざまな企業が参加しています。

　CIMは，ネットワーク環境やエンタプライズ環境を構成する各種システム情報を表現するための，統一モデル（つまり，わかりやすい説明モデル）を定める仕様と考えるとよいでしょう。ネットワーク環境やエンタプライズ環境には，多数の機器やソフトウエアが用意されているのが普通ですから，多くの人は，情報表現を統一することなどできるのだろうかと，まず目を見開いてしまいます。そして，それができたところで，それを説明されても私たち外部の人間にはとても理解できないのではないかという不安も持ってしまいます。私も当初はそのように考えていましたが，自分のシステム環境を構成する，例えば，デスクトップなどの情報をいとも簡単に調べられることが実際にできるに及んで，「これはすごい！」とかなり感激したのを今でも鮮明に思い出すことができます。そして，それを可能としているのがオブジェクト指向開発方法論であり，クラスであることを知るに及んで，次のような結論を得ました。

“オブジェクト指向開発方法論とその中心にあるクラスは，人々の間のコミュニケーションを促進する”

この言葉の意味するところは，明日説明します。ごきげんよう。