現状分析プロセス-情報体系整理図作成

現状分析プロセスの最後のステップは情報モデルである「情報体系整理図」を取り
上げます。このモデルは情報分析図の項で取り上げたエンティティ(ひと、もの、
かね)、つまり固定情報としてのマスター項目を取り上げた「スタンディング情報」
とトランザクションデータである「イベント情報」の関係を体系化した図です。
最適化ガイドラインにそのイメージ図がありますので紹介します。
体系化イメージ図URL: http://www.e-gov.go.jp/doc/060331/doc5.pdfの
38ページです。
情報体系モデル図は前回のテーマである情報分析図(EEM:Entity Event Matrix)
を描くときに、DAM(Data Abstraction Matrix:情報抽象化表)という情報抽象化表
を作成します。
このDAMをもとに「情報体系整理図」を作成することになります。
DAMとはスタンディング情報とイベント情報のデータ項目を抽象化した項目表です。
従来使用しているファイル定義表のデータ項目がより抽象化された表と考えれば良い
でしょう。
今日の話はこの2点、“なぜ、情報体系整理図を作成するのか”と“DAMはなぜ必要
か”について述べてみます。
“なぜ、情報体系整理図を作成するのか”から始めましょう。表記法はUMLを用いて
います。UMLでデータベースを体系化する利点はスーパークラス(上位データベース)
の考え方です。共通項目を上位概念のクラス(データベース)として置いてデータ
ベースの体系化が出来ることでデータベース体系的な“見える化”を図表化すること
が出来ます。
よく引用されますのが、動物という抽象概念と犬、猫、人間、鯨などの個々の動物と
の関係です。個々の動物に共通している事項には、口、目、鼻、足や動く、しゃべ
る、食べる等の属性があります。一方、共通化できない属性もあります。
しかし、動物のグループとして一括りに出来ます。「動物」というスーパークラスの
もとに「犬」、「猫」、「人間」、「鯨」等が関係付けられ体系化できます。
IT設計に置き換えてみましょう、ガイドラインのイメージ図では「研修情報」が
スーパークラスで定義され、「受講申込」、「受講記録」、「テスト結果」が「研修
情報」の下位のデータグループであるサブクラスとして構成されています。
サブクラスの共通属性は受講生、研修場所、研修クラス、研修時間などの共通属性が
あり、スーパークラスの「研修情報」に組み込まれグループ化されています。
さらに、この「研修情報」クラスはスーパークラス「人事活動情報」の1つの
サブクラスとして体系化されています。まさに、データベースの“見える化”です。

次に、“DAMはなぜ必要か”に話を移しましょう。情報体系図にまとめられるエンティ
ティやイベントのデータ項目は抽象化された項目名を定義することを言っています。
この意味は、1システムの設計をするときには問題にならないのですが、今回の電子
政府で複数の府省に跨る共通業務システムを扱い時には現状調査時にも必須になり
ます。
例えば、物品調達業務の調達計画の承認者を捉えてみましょう。各府省のシステムは
独自で設計されていますので、業務としては同じでも承認者が同じ課長でもファイル
のフィールド名称はそれぞれ異なり、担当承認、課長承認などさまざまです。
基本的にフィールド名は“承認者”だけで良いはずです。DAMで同業務での各府省の
データ項目の抽象化をすることで複数の府省でのヒアリングが可能になりますし
現行体系としての「情報体系整理図」の作成が可能になります。
また、業務プロセスを見てもこの承認者と言うフィールド名はまったく別々に設計
されています。計画承認者、調達承認者、支払い承認者など雑多です。このDAM化は
業務プロセスの抽象化ですので、EEMを通して作成することになります。この現行体系
でのプロセスの抽象化は実際には行いません。将来体系のデータ体系として設計する
ときに作成されます。現行体系では現行業務の課題が見える程度で十分であるという
ことでしょう。

第128回はここで終了します。
今回は「現状分析プロセス-情報体系整理図」を取り上げました。
次回は「見直し方針プロセス-見直し方針全体フロー」をとりあげます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする