社内用語・概念を整理する「ユーザー辞書」は役立つ：システム部門Q＆A（27）（1/3 ページ）

本連載の第9回では、情報検索系システム活用の効果や運用を誤ったときの危険性といった全体的なことを述べ、その中でユーザー辞書に触れた。今回は、ユーザー辞書に焦点を当てて、その概要や有効な使い方などを説明する。

[木暮 仁，＠IT]

質問

以前ユーザー辞書について書かれていましたが、よく理解できませんでした。詳しく教えてください。

このシリーズの第9回「情報システム部門の生産性が上がらない理由」に出てきた「オンライン・ユーザー辞書」（以下、ユーザー辞書）に関する質問です。以前のお話では、情報検索系システムの普及を阻害する要因として、利用者が公開されているファイルやその項目の内容が分からないことを挙げており、その対策として、ユーザー辞書を整備するべきだと論じていました。確かにユーザー辞書があれば便利ですが、具体的なものが想像しにくいし、その構築作業は膨大な量になると思います。ユーザー辞書について、もっと詳しく教えてください。

回答

　第9回では、情報検索系システムの活用の効果と、運用を誤ったときの危険性など、全般的なことをテーマにしましたので、ユーザー辞書そのものについては舌足らずでした。このような以前に述べた内容で説明不足のことがありましたら、ぜひご指摘ください。今回は、ユーザー辞書に焦点を当てて説明していきます。

情報検索系システムでの危険

　ここでの情報検索系システムとは、まず販売システムや生産システムなどの基幹業務系システムで収集・蓄積したデータを、エンドユーザーが使いやすい形式のファイルにして公開します。そのデータを、ユーザー自らが簡易ツールを用いて任意の切り口で検索加工できるようにした利用形態、すなわちデータウェアハウスのような利用形態のことと定義します。

　このような利用形態では、ファイルや項目の定義を知らないユーザーが利用するときには、いろいろなトラブルが生じます。

　どのファイルや項目を使えばよいのか分からない　

　例えば、いくつかの得意先の売上高を見たいとき、ユーザーは次のようなことに戸惑います。

• 詳細な売上データファイル、何らかのキーで集計した売上ファイル、月別あるいは年度別に分けた売上ファイルなど、多くの売上ファイルが存在しているが、どの売上ファイルを用いればよいのか分からない。分からないので、詳細なデータのファイルを用いると、データが膨大なので時間がかかってしまう
• 得意先の「日本情報処理株式会社」はその正式名で指定する必要があるのか、または社内でよく用いている「日情」とか「JIK」と指定しても取り出せるのか。コードで一括して取り出したいが、コード体系はどうなっているのか、それには例外はないのか
• 得意先マスタと売上ファイルを得意先コードによりジョイン（結合）するが、得意先マスタには得意先コードという項目があるが、売上ファイルにはそれがなく、客先コードと納入先コードという項目がある。どの項目でジョインすればよいのだろうか

　ファイルや項目の内容が分からない　

　情報検索系システムでは、例えば次のようなトラブルが生じます。

• 売上ファイルの全データの売上数量項目を集計してみたが、全社の売上高とはかなり異なる値になった
• 先月の出荷数量と入荷数量を計算したが、月末の在庫数量がマイナスの商品がある
• 配送費用の項目を距離別に配送数量加重平均を計算したら、配送距離が短いところが異常に高い運賃になっていた

　このようなことが続くと、「だからコンピュータなんかアテにならない！」と評価されてしまいます。逆に、このようなことに気付かないままにデータを信じて意思決定をしたら、大きな失敗を招くかもしれません。ところが、これらのデータは請求書や財務諸表に用いる基幹業務系システムから得たデータですから、データそのものは正しいことが立証されているのです。

　これらのトラブルは、ファイルの内容や項目の定義が利用者に正確に伝わっていないことに起因します。例えば、次のようなことが明確になっているでしょうか。

• 売上ファイルでは、顧客への売り上げだけがすべて入っているか。社内での転送データも入っていたり、営業を通さない取引は入っていない（別のファイルにある）ということがないか
• 100個売り上げたものの10個返品されたとき、データとしては、90個というデータが1つ入っているか、100個と−10個の2つのデータがあるか。売り上げが4月で、返品が5月にされたときはどうなるのか
• 配送費用では、先方の車で取りに来たときには基準により運賃を支払うとしていたとき、その配送距離をどのように入れているのか。不明のときは空白（0）にしていることを全員が理解しているか

　ユーザー辞書の必要性　 　

　上記のようなトラブルを回避するには、ファイルや項目名の定義が必要です。それを紙の仕様書にしたのでは、かなり分厚いものになりますので、ユーザーは参照しようとも思いません。また、更新をしても、ユーザーが適切に差し替えてくれることは期待できません。簡易ツールを使っている環境で、違和感がなく参照できるオンライン辞書にしておかなければなりません。

　DBMSやOLAPツールなどでは、ファイル・項目の一覧や、それらの定義を記述して画面表示する機能を持っていますが、通常はファイルが持つ項目名一覧や、項目のけた数など、システム側に必要な事項ばかりで、上記のようなユーザーが利用するのに当たって必要な情報を記述したり、表示したりする機能に欠けています。このような理由から、ユーザー辞書が必要になるのです。