「要求」から「コード」に至る長く険しい道：実行可能な知識とソフトウェア（6）

……そういう意味では「コード」よりも「動く知識」といった方がいいかもしれない。アーキテクトの仕事は、要求をドメイン知識やアプリケーション知識を利用して動く知識に変換することであった（本文より）

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

　「ソフトウェアを作る」というのは、顧客や市場のニーズを「動く」プログラムに変換すること、である。アーキテクトだのプログラマだのは、つまりそのための「変換装置」というわけだ。一部分の変換過程はコンパイラやマクロ・プロセッサ、モデル駆動開発などの技術によって自動化されているけれど、多くの変換過程はまだまだ人間の仕事だ。例えば古典的なウォーターフォール・プロセスを変換過程として考えるとこんな感じになる。

　まず顧客やユーザーの頭の中にある要求を仕様というものに落とし込む。その変換過程が「分析」と呼ばれる仕事だ。 分析はあいまいで （一般的には）非定型的で矛盾を含んだ要求を、明確で定型的で矛盾のない仕様に変換する。

　次に「何がしたいか」を記述した仕様から、それを「どうしたら実現できるか」という見取り図へと変換する。この見取り図がアーキテクチャであると大ざっぱにいい切ってしまおう。この変換過程では「どうやって実現するか」という要求や仕様には含まれていなかった知識が付加されることになる。

　見取り図だけではモノを作ることはできないから、アーキテクチャをさらに変換して詳細な設計に落とし込む。この変換過程ではさらに実装プラットフォーム（プログラミング言語やミドルウェアなど） に関する知識がどんどん付加されていく。これらの「どうやって」という知識の付加過程が「設計」という仕事である（設計の成果物も設計と呼ばれる）。

　ここまでの変換過程は多くの場合、自然言語から自然言語への変換だ。最近は途中からUMLのようなモデリング言語に変換されることも増えてきたけれど、たいていは補助的に使われるにすぎないので、自然言語による記述がまったく不要になることはあまりない。 ま、いずれにしろ最終的にはプログラミング言語に変換しなければならない。その変換過程が「実装」と呼ばれる。

　世の中こんなに単純に物事が運べばいうことはないのだが、実際はそんなに甘くない。まずたいていの場合、もともとの「要求」というのがぐずぐずの代物で、それを基に変換を重ねていったらとんでもないソフトウェアが出来上がってしまう。おまけに要求はどんどん変わっていくから、きまじめにそのたびに変換をやり直していたらいつまでたってもコードに行き着くことができない。

　つまりあるレベル、ある時点で変換作業を停止しなければならないらしい。言葉を換えれば元の要求は無限の情報量を持っているので、それを有限の情報量に変換するためにはどこかで「近似」せざるを得ないのだ。しかもこの近似の仕方に絶妙なポイントがあるようなのだ……（注1）。

［注1］　　「どうせ近似変換なんだし、この後で出てくる誤差の方がずっと大きいんだから、ここでむやみに精度を上げてけた数を増やすのに時間をかけても仕方がない。2〜3桁のほどほどの近似で十分」というのがアジャイル開発プロセスの（大ざっぱな）立場である。

　実は要求を仕様に変換するためには、要求を「解釈」できなければならない。 解釈とは「こいつのいっていることと矛盾しないような自分の辞書（モデルという）を作ること」である。解釈のためには要求そのものだけでは足りなくて、要求の背景となっている知識がある程度共有されていなければならない。

　その1つがいわゆる「ドメイン知識 （顧客やユーザーの分野の専門知識）」であり、もう1つが「常識」なのである。常識を明示的に表すことは多分無理だけど、ドメイン知識を何らかの形で明示的に表すことはある程度はできるだろう。データ辞書やビジネス・モデリングなんてのはその例だし、エンタープライズ・アーキテクチャはドメイン知識と仕様を統一的な構造の下で表現しようという試みといっていいかもしれない。 いずれにしろ、もしドメイン知識をうまく表すことができれば、この変換過程の半分はうまくいったようなものだ。常識の方は……、多分経験値を上げるしかない……。

