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

[木暮 仁，＠IT]

構築・運用での注意と発展のアイデア

　実際に構築・運用したとき、いろいろな問題が発生しました。また、私には技術的能力はありませんが、いろいろな発展が考えられます。

　　　項目やファイルの定義について　　　

• 得意先コードを「tokui」、得意先名称を「tokui-n」、得意先略称を「tokui-r」とするような命名基準の標準化が重要
• 項目の一意性をどこまで行うかの考慮が重要。あまりにも一意性を追求すると、項目数が膨大になり管理し切れなくなる。例えば年月日などは多くのファイルに存在するが、データ創成年月日などは1つの項目名にした方が便利だ。SQLのように、「ファイル名.項目名」として管理する方法もあるが、そうすると共通での項目として扱うのと混在して複雑になる。構造化したデータベースにすればよいのかもしれない。あるいは、後述の「世界」で独立させることも考えられる
• 売上ファイルのようなトランザクションファイル（ファクトテーブル）では、処理負荷の低減のために、蓄積されているデータの年月範囲、各種の切り口でサマリーしたファイルなど多様なファイルが存在する。どのファイルを使えばよいかを利用者に適切に示す表現が求められる

　　　ユーザー辞書の機能について　　　　 　

• すべての公開ファイルや項目について一覧表などを表示すると、あまりにも膨大な量になり不便だ。「共通」「販売」「経理」のような分野に区分しておき（これを「世界」という）、それを指定することにより、対象とするファイルや項目を絞り込めると便利だ。これはアクセス制限としても使える
• 過去類似処理では、管理者が登録したものと、本人あるいはグループが作成したものに制限するような工夫が要る。検索エンジンのように、優先順位を付けて表示するような工夫をするとよい
• 利用者各人の利用状況を学習して、適切な表示ができれば便利だ

　　　分散形態や3層構造での利用　　　　 　

• ここでのユーザー辞書機能は、原則として集中管理を前提としていた。それで、サーバの負荷が増大してしまう。中央のデータウェアハウスから、必要なデータを分散したデータマートに取り出したとき、それに関係するユーザー辞書をデータマートに作り出したい。「世界」をデータマート／データウェアハウス／ほかのデータマートのような構造にすれば、効率が良くなるだろう
• また、3層構造のブローカ機能やMVCでのコントローラとモデル機能に組み込むことができれば、資源の所在を仮想化できるので、柔軟な活用ができるはずだ

ユーザー辞書はデータ体系整備そのもの

　このユーザー辞書を構築した経験では、これらの処理システムを作成するよりも、ファイルや項目の個数が多く、その解説書を作成する作業量が膨大なことが、ユーザー辞書の展開を妨げることを実感しました。そこで、ある分野を対象にしただけで放棄してしまった次第です。

　しかしユーザー辞書は、情報検索系システムに非常に役に立つツールですし、それだけでなく、基幹業務系システムの理解に大きな効果がありました。いまでいえば、EAのデータ体系整備そのものであるといえます。

　　ユーザー辞書は存在するのが当然だ　　　 　

　ここでは、情報検索系システムの利便のためにユーザー辞書を作ることにしたのですが、そもそも基幹業務系システムでのER図やクラス図を検討するときに、項目やファイルの定義を明確にする必要があったはずです。しかも、そのときは、実装のための定義以前に実務での定義がなされていたはずなのです。すなわち、ユーザー辞書のコンテンツは、ことさらに意識して作成するのではなく、システム検討のプロセスで必然的に作成されるべきものなのです。

　ですから、ユーザー辞書作成の作業が大変だというのは、実はシステム開発プロセスの管理が不十分であったということなのです。

　当初からユーザー辞書を作ることは効果が大きい　 　

　利用者の視点で項目やファイルの定義をすることにより、次のような効果が得られます。

• 項目の定義を行うことにより、社内での用語や概念の統一ができる。これは、要求分析段階での誤解を防ぐのに重要なうえ、出力情報での解釈の誤解も減少する。ここでの定義を実務でも採用することにより、情報システム以外の業務でも効果がある
• 目的とする情報システムが、個々の帳票類ではなく、公開ファイル群になる。そのファイルやそれが持つ項目が、誰にも理解しやすい表現で、参照しやすくなっているならば、開発するべき情報システムの内容が明確になる。これはベンダへ説明をするにも便利だ
• 公開ファイル群を正規化したデータベースだとすれば、得意先マスタや商品マスタなどのマスタファイルは、販売システムだけでなく、会計システムや購買システムなどと統合した内容になる。また、項目の定義を熟考することにより、得意先と仕入れ先を相手先という概念に統合することも考えられるだろう。このように、縦割りのシステムになるのを防ぐことができる
• このような考え方を進めれば、項目やファイルの定義とは、データの可視化をする手段であるといえる。そして、ユーザー辞書の機能は、可視化を効果的に示す手段であり、しかも、データが実装できたときには、そのまま検索加工のツールになる

　　　　　逐次改善しやすい　　　　　

　ユーザー辞書は当初からあるべきものではありますが、現実には当初から万全のものが整備されるとはいえません。実際に利用している間に、いろいろな質問に回答するときに随時補充していけばよいのです。機能も同様で、当初はシンプルなもので構築し、ニーズにより追加していけばよいのです。それには、ここで示したような、柔軟な結合の構造にしておくのがよいと思います。

筆者からのお願い

　このように考えると、このユーザー辞書は、情報検索系システムの普及に効果があるだけでなく、データ定義支援ツール、データリポジトリ、DBMSの基本機能として位置付けられると思います。第14回「データウェアハウス中心アプローチで問題解決しよう」で、情報検索系システムを基幹業務系システムに先行して検討するべきだとの「逆歴史的体系」を提唱しましたが、ユーザー辞書はそのアプローチと一致しています。

　ところで、筆者はこのユーザー辞書機能をDBMSやOLAPツールに実装する能力がありません。アイデア権（？）は主張しませんので、どなたか実装をご検討いただけないでしょうか。あるいは、筆者の不勉強で、このようなツールがすでに存在しているとか、自社でこのような利用を実践しておられるようでしたら、ぜひ教えてください。

この記事に対するご意見をお寄せください　[e-mail]

筆者プロフィール

木暮 仁（こぐれ ひとし）

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士（情報工学）、中小企業診断士、ITコーディネータ、システム監査、ISMS審査員補など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」「情報システム部門再入門」（ともに日科技連出版社）など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している