工場の作業とシステムの構築を対比してみれば、データベースが部品の貯蔵庫であり、プログラムが製造ラインになるでしょう。（ＩＴミックスのなかで、ハードウェア構成・システムソフトウェア構成・ネットワーク構成が与件になっていて、データ構成とアプリケーション構成を対象にして、） 「物を作る」という行為だけを考えれば、データとプログラムがあれば良いのであって、ディスパッチ法 （作業指図）は、さほど、論点にはならないでしょう。

　いっぽうで、マーケットのニーズを把握するということを、ユーザのニーズを把握するということに対比できるかもしれない。さて、この点が、やっかいな論点になっているようです。すなわち、ユーザのニーズを把握するためには、どのような やりかた が良いのか、という点が論点になっているようです。
　データベース設計の観点から言えば、ユーザの欲しい「情報」が記述されていれば良い、というだけのことです。おそらく、プログラム作成の観点から言っても、データの意味がわかって、（単純なデータ照会を除けば、） データの加工仕様がわかれば良いだけでしょう。

　とすれば、僕が理解できない点は、概念設計と称して、事業を対象にして「絵 （diagram）」を作成する作業が、いったい、どういう意味を持っているのか、という点です。概念設計という作業が、システム構築を請け負った外部のソフトウェアハウスが、依頼主の事業を理解することを目的としているのでしょうか。

　もし、そうだとすれば、データベースを設計するシステム・エンジニアおよびプログラムを作成するプログラマが、会計・生産管理・経営・マーケティングなどの「通論」を習得していれば、依頼主が提示した「情報」を観て、「情報」の目的を確認して、「情報」のなかで理解できない点を質問すれば済むことではないでしょうか。
　情報全体の体系図が提示され、それぞれの情報に関して、使用目的 （だれが、なんのために、いつ） と報告形式 （帳票、画面、レポートなど） が提示されたら、済むことではないでしょうか。

　船と荷物と倉庫という３つのアイコンを作図して、船のなかに積まれている荷物 （複数の商品が１つの束になった荷造り） には、積荷伝票が添付されて、入港後に、検査された荷物には検査伝票が添付されて、荷物を倉庫に保管する前に、入庫伝票が起票される、という絵を作成して、いったい、どういう意味があるのでしょうか。
　積荷伝票のなかで、数量という記述があれば--あるいは、積載されている商品を、複数個、記述する欄があれば--、１つの荷物には、複数の商品を荷造りすることがわかるのではないでしょうか。したがって、エンドユーザに対する質問点となるのは、荷造りには、最大個数という限度数があるのか、あるいは、１つの荷造りでは、つねに、一定数を積載するのか、という点でしょうね。また、検査票のなかで、個数があれば、「積荷伝票の個数＝検査票の個数」「積荷伝票の個数＞検査票の個数」および「積荷伝票の個数＜検査票の個数」の３つの場合が起こることを確認すれば良いでしょうね。まさか、「積荷伝票の個数＜検査票の個数」--検査済みの数量のほうが、積載数量に比べて多いこと--を、データベースを設計するエンジニアが、概念設計を担当したエンジニアに対して質問したときに、それは調べていなかった、とは言わないでしょうね。実際に使われている「情報」を観れば、もっと、詳細なことを把握できるのですが、概念設計の段階では、そういう情報を集めておきながら、「情報」の中味を無視して絵を作成するという点を、僕は理解できない。
　そういう細かな情報解析は、詳細設計でやるそうです（苦笑）。概念設計では、業務全体の流れ--あるいは、構造--を把握するそうです （苦笑）。

　船から荷物を降ろす作業が非効率であるとか、検査する手順が非効率であるというような現状の問題点を調べるために、絵を描いているのだとすれば、作図された絵は粗すぎる（苦笑）。業務手順の非効率性を改善するのなら、テイラー （Taylor, F.W.） がやったように、ストップウォッチを使った計測をやるべきでしょう。
　もし、仕事の効果性を調べるのであれば、その仕事のなかで使われている「情報」の使用目的と、その「情報」が、ほかの「情報」に対して及ぼしている影響度 （関連性） を調べれば検証できるでしょう。

　あるいは、「情報」を使用しない業務があること--たとえば、船から荷物を降ろして、検査場まで運搬するなど--を知るためなら、「情報」を、だれが使うか、という確認をすれば、荷物を降ろす人たちと荷物を運搬する人たちが同じなのか、あるいは、それらの人たちが違うのかを認識することができるし、もし、それらの人たちが違うのであれば、運搬手段を情報化しなくても良いのかどうか、という点を質問すれば良いでしょう。
　業務を対象にして流れ図やユース・ケースを使う意味を、僕は理解できない。
　システム・エンジニアが露呈している根本的な問題点は、「情報を読む」ことができない、という点ではないのでしょうか。業務の「可視化」とは言うけれど、人間のアイコンや伝票のアイコンを使って、流れ図を描くことが、システムを構築するための論理力にとって、どのように、役立っているのでしょうか。

　ただし、流れ図やユース・ケースを使う事態を、１つだけですが、僕は認めます。
　その事態というのは、「いままで先例のない」業務を新たに立案する、という新規の業務設計です。このときには、おそらく、まず、やりたいことを、おおまかな流れ図として描くことになるでしょう。つまり、流れ図やユース・ケースは、対象となる業務がないときにこそ、役立つ手段です。そして、おおまかな図を、次第に、詳細にしていくでしょう。そして、「やるべき仕事」を詳細に記述しながら、それぞれの仕事が使う「情報」を設計するでしょう。
　新規の業務構成を立案するなら、流れ図やユース・ケースは役立つ、と思います。しかし、既存の事業の現状を記述したり、改善したりするために、絵を描くことは時間の浪費でしょう。

　業務を対象にして、業務の構造を図式化する作業 （あるいは、意味論） は、システム・エンジニアを惑わせるローレライの歌でしょうね。
　というのは、対象領域となっている業務には、境界線がないので、意味論が提示できることは、せいぜい、「ａＲｂ」という１語しかない。つまり、出来事は、モノと関係を使って記述でき、ａ は ｂ に対して関係Ｒにある、ということしか言えない。とすれば、ａ とか ｂ を、どのようにして認知するのか、そして、Ｒ を、どのようにして認識するのか、という認知の判断規準を示さないかぎり、「記述のしかた （絵の描き方）」しか提示できないでしょうね。つまり、意味論は、記述作法を提示するしかない。
　もし、意味論が単なる作図作法 （お絵描き） で終わりたくないなら、「モノを認知するための判断規準」と「関係を認識するための判断規準」を提示すべきです。もし、それができないなら、作図が整合的であることを証明する手順 （アルゴリズム） を示すべきです。モノを認知する判断規準あるいはモノを認識するアルゴリズムを提示しない意味論など、単なるアイコンの作図作法であって、描かれた絵は、設計図を作成する （データベースを設計しプログラムを作成する） ための準備材料として値しない。

　
　（2004年3月14日）