オブジェクト指向を論じるときに問題になるのは，関係する領域が異常なまでに広く深い，ということです。今回は一番基本的，逆に言えば一番普遍的でもある「オブジェクトとは何か」にテーマを定めて，議論していきたいと思います。

ビット処理から概念操作へ

　ソフトウェアはコンピュータ上のビット列を処理する命令語として始まりました。その命令自体も元々はビット列（機械語）だったわけです。これを少しでも理解しやすくしようと，意味のあるビット列にラベルやコードを付けて呼ぶようになりました。これがアセンブラ，あるいはアセンブリ言語と呼ばれるものです。そうこうするうちに似たようなコード列が頻繁に登場することに気づき，それらをまとめてサブルーチンとして呼び出して実行するというアイデアが生まれます（手続き型言語：Fortran, Cobolなど）。これにより小さな処理シーケンス（ロジック）の再利用が可能になりました。プログラミングの大衆化が進むと，手続き内の処理の記述方法が混乱しており理解しづらいという問題が出てきます。goto文や判断ジャンプなどがどこに行くのか，分かりにくかったからです。それを解決したのが構造化プログラミング（構造化言語：Pascal, Cなど）です。

図1●オブジェクト指向への道

　しかし手続きだけでは，業務で利用するデータ構造や業務フローといった大局的なモジュールを管理したり業務知識を再利用するのは難しいのです。そこで，関連するデータ構造と業務ロジックをまとめてパッケージにして，それをソフトウェアの単位にしようという言語が登場しました（モジュール指向言語，抽象データ型言語：Modula-2，Adaなど）。これは日本では普及しませんでしたが，その正当な進化形としてオブジェクト指向がようやく近年活況を呈してきたところです（図1[拡大表示]）。

概念をプログラムできる

　オブジェクト指向言語の特徴を一言でいえば，業務に登場する概念をプログラミングの対象にできるということです。業務に「顧客」や「口座」「取引」「信用」が登場すれば，それらを直接モジュールとしてプログラムで表現してしまえるわけです。さらにオブジェクト指向では，例外的なものも定義できます。これは現実世界ではよくあることです。例えば顧客の中で信用があり，取り引き額の多い顧客を優良顧客として特別扱いすることはよくあります。オブジェクト指向であればこれを継承メカニズムで自然に表現できます。

　人間は概念の分類や組み合わせで思考を進めます。このプロセスをサポートする言語として生み出されたのがオブジェクト指向言語です。ですから，概念をプログラミングするという動的な手段を使って「知識を表現し，問題を解決する」行為がオブジェクト指向に基づく考え方だといえるでしょう。

　したがって，今後ソフトウェア工学が進歩しても，そのベースにあるのはオブジェクト指向的な発想です。そこに新たな機能や機構が追加されて新言語が設計されることになるでしょう。人間の思考のメカニズムが変わらないのですから。現に，オブジェクト間の制約を表現しやすくした「コンストレイント指向」，オブジェクトの自律分散性を強化した「エージェント指向」，複数のオブジェクトにまたがる関心事（制御・管理したい共通特性）をうまく整理できるようにした「アスペクト指向」が登場してきています。

縦軸の「機能」と横軸の「データ」

　プログラムではデータと機能を扱います。どちらが格上でも格下でもありません。例えばある販売会社は，「仕入れる，受注する，配送する，請求する」といった機能を備えます。同時にデータとして「商品（さらに商品コード，商品名，仕入単価，販売単価，メーカー名），メーカー，注文，売上，顧客」を管理しています。

　機能に着目して，「仕入れる」「受注する」といった縦方向の単位でシステムを構造化するのが『機能中心』の考え方です。業務の流れの中で時系列に機能を取り出せるので，わかりやすいのがメリットです。半面，企業の業務形態や対応組織は頻繁に改変されますし，機能の切り出し単位も不明確です。結果として不安定な構造になりがちです。

　逆にデータに着目して，「商品」「商品コード」「単価」「メーカー」といった横方向の単位でシステムを構造化するのが『データ中心』の考え方です。仕入れ手順や売り上げ計上手順が変わっても，そこで処理される商品コードや単価といったデータはあまり変化しません。この方が機能中心のアプローチよりも安定した構造を構築できると考えられています。

　しかし「商品コードと商品名のどちらを優先するのか」とか，「商品と商品コードの関係」などにルールが必要になります。これが「正規化」です。データ自体は安定していても，正規化する際に用いるデータの形式や表現形式が不安定になり得ます。例えば商品コードやメーカー名といったデータ項目をどうコード化し，表現するのか。システムごとに変化するので案外不安定なのです。実際データ中心アプローチのプロジェクトでは，組織全体でコードを体系化し，それを維持することが最重要課題となります。

　よく考えると，安定しているのは個々のデータ項目ではなく，意味的に関連するデータ項目を束ねた「エンティティ」ということになります（上の例で言うと，商品コード，商品名，単価，メーカー名を束ねた「商品」）。つまり「データ中心」というのは本来『エンティティ中心』なのです。これはオブジェクト指向的な発想に近づいています。

羽生田 栄一 Hanyuda Eiiti

豆蔵 取締役会長
富士ゼロックス情報システム時代にSmalltalk-80システムに触れ，オブジェクト指向に開眼。以降オブジェクト指向技術の普及に努める。オージス総研を経て2001年にオブジェクト指向技術専業ベンダーである豆蔵の代表取締役社長に就任。2003年より現職。オブジェクト指向技術関連の訳書多数。技術士［情報工学部門］。