ＤＲｉ通信４９号「データからプロセスが見える」２０００．１０．１
オリンピックが終わって、本格的な秋になりましたが、みなさま元気にご活躍
のことかと思います。ポータル、ナレマレ、ＢＩ、コラボレイティブなど、相
変わらず新しい言葉が流行しています。シーズが多ければ多いほど、われわれ
はニーズと体力に合った賢明な選択が重要かと思います。
■データとプロセス
さて今月はデータとプロセスの関係についての認識や表現について考察します。
その粒度（Granularity、大きさ）については
（データ） （プロセス）
１ 属性 （加工データ） 加工データ導出ロジック
２ ファイルや画面・帳票 入出力プログラム
３ データベース や画面帳票群 システム（グループ）
のように３階層くらいを考えます。
■システム系処理と業務系処理
またその処理としては、システム系のものは除外し、業務系固有のものに限定
します。したがって、単なる「合計」、「在庫更新」、「追加」、「削除」、
「参照整合性チェック」など汎用的な処理は含みません。
＜注＞＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ちょっと分かり難いかと思いますので説明を追加します。たとえば
在庫ファイル ［品＃．倉庫＃］−（在庫数）
売掛けファイル［顧客＃］−（売掛￥）
があったとき、在庫数、売掛￥、いずれも在庫データですが、これらにそれぞれ
更新用のプログラムを作る必要があるでしょうか。弊社のTHeRepositoryでは、
これらが在庫データであること（データ機能コード＝ＮＮＩ）、およびその加工
元が、それぞれ入庫数量・出荷数量、あるいは出荷￥・入金￥であることを（正
確には対応する参照ＫＥＹとの関係とともに）定義することによって、「都度プ
ログラムを開発する必要はない」として設計されています。
在庫計算のロジックは新在庫量＝旧在庫量＋入庫量（出庫のときはマイナス）
のようなものを、THeEngine（弊社企画中のプログラムレスを指向するミドルウ
エア）に１回書けば処理できるからです。
すなわちこのプロセスは、ＯＳやＤＢＭＳ側のシステム系のプロセスとして扱われ、
ユーザとして考慮する必要がありません。エンティティの追加・削除や参照ＫＥＹの
制約などの処理も同様、システム系のプロセスとしてTHeEngineで処理されます。
＜／注＞＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
■データとプロセスの対応
粒度を適切に選ぶと、１個のプロセスは１個のデータを生成するものとして定義
できます。同じデータを生成するプロセスは複数ありえますが、一般には最適な
プロセスを１個選択します。これは成果物（ＷＨＡＴ）と最適処理（ＨＯＷ）の
関係ですから当然のことです。
一方、原料としてのデータとプロセスの関係は、一般に複数のデータが１個のプ
ロセスに必要とされます。したがってたとえば次のようになります。
（データ項目レベル） （画面・帳票レベル）
成果物 給与 受注画面
プロセス 給与計算ロジック 受注処理ロジック
原料 基本給 発注データ
残業時間 在庫データ
手当て 単価データ
これを概念ＤＢ構造図的に書くと次のようになります。
［生成データ］−［生成プロセス］ あるいは Ｄ−Ｐ
↓ ↓
［原料データ］ Ｄｉ（入力データ）
■データとプロセスの表現
ここで実際にデータとプロセスがどのように表現されているかを、代表的な表現
形式である、業務機能関連図とわれわれの推奨する概念ＤＢ構造図・ＩＰＦチャ
ートについて見てみます。
・業務機能関連図
名称は企業ごとにまちまちですが、システムの概要を示すために
［営業］→［経理］
↓↑ ↑
［生産］――・
のような表現が多用されています。この場合は［営業］や［経理］などは組織で
あると同時にその処理を表していますので、プロセスがノードとして明示的に、
またデータが矢線上に暗示的に表現されているのでＰ（ｄ）→Ｐ（ｄ）の形式と
言えます。
・概念ＤＢ構造図・ＩＰＦチャート
一方概念ＤＢ構造図やＩＰＦチャートでは、
［受注＃］→［出荷＃］→［検収＃］→［請求＃］→［入金＃］
―（・・） −（・・） −（・・） −（・・） −（・・）
のようにデータがノードとして明示され、プロセスが暗示的に扱われています。
すなわち矢線に生成プロセスが隠れている、Ｄ（ｐ）→Ｄ（ｐ）の形式です
■メリットとデメリット
業務機能関連図は、組織との関連があり、ユーザにとって分かりやすいため、
抵抗無く受け入れられるメリットがあります。しかしそのプロセスにどのような
下位のプロセスが含まれるか、矢線上にどのようなデータが流れるか、が明示
されないため各人勝手に想像するしかありません。
そこでこれを何回層にもブレークダウンすることになりますが、プロセスに着目
してブレークダウンを試みるために個人差が出やすく、工数の割にコミュニケー
ションの効果が上がらない傾向がみられます。
データ側を明示する概念ＤＢ構造図やＩＰＦチャートでは、客観的に切り出された
概念ファイル（エンティティ）や画面・帳票が明示され、ユーザ要件の共有が進みます。
入力画面帳票（および概念ＤＢ構造図上のエンティティやサブタイプ）は入力プ
ロセスに、加工データは加工処理プログラムに、出力画面・帳票は出力プロセス
に対応しますので、更なるブレークダウンなしに詳細が見え、開発ボリュームも
かなりの精度で見積もることができます。
ユーザ要件は画面・帳票すなわちデータとして与えられます。またシステムの統
合はインターフェースデータの共有・標準化によって実現されます。したがって、
これらを明示するＤ（ｐ）の図や表の方がはるかに生産性が高いといえます。
Ｐ（ｄ）の図を用いていると、どうしても機能分割的発想になり、プロセス中心に、
データも成果物側というより、原料側のデータとの関係を重視するようになります。
原料側のデータはプロセスを介さず、（生産管理の部品展開と同様）成果物データ
と直接関係させて考えればよいはずです。
Ｐ（ｄ）の発想は、プログラムとプログラムをワークファイルで繋ぐ発想になり、
共通の通信場としてのＤＢの認識を育てにくいようです。Ｐ（ｄ）の発想に凝り
固まったの人はプッシュ型でデータを送り込んでない限り、「これらのシステム
間には関係が無く独立だ」などと考え、孤島システムを企画するようになり勝ちの
ように見受けられます。
私は、「虫歯とデータの不整合は、放っておいても直らない」といっています。
データに不整合があっては、強い戦いはできません。Ｄ（ｐ）にしてはじめて、
広域のデータの整合性がとれるようになります。２１世紀を生き残るために、
Ｄ（ｐ）の表現方式の検討をお勧めします。
« 【第48号】リポジトリと方法論【第50号】要件定義の品質保証 »
