変幻する実行可能知識 06
「かゑるといふこと」
ソフトウェアを作るとは顧客や市場のニーズを「動く」プログラムに変換することである. アーキテクトだの, プログラマだのは「変換装置」というわけだ. 一部分の変換過程はコンパイラやマクロ・プロセッサ, モデル駆動開発などの技術によって自動化されているけれど, 多くの変換過程はまだまだ人間の仕事だ. 例えば古典的なウォータフォール・プロセスを変換過程として考えるとこんな感じになる.
まず顧客やユーザの頭の中にある要求を仕様というものに落とし込む. その変換過程が「分析」と呼ばれる仕事だ. 分析は曖昧で (一般的には) 非定型的で矛盾を含んだ要求を, 明確で定型的で矛盾のない仕様に変換する.
次に「何がしたいか」を記述した仕様からそれを「どうしたら実現できるか」という見取り図へと変換する. この見取り図がアーキテクチャであるとおおざっぱに言い切ってしまおう. この変換過程では「どうやって実現するか」という要求や仕様には含まれていなかった知識が付加されることになる.
見取り図だけではモノを作ることはできないから, アーキテクチャをさらに変換して詳細な設計に落とし込む. この変換過程ではさらに実装プラットホーム (プログラミング言語やミドルウェアなど) に関する知識がどんどん付加されていく. これらの「どうやって」知識の付加過程が「設計」という仕事である (設計の成果物も設計と呼ばれる).
ここまでの変換過程は多くの場合, 自然言語から自然言語への変換だ. 最近は途中からUMLのようなモデリング言語に変換されることも増えてきたけれど, たいていは補助的に使われるに過ぎないので, 自然言語による記述がまったく不要になることはあまりない. ま, いずれにしろ最終的にはプログラミング言語に変換しなければならない. その変換過程が「実装」と呼ばれる.
世の中こんなに単純に物事が運べば言うことはないのだが, そんなに甘くはない. まずたいていの場合もともとの「要求」というのがぐずぐずの代物で, それを元に変換を重ねていったらとんでもないソフトウェアができあがってしまう. おまけに要求はどんどん変わっていくから, きまじめにそのたびに変換をやり直していたらいつまで経ってもコードに行き着くことができない. つまりあるレベル, ある時点で変換作業を停止しなければならないらしい. 言葉を換えれば元の要求は無限の情報量を持っているので, それを有限の情報量に変換するためにはどこかで「近似」せざるを得ないのだ. しかもこの近似のしかたに絶妙なポイントがあるようなのだ...
どうせ近似変換なんだし, この後で出てくる誤差の方がずっと大きいんだからここでむやみに精度を上げて桁数を増やすのに時間をかけても仕方がない, 2~3桁のほどほどの近似で十分, というのがアジャイル開発プロセスの立場である.
実は要求を仕様に変換するためには, 要求を「解釈」できなければならない. 解釈とは「こいつの言っていることと矛盾しないような自分の辞書 (モデルという) を作ること」である. 解釈のためには要求そのものだけでは足りなくて, 要求の背景となっている知識がある程度共有されていなければならない. その一つがいわゆる「ドメイン知識 (顧客やユーザの分野の専門知識)」であり, もう一つが「常識」なのである. 常識を明示的に表すことは多分無理だけど, ドメイン知識を何らかの形で明示的に表すことはある程度はできるだろう. データ辞書やビジネス・モデリングなんてのはその例だし, エンタープライズ・アーキテクチャはドメイン知識と仕様を統一的な構造の元で表現しようという試みと言っていいかも知れない. いずれにしろ, もしドメイン知識をうまく表すことができれば, この変換過程の半分はうまくいったようなもんだ. 常識の方は... 多分経験値を上げるしかない...
さて, ここまでは何だかんだ言ってもしょせんは精度を上げる, あるいはうまく解釈するという変換であった. 不可逆過程ではあっても相似変換と言っていい. しかしお察しの通り, 次の変換過程には大きなギャップがある. 「what」を「how」に変換するのである. 言ってみれば2次元の物体を3次元の物体に変換するようなものだ. 明らかに何かの知識を足し込んでやらなければやりたいことが実際にできるようにはならない. しかもその足し込み方は一通りではなく, 何通りものやり方がある. いや, 場合によってはどんなやり方があるかさえ分かっていないことだって多いのだ. ここで足し込まなければならない知識は実現方法に関する知識, アプリケーション知識である.
ここでは変換したものを射影すると同型になるという意味で逆射影変換と言っている. 変な用語だけど, 適切な用語が浮かばない.
アプリケーション知識は例えばAPIとか, パターンとか, 解説書とかの形で断片的にはかなり多量に明示的に存在している. しかしその組み合わせ方は無数にあって, さまざまな状況や対象によって異なるので, 断片的なアプリケーション知識を持っているだけではまったく十分ではない. 将棋で言えば定石を知っているだけでなく, 盤面を読まなければならないわけだ (しかも盤面は無限に広く, ルールも変わるかも知れない!).
このアプリケーション知識をどこに持たせるか, でいろいろなやり方がある. そんなものは変換過程の中に埋め込んでしまえ (そして自動的に変換すればいい) というのが, 形式的仕様とかモデル駆動開発というものだ(注). 読みの方は... 多分経験値を上げるしかない...
簡単に言うと形式的仕様は「how」をすべて変換過程に埋め込んでしまう, モデル駆動開発は「how」を半分人間が書いて半分変換過程に埋め込むという違いだと思っていい. これらの場合は2次元から3次元への膨らませ方が既に決められているので, あたかも「要求がそのまま動く」錯覚に陥るわけだ.
この先, 古典的なウォータフォール・プロセスでは何段階も変換過程が続いていくことになる. その変換過程ではとても多くの打ち合わせが開かれ, とても多くのドキュメントが作られて配られ, とても多くのレビューが行われる. 変換を重ねるほど, 対象によく近づいていくはずという信念に基づいて...
しかし, この変換過程はそんなによくできた変換過程ではない. 従って変換によって情報が欠落してしまったり, 歪んでしまったりすることがよく起こる. すると変換を重ねれば重ねるほど「変」に換わっていくのである. しかも自然言語から自然言語への変換では, どれくらい「変」になってしまったかを確認する術がないから「変」になったことに気付きにくい. いつの間にか「変」になってしまって, どこまで戻ればいいかも分からないだろう.
だからこの変換過程はできるだけ短く, できるだけ「変」に気付きやすく, 後戻りしやすくしろ, というのがソフトウェア開発を知識変換過程としてみたときに得られる鉄則だ.
変換過程のチェーンがずいぶん短くなって, その代わりに幅が広くなったでしょ. これは多くのアジャイル開発プロセスにも共通する性質でもある. ただこの最後の「コード」というのがとても低水準のプログラミング言語だったりするとこの短い変換チェーンではやっぱりうまくいかないので, 高水準のプログラミング言語やモデリング言語を使いたいところだ. その先の変換はコンパイラやマクロ・プロセッサ, インタプリタ, シミュレータなどに任せてしまえばいい. そういう意味では「コード」よりも「動く知識」といった方がいいかも知れない. アーキテクトの仕事は要求をドメイン知識やアプリケーション知識を利用して動く知識に変換することであった.
- ドメイン知識をモデルなどの形でちゃんと表しなさい
- 常識を磨き, 分かち合いなさい
- アプリケーション知識をルールなどの形でちゃんと表しなさい
- 読みの技術を磨き, 分かち合いなさい
結局そういうことなんだね.
2004.06.20
山田正樹 (メタボリックス)
