すなわち、

　（1） 事業過程・管理過程で使われている 「情報」 を in-put とする。
　（2） 「情報」 に記述されている語彙に対して 「形式的構造」 を与える。
　（3） 「形式的構造」 と現実的事態を対比する。

　（2） を 「tentative modeling」 と云っています──すなわち、「文法」 に従って、語彙を前提にして文を構成する、ということ。構文論重視の作業と云っていいでしょう。そして、（3） を 「semantic proofreading」 と云っています──すなわち、構成された文が現実的事態と対比して、「真」 かどうかを験証する、ということ。意味論重視の作業と云っていいでしょう。

　以上の作業は、以下の 2点を前提にして、「事業を 『正確に』 記述する」 ことを目的としています。

　（1） ユーザ 言語を変形しない。
　（2） できるだけ機械的に構成する。

　さて、「事実を 『正確に』 記述」 したならば、以下の 3点を考慮して 「構造」 を修正します。

　（1） 再設計の目的
　（2） 現 やりかた の強み・弱み
　（3） 現 やりかた の環境適応力

　以上の 3点のなかで、「再設計の目的」 は、ユーザ が すでに提示しています。ただ、ここで われわれ システム・エンジニア が注意しなければならない点は、ユーザ が抱いている実現目的が、現 やりかた と対比して、実現できる範囲にあるかどうか ということを見極めなければならない。実現目的は、ユーザ が望んでいる改善なので、現 やりかた と隔たっているのがふつうですが、その隔たり [ 距離 ] を システム・エンジニア は或る程度 計量しなければならない。たとえば、「コスト を30％削減する」 という目的が示されたときに、TMD のなかで、コスト に係わる データ が どの 「箱」 （entity、対照表、対応表、再帰表など） のなかに記述されていて、どういう 「関係」 のなかで どのように並ぶのか を観て、それらの構成のなかで目的を実現できるのか、それとも、構成の変更──既存の データ を使った新たな構成──を考えなければならないのか、さらに、いままでにない新たな構成を導入しなければならないのか、を考えなければならない。

　と同時に、形式的構造のなかで、ユーザ の気づいていない 「潜在的な問題点」 が存在していないかを システム・エンジニア は感知しなければならない。システム・エンジニア が、もし、そういう 「潜在的な問題点」 を感知したならば、それを ユーザ に伝えて、対応を協議しなければならない。

　上述した問題点を把握するには、現 システム の 「事実を 『正確に』 観る」 しかない。問題点に対して ソリューション が考えられたならば、その ソリューション を 「構造的」 な プログラム として構成することを私は悪いと謂わないけれど、irrelevant だと思っています。私は、寧ろ、「抽象 データ 型 （abstract data type）」 のほうが legitimate だと思っています。というのは、「抽象 データ 型」 のほうが 「事業 （現実的事態）」 と その 「形式的構成」 の対応が わかりやすいので。まず、「事実を 『正確に』 記述」 した形式的構成を基礎資料にして、以下の補助資料を使えばいいでしょう。

　（1） 再設計の目的を具体的な実現数値で 3つほど列挙する。
　（2） 現 システム の長所 を 3つ、短所を 2つ 列挙する。

　再設計の目的は、「戦略的 （stratigic）」 な考慮点──すなわち、環境の変化に対する適応点──を扱い、現 システム の長所・短所は、「問題解決型 （issue-solution）」 の改良点を扱っています。これらの 2点を実現するために TMD を修正 [ 推敲 ] します。ここで くれぐれも注意しなければならない点は、形式的構成を変更したならば、かならず、変更点に対して 「アトリビュート・リスト」 を作成して 「『制約・束縛』 を網羅的に検証する」 という点です。DA （Data Anayst） は、往々にして、TMD （「妥当な構造」） を作ることばかりに興味を示しますが、モデル が モデル として使われるためには、「真とされる値」 が充足されるための 「制約・束縛」 を ひとつとして見逃してはいけないことに もっと注意を払っていただきたい。