本 ヘ゜ーシ゛ を、いま、読み返してみたら、「『ｅ-ヒ゛シ゛ネス と国際会計基準』 を経営の観点からまとめる」 と言っていながら、それらを無視して、「Advanced Learner's」 は、会計学・経営学・マーケッティンク゛・生産管理 （MRP） の基礎知識を語ってきましたね （苦笑）。それらの基礎知識は、「経営の コンテクスト （文脈）」 を理解するためには役立つので、当初の目的から離れてしまったけれど、ご了承のほどを。

　さて、本 ヘ゜ーシ゛ を綴り始めた時点 （2002年 1月） から、「補遺」 を綴る今 （2006年 5月） までの約 3年半のあいだ、コンヒ゜ュータ 業界では--正確に言えば、経営過程を対象にした システム 作りの分析工程では （以下、Ma と略称）--、「奇怪な」 現象として、「モテ゛ル （modeling）」 がもてはやされていました。「奇怪な」 という語を、私は、「近頃以て奇怪至極ぢや」 （芥川竜之介、「邪宗門」） という用法と同じ使いかたをしています。すなわち、「けしからぬさま、不思議なさま」 を指示しています。

　「『モテ゛ル （modeling）』 を重視することは、科学的手法を導入することであって、仕事の品質を高めるし、かつ、『モテ゛ル （modeling）』 を使った作図は、ものごとを 『可視化 （give visibility）』 して、多数の人たちが同じ 『意味』 を共有できる」 などという大雑把な言いかたがされていますが、私は、そういう大雑把な見かたを認めるつもりなぞない。こういう大雑把な見かたを認めない理由として、以下のように反証しましょう。

　（1） 「モテ゛ル （modeling）」 は、「語彙と文法」 を具 （そな） えていなければならない。
　（2） 事業過程に関与している人たちが 「共有」 している 「意味」 構造を記述しなければならない。

　（1） は、Ma 向けとして世間で提示されている ほとんどの 「モテ゛ル （modeling）」 が 「文法」 を具えていないことに対する反証であり、（2） は、Ma 向けの 「モテ゛ル （modeling）」 が対象を間違えていることに対する反証です。

　「ユーサ゛ 要件を定義する」 なら、いかような図法でも良いが、それらの要件と対比される 「事実」 が 「正確に」 記述されていなければ、要件の有効性を判断できない。「モテ゛ル （modeling）」 の対象となる 「事実のあつまり」 を domain （あるいは、universe） と云いますが、Ma では、domain は管理過程であって事業過程そのものではない。そもそも、ひとり （あるいは、数人の） システム・エンシ゛ニア が （事業を計画・管理している management 構造を無視して、） 事業過程のなかで起こっている すべての事態を観ながら、事業過程を domain として、「構造」 を記述できる訳がない。というのは、「構造」 は 「個体と関係」 の記述であるが、実際に営まれている事業を観て、どのような事態を 「個体」 として認知するのかを判断できる訳がない。いま営まれている事業のやりかたを改良するために提示された 「要件」 は、その事業を制度化している--計画・管理している--管理のやりかたと対比しなければならないのであって、「事実を正確に記述する」 というのは 「管理過程を正確に記述する」 ということと同値です。
　すなわち、管理過程のなかで使われている語彙 （事業に関与している人たちのあいだで伝達される 「情報」 のなかに記述されている語彙） を対象にして、「事業過程に関与している人たちのあいだで、『意味』 が どのように共有されているかを示す 『構造』」 を記述するのが Ma 向けの 「モテ゛ル （modeling）」 です。たとえば、以下の事態を考えてみて下さい。

　　　　要件：　顧客は、いままで、地域ごとに管理していたが、今後、商品ごとに管理したい。

　この要件に対比する 「事実」 として、以下の諸点を調べることになるでしょう。
　　（1） 顧客に関して、どのような管理をしていたのか。
　　（2） 地域に関して、どのような管理をしていたのか。
　　（3） 商品に関して、どのような管理をしていたのか。
　　（4） 受注に関して、どのような管理をしていたのか。

　そして、上述した 「文」 は、以下の 「文」 と同値でしょう。
　　（1） 顧客に関して、どのような テ゛ータ を記録していたのか。
　　（2） 地域に関して、どのような テ゛ータ を記録していたのか。
　　（3） 商品に関して、どのような テ゛ータ を記録していたのか。
　　（4） 受注に関して、どのような テ゛ータ を記録していたのか。

