» 【第8号】実装独立のプロセスモデル

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第8号】実装独立のプロセスモデル

DRI通信 8号 「実装独立のプロセスモデル」    1997.5.1
情報は、直接対話や電話によっても伝達されるが、企業の基幹業務にかかわる情
報は基本的に画面・帳票(IO)によって伝達される。DBはこの本質を写した
ものでこれによって非同期で、かつ公共の通信が可能になる。画面・帳票は独
自の物理的制約を持っている。しかしこれは伝達される本質的な内容ではない。
これを除いた本質的な内容が情報であり、画面・帳票の論理的部分として伝達さ
れる。
画面・帳票における、A4かB5か、フォントは何か、1ページに収まるか2ペ
ージになるか、紙か画面か、さらに「これはペンです」か “This is a pen.”か、な
どの違いは、物理的部分であり、論理的部分との区別はさほど難しくない。とこ
ろがプロセスにおける物理と論理/概念の区別は一般にあまり明快でない。


プロセスはその表現にもとづいて、次の2つのレベルに分けて考えられる。
  ・IOからIOが作られる業務プロセスレベル
  ・データからデータが作られる業務(データプロセス)レベル
・は、加工データやチェックデータの導出にかかわるものであり、まだRDBの
テーブルなど、物理レベルに落としてから考えるものと思い込んでいる人も少な
くないが、PLAN−DBにおいては、すでに概念レベルの処理としてSPFチ
ャートによって記述されている。これは本来サーバーがデータ管理の一貫として
行うべき処理である。そしてこのときは、クライアント処理は必要なデータをD
Bから収集し編集するだけで、新しいデータは作らなくてよい。
・は本号の主題であるが、「だれが、いつ、どのような条件が整ったとき、どの
ような目的で、どのようなIOを、生成するか」を記述するものである。PLA
N−PROCのIPFチャートがこれに対応しており、論理レベルの記述、特に
IO(情報システムの製品/目的)の位置付けの明示を主目的としている。しか
しプロセスにおける物理と論理の区別に関する理解に不備があり、かつては若干
物理的内容を記述する場合があった。
ひとつはIOの送付の記述である。「だれが」はIOを生成する論理組織単位
(設計係、購買係、発注先/メーカー、コンピュータ/DBなど抽象的組織)を、
また「どのような目的で」はIOを受け取り活用する論理組織単位を記述するこ
とによって表現するが、たとえば注文書を送るにあたり、送付先として、発注先
を直接指定せずまづ社内送付係を記述するなど、IOを直接活用しない論理組織
単位を記述することがあった。厳密には郵便か宅急便かFAXかなどの記述を書
きたい場合もあり、どこまで書くかの基準が必要である。
電話においては、われわれは信号が海底ケーブル経由か通信衛星経由かは意識し
ない。物理的実現手段は隠蔽し、始点と終点の論理的仕様だけを問題にする。そ
こでIOの送付においても、最終的ユーザのみを意識し、経由など、送付方式の
詳細は物理仕様として隠蔽するものとした。
たしかにIO送付方式も、BPRのテーマとなりうる重要な課題であるが、パフォ
ーマンスの観点がからむ(これは物理仕様の特徴)ので、ユーザの情報要求を位
置付ける局面とは分けて検討すべきと考えたのである。通信に関しては技術革新
が激しい。IOの送付方式はこの影響を受けやすい。これを物理仕様として隠蔽
することによって、業務プロセスの記述を安定させ、保守の負荷を軽減させるこ
とができる。
また業務プロセスレベルにおいては、チェックや承認、これに基づく差し戻しを
どこまで書くかが問題になる。極端にいえば、すべての業務でチェックと差し戻
しが発生しうる。これをどこまでが論理的ユーザニーズで、どこからが物理的詳
細かと切分けるのはやさしくない。結局「情報システムの製品であるIOを設計
するとき不可欠なチェック・差し戻しは書くが、そうでないものは書かない」も
のとした。この辺、DOAにおけるプロセス表現の特徴が出ているかと思う。
データ分析においては、サブタイプやサブストラクチャーをどこまで書くかが、
そのときの目的や設計者のセンスに依存する。同様にこの基準も、適用の際、業
務プロセス設計者の判断を要する。しかしこれによって必要以上に複雑な成果物
を作り、工数を無駄遣いすることを防ぐなど、実用的には十分有効なものと思わ
れる。
承認前のIOと承認後のIOで扱いが異なり、これを意識し明示するときは、状
態コードの値が上がると考えられる。このときはリポジトリにこれを反映する都
合上別IO番号をとるものとした。はんこ一つで別IOとするのである。
IOはコンピュータか人かは別として、ある業務によってつくられる。原理的に
1個のIOに1個の固有の業務が対応づけられる。システムの他の要素と直接関
係するのはIOであり、これをつくる業務ではない。したがって業務プロセスの
記述としては、
  IO:What、論理
  業務:How、物理
として、業務の記述を省略することができる。なおこれが業務アプリケーション
のオブジェクト指向適用の形ではないかと私は考える。
IPFチャートは、基本的にはDFDや事務フローチャートとほぼ同じレベルの
プロセスを扱っているといえるが、
  ・業務プロセスという単位を識別する
  ・論理/概念レベルを扱う
  ・業務は物理レベルとして隠蔽する
  ・IOはすべて記述する
  ・IO生成のための十分条件を明示する
  ・リポジトリと正確に対応づける
などを徹底し、必要かつ十分でメンテナンス性の高い簡潔な業務プロセスの記述
をねらっている。
なおツールについては、GUIで扱いやすいように、記法を改良したことも手伝
って、すでにTH図の書けるツールPolyで書くことができるが、リポジトリとの
連携は今後の課題となっている。
われわれは、データとプロセスをともに実装独立に記述することによって、品質
の高いビジネスモデルを作り、これをリポジトリにストアして、ソフトウエアは
これから生成する、さらにプログラムレスとするのがDOAの目指すべき方向と
考える。今回はこのため、プロセスの実装独立/概念/論理について述べた。概
念と物理の区分など、データ総研内部でも必ずしもコンセンサスが得られた状態
ではないが、なんらかの参考にしていただければと思う。また便乗して若干IP
Fチャートの宣伝をすることになったが、乞ご勘弁。
                          データ総研 椿 正明