エンシ゛ニア であるのならば、みずからの技術を非の打ち所のない状態で駆使することが使命であって、その技術を どのように理解・習得・適用するかという点は、ユーサ゛ の責任であって、エンシ゛ニア は、あくまで、現状の問題点 （issue） に対して、みずからの技術を最大限に駆使して ソリューション を示すのが職責であると考えることもできます。すなわち、エンシ゛ニア が仕事の対象にしているのは、事実的対象 （現状の問題点） と技術であって、依頼主の力量ではないと考えることもできます。

　同じ技術であっても、上手に使いこなす ユーサ゛ もいれば、使いこなせない ユーサ゛ もいます。技術の理解度は、ユーサ゛ の責任であって、そして、技術の適用法は、コンサルタント が指導すべきであって、エンシ゛ニア の職責ではないと考えることもできます。

　たとえば、TM （Ｔ字形 ER手法） を使って、或る管理過程の構造を作図したとしましょう。TM の文法そのものは、単純なので、だれでも、作図できます。論点になるのは、作図された 「現状」 を観て、以下の点を感知できるかどうかという点です。

　　（1） 現状のなかに潜んでいる問題点 （issue）
　　（2） 問題点に対する改善案 （solution）

　
　問題点 （issue） は、以下の 3点を 「参照項」 として感知できます。

　　（1） 「構造 （管理過程）」 のなかで起こっている矛盾点
　　　　　 （structural inconsistencies）
　　（2） 依頼者から提示された達成すべき目標
　　　　　 （mission statement）
　　（3） ほかの事態 （環境変化など） と対比した乖離点
　　　　　 （maladjustment）

　
　フ゜ロフェッショナル な テ゛ータヘ゛ース 設計者であれば、TMD （TM Diagram） を観て、管理過程の構造上の欠点 （structural defect） を見て取ることや、依頼者から提示された目標を実現するために、構造を いかに変更すれば良いかを考えることは、そうそう、難しいことじゃない。したがって、それらに対応するために、構造を技術的に修正することは、いちいち、依頼者に説明して説得しなければならない点ではないでしょうね。
　ただ、そのときに論点になるのは、ユーサ゛ のほうが、はたして、「問題意識 (an awareness of the issues）」 を抱いているかどうかという点です。

　ユーサ゛ にしてみれば、現場にいる 「当事者」 が、事の次第を一番に知っているという自負を抱いているかもしれないのですが、「（管理過程の） 構造上の欠点」 を見て取ることは、なにも、現場にいることが必要条件になる訳じゃない。だから、（TMD を丁寧に観て、「（管理過程の） 構造上の欠点」 を調べる） DA （Data Administrator） という職種が、独立して成立します。また、ユーサ゛ から示された目標が、管理の構造と対比して、実現できるかどうか、あるいは、実現するために、構造の どこを修正すれば良いかという点も、管理の構造を知っていれば良いことなので--構造が示されていれば良いので--現場にいることは必要条件にはならないでしょうね。
　そして、これらの点が、エンシ゛ニア と ユーサ゛ のあいだで、意識の ス゛レ として論点になるようです。

　「構造上の矛盾点」 を改善することや、目標を実現するために 「構造」 を改良することは、いちいち、ユーサ゛ を説得しなくても、エンシ゛ニア が実現できる点です。とすれば、エンシ゛ニア が、（ユーサ゛ の理解度を度外視して、） みずからの技術を駆使して、管理の 「構造」 を改善することができます。
　もし、そういう やりかた に対して、ユーサ゛ が反感を抱いたとすれば、フ゜ロシ゛ェクト の進めかた （フ゜ロシ゛ェクト に関与している人たちが 「同意」 しながら、フ゜ロシ゛ェクト を進めるという やりかた） の論点であって、エンシ゛ニア の力量が問題視される訳じゃない。どれほど すばらしい技術であっても、ユーサ゛ が反感を抱いたら、使ってもらえないと判断して、ユーサ゛ の反応を観ながら、ユーサ゛ が納得する同意点を妥協するか、それとも、ユーサ゛ が、そういう技術--システム を改善するために導入された技術--を使わないというのは、組織管理の論点であって、ユーサ゛ が技術を使わない （あるいは、使えない） ことを 「仕事の遂行能力」 として人事考課の対象するかどうかという点は、それぞれの 「組織」 の管理形態を考慮しなければならないので、一概に言えない。

　テ゛ータヘ゛ース・エンシ゛ニア であり、かつ システム・コンサルタント でもある私が、「ユーサ゛ の反応を観て技術の導入を考慮する」 ことを、前回、「良い意味でも、悪い意味でも」 と綴った点は、以上に述べた理由を前提にしています。

　
　（2006年 1月 1日）