» 【第49号】データからプロセスが見える

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第49号】データからプロセスが見える

DRi通信49号「データからプロセスが見える」2000.10.1
オリンピックが終わって、本格的な秋になりましたが、みなさま元気にご活躍
のことかと思います。ポータル、ナレマレ、BI、コラボレイティブなど、相
変わらず新しい言葉が流行しています。シーズが多ければ多いほど、われわれ
はニーズと体力に合った賢明な選択が重要かと思います。
■データとプロセス
さて今月はデータとプロセスの関係についての認識や表現について考察します。
その粒度(Granularity、大きさ)については
(データ)      (プロセス)
1 属性 (加工データ)    加工データ導出ロジック
2 ファイルや画面・帳票   入出力プログラム
3 データベース や画面帳票群 システム(グループ)
のように3階層くらいを考えます。


■システム系処理と業務系処理
またその処理としては、システム系のものは除外し、業務系固有のものに限定
します。したがって、単なる「合計」、「在庫更新」、「追加」、「削除」、
「参照整合性チェック」など汎用的な処理は含みません。
<注>********************
ちょっと分かり難いかと思いますので説明を追加します。たとえば
在庫ファイル [品#.倉庫#]−(在庫数)
売掛けファイル[顧客#]−(売掛¥)
があったとき、在庫数、売掛¥、いずれも在庫データですが、これらにそれぞれ
更新用のプログラムを作る必要があるでしょうか。弊社のTHeRepositoryでは、
これらが在庫データであること(データ機能コード=NNI)、およびその加工
元が、それぞれ入庫数量・出荷数量、あるいは出荷¥・入金¥であることを(正
確には対応する参照KEYとの関係とともに)定義することによって、「都度プ
ログラムを開発する必要はない」として設計されています。
在庫計算のロジックは新在庫量=旧在庫量+入庫量(出庫のときはマイナス)
のようなものを、THeEngine(弊社企画中のプログラムレスを指向するミドルウ
エア)に1回書けば処理できるからです。
すなわちこのプロセスは、OSやDBMS側のシステム系のプロセスとして扱われ、
ユーザとして考慮する必要がありません。エンティティの追加・削除や参照KEYの
制約などの処理も同様、システム系のプロセスとしてTHeEngineで処理されます。
</注>*******************
■データとプロセスの対応
粒度を適切に選ぶと、1個のプロセスは1個のデータを生成するものとして定義
できます。同じデータを生成するプロセスは複数ありえますが、一般には最適な
プロセスを1個選択します。これは成果物(WHAT)と最適処理(HOW)の
関係ですから当然のことです。
一方、原料としてのデータとプロセスの関係は、一般に複数のデータが1個のプ
ロセスに必要とされます。したがってたとえば次のようになります。
(データ項目レベル)   (画面・帳票レベル)
 成果物   給与   受注画面
 プロセス  給与計算ロジック 受注処理ロジック
 原料    基本給   発注データ
 残業時間  在庫データ
 手当て   単価データ
これを概念DB構造図的に書くと次のようになります。
[生成データ]−[生成プロセス] あるいは D−P
↓ ↓
[原料データ] Di(入力データ) 
■データとプロセスの表現
ここで実際にデータとプロセスがどのように表現されているかを、代表的な表現
形式である、業務機能関連図とわれわれの推奨する概念DB構造図・IPFチャ
ートについて見てみます。
・業務機能関連図
名称は企業ごとにまちまちですが、システムの概要を示すために
  [営業]→[経理]
  ↓↑ ↑
 [生産]――・
のような表現が多用されています。この場合は[営業]や[経理]などは組織で
あると同時にその処理を表していますので、プロセスがノードとして明示的に、
またデータが矢線上に暗示的に表現されているのでP(d)→P(d)の形式と
言えます。
・概念DB構造図・IPFチャート
一方概念DB構造図やIPFチャートでは、
[受注#]→[出荷#]→[検収#]→[請求#]→[入金#]
―(・・) −(・・) −(・・) −(・・) −(・・)
のようにデータがノードとして明示され、プロセスが暗示的に扱われています。
すなわち矢線に生成プロセスが隠れている、D(p)→D(p)の形式です
■メリットとデメリット
業務機能関連図は、組織との関連があり、ユーザにとって分かりやすいため、
抵抗無く受け入れられるメリットがあります。しかしそのプロセスにどのような
下位のプロセスが含まれるか、矢線上にどのようなデータが流れるか、が明示
されないため各人勝手に想像するしかありません。
そこでこれを何回層にもブレークダウンすることになりますが、プロセスに着目
してブレークダウンを試みるために個人差が出やすく、工数の割にコミュニケー
ションの効果が上がらない傾向がみられます。
データ側を明示する概念DB構造図やIPFチャートでは、客観的に切り出された
概念ファイル(エンティティ)や画面・帳票が明示され、ユーザ要件の共有が進みます。
入力画面帳票(および概念DB構造図上のエンティティやサブタイプ)は入力プ
ロセスに、加工データは加工処理プログラムに、出力画面・帳票は出力プロセス
に対応しますので、更なるブレークダウンなしに詳細が見え、開発ボリュームも
かなりの精度で見積もることができます。
ユーザ要件は画面・帳票すなわちデータとして与えられます。またシステムの統
合はインターフェースデータの共有・標準化によって実現されます。したがって、
これらを明示するD(p)の図や表の方がはるかに生産性が高いといえます。
P(d)の図を用いていると、どうしても機能分割的発想になり、プロセス中心に、
データも成果物側というより、原料側のデータとの関係を重視するようになります。
原料側のデータはプロセスを介さず、(生産管理の部品展開と同様)成果物データ
と直接関係させて考えればよいはずです。
P(d)の発想は、プログラムとプログラムをワークファイルで繋ぐ発想になり、
共通の通信場としてのDBの認識を育てにくいようです。P(d)の発想に凝り
固まったの人はプッシュ型でデータを送り込んでない限り、「これらのシステム
間には関係が無く独立だ」などと考え、孤島システムを企画するようになり勝ちの
ように見受けられます。
私は、「虫歯とデータの不整合は、放っておいても直らない」といっています。
データに不整合があっては、強い戦いはできません。D(p)にしてはじめて、
広域のデータの整合性がとれるようになります。21世紀を生き残るために、
D(p)の表現方式の検討をお勧めします。