システム・エンジニア は、業務を完全に解析することが できるのだろうか。

　すなわち、数十人の エンドユーザ の仕事を、わずか、数ヶ月のあいだに、観察し面談しながら 「理解」 して、仕事の手順 （手続き） を詳細に記述して、それを 1つの体系として まとめることができるのだろうか。ザッ とした （おおまかな） 解析は、解析に値しない。
　もし、「解析できる」 と言うなら、SE は自惚れているのでしょうね。

　事業のなかで使われている データ の意味を一般化 （共有） するためには、それに先立つ膨大な使用例 （事実） が前提となります。しかじかの データ が、かくかくの仕事のなかで使われ、事業のなかで、しかじかの意味を付与されて伝達されている事態を観察して、以下の 2点を、ほんとうに実現できるのだろうか。

　　（1） 網羅性 （記述されている事態には漏れがない、ということ）
　　（2） 完全性 （記述されている体系が「正しい」ことを検証できる、ということ）

　たとえば、10人の SE が、それぞれ、DFD を使って、1つの （同じ） 事業を記述したとしましょう。おそらく、10通りの DFD が作成されるでしょうが、そのなかのどれが正しい記述なのでしょうか。そういう杜撰な作業を エンジニアリング だと思っている SE に対して、網羅性と完全性に関して、どのように責任をもつのか、という点を訊いてみればいい。
　SE が事業を理解しようがしまいが、事業は、実際に おこなわれているし、SE が理解できた点のみ記述されても、「事業に役立つ」 ことを目的としている システム は事業と懸け離れてしまう。

　SE が習得できる 「業務知識」 というのは、せいぜい、「通論 （あるいは、原論）」 の知識にすぎないでしょうね。その知識を前提にして、「事実」 を記述しなければならない--なお、そういう知識がない、というのは論外です。
　ところが、この 「事実の記述」 がむずかしい。「事実」 とは、どういうことをいうのか、、、。「実際に、この目で見た」 と言っても、その目 （見かた） が怪しい。

　「構造」 というのは、「モノ」 と 「関係」 から構成されますが、もし、事業のなかで起こっている事態 [ 事業のなかで おこなわれている仕事 ] そのものを対象にしたら、「モノ」 として、どういう集合を形成すればよいのか、という初めの時点で、躓いてしまうでしょう。だから、「私には、或る モノ が見えるが、あなたには、それが見えない」 という不意打ちが起こってしまい、それぞれの SE が、それぞれの感想文を綴ることになってしまう。前述しましたが、SE が事業を理解しようがしまいが、事業は、実際に おこなわれているし、事業は 1人の SE の価値観では揺らがない。

　逆に考えてみれば、膨大な事例を一般化して 1つの体系として まとめた プロダクト が アプリケーション・パッケージ です。したがって、1人の SE の乏しい 「業務知識」 を前提にするという 危うさ を回避できます。いくつかの アプリケーション・パッケージ は、実際に使ってみて、品質が良いという高い評価を得ているようです。
　ただ、「最大公約数的な」 汎用性を前提にしているので、それぞれの事業のなかで、パッケージ のなかに搭載されている諸機能を、すべて、使うことはむずかしいでしょうね。とすれば、パッケージ が扱うことのできなかった領域に対して、システム を 「拡張 （add-on） 」 しなければならないのですが、そのためには、やはり、事業の 「事実」 を知っていなければならないでしょう。

　いずれにしても、「モノ」 と 「関係」 を記述するには、事業のなかで起こっている事態そのものを対象にすれば、収拾がつかない。
　ちなみに、数社の企業を対象にして、事業を記述してきた、という 「経験」 を ウリ にするような SE は、「いかがわしい」 でしょうね。なぜなら、「経験」 というのは個人に帰属する性質であって、（本来、技術を ウリ にするはずの） エンジニア が、「経験」 しか自慢できない、というのでは悲しい。

　「事実」 の記述として、どのような対象を選べば、網羅性と完全性を保証できるのか、という点を考え直してみなければならないでしょうね。

　（2003年10月8日）