シス開発：注目すべき重要技術 |
社内の情報システムを構築する場合、開発や維持コストを考慮するなら、ERPパッケージを利用するのが賢明な選択となっている。導入の際には、一緒にリエンジニアリングを実施し、組織構成や仕事の進め方を大改革するのがベストだ。
そうではなく、情報システムを自社で開発すると選択したなら、情報資源管理を大々的に取り入れたほうがよい。その際に役立つように、情報資源管理を実現するときの設計ポイントをまとめてみた。なお、以下に説明する内容は個人的な見解であり、情報資源管理（データ中心アプローチと呼ぶ人もいる）に関する本や記事とは異なる場合もある。その点を理解したうえで読んでほしい。
情報資源管理が注目したのは、簡単に表現すると「データは処理に比べて安定しているので、全社で共通のデータを深く分析して求め、各業務システムで利用しよう。業務の機能が変わったときは、処理だけを変えればよい」という点だ。つまり、「全社的なデータ基盤を整え、それを複数の業務システムで利用する」という発想である。
この考えを実現するのは、残念ながら簡単ではない。すべての業務システムで使えるように、データを分析するのが非常に難しいからだ。そこで、実際に構築する際には少し工夫を加え、システム全体に融通性を持たせて対応する。その工夫を加えた情報資源管理は、以下の３つの項目を満たさなければならない。
情報資源管理を実現するための設計３項目 ・1. 重要データは深くデータ分析して、共通のデータベースに保存する
・2. 業務システム向けのインターフェースを用意し、それ経由でアクセスする
・3. 分析したデータは、ツールできちんと管理する
１番は情報資源管理の基本で、２番が実務上の工夫である。３番は必須ではないが、できれば満たしたほうがよい。どれも重要なので順番に解説しよう。
商品や顧客といったマスター関連のデータは、情報資源管理でなくても共通のデータベースに入れるだろう。それ以外のデータでも、一部の業務システムだけでしか使わないローカルなデータを除き、共通のデータベースに入れるのが基本だ。
これらの共通データベースは、関連する複数の業務システムからアクセスする。データの読み出しだけでなく、データの追加や更新も必要ならば許す。マスター関連のデータでは、データの登録に専用サブシステムを用意する場合もある。業務システムからの追加や更新を許さず、データの正確性を確保したいときに有効だ。当然、運用面でのルール化も必須で、登録や検査の担当者や流れを明確にしておく。
情報資源管理では、消費税率のような重要値も管理する。外部で決まる値のほかに、社内で決める重要値もあるだろう。複数の業務システムで使う値だけでなく、単独の業務システムで使う値も含めて、データベースに入れてきちんと管理する。少し凝るなら、値の有効期間を指定できるように作る。読み込む際には当日の日付を指定し、該当する値を引き出す仕組みにすれば、将来の値を事前に登録できる。
以上のような考え方が、共通データベースを構築する際の基本となる。もっとも大変なのは、どの業務システムでも使えるようにデータを持つことで、きちんとしたデータ分析が求められる。この分析作業は、その分野の専門家ですら難しいが、可能な限り努力して理想に近いデータの姿を求めよう。
共通データベースを用いると困るのは、変更が発生したときだ。複数の業務システムで使っていると、その全部を変更しなければならない。複数の業務システムを一緒に変更するのは困難で、何らかの対処が求められる。
この問題を解消するために、業務システムごとに専用インターフェースを用意し、それを介して共通データベースにアクセスする。アクセス用のインターフェースとしては、データベースの表でも専用ルーチンでも構わない。とにかく、共通データベースに直接アクセスしないようにする。それにより、共通データベースの構造が変わった場合、インターフェース部分までの変更でよく、業務システム側は最小限の動作確認で済む。
インターフェースを介する構造は、共通データベースを構築する難しさも軽減する。業務システムを構築する際には、インターフェース部分だけをきちんと決め、共通データベースは仮の形で作っておく。その後に別な業務システムで使うとき、共通データベースを修正すればよい。前の業務システムとのインターフェースさえ変えなければ、前の業務システム側を変更する必要はない。
ただし、インターフェースを入れることによって、何でも自由に変更できるわけではない。共通データベースのデータ構造が大きく変わると、インターフェースにも影響を与える。後での変更を最小限にしたいなら、最初に共通データベースを作る段階で、きちんとしたデータ分析をしなければならない。
システム設計の心得の１つとして「変更の影響を広げすぎないこと」がある。何でも共通にすると、変更したときに影響範囲が広くなって、変更作業やテストが大変になる。そうならないように、ほどほどの共通化で押さえようという考え方だ。
この考えをインターフェースの作成にも適用する。たとえ内容が同じであっても、業務システムごとに別々にインターフェースを用意したほうがよい。インターフェースが共通だと、業務システム単位での変更が面倒になる。たとえば、ある業務システムでインターフェースの変更が必要になったとする。新しいインターフェースを別名で用意してから、それを使うソフトを全部修正し、古いインターフェースを削除してテストするだろう。古いほうを削除することで、修正し忘れを発見できるからだ。もし古いほうを別な業務システムで使っていると、削除してテストできない。このようなことが起こらないように、インターフェースを業務システムごとに分ける。もちろん、変更の影響範囲が該当する業務システムだけなので、変更の作業もラクになる。
通常は業務システムごとに略号を用意するので、その略号をインターフェースの名前にも付ける。こうすると、どの業務システム用なのか簡単に見分けられて、修正などのミスが減る。
情報資源管理では、共通データベースやインターフェースなどのフィールド定義を、きちんと管理する必要がある。手作業では大変なので、データ・ディクショナリのようなツールを用いるのがベストだ。
プログラムや画面設計で用いるデータ定義も、データ・ディクショナリからできるだけ生成し、プログラム内や画面設計内に直接書かないようにする。フィールド定義を一元管理できれば、単純なミスによるバグを発生しにくい。
ツールによる管理でもっとも重要なのは、データ全体がどんな状態なのか、簡単に把握する点にある。多くの業務をシステム化すると、同じ項目を別々に定義するミスが起こりやすい。ツールで管理すれば、最小限の手間で防げる。
以上のような方法により、変更に強い情報資源管理を実現できる。実行速度以外の面では万全とも思える仕組みだが、１つだけ注意点がある。
共通データベースには、インターフェースからは見えないフィールドも含まれる。もしインターフェースを介してフィールドを更新する場合、そのフィールドと見えないフィールドの整合性が求められるなら、勝手に更新できない状況が発生する。データの追加も同様で、見えないフィールドとの整合性のために、見える部分だけを登録できないこともある。
業務上で問題なければ、見えないフィールドの更新を自動化する方法で逃げられる。更新したフィールドの値と、見えないフィールドの既存の値から、見えないフィールドの新しい値を計算で求められる場合だ。このような処理は共通データベース側に用意して、業務システム側から更新する際に、処理を自動的に起動させる。
人間の判断が必要といった理由で自動更新が不可能なら、別な方法で逃げるしかない。マスター関連のデータなら、入力したデータを仮に登録して、残りのフィールドを別な部署で入力してもらい、両方が揃った時点でデータベースへ追加または更新する。夜中に実行というように決まった周期で処理し、マスターに反映させる。最悪の事態に備えるために、更新処理の前と後でデータをバックアップするのは当然だ。
この種の話は、業務上の担当や権限が大きく関係するため、業務レベルで検討する必要がある。業務上の運用ルールも含めて決め、情報システム側がそれに合わせるしかない。情報資源管理では「データの質を高く保つ」のが基本なので、マスター関連のデータは、きちんとした手順で入力や更新するように設計する。
以上が、情報資源管理を実現するために必要な設計上のポイントだ。システム更新が大変にならないように考慮した点こそ、一番の工夫といえる。実行速度が低下する欠点はあるものの、システムがなかなか更新できない問題よりは小さいので、速度向上のほうは別な工夫で対処したい。
（1998年５月７日）
情報資源管理を実現する際の設計ポイント |
