「要求」から「コード」に至る長く険しい道

http://www.atmarkit.co.jp/farc/rensai/knowledge06/knowledge06.html

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

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

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