システムに適した知識の表現方法を探る：実行可能な知識とソフトウェア（1）

» 2004年03月17日 12時00分 公開
[山田正樹，メタボリックス]

　プロ （＝あらかじめ）・グラム （＝書かれたもの）、アーキ （＝形）・テクト （＝作る者）…。プログラムはCPUへの指令書だ。「まずメモリ4番地にある値を取ってこい」「それとレジスタAにある値を足せ」「その値をメモリ6番地に書け」……。プログラムがなければソフトウェアは動かない。でも、実は、ソフトウェアの本質はプログラムではない。プログラムはソフトウェアの一最終形態にすぎない。みんなうすうすその事実に気付き始めている。けど、なかなか「ソフトウェア=プログラム」のわなから抜け出せない。プログラムを書くことは気持ちいい（うまく動けばなおさら！）。だけど、ソフトウェアって何？

って考え始めると納期に間に合わなくなる。

　Javaを使っている人も、Javaが嫌いな人も例えば次のページを見てみよう。

◎ http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/util/Calendar.html

　これはCalendarという暦を表すクラスのAPIだ。読んでみれば分かるようにここには実は、「暦とは何か？」という知識が書かれている。極端にいえば、JavaのAPIとは1冊の百科事典だ。最も正確にいえばJava

APIに書かれているのは、「Javaにとっての」暦の知識なんだけど、それはどんな百科事典でも執筆者や編集者や時代にとっての知識の集大成なんだから同じこと。もちろんAPIは表層的なもので、その裏にはその知識を「実行可能」にするプログラムが隠れている。でも、ここで重要なのは「Javaにとって暦という知識はどういうものか」ということをAPI（ドキュメント）が表しているということだ。

　オブジェクト指向という言葉もいい加減手垢が付いてきて、いまじゃ単にJ2EEや.NETでシステムを作ることくらいにしか思われていないけれど、もともとはそうじゃなかった。そもそも、J2EEや.NETはオブジェクトとは多分ほとんど関係ない。本来のオブジェクトとは、知識をモジュールとして表す1つの方法だったはずだ。オブジェクト指向言語／環境とは、知識をうまく表現できるものでなければならない。元祖（！？）オブジェクト指向言語Smalltalkはまさに、そういう言語／環境だった。

　例えばJunというオープン・ソース・ソフトウェアとして配布されている3次元マルチメディア・グラフィック・ライブラリがある。

◎ http://www.sra.co.jp/people/aoki/Jun/Main.htm

　この中からJunTriangleという三角形を表すクラスを見てみよう。本当はSmalltalkのブラウザで見るといいのだけれど、普通のWebブラウザからも見られるようになっている。

◎ http://www.sra.co.jp/people/aoki/Jun/Encyclopedia/

htmls/JunTriangle.html

　これを見ると、Smalltalkでは、ソースコード／プログラムそのものが知識を表していることが分かるだろう。

「三角形とは面の一種である」（スーパークラス JunSurface）

「2つの三角形が等しいとは……ということである」（インスタンス・メソッド =）

「三角形の面積とは……である」（インスタンス・メソッド area）

などなど。それぞれの知識に対応するプログラムは平均して7?8行しかない。ここでは知識の宣言的な表現と手続き的な表現がうまく融合している。Jun全体が2D／3Dグラフィックスの素晴らしい教科書になっているはずだ。

　“J2EEが手近だから取りあえずオブジェクト指向で行くか”などと考えるくらいならば、オブジェクトよりももっと「あなたのシステムの知識をよく表現する」方法を見いだした方がいい。あなたのソフトウェアは、あなたのシステムに関する知識を本当によく表しているだろうか？

それはどこに書かれているだろうか？ 設計ドキュメント？ プログラム？ 誰かの頭の中？ オブジェクト指向の考え方だってすべての知識を表す万全の方法じゃない。すべての知識を表すたったの1つの方法なんて便利なものはない。きっとあなたのシステムに適した知識の表現方法があるはずだ。苦労してでも、それを探すしかない。