　さて、ここまでは何だかだいってもしょせんは精度を上げる、あるいはうまく解釈するという変換であった。不可逆過程ではあっても相似変換といっていい。しかしお察しのとおり、次の変換過程には大きなギャップがある。「what」を「how」に変換するのである。いってみれば2次元の物体を3次元の物体に変換するようなものだ。明らかに何かの知識を足し込んでやらなければやりたいことが実際にできるようにはならない。しかもその足し込み方は一通りではなく、何通りものやり方がある。いや、場合によってはどんなやり方があるかさえ分かっていないことだって多いのだ。ここで足し込まなければならない知識は実現方法に関する知識、アプリケーション知識である（注2）。

［注2］　ここでは変換したものを射影すると同型になるという意味で「逆射影変換」といっている。変な用語だけど、適切な用語が思い浮かばない。

　アプリケーション知識は例えばAPIとか、パターンとか、解説書とかの形で断片的にはかなり多量に明示的に存在している。しかし、その組み合わせ方は無数にあって、さまざまな状況や対象によって異なるので、断片的なアプリケーション知識を持っているだけではまったく十分ではない。将棋でいえば定石を知っているだけでなく、常に状況に応じて盤面を読まなければならないわけだ（しかも盤面は無限に広く、ルールも変わるかもしれない！）。

　このアプリケーション知識をどこに持たせるかでいろいろなやり方がある。そんなものは変換過程の中に埋め込んでしまえ（そして自動的に変換すればいい） というのが、形式的仕様とかモデル駆動開発というものだ。「読み」の方は……、多分経験値を上げるしかない……（注3）。

［注3］　簡単にいうと形式的仕様は「how」をすべて変換過程に埋め込んでしまう、モデル駆動開発は「how」を半分人間が書いて半分変換過程に埋め込むという違いだと思っていい。これらの場合は2次元から3次元への膨らませ方がすでに決められているので、あたかも「要求がそのまま動く」錯覚に陥るわけだ。

　この先、古典的なウオータフォール・プロセスでは何段階も変換過程が続いていくことになる。その変換過程ではとても多くの打ち合わせが開かれ、とても多くのドキュメントが作られて配られ、とても多くのレビューが行われる。変換を重ねるほど、対象によく近づいていくはずという信念に基づいて……。

　しかし、この変換過程はそんなによくできた変換過程ではない。従って、変換によって情報が欠落してしまったり、ゆがんでしまったりすることがよく起こる。すると、変換を重ねれば重ねるほど「変」に換わっていくのである。しかも自然言語から自然言語への変換では、どれくらい「変」になってしまったかを確認するすべがないから、「変」になったことに気付きにくい。いつの間にか「変」になってしまって、どこまで戻ればいいかも分からないだろう。

　だからこの変換過程はできるだけ短く、できるだけ「変」に気付きやすく、後戻りしやすくしろ、というのがソフトウェア開発を知識変換過程として見たときに得られる鉄則だ。

　変換過程のチェーンがずいぶん短くなって、その代わりに幅が広くなったでしょ。これは多くのアジャイル開発プロセスにも共通する性質でもある。ただこの最後の「コード」というのがとても低水準のプログラミング言語だったりすると、この短い変換チェーンではやっぱりうまくいかないので、高水準のプログラミング言語やモデリング言語を使いたいところだ。その先の変換はコンパイラやマクロ・プロセッサ、インタプリタ、シミュレータなどに任せてしまえばいい。

　そういう意味では「コード」よりも「動く知識」といった方がいいかもしれない。アーキテクトの仕事は、要求をドメイン知識やアプリケーション知識を利用して動く知識に変換することであった。つまり、

  • ドメイン知識をモデルなどの形でちゃんと表しなさい
  • 常識を磨き、分かち合いなさい
  • アプリケーション知識をルールなどの形でちゃんと表しなさい
  • 読みの技術を磨き、分かち合いなさい

こういうことなんだ。

著者プロフィール

山田正樹

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


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

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