【4】第二章 “ＤＯＡ”ってなんだろう？
（その数日後）
佐藤さんのもとに、吉田さんの友人である内山さんが訪問してきた。
「はじめまして。内山と申します」
と頭を下げたのは、いかにも頼りなさそうな風貌の男だった。
佐藤さんはちょっと不安にかられたが、先日の社長室でのことを思い出しながら気を取り直して言った。
「いやぁ、お忙しいところお呼び立てして申し訳ありませんでした。では、ご案内いたします」
と、そこに山田さんが、なにやら大きな紙を丸めたものを小脇に抱えてやって来た。
「部長、私も同席させていただきたいのですが、お願いできませんか？」
なんとなく挑戦的な雰囲気の山田さんに気圧されたかの様に、佐藤さんは言った。
「う～ん。そうだな。今後のことを考えると君にも聴いておいてもらった方が良いのだろうな。分かった。一緒に来てくれ」
「お待ちしておりました。どうぞお座りください」
と、社長がにこやかに内山さんに席を勧め、社長、佐藤さん、山田さんも席についた。
「さて、早速ですが」
と口を切り出した佐藤さんのかたわらから、山田さんが口を挟んできた。
「まず、私からご報告させてください。実は、当社はすでに“ＤＯＡ”を使っておりました」
社長と佐藤さんは、あっけにとられた様子で彼を見た。
「実は、販売管理システムの開発をお願いしたＳＥ(エス・イー)（システム・エンジニア）の方に確認したのですが、あのシステムを開発する時には“ＤＯＡ”という手法を使っていたというのです。そして、これがその成果物である“データ構造図”です」
と、小脇に抱えていた大きな紙を、皆の目の前に広げて見せた。
そこには“販売管理システム データ構造図”という表題と、なにやら四角と線がたくさん描かれていた。
この図面を前に、彼はやや挑戦的な視線を内山さんに向けた。
「この様にすでに“ＤＯＡ”が使用されていたにもかかわらず、先日の様なことが発生したのです。このことから分かる通り、“ＤＯＡ”が先日の件に有効であるとは思えません」
佐藤さんはやや興奮気味の山田さんの様子を見ながら、（先日の社長室でのことが相当悔しかったんだな。無理も無いとは思うが、それだからと言って吉田君の友人にあたるのは感心しないな）と内心思った。
内山さんの手前もあるので、とりあえず山田さんの意見を否定しようと口を開きかけた佐藤さんより先に、内山さんがにこやかに話し始めた。
「ええ、おっしゃる通りです。先日の件には“ＤＯＡ”は有効ではありません」
内山さんの発言に社長と佐藤さんは思わず「えっ？」と声を出して、内山さんに向き直った。
が、彼らよりももっと驚いたのは山田さんの方で、彼はやや口をあけたまま呆然としていた。
しかし、さらに驚きうろたえたのは、当の内山さんの方であった。
「あっ！ 何かまずい事を言ってしまいましたか？ 申し訳ありません」
と小声で謝る彼の様子を見た佐藤さんは、山田さんのまいた険悪な雰囲気が無くなったことに苦笑した。
「いや。でも、内山さん。今日、我々はあなたから“ＤＯＡ”の有効性についてお聴きするつもりだったのですが」
この言葉で内山さんはやっと気づいたかの様に「あっ」と小さく叫ぶと、やおら話し始めた。
「いえ。私が今日ご説明するのは、“ＤＯＡ”の有効性でなく“概念ＤＯＡ”の有効性なのです。これらは一見同じものの様に誤解されがちですが、実は全く別物と考えていただいても構わないほどのものなのです。とはいえ“概念ＤＯＡ”は“ＤＯＡ”の発展過程から出てきたものですから、無関係ではありませんが」
佐藤さんは三人の代表として言った。
「なんだかよく分かりませんが、とりあえず“ＤＯＡ”と“概念ＤＯＡ”とはどこがどう違うのですか？」
内山さんもこの様な展開になるとは思っていなかったのかちょっと考え込んでいたが、しばらくすると鞄からレポート用紙を取り出しながら話し始めた。
「では、まず“ＤＯＡ”からお話しましょう」
内山さんは取り出したレポート用紙に“ＤＯＡ”と書き出した。
「“ＤＯＡ”は、“Data Oriented Approach”の略語です。“Data Oriented Approach”という言葉自体は、いわゆる“和製英語”ですが、これを日本語訳すると“データ中心アプローチ”とか“データ中心指向”などとなります。『和製英語を日本語訳する』というのもちょっと変ですが」
「外国では、どう言われているのですか？」
「佐藤さん、良い質問です。そうですね、欧米では“Information Engineering”略して“ＩＥ(アイ・イー)”などと言われています。とはいえ、この用語は日本ではほとんど使用されていないようですが」
「う～ん。日本と欧米で用語が違うと言うのは珍しいな。内山さん、もしかすると『ＤＯＡというのはこれだ』という一つのものは無いのですか？」
内山さんは、少し驚いた様に佐藤さんを見た。
「鋭い質問ですね。その通りです。“ＤＯＡ”の考え方というのは、その研究者──というと語弊がありそうなので“ＤＯＡ論者”とでも言っておきましょうか──このＤＯＡ論者ごとに内容に微妙な差があります。従って、これから私が説明させていただく内容も、私という一個のＤＯＡ論者のものとお考えになってお聴きください」
ここで、社長が口を挟んできた。
「まぁ色々細かなことに問題はあるかもしれないが、ともかく内山さんの話を聴こうじゃないか。内山さん、早くＤＯＡの説明をお願いします」
「分かりました。では、ＤＯＡの最も重要な背景である“データベースという考え方”から説明させていただきます」
内山さんの説明が始まった。
「佐藤さんは“データベース(data base)”という考え方をご存知ですか？」
「もちろん知っていますよ。“コンピューター・システムの中のデータを集中管理するシステム”のことでしょう」
「いいえ、それは“データベース管理システム”というコンピューター・システムのことです。私がお聞きしたかったのは“データベースという考え方”です」
「なるほど。では、こう言った方が良いな。『データベースという考え方は、様々なコンピューター・システムのデータを集中管理することにより、様々な利用者が使用できるようにし、利用を効率化させようとするもの』と。どうですか？」
「お見事です。そして、この“データベースという考え方”が“ＤＯＡという考え方”の元となっています。ちなみに、ＤＯＡ論者の中には、このことを『One fact to all users.』と言っている人もいます」
そう言いながら、内山さんはレポート用紙に「One fact to all users. （一つの事実データは皆で共有する）」と書き加えた。
と、ここで社長が口を開いた。
「ちょっと待ってくれ。“データベースという考え方”と“データベース管理システム”とは、前者の考え方を実現したのが後者なのだから、同じもんじゃないのか。 内山さん、どうなんですか」
「良いご質問です。“データベース管理システム”はＤＢＭＳ(デー・ビー・エム・エス)(data base management system)と略されますが、厳密に言えば“データベースという考え方の実現をサポートするコンピューター・システム”のことで、あくまで“実現のサポート”役でしかないんです」
まだ納得できない顔の社長に対して、佐藤さんがサポートした。
「もしＤＢＭＳを会社に導入しても、“データベースという考え方に合った使い方”をしなければ、この考え方を実現したことにはならないということです」
「う～ん」と唸る社長に、（内山さんがいる前で言いたくは無いが、仕方がないか）と思いつつも佐藤さんが言った。
「社長、実は当社でも、以前の販売管理システムと請求管理システムはどちらもＤＢＭＳを使って作られていましたが、それぞれのシステムの中のデータは別々に登録していました。つまり、集中管理されていなかったので、有効利用できていなかったんです」
と、これは初耳の社長。
「えっ、そうなのか？ じゃ“データベース管理システム”っていう名前はおかしいんじゃないのか？」
「（苦笑しながら）まぁ、“言葉のあや”みたいなものですよ。でも、今回開発した販売管理システムでは請求管理システムのデータ共々集中管理していますので、この部分の有効活用は実現できています」
「あの～。そろそろ先へ進めてよろしいですか？」
と、あいも変わらず頼りなげな内山さんが佐藤さんに聞いてきた。
「すみませんでした。どうぞ進めてください」
「では、先に進めさせていただきます。さて、佐藤さん、“データベースという考え方”で集中的に集められたデータは、どうすれば『効率良く記録し、効率良く利用できる』と考えられますか？」
と、問いかけられた佐藤さんはちょっと考えていたが、いきなり社長が割り込んできた。
「そりゃ、“効率的”であるためには“非効率”なところが無くなればいいのではないですか？」
佐藤さんがこの回答に苦笑しつつ内山さんを見ると、意外にも彼は頷いた。
「社長、良い回答です。つまり『記録の非効率をなくそう』ということです。これは別の言い方をすれば『同じことを繰り返し記録する様な、無駄なことは止めよう』ということもできます。このことをＤＯＡ論者は『One fact in one place.』と言っています」
そう言いながら、内山さんはレポート用紙に「One fact in one place.（１つの事実データは１つの場所で記録する）」と書き加えた。
「この様に、『One fact to all users.』と『One fact in one place.』という二つの大きな考え方から、現在の“データベース”というものは生まれてきました」
「なるほど」
「では、この『One fact in one place.』という考え方を実現するにはどの様にすれば良いのでしょうか？ これへの一つの回答が“正規化(せいきか)”という手法です」
「“正規化”ですか」
（さぁ、また訳の分からない言葉ができてきたぞ）と、口には出さないが顔では雄弁に語っている社長の顔を見て取って、内山さんは慌てて付け加えた。
「とはいえ、今日は皆さんに“正規化”手法の具体的な手順などといった細かな話を理解していただく必要はありません。とりあえず、結果として“効率的な記録”がどの様なものになるかを、例を用いて、ちょっとだけご説明しておきます」
そう言うと、内山さんは山田さんの方を向いた。
「山田さん、すみませんが、お持ちいただいた“データ構造図”を拝見させていただけませんか？」
急に言われ面食らいながらも、山田さんは内山さんに“データ構造図”を手渡した。
内山さんは“データ構造図”を両手で広げながら数十秒眺めていたが、「なるほど」とつぶやくとそれを丸めて再び山田さんに軽く頭を下げながら手渡した。
内山さんは、今度はレポート用紙に次の様に書いた。
「例えば、販売管理システムを考えてみると、社員の台帳情報には社員番号や社員の氏名が記録されなければならないし、受注伝票綴りといった情報には、受注日や受注を担当する社員の社員番号が記録されなければなりません」
内山さんは、さらに次の様に書いた。
「ところが、受注担当社員の氏名は、受注担当社員番号が分かりさえすればその時々で社員台帳の方を参照しに行けば良く、わざわざ受注伝票の方に記録しておく必要はありません。これを記録しておくと、同じ受注担当社員番号の時には同じ社員の氏名を繰り返し記録しなければならず、無駄となってしまいます」
内山さんは、次の様に“社員番号”と“受注担当社員番号”の間に線を描いた。
ここで社長が、誰にとも無く言った。
「でも、いちいち受注伝票を見に行く度に社員台帳を見に行かなくちゃならないなんて、非効率じゃないのかな？」
これには苦笑しながら、佐藤さんが答えた。
「社長、これはコンピューター・システム上の話であって、社員台帳や受注伝票綴りといった紙のファイルを見る訳ではないんですよ。コンピューター・システムでは、こういった参照作業はあっと言う間にできるんです」
「そうか。参照作業があっと言う間にできるんだったら、何も受注担当社員の氏名なんぞ繰り返し記録しておく必要も無いか」
内山さんが話を続けた。
「この様に、“正規化”という手法によって“社員”や“受注”と言ったものに対するデータの記録は必要最小限に抑えられます。そして、この“正規化”を行った結果を“図面”で表現したものが、今回山田さんが持ってきてくださった“データ構造図”なのです」
と言いながら、内山さんは再び山田さんから先ほどの“データ構造図”を受け取ると、皆の前に広げだした。
「ちなみに、ＤＯＡの世界では“社員”や“受注”といったものを“エンティティ(entity)”と言っており、図面の上では四角形で描き表します」
内山さんは“データ構造図”を見ていたが、右手と左手で二つの四角形を指差した。
「ここに“社員”と書かれた四角形があり、あちらに“受注”と書かれた四角形があります。これらがエンティティです」
という内山さんに釣られて、皆は構造図を覗き込んだ。
「そして、先ほどの“社員番号”や“受注担当社員番号”と言ったものをＤＯＡの世界では“データ項目”と言っており、図面の上ではエンティティの四角形の中に書きます。この時“受注”の四角形の中には“受注担当社員番号”というデータ項目は書かれていますが、“受注担当社員名”と言ったデータ項目は書かれていません。正規化を行った結果が表現されているからです」
構造図を覗き込んでいた社長と佐藤さんは「なるほど」と頷いた。
「さらに、この二つのエンティティの間には、先ほどお話した“社員番号と受注担当社員番号との間の参照・被参照関係”がある訳ですが、これは図面の上ではそれぞれの四角形を繋ぐ線で描き表します」
と言いながら、内山さんは“社員”と“受注”の間を繋ぐ線をなぞった。
しばらく構造図を眺めていた社長が顔を上げて、内山さんに言った。
「販売管理システムだけで、結構エンティティというものはたくさんあるものですね。で、この後はどうなるのです？」
内山さんは“データ構造図”をしまいながら言った。
「この図面で表現された内容を手がかりにして、先ほどの“データベース”というものを設計します」
「内山さん」
「なんでしょうか？ 佐藤さん」
「ということは、『ＤＯＡというのは“データベースの考え方”を実現するための“正規化”などを使ったデータベース設計手法である』という風に理解して良いのですか？」
「おそらく現時点で最も使用されている“ＤＯＡ”の理解は、その通りです。ちなみに“ＤＯＡ”自体の発展もここから出発しています」
ここで、今までずっと内山さんの言うことを聴いていた山田さんが、内山さんに質問を投げかけてきた。
「内山さん、今まで説明していただいた“ＤＯＡ”は良く理解できました。私もこの“データ構造図”を作成するときは、担当してくださったＳＥの方と一緒にいましたから“正規化”という話は聞いていました。“ＤＯＡ”っていう言葉は知りませんでしたが。でも、やっぱり、これでは今回のトラブルは避けられないと思うのですが、どうなのです？」
「その通りです、山田さん。では、次に『なぜＤＯＡを使用したのに、今回の様な問題が発見できなかったのか？』をお話しましょう」
「では、まず、社長にお聴きします。『コンピューター・システムの中にあるデータを完全に保証する』のは、コンピューターの仕事だと思われますか？」
「そりゃ、そうでしょう。コンピューター・システムの中のデータなのだから」
「いや、社長そうはいきません」
「ん？ 佐藤君、どうしてだね？」
「データをコンピューターに入れる時に人間が間違ってしまうと、結局は駄目なんです」
「（ムッとした様に）だから、いろんなチェックをする“プログラム”っていうのを作っているんだろう。ウチにコンピューター・システムを初めて導入した時には、みんな『やたらエラーが出て、なかなかデータが入れられない』ってこぼしていたぞ」
「（苦笑しながら）と言われても、所詮コンピューターでできるチェックというのは“完璧”ではないのです」
「どういうことだ？」
「例えば、ある女性社員──仮に“山田花子”さん、とでもしましょうか──が結婚して“佐藤花子”に名前が変わったとします。この事実を総務がコンピューター上の“社員台帳”にあたる“社員マスター”に登録する訳ですが、この時本来ならば『その社員の氏名欄を変更する』はずが、誤って『別の社員として登録してしまう』と、コンピューターはこれを“正しいもの”として受け入れてしまいます」
「えっ！ そうなのか？」
「それは、コンピューターが『山田花子さんと佐藤花子さんは同一人物であるから、二重登録はできない』というチェックができないからです。コンピューターができるのは『社員マスター上では、社員番号は重複できない』ということだけなのです」
ここで、内山さんが口を開いた。
「つまり、コンピューターは『社員を登録している』という認識はしていないのです。例えば“社員氏名”という名の欄に“山田花子”という文字を記録している……といった認識にしかすぎません。結局、コンピューターは“データを記録しておく単なる器(うつわ)”を提供しているに過ぎないといえます。そして、この“器”に何を入れるかは、人間が判断していかなければならないのです」
面食らった顔の社長が言った。
「しかし、ちゃんと“プログラム”というものでデータはチェックされるのですよね。そうでは無いのですか？ 内山さん」
「ええ。でもそれは、例えば“社員氏名”という名の“器”には『漢字のみが入る』といったチェックに過ぎないのです。コンピューターは、データに対してはこの程度の認識でしかないものですから。従って、“社員氏名”に“花子”とだけ入れても“漢字のみ”という条件は満足しているので、コンピューターは受け入れてしまうのです」
「でも、“プログラム”は“請求書を印刷”したり“売上を集計”したり、様々なことをしているのではないですか？」
「その通りです。でも、コンピューター・プログラムは“請求書という文字も含めた様々なデータを印刷”したり“売上金額という器に記録されているデータを合計”したりしているだけなのです。『自分が印刷しているのは請求書だ』とか『自分の集計しているのは売上だ』といった、作業そのものの“意味”を理解している訳ではないのです。結局、こういった“仕掛け”を提供しているだけ、というのが最も適切な理解なのです」
しばらく考え込んでいた社長が、やっと口を開いた。
「内山さんの話を聴いていると、なんだかコンピューターが“馬鹿正直な社員”に思えてきたんですが」
ここで佐藤さんが言った。
「社長。ちょっと過激な言い方でしたが、内山さんの言うことは間違ってはいません。所詮、コンピューターには限界があるんです」
「（それでも諦め切れないかの様に）じゃぁ、あれだけの金をかけて作ったコンピューター・システムはなんだったんだ？」
慌てて、内山さんが言った。
「いや、コンピューター・システムが全く役に立たないと言っている訳ではないのです。コンピューターは与えられた作業を非常に迅速にこなすことが出来ますし、この能力があるからこそ、先ほどの“正規化”という考え方も実現できるのです。要は『業務全部を人間がこなすのは非効率だが、かといって業務全部をコンピューター・システムに行わせるのも難しい』ということです。結局『業務の内、コンピューター・システムの方が効率良く処理できる部分はコンピューター・システムに、それ以外はすべて人間が担当する』というのが、最も正しい姿なのです」
佐藤さんも“補足”した。
「ですから、先程の内山さんの『コンピューター・システムの中にあるデータを完全に保証するのは誰か？』という質問には、『コンピューター・システムの補助を受けながらも、業務担当者が保証する』というのが正解なのです。内山さん、そうではないですか？」
「その通りです。言われてみれば“当たり前”の答えなのですが。コンピューター・システムを構築する上で、こういったことが忘れられてしまうケースは、今でもまま見受けられるようです」
「そうか、そういうことなのか。でも、そうなると、なおさらコンピューター・システムというのは高い買い物なのだと思ってしまうな。そう思わんかね？ 佐藤君」
「（苦笑しながら）その通りです。だからこそ『いかに安く、いかに効率良い、コンピューター・システムを作るか？』が我々システム部の課題の一つとなっているんです。でも、そのためには、業務の現場で働いている社員の協力無しでは実現できない、ということもご理解いただけますか？」
「なるほど、わかったよ」
社長の様子を見て、内山さんが話を続けた。
「今までお話ししてきた様に、コンピューター・システム内のデータベースは“データを記録する器”であって、その中に記録されるデータがどういう“意味”を持っているかは関知しません。この“意味”を理解し、その“意味”通りのデータをデータベースという“器”に入れるのは、やはりその業務を担当されている方達なのです」
「なるほど」
「さて、ここで改めて『システム・エンジニア──略してＳＥ──とは何か？』を考えてみましょう」
と、内山さんは新しいレポート用紙に“ＳＥ”と書きながら、話を続けた。
「ＳＥは、コンピューター・システムを設計するエンジニアです。そして先程からの話でもお分かりの様に、彼らの設計する“コンピューター・システム”というものは“器”と“仕掛け”です」
と、内山さんがレポート用紙の“ＳＥ”と書いたすぐ下に、“器と仕掛け”と書いた。
「この内、業務担当者にとって最も重要なのが“器”です。“仕掛け”の方がこの“器の中のデータを記録”したり“器の中のデータを印刷”したりすることを考えれば、まず『器ありき』と言えるからです。そこでちょっと“仕掛け”の話は横に置いておいて、ここからは“器”という点を中心に話をしていきましょう」
と、内山さんはレポート用紙の“器”と書いた部分を丸く囲んだ。
「さて先程お話した通り、本来業務担当者はコンピューター・システム上の“器”にどんなデータを記録していくのかを厳密に“定義”しなければなりません。ところが、その“器”を作成するＳＥの側から見れば、厳密な定義は不要なのです」
ここで社長が口を開いた。
「なぜです？ “入れるもの”が分からなければ“器”も作れないじゃないのですか？」
「先程、佐藤さんが言われていた“社員マスター”の話を思い出してください。“社員マスターという器”に関してコンピューター・システムができることは、“社員番号のデータが重複していないことのチェック”や“社員氏名のデータが漢字であることのチェック”など、非常に限られたことだけです。このために、ＳＥはこの限られた事柄だけが分かれば良いと考えがちなのです。結局、『社員マスターには、社員番号、社員氏名、などの、データを記録する場所があれば良い』し、『社員番号のデータは社員マスターの中で重複さえしなければ良い』し、『社員氏名のデータは漢字であれば良い』ということだけを聞き取れれば、ＳＥは満足してしまいがちなのです」
「（ちょっと面食らった様に）そうなのか？ 佐藤君」
「（苦笑しながら頷いて）社長、例えば“バケツ”を考えてみてください。バケツには“何々を入れる器”という厳密な“定義”は不要です。ある人は掃除をする時の水を入れるでしょうし、またある人はガーディニング用の土を入れるでしょう。でも、バケツを作る人にとっては“水入れるため”とか“土を入れるため”といった情報で、バケツをあの様な形に作っている訳ではないはずです。結局『どんな形の器を作れば良いのか』が分かれば器を作る上では何の支障もないのですから。“器を使う側”と“器を作る側”では、これだけの認識の違いがあるんです」
佐藤さんの話に「う～ん」と腕組みをした社長が考え込みだしたので、内山さんも佐藤さんも黙って社長を見守った。
と、一分ほど経ったころ、おもむろに社長が「ということはだ」と佐藤さんに向かって口を開いた。
「ということはだ。今回の販売管理システムのトラブルのそもそもの発端はだ。顧客マスターを作る時に、担当した山田君やＳＥが“顧客コードや顧客名といったものがある器”という情報だけで満足して、作ってしまったことにあるんだな？ そして、彼らが『顧客マスターには顧客のデータが記録される』といったあいまいな理解でいたために、今回の様なトラブルが発生したんだな。とは言え、彼らは“器”を作るのが商売だから、それを責めることはできないと。こういう訳だ」
佐藤さんも内山さんも社長の理解力に感心しながら頷いた。
「その通りです。先程お話した“ＤＯＡ”がデータベースという“器”の設計のために使用されるのであれば、結局その“中身”に関する情報は不要となってしまい、結果として大きな誤解が発生する危険性を含んでしまうのです。私が最初に『今回のトラブルにはＤＯＡは役に立たない』と言ったのは、正にそこなのです。“ＤＯＡ”にはこういった限界があるのです」
という内山さんに社長も佐藤さんも頷いたが、山田さんはなんとなく釈然としない様子で内山さんに聞いてきた。
「ということは、内山さん。この“ＤＯＡの限界”を打ち破るのが、内山さんの言われる“概念ＤＯＡ”なのですか？」
「その通りです、山田さん。では、いよいよ“概念ＤＯＡ”の話に入りましょう」
と、その時、社長室のドアが開いて、鈴木さんが顔を出した。
「社長、もうそろそろお出かけになりませんと」
と言われた社長が時計を見て、慌てて言った。
「おお、もうそんな時刻か。内山さん、申し訳ないが、私はそろそろ出かけなければなりません。貴重なお話なので、もっとお聴きしていたいのですが」
内山さんも腰を上げながら、にこやかに言った。
「では、日を改めてお伺いしましょう」