　別の知識の表し方を見てみよう。最近大流行のEclipseにはEclipse Modeling Framework （EMF）というプラグインが標準的に提供されている。

◎ http://eclipse.org/emf/

　EMFは対象となる分野に関する知識（ドメイン知識）をモデルとして表現する。例えば、「ライブラリとは名前と著者一覧、書籍一覧を持つものである。著者とは名前があり、著作を持つものである。書籍とはタイトル、ページ数、著者を持つものである」という知識は次のようなUMLのクラス図で表せる。

◎ http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E/emf-home/docs/glibmod/gl001.gif

　やることはこのような図を描くことだけ。あとはEclipseのいくつかのボタンを押すと、この知識を「動かせる」ようになる。「動かせる」とは本を作ったり、本と著者をつないだり、本のページ数を設定したりできるということだ。もちろん、これだけではユーザーがお望みのGUIもビジネス・ロジックもない。けどそれはまた別の分野の知識だから別の表し方がある。

　いままでのあなたは、こういうクラスを作って、それを操作できるようにするために何十行ものプログラムを書くことを「ソフトウェアを作ること」だと勘違いしていたかもしれない。だけど、多分それは“正しい”ことじゃないのだ。EMFをうまく使うことによって生産性ももちろん上がる（ただし、多分あなたがいま思ったほどではない）けど、もっと重要なことは、ソフトウェアの本質の一部が、もっと的確な形で知識として表現されているということなのだ。

　さて、いままでは対象に関する表面的な知識、形式的に記述できる知識だけを見てきたけれど、知識にもいろいろな種類があることを思い出さないといけない。例えば、いわゆる「暗黙知」。言葉にできない知識、体で感じ取るような知識もソフトウェア開発には大きな役割を果たす。それから、自分たち自身に関する知識。自分たちがどうやってソフト

ウェアを作るのかという知識（プロセス知）ももちろん非常に重要になってくる。

　そういったさまざまな知識をうまく表現すること、知識をうまく作り出すこと、知識をうまく伝えること、知識をうまく育てていくこと、知識と知識をうまくつなげることがソフトウェア開発の本質にかかわっている。何もこんなことをいい始めたのは僕が最初でも何でもなくて、ほかのエンジニアリングの分野ではすでに何年も前からさまざまな取り組みが行われているのだ。ソフトウェアにとっても、いやソフトウェアにこそそういう考え方が必要なんじゃなかろうか？

　ただ間違えてほしくないのは、「知識としてのソフトウェア」は別に人工知能（AI） とか、Prologでプログラムを書くことを意味しているわけではまったくない、ということだ。もちろんAIのテクノロジで役に立つことがあるかもしれない。Prologも知識表現の1つの方法だ。だけど重要なのは、僕たちが日々やっている「ソフトウェアを作る」という作業そのものが知識と切っても切り離せないということだ。

　これからしばらくは、ソフトウェアを作ることを、知識という切り口から見ていこうと思う。僕はそれによっていま、ソフトウェア開発が陥っているある種のどん詰まりから抜け出せる道が見つかるんじゃないかと期待しているけれど、そううまくいくかどうかは分からない。険しい道ばかりではなく、面白そうな道を探して歩こう。しばらくお付き合いをいただきたい。

　最初にアーキ （=形）・テクト（=作る者）と書いたけど、「アーキ」とは自然な形（モーフ）よりはどちらかというと力／権力によって作られる形を表しているようだ。僕たちが自らアーキテクトを名乗るとすれば、そのことにも一度思いをいたすべきなのかもしれない。

著者プロフィール

山田正樹

（株）ソフトウェア・リサーチ・アソシエイツ 、（株）ソニーコンピュータサイエンス研究所を経て、1995年（有）メタボリックス設立。代表取締役。アーキテクチャ、モデリング、マネージメント、コラボレーションなどを含む広い意味でのソフトウェア・プロセス・エンジニアリングが専門。ソフトウェア・ツール開発、メンタリング、コンサルティングなどを行っている。



「実行可能な知識とソフトウェア」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