» 【第30号】IPFチャートの本質

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第30号】IPFチャートの本質

DRI通信30号 「IPFチャートの本質」      1999.3.1
今年は、決算は厳しいものを強いられていますが、気温の方は雪らしい雪も降ら
ず、氷らしい氷も張らず、おかげでコートなしで冬を越すことになりそうです。
気候とともに、景気の方の春が待たれます。
さて今回は、弊社ノウハウパッケージオープン化第一段(教育コースに限定)と
してPLAN-DBとともにオープン化されるPLAN-PROCの主題「IPFチャート」について
紹介させていただきます。


IPFとはInformation Process Flow の略称で、DFD(Data Flow Diagram)や事務フ
ローとほぼ同じレベルの処理を記述する図表現です。主題はIO(画面・帳票)で
その位置付けを明示するものです。われわれは「情報システムの目的は、ビジネ
スに役に立つIOを作ること」と考えますので、情報システムの製品の位置付け、
すなわち「どのようなIOを何時誰が作り誰に届けるか」は全員で共有すべき最も
基本的な事と考えます。
IPFチャートの原形は、椿が考案し、1977年に情報処理学会に発表し、1982年協和
発酵のプロジェクトではじめて本格的に適用いたしました。初めはもちろん手書
きでしたが、PC上でGUIが使えるようになり、これに適用しやすいよう、またリポ
ジトリへのマッピングがやさしいようにと若干の変更を行いました。
抜けや矛盾を議論するためのエンジニアリングドキュメントとして、IPFチャート
には原則として全てのIOが記述されます。保守の対象と考えられ、レビューの素
材となるために成果物に個人差の出ないことが要求されます。そのためしっかり
した文法を定めていますが、一般にその目的は厳密なIPFチャートを書くことでは
ありません。基本はIOリストを、作成・受領の担当者(論理組織)軸と時間軸の
2次元に展開するものであり、この場合は、その限りにおいて個人差のない正し
いものであれば良いと言えます。
IOは、IO番号や名称によって識別され、その詳細はIOイラストおよびIO項目定義
書によって記述されます。したがってIPFチャートとこれらIOに関するドキュメン
トによってクライアント側(ユーザ側)のビジネスモデルが記述されるというこ
とができます。
なおサーバー側(共用資源側)のビジネスモデルは、概念DB構造図とデータ項目
定義書(SPFチャートを含む)に記述され、クライアント側と合わせてビジネスモ
デル(実装独立の業務仕様)が完璧に記述されることになります。実際このうち
の主要ドキュメント、概念DB構造図およびIPFチャートがあれば相当精度の高い見
積りが可能になります。
最近リポジトリを用いたDOA開発プロジェクトのリポジトリメンテナンス記録を見
る機会がありましたが、その開発時のメンテナンス発生の原因の大部分が、新規
IO洗いだし不全によるもののようでした。作るべき製品が確定しないまま、ガン
トチャートにしたがって物理DB設計に入り、新しい製品が洗い出される都度リポ
ジトリのメンテナンスを続けているようでした。家に例えるならば、平面図が固
まらない内に工事に取りかかり手直しが多発するようなもので、難しいプロジェ
クトになっています。
「当初より徹底的にIOを洗い出すには」、この課題に応えるのがIPFチャートの本
質を活用する最大の用途かと思われます。このためにはIPFチャートを用いた全員
参加のレビュー会議が必須になるはずです。そしてこの新規IPFチャートを効率的
に作成するベースとして現状IPFチャートは作られるべきと考えました。
データ総研も、今までは方法論技術移転のコンサルテーションが主体だっため新
規IPFチャートにかかわる機会が少なく、レビューノウハウの蓄積は今後の課題に
なっています。ともすると詳細なワークフローの記述に用いるものと誤解して工
数や時間を浪費したり、またコンピュータのジョブフローをとりこんで、個人差
のある、ユーザに分かりにくいものを作ったりしていることもあるようです。こ
れらに対するガイドをきちんと行わなければなりません。
IPFチャートは、データ総研の提唱するDOAのベースとなるIOを固めるきわめて重
要なツールであり、またBPR検討に不可欠の素材と考えられます。トリガーやタイ
ミング条件を記述するのも、これを読みながらIOの抜けを発見したり、よりス
ムーズな業務運用を検討するためであります。DOAを前提に考案したものであり、
概念DB構造図と合わせて、多くの用途が開拓されてくるものと思われます。99
年度は5月25日(火)を初回としてこのIPFチャートを扱うPLAN-PROCのオープ
ン教育コースを開催いたします。是非前向きのご検討を賜わりたいと存じます。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
1999/03/19
DRI通信号外 「DRIのオープン化戦略」 1999.3.16
われわれDRIが、類例のないDOA(Data Oriented Approach) ないしデータモ
デリングの専門家集団として活動を始めてほぼ13年半を数えますが、DOAも
システム開発の方法論としてかなり認知されるようになってまいりました。
DOAはデータの標準化を行うものであり、結果としてインターフェースの標準
化を実現することになります。したがって、それが優れたものであれば、円滑な
データ流通を実現すべく、十分成熟した段階において――不用意なオープン化/
標準化はSQL3のような混乱を招きます――オープンにすべき必然性を持つも
のと考えられます。PLAN−DBを中核とするわれわれのDOA技法も、多く
のプロジェクトへの適用、ツール開発などを通じてかなりの完成度に到達し、そ
のオープン化を経営課題として、具体的に検討すべき段階に入ったと自覚するに
いたりました。
お断り:このDRI通信は、1996年10月以来毎月1回発信しております。
EMAILアドレスをいただいた方にとりあえず発信しておりますが、ご不要の方は遠
慮なくご連絡ください。すぐにストップいたします。またDRI通信バックナン
バーはホームページ(http://www.drinet.co.jp)に載せてありますのでご利用くだ
さい。(発行者:椿正明@データ総研mtsubaki@drinet.co.jp)
DOAが認知され、支持者は増えてまいりましたが、多くはいわばその第一世代
に留まっているように見受けられます。すなわち、かつてのVSAMや構造型
DBMSの代わりにRDBMSを用いるだけで、これらとプログラム/処理の関
係は、基本的に以前と変わらず、プログラムの1単位は依然として属人的なSE
の判断により設定されているのではないでしょうか。
われわれが、本来あるべきと考える第二世代のDOAとは、基幹系のデータベー
スにおいても情報系と同様、「必要な素材データはすべてデータベース――ただ
し正確には概念データベース――にあり、ユーザの情報要求はこれをアセンブル
することによってすべて満たすことができるアーキテクチャ」を実現するものと
言えます。このアーキテクチャでは処理(システム)は必ずデータベース経由コ
ミュニケートし、処理と処理とが直接データをやり取りすることはありません。
これをわれわれはBMHub (Business Model Hub) Architecture と呼ぼうとしてお
ります。
処理がn個あるとき、BMHub Architectureにおいては、インターフェースの数は
n個となりますが、処理と処理とが直接コミュニケートするアーキテクチャにお
いては、インターフェースの数はn(n−1)/2個になります。n=3ではど
ちらでも同じ3個ですが、n=10になると、前者では10個ですが、後者では
45個となります。初めはnが少なく、また一つ一つ追加されてくるため、さら
に一般には納期が限られるために、処理と処理とを直接、個別インターフェース
により接続したくなります。するといつのまにかインターフェースのスパゲッ
ティができ、容易には変更に対応できない、いわば「システムの肝硬変」を招来
することになります。BMHub Architectureは、この弊を免れ、全体システムを、
独立性の高い、できるだけ小さなサブシステムから構成しようとするものです。
このためには、二つの大きな条件、(1)実装独立と(2)データ先行の処理単
位識別が必要になります。これらについて簡単に述べてみましょう。
(1)実装独立
われわれは
ソフトウエア=ビジネスモデル*実装手段
すなわち、ソフトウエアをビジネスニーズの変化に対応して変えるべきビジネス
モデルと、ITの変化によって変えるべき実装手段に、完全に分離します。した
がって
情報システム≠ソフトウエア
=ビジネスモデル(業務仕様)
すなわち情報システムとはITに独立のユーザの世界のビジネスモデルそのもの
と考えます。これによってITの変化の影響を受けない情報流通の場BMHubが実現
されます。
これを支えるのは、実装独立のビジネスモデルと実装従属のソフトウエアモデル
の関連を記述するデータベース――21世紀の主役リポジトリ――です。BMHubに
よって、既存のレガシーシステム,ERPパッケージなど、個々の物理的システ
ムが接続されます。BMHubをねらった、ここまで実装独立を徹底したアプローチ
は、データ総研以外には見当たらないようです。
(2)データ先行の処理単位識別
第二世代DOAでは、まずエンティティ、データ項目、IOなどデータ部品を識
別し、次にこれを作る処理単位を識別します。データ部品は客観的に識別できま
すから、処理単位もSEのスキルなどによらず客観的に決めることができます。
データ部品は、情報システムの骨格を形成し、処理部品は肉付けとなります。
われわれはかねてより「ビジネスモデル(業務仕様)は、手順的なテキスト言語
によらずとも、原理的には静的な図面言語とテーブル言語――したがってリポジ
トリ――によって記述し尽くせるのではないか」と考えてきました。これが正し
ければ、基幹系においても、DWHと同様の意味において、業務仕様を記述した
プログラムを作らない「プログラムレス開発」が実現できることになります。
21世紀においては、BMHub経由コミュニケートする、いくつものアプリケーショ
ンパッケージ――既存レガシーアプリを含む――からなる物理システムを、アウ
トソーサーが運用し、ユーザはこれをWeb経由利用するものと思われます。
BMHubは、1社から関連企業数社へとスコープを広げ、安価で変更に強いSCM実
現の環境を用意するでしょう。
データ総研は、このようなBMHubを実現すべく、基礎技術を磨き成熟させオープン
化し普及しなければならない、これを経営戦略の中核として位置づけなければな
らないと考えています。BMHubは技術問題というより経営問題です。経営と情報の
距離はますます接近してまいります。これ以上欧米に離されたくありません。普
及に当たってはユーザ各位のご支援が不可欠です。ご支援よろしくお願いしま
す。
――――――――――――――――――――――――――――――――――
教育のオープン化
DOAシステム――DOAのビジネスモデル――はDOA人間が作ります。
DOA人間なしで、DOAシステムは作れず、運用・保守できません。決め手は
人であり、その教育には時間がかかります。
DOA人間はERPパッケージ導入時のギャップ分析で大活躍いたします。シス
テムがユーザニーズを満たしているかどうかは、ユーザのほしいデータがシステ
ムの提供しているデータと一致しているか否かを、データモデル上で確認しなけ
ればならないからです。またERPのデータと既存システムやアドオンのデータ
の接続法の検討にもDOA技法が不可欠です。
そこでオープン化の準備が整わないながらも、まずその第一弾として、データモ
デリング技法PLAN−DBおよび業務プロセス表現技法PLAN−PROCの
教育コース(出張教育コースあり)のオープン化(ライセンス契約不要)を実施
することにいたしました。21世紀対応として是非ご検討くださるようお願いい
たします。