01.architect

変幻する実行可能知識 01

プロ (= あらかじめ)・グラム (= 書かれたもの).
アーキ (= 形)・テクト (= 作る者)

プログラムはCPUへの指令書だ. 「まずメモリ4番地にある値を取ってこい」「それとレジスタAにある値を足せ」「その値をメモリ6番地に書け」... プログラムがなければソフトウェアは動いてくれない.

でもソフトウェアの本質はどうやらプログラムではない. プログラムはソフトウェアの一最終形態に過ぎない. ソフト (= 柔らかい)・ウェア (= 物) が最後に実行されるために必要なうんちみたいなものだ. みんなうすうすその事情に気付いてはいる. けど, なかなかソフトウェア == プログラムの罠から抜け出せない. プログラムを書くことは気持ちいいし (うまく動けばなおさら!), じゃソフトウェアって何? って考え始めると納期に間に合わない.

Javaを使っている人も嫌いな人も例えば次のページを見てみよう. これはCalendarという暦を表すクラスのAPIだ. けど, 読んでみれば分かるようにここには実は「暦とは何か?」という知識が書かれている. 極端に言えば, JavaのAPIとは一冊の百科事典だ. もっとも正確に言えばJava APIに書かれているのは「Javaにとっての」暦の知識なんだけど, それはどんな百科事典でも執筆者や編集者や時代にとっての知識の集大成なんだから同じこと. もちろんAPIは表層的なもので, その裏にはその知識を「実行可能」にするプログラムが隠れている. でもここで重要なのは「Javaにとって暦という知識はどういうものか」ということをAPI (ドキュメント) が表しているということだ.

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

例えばJunという, オープン・ソース・ソフトウェアとして配布されている3次元マルチメディア・グラフィック・ライブラリがある. この中からJunTriangleという三角形を表すクラスを見てみよう. 本当はSmalltalkのブラウザで見るといいけど, Webからも見られるようになっている. Smalltalkではソースコード/プログラムそのものが知識を表していることが分かるだろう.

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

「二つの三角形が等しいとは...と言うことである」(インスタンス・メソッド =)

「三角形の面積とは...である」(インスタンス・メソッド area)

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

J2EEが手近だからとりあえずオブジェクト指向で行くか, と考えるくらいならばオブジェクトよりももっと「あなたのシステムの知識をよく表現する」方法を見いだした方がいい. あなたのソフトウェアはあなたのシステムに関する知識を本当によく表しているだろうか? それはどこに書かれているだろうか? 設計ドキュメント? プログラム? 誰かの頭の中? オブジェクト指向の考え方だってすべての知識を表す万全の方法じゃない. すべての知識を表すたったの一つの方法はない. きっとあなたのシステムに適した知識の表現方法があるはずだ.

別の知識の表し方を見てみよう. 最近大流行のEclipseにはEclipse Modeling Framework (EMF) というプラグインが標準的に提供されている. EMFでは対象となる分野に関する知識 (ドメイン知識) をモデルとして表現する. 例えば「ライブラリとは名前と著者一覧, 書籍一覧を持つものである. 著者とは名前があり, 著作を持つものである. 書籍とはタイトル, ページ数, 著者を持つものである」という知識は次のようなUMLのクラス図で表される.

やることはこのような図を描くことだけ. 後はEclipseのいくつかのボタンを押すとこの知識を「動かせる」ようになる. 「動かせる」とは本を作ったり, 本と著者をつないだり, 本のページ数を設定したりできるということだ. もちろんこれだけではユーザお望みのGUIもビジネス・ロジックもない. けどそれはまた別の分野の知識だから別の表し方がある. 今まではこういうクラスを作ってそれを操作できるようにするために何十行ものプログラムを書くことを「ソフトウェアを作ること」だと勘違いしていたかもしれないけど, 多分そうじゃない. EMFをうまく使うことによって生産性ももちろん上がる (ただし多分あなたが今思ったほどではない:-). けど, もっと重要なことはソフトウェアの本質の一部がより的確な形で知識として表現されていることなのだ.

さて今までは対象に関する表面的な知識, 形式的に記述できる知識だけを見てきたけど, 知識にもいろいろな種類がある. いわゆる「暗黙知」, 言葉にできない知識, 体で感じ取るような知識もソフトウェア開発には大きな役割を果たす. それから自分たち自身に関する知識, 自分たちがどうやってソフトウェアを作るのかという知識 (プロセス知) ももちろん非常に重要になってくる.

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

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

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

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

2004.02.07
山田正樹 (メタボリックス)

Comments