1980年代半ば、CASE （Computer-Aided Software Engineering） ツールが流行になった。CASE ツールは、構造化手法を自動化して、SDLC （System Development Life Cycle） の工程自動化を目指した。歴史的な結末は、CASE ツールが、当時の技術では、実現できなかったことを示した（そして、今も、CASE ツールが目的とした点は実現されていない）。

　CASE ツールのなかで、上流工程の作業を自動化するツールもあった。すなわち、業務分析の作図 （モデル作法） を、コンピュータ （パソコン） を使っておこなうツールである。上流工程の作業では、業務分析のほかに、トップダウン手法として、企業モデル （Enterprise Business Model） の作成が提唱された。

　企業モデルは、CSF （Critical Success Factor） を考慮して、事業 （funciton） の構造を階層図として描く手法である。階層図は、6階層として描くことが通論であった-- 6階層は、以下の階層とされた。

　（1） funciton area
　（2） function
　（3） process
　（4） activity
　（5） procedure
　（6） task

　6階層を、すべて、トップダウンに （上位から下位に向かって） 作成する やりかた もあるが--詳細な課業 （task） に至るまで、すべての構造を、トップダウン的に作成することなど、無理なことであって、空論に過ぎない--、小生が関心を抱いたやりかたは、上位 4階層をトップダウン的に （設計図として） 作成して、下位 2階層をボトムアップ的に （現状記述として） 作成して、4階層目 （CSF を加味した今後の設計図） と 5階層目 （事業の現状） を対比する やりかた であった。

　トップダウン的な上位 4階層が、どうして、4階層なのか、という点を考えてみてほしい。最上階は、アプリケーション単位 （たとえば、購買とか生産とか販売とか財務とか労務など） が記述されるので、上位 4階層は、実質的には、3階層である--部品表の最上位が「製品」を示して、レベル 0 とされ、2階層目がレベル 1 になることと同じである。

　さて、3階層は、概念を整理するために、都合の良い階層である--すなわち、大分類・中分類・小分類に対応する。いっぽう、下位 2階層は、事実を記述するためには、都合の良い階層である--すなわち、事物と （事物の） 集合に対応する。

　以上のように検討してみれば、（新しい CSF を対象にして記述された階層を除けば、） 最下位 （事実の記述） 以外は、集合 （あるいは、概念） を整理する階層である。したがって、「（最下位の） 事実が正確に記述されていれば」、概念の整理が混乱していても、事業の構成を理解しにくいということであって、事業の中身を間違うことはない。しかし、最下位が的確に記述されていなければ、上位階層が、どれほど端正に整理されていても、事業の中身を正しく理解することはできない、という点を肝に銘じてほしい。

　形式的体系の記述は、「構造」の記述が論点になるので、システム・エンジニアは、往々にして、整理を目的としている階層ばかりを注目するが、現実を的確に記述できなければ、事業環境の変化に対して、現状のなかに潜んでいる問題点を感知することもできないし、 CSF を達成するための資源が入手できるのかどうかも判断できない。

　では、「現実を的確に記述する」ということは、どういうことなのか、を考えてほしい。「業務を記述した図が、ほんとうに、業務を『網羅的に （漏れがないように）』記述しているかどうか」という点を検証する やりかた を考えてほしい。

　
　（2004年5月16日）