「ユーザ辞書」を整備せよ
情報検索系システムが普及しない原因，あるいは個別帳票メニュー提供方式に流れて公開ファイル提供方式が不評である原因の一つに，ユーザが公開ファイルの内容が理解できないことがあります。これを解決するための手段として「ユーザ辞書」があります。ここでは，ユーザ辞書が持つべき機能，その構築方法をなどを示します。
なぜ情報検索系システムが利用されないのか
「公開ファイルも作り，講習会も開催したのに，全然利用されない」ということがよくあります。なぜでしょうか？
このようなとき，とかく「教え方が悪いのでは？」「ツールがユーザにとって使いにくいのでは？」と考えがちですが，むしろ，使い方よりもファイルや項目がわからないので使いようがないということが多いのです。
- ファイルがわからない
- 「講習会では売上ファイルを用いる例題だったが，私は生産部門なのに，どのようなファイルがあるのかわからない」「教わった売上ファイルでは，データが年月と製品で集計されたデータだった。私が担当している得意先だけを知りたいのに，それにはどのファイルを使えばよいのだろうか」「売上ファイルだけでも多くのファイルがあり，どのファイルを使えばよいのかわからない」
- 項目名あるいは項目の意味がわからない
- 「［得意先］なのか［顧客］なのかわからない」「売上ファイルに［支店］の項目があるが，それには本社営業部は入っているのだろうか」
- データの内容がわからない
- 「すべてのデータの［売上金額］を集計すれば全社売上高に一致するはずなのに，決算書にある数値と違う。情報システム部門に問い合わせたら，返品をマイナスとして計算したほしいという。それをしても一致しない。今度はリース分が入っていないという。いったいどうすれば本当の売上がだせるのだろうか」「商品コードの体系がわからないので，必要な商品群のデータを取り出すことができない」
- ジョイン（結合）の仕方がわからない
- 「商品系列別の売上を知りたいのだか，どのファイルとどのファイルを使えばよいのかわからない」「売上ファイルと商品マスタを用いればよいのだろうが，何をキーにして結合するのだろうか。売上ファイルの［商品］と商品マスタの［品目］は同じものなのだろうか？」
このようなことが不明のままに適当にやってみると，常識的ではない数字が出てくるので「コンピュータなんか使いものにならない」として，使わなくなってしまうのです。また，このような苦情が重なると「やはり公開ファイル提供方式はダメだ。個別帳票メニュー提供方式か帳票直前ファイル提供方式にしよう」となってしまいます。
オンラインのユーザ辞書が必要だ
これを避けるには，ファイル一覧表とか項目解説書などを整備する必要があります。しかし，それを紙で渡すのではなく，デジタルファイルに作成して，それらの間の連携ができるようにする必要があるのです。
- 文書量が非常に多い
- ファイルや項目の個数は非常に多くなりますので，それぞれに解説をつけた文書は非常に分厚いものになってしまいます。それを全ユーザに配布することもできませんし，利用時にそれを参照するのも大変です。「ヘルプ」のようにデジタル化する必要があります。
- 多様な索引が必要である
- 項目名からそれを持つファイルを検索したり，そのファイルを知ったらそのファイルを使うときの注意見たりするように，多様な文書を多様な面から検索する機能が必要です。
- 改訂や追加が頻繁に起こる
- 公開ファイルの追加，ファイルデザインの改訂，説明の改善など，ユーザ辞書は頻繁に改訂・追加が必要になります。それを紙で管理するのは困難ですし，ユーザによっては旧版を使ってしまうこともあります。
ユーザ辞書の例
ユーザ辞書の例を示します。
ユーザ辞書では，開発側ではなく利用側の立場での説明や機能が重要なのです。なおここでは項目やファイルを次のように区分しています。
- キー項目，付随項目，計算項目
- ［得意先コード］や［商品コード］のように，レコードの抽出や集計のキーになる項目をキー項目といいます。［得意先名称］や［得意先住所］のように，キー項目と１：１に関連した項目を付随項目といいます。［売上金額］や［在庫数量］などの主に計算対象になる項目のことを計算項目といいます。
- マスタファイルとイベントファイル
- ［得意先マスタ］や［商品マスタ］のようなファイルをマスタファイル，［売上ファイル］や［在庫ファイル］のように，取引が発生したときにデータが更新されるファイルをイベントファイルといいます。マスタファイルは主キーに対して唯一のマスタファイルが存在するのが原則ですが，イベントファイルでは，売上ファイルといっても，短期間のデータを明細データで持ったり，長期間のデータを年月・得意先・商品でサマリしたりしたいくつかのファイルが存在します（当然ながら異なったファイル名称になっています）。
項目による機能
- 項目の特定
- ［得意先コード］などの項目名を特定するには，次の方法があります。
- その名称（日本語名称，略称，カナ名称，英名称）あるいはその部分文字列を指定すると，該当する候補の一覧表が表示されるので，それから特定する。
- ［ファイル項目表示］での項目一覧から指定する。
- 項目解説
- キー項目
- ［得意先］の定義：契約や請求をする企業を指しているのか，納入先である事業所をいうのか。出荷先だとすれば，自社の他事業所なども入れるのかどうかなど
- 関連項目：［得意先区分］［納入先］［仕入先］など関連する項目との関係
- コード体系：先頭の２桁が業種であり，次の４桁が発生順であるなどの説明。［性別］や［府県］のようにコードが少ないときは，具体的なコードの表示
- ［得意先］について「日立」と指定すると，「日立製作所」や「日立精機」などの得意先名称や得意先コードが表示される。
- ファイル一覧
- 特定された項目名を持つファイルの一覧表の表示。これをクリックすることにより「ファイルの特定」をすることができます。［年月別・得意先別・商品別の売上数量・金額］とか［得意先マスタ］のような非常に簡単な「１行解説」も表示します。
- レコードの抽出・編集表示
- 特定した項目が得意先であれば得意先マスタのように，特定したキー項目を主キーとするマスタファイルの項目一覧が表示されます。さらにこの画面で，取り出す項目や選択条件を指定することにより，新しいファイルを作成したり，台帳形式で表示したりすることができます。
ファイルによる機能
- ファイルの特定
- 「項目の特定」と同様に，ファイル名やファイルの「１行解説」の部分文字列を与えることにより，該当するファイルの候補が一覧表示されます。また，項目での「ファイル一覧」から特定することができます。ファイルが特定されると，次の機能が利用できます。
- ファイル解説
- 特定されたファイルについての解説です。マスタファイルに関してはあまり解説の必要はありませんが，イベントファイルについては，利用するときに留意するべき事項を詳細に解説する必要があります。売上ファイルについていえば次のようなことを解説します。
- ここでの売上とは何か。全出荷を意味するのか，金銭を伴う出荷に限定しているのか。これ以外に売上になるものがあればそのファイル名
- 収録している期間（○○年○○月から○○年○○月まで），明細かサマリか，サマリなら集計単位は
- 全体での値引きや返品などの処理。別レコードにしているのか，売上レコードを修正しているのか
- ファイル項目一覧
- 特定されたファイルの持つ項目一覧です。「１行解説」も表示します。特にこのファイルでの特有な説明が必要なときは，それを表示するか解説をした文書名へのリンクをつけておきます。なお，この項目を指定することにより「項目の特定」をすることができます。
この項目一覧の画面で，取り出す項目，選択条件，集計条件を指定して新しいファイルを作成することができます。そのファイルを登録することもできます。 - 個別処理
- 特定されたファイルを主入力とする既存の個別処理メニューを表示して，それから必要な処理を実行したり，プログラムを表示して部分修正をして実行したりできます。
- 情報検索系システムの多くは，一つのイベントファイルをいくつかのマスタファイルと照合して抽出・集計する処理が多いので，抽出条件や集計項目をパラメタとして与えればよいようなプログラムを準備しておくと便利である。
- 先に処理したプログラムをこのメニューに登録できるようにしておけば，あまり労力をかけずにメニューを逐次充実させることができる。
ユーザ辞書の実装には工夫が必要だ
上記の例は，私がある企業にて開発したものをベースにして，やや理想的に汎用化した記述にしたものです。現実に実装するには，次のような事項を考慮する必要があります
辞書構築・維持のプロセス
- 辞書作成の目的
- 情報検索系システムのためだけを目的として，わざわざユーザ辞書を構築するのは費用対効果の面で不適当です。しかし，項目の定義やファイルの説明など，ここで必要とする文書の大部分は，本来，基幹業務系システムやデータウェアハウスを構築するときの初期段階において文書化するべきものなのです。そのときに，ユーザ辞書としても利用することを考慮して，ユーザ側からの視点を重視した記述にすることが望まれます。
- 維持拡充の対策
- 現実には，ユーザ辞書は構築するよりも改訂する作業を継続することが大変なのです。わかりやすくするためにユーザからの質問を解説のなかに取り込む作業や，新規の項目やファイルについて各種文書を追加する作業は，地味なだけに放置されがちです。しかし，辞書は鮮度が悪いと使い物になりません。そのために，次のような対策が必要になります。
- 維持改訂のための組織を明確にすること。鮮度を保つように常に状況を監視する必要があります。また実際の維持改訂作業には情報システム部門やユーザの協力が必要ですが，それを働きかけることが必要です。
- 作業を容易にするためには，解説書類はむしろルーズな形式のほうが適切です。個々の情報そのものを厳格なデータベース化をするのではなく，一般的な文書ファイルとして記述しておき，それをデータベース側でリンクするようにします。
- 逆に自動化できることは自動化するツールが必要です。新規項目や新規ファイルができたとき，いちいち一覧表表示プログラムを修正するのは大変です。
- 既存ツールとの連携
- ＡｃｃｅｓｓやＯｒａｃｌｅなどのデータベース管理システムでは，このユーザ辞書に類似した機能を持っています。しかし，一般的にはデータベースを構築する提供側のための機能に限定されており，解説文書的なものを取り扱う機能が不十分です。しかも，あまりにも形式的統一が厳格であり，ここで示したような一般文書的な情報を扱うのには不便なこともあります。それをどのように連携させるかを考える必要があります。
利用での工夫
- スコープの設定
- 全体の項目数やファイル数は膨大なものになります。一覧表を表示したときにあまりにも多いとプルダウンメニューが使いにくくなります。［年月］のような項目はいろいろなところで使われるので特定がしにくくなります。その対策として，ユーザが自分はどの分野に限定しているかを指定できるようにします。それをスコープといいます。これは，公開用のファイルと個人用のファイルを区別したり，セキュリティの観点からアクセスの制限を設けるときにも必要です。
- 辞書情報の継承
- 標準のファイルから派生ファイルを作成したり，個別処理で新しい処理プログラムを作成したりしたとき，そのファイルや処理に関する辞書情報を元の辞書情報と追加条件により自動作成できるようになっていると便利です。
最近の技術動向への対応
- 分散環境への対応
- 標準的なファイルや辞書は全社的なサーバにあるが，ローカルでよく利用するものは部門別のサーバに置いたり，仕掛中のものはやユーザ個人のクライアントに置くことが多いのですが，クライアントにあるイベントファイルと全社サーバにあるマスタファイルをマッチングさせるような作業も多くなります。分散データベース環境で機能できることが必要になります。
- 文書のＸＭＬ化
- 解説文書の形式は，通常はＨＴＭＬあるいはグループウェア特有の記述形式にするのが作成上は便利ですが，それをデータベースに取り込んだり多角的なリンクを行うには，ＸＭＬにするのが適切でしょう。ところがＸＭＬではかなり形式が厳格になりますので，どのように両者の利点を持たせるかの工夫が必要になります。