概念設計の仕事をしているシステム・エンジニアが陥りやすい罠は、現実世界を写像して構造化したモデルが人為的な構成物にすぎないのに人為的でない、という錯覚を抱く点である。実地の事業は混沌とした１つの事態であるが、我々は、それを１つの構成物として、全体と個々の関係を構造化して、（１つの構成物のなかで） いくつかの・それぞれ独立した funciton として扱う。すなわち、「生の」事業を「閉じた」体系として記述する。

　仮言命題 （ｐ ⇒ ｑ） がトートロジー （恒真命題） になる「必然的な因果関係」なら、現象を探究して「構造」を作れば、「構造」は、いったん、作られたら、反復して使うことができる。
　しかし、事業を対象にしたモデルでは、「必然的な因果関係」が成立するのではなくて、「選択的 （偶然的） な関連」が記述される。たとえば、受注の集合と請求の集合では、かならずしも、「出荷 ⇒ 請求」という内包従属性が成立するとは限らない。「請求 ⇒ 出荷」も起こりうる。つまり、請求と出荷との関係には、「必然的な因果関係」はない。

　しかも、企業は、「継続企業 （going concern）」を前提にしているので、事業環境が変化すれば、事業環境の変化に対応するように、適応しなければならない。環境変化、あるいは、いわゆる「基幹系システム」の変化は、緩慢であって、日々の変更に晒されていない、というのは大きな錯覚である。変化が緩慢な function は、伝票入力 （データ入力） であって、システムから生成される情報 （アウトプット） は、６ヶ月 （あるいは、３ヶ月） 単位で変化する、と思ったほうがいい。なぜなら、半期 （あるいは、四半期） ごとに、事業の成績を判断して、次の対応を考えるのだから、新たな対応を支援するための fuction や 新たな対応を追跡する情報が出力されなけれならない。

　たとえば、セールス体制として、地域担当制を、かって、導入していたが、企業担当制に変更するとか、あるいは、企業担当制を導入していて、１つの企業に対して１人の営業員が担当していたが、複数の営業員が担当するように変更するとか、、、こういう細やかな、しかし、事業のなりゆきに対して大きな影響を及ぼす変更というのは、企業組織全体のなかで、多く起こっている。いわゆる「基幹系システム」が、こういう繊細な変化に対応できないのであれば、当然ながら、実地の事業のなかで、インフォーマル・システムが作られる。

　funciton を構造化したモデルでは、こういう変化には対応しにくい。構造化されたモデルは、いったん、作ればよい、という代物ではない。現実の事業が、ひとたび作られた人為的な体系と同じになることはあり得ないことであって、概念設計を仕事にしているシステム・エンジニアがやらなければならないことは、事業を抽象化して構造化 （固定化） するのではなくて、事業を繰り返し解析し直す方法 （事実を記述する方法） を提示することである。

　
　（2004年2月18日）