　たとえば、「いままで、地域ごとに管理してきた」 と言っても、ひょっとしたら、地域は、顧客住所のことを意味しているかもしれないし、営業所の所在地を意味しているかもしれないし、あるいは、地域は、JIS の体系とはべつの体系として戦略的に分割して、それぞれの地域に対して管理番号を付与して、地域と営業所と対応して、しかも、それぞれの営業所のあいだには、「営業 （受注を担当する営業所）」 と 「管轄 （受注営業所を統轄する営業所）」 という組織体制が導入されているかもしれない。「いままで、地域ごとに管理してきた」　という 「意味」 は、管理情報を調べなければ、「正確な意味」 を理解できないでしょう。

　したがって、「事実を正確に記述する」 ということは、管理情報に対して、「構造」 を与えるということと同義です。さらに、管理情報に対して 「構造」 を与えて、「事実」 を正確に記述したら、「事実」 に照らしてみて、要件が有効なのかどうかを再検討しなければならないでしょう。たとえば、ほどんどの地域で、年々、売上高が減少してきているという理由から要件が提示されたのであれば、地域の管理 テ゛ータ が足らないために、そうなったのかもしれないという点を調べたほうが良いでしょう--もし、ほとんどの地域で、ほとんどの商品の売上高が減少していれば、商品ごとの管理体制に変更しても、目立った ききめ はないでしょうし、そもそも、地域を管理する体制そのもの あるいは商品そのものに問題点があったのかもしれないから。

　「ユーサ゛ 要件を定義する」 という言いかたには、以下の 3つの 「意味」 があります。
　　（1） 要件を作成する。
　　（2） 要件の妥当性・有効性を検証する。
　　（3） 要件を具体的な手続きとして導入する。

　はたして、（1） は、システム・エンシ゛ニア の仕事なのかしら [ 否、それは、エント゛ユーサ゛ の仕事です ]。システム・エンシ゛ニア の仕事は、（2） および （3） です--ただし、ユーサ゛ が提示した要件に対して、システム・エンシ゛ニア が代替案を提示することを排除しない。さて、システム・エンシ゛ニア は、（2） として、どのような検証手続きをもっているのかしら。要件の妥当性・有効性を検証するためには、「事実」 のなかで、問題点が 「具体的に・確実に」 示されていなければならない。こういう手続きは、「issue/problem-solution」 型の手続きです。

　さらに、事業過程を マーケット の変化に適応するように、管理過程を変更することもあります。そういう事態では、要件は、「戦略 （環境適応のための調整力）」 として提示されます。こういう要件は、「strategic planning」 型の要件です。
　はたして、「strategic planning」 型の要件を定義することは、システム・エンシ゛ニア の仕事なのかしら [ 否、それは、top-management の仕事です ]。要件を実現するためには、いまの 「構造」 を、どのように変更しなければならないのかを調べて、変更の影響度を計量しなければならない。

　したがって、「issue/problem-solution」 型であれ、「strategic planning」 型であれ、「事実」 を正確に把握していなければならないでしょうね。「事実」 とは、さきほど言いましたように、管理過程の 「構造」 を記述することです。したがって、ひとり （あるいは、数人の） システム・エンシ゛ニア の理解力 （認知力） に頼って記述する対象ではない。言い換えれば、「管理過程の 『構造』 を記述する文法」 を与えるのが 「モテ゛ル （modeling）」 の目的です。しかし、いま、世間でもてはやされている 「モテ゛ル （modeling）」 は、文法と図法を混同しています。文法とは、「構造」 を生成する規則であって、語彙を使って文を組み立てる規則です。どのような語彙に対して、どのような文型を与えるかという規則です。その文法は、以下の 4点に関する文法です。
　　（1） 個体の認知
　　（2） 個体の性質
　　（3） 関係の認知
　　（4） 関係の性質

　この 4点に関する文法が 「構造」 を作ります。逆に言えば、管理過程を記述できる文法が 「モテ゛ル （modeling）」 ということです。そして、管理過程のなかで伝達されている 「意味」 を記述できるほど豊富な--「豊富」 という意味は、数が多いということではなくて、「できるかぎり数少ない文法で、管理過程の 『構造』 を記述できる」 という意味ですが--文法を提示することこそ、「モテ゛ル （modeling）」 の主題です。