» 【153号】 IPFチャートの設計条件

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

■IPFチャートの成り立ち
IPF(Information Process Flow)チャートは、弊社が標準としている業務フ
ローチャートです。古くはDFD、UMLのアクティビティ図、最近話題のBP
MNとほぼ同じ粒度の業務プロセスを記述する図といえます。

1977年、私が情報処理学会で発表し、1982年顧客プロジェクトで使用した
のが始まりです。後GUIツールの実用化にあわせ、表記ルールの改定を行い
ました。現在はIPFモデラーとして、ツールが用意されています。

■設計条件
その設計条件は、次の7つにまとめられるかと思います。
①縦軸に組織を、横軸に時間をとり、この2次元平面に、対象とするアプ
 リケーションで生成/送付される全画面・帳票(IO)を配置する。
②組織としては「営業1部」、「製造2課」などではなく、抽象化して
 「販売担当」、「生産計画担当」など役割を明示したものとして定義する。これ
 を論理組織(LS:Logical Section)と呼び、図では横長のレーンを割り付ける。
③論理組織のひとつとしてシステム/DBを位置づける。
④業務(TK:Task)とは、1個の論理組織が、同時に生成される1個以上のIOを
 生成する処理として定義する。
⑤IOはこれを必要とする論理組織に送信され、受領される。受領されたIOの情報
 は記憶され、以後(右方で)随時活用可能となる。なおこのIOが品物やお金の送り
 状の場合、これらを抽象化し、■や●を添付して表現することができる。
⑥この受領がトリガーとなって即、次の業務を起動する場合と、後に活用するために
 IOがストアされ、流れを中断する場合がある。
⑦したがってIPFチャートには、4要素「トリガー、業務、IO、送信」が、繰り
 返し現れる。この場合、トリガーとIOはノードで、また業務は横線、送信は縦線
 として表す。落着するまでの4要素の連鎖を業務プロセス(TP:Task Process)、
 先頭のトリガーを業務プロセス(TP)トリガーと呼ぶ。

①はビジネスシステムを駆動する主役はIOであり、これを誰が何時作り、誰
が使うかを示すことによって、ビジネスの骨格を明示するものです。Inputとは、
入庫や受注など「実世界に発生した情報」や、何をどこにどれだけ発注するか、
何をどれだけ生産するかなどの「意思決定データ」をDBに反映するもの、また
Outputとは、これらの意思決定のために、受注の「現状や傾向」などをDBから
取り出すものです。これらIOの生成や活用が、ビジネスの骨格を形成すると考
えます。

②は、物理的な組織は変化するが、その役割は安定しているはず、保守の手間
を少なくしつつ、より本質的なビジネス実態を表現するためです。

③は、「ビジネスシステムにおいて発生した情報は必ずDBにストアすべき、
これによってDBがビジネスの実態を反映するものになるはず、DBに聞けば最
も速く安く正確なビジネスの実態がわかる。皆でDBをメンテしよう」という考
えからです。IPFチャートは処理を記述しているわけですが、これによって、
「システムはDB中心に考えるべき」というDOAの思想を刷り込もうとしてい
ます。なおDBは概念/仮想レベルでよく、またローカル、セントラルなどと分
離され、これを表現したいときはレーンを分けて書きます。

④は、成果物によって業務を定義し、その大きさ/粒度を固定するためです。
IOとして成果物名称を書きますので、業務の名称は一般に書きません。業務は
その成果物であるIOとこれを構成するデータによって把握できると考えます。
その意味ではきわめてDOA的な業務フロー図と言えます。業務フロー図に個人
差が出て品質低下・コミュニケーションミスが発生する原因のひとつは、業務の
大きさ/粒度がぶれるからだと考えます。営業業務、経理業務などといった大き
な業務をトップダウン的/POA的に分割して行った場合、OO業務、XX業務
と処理の名称は列挙されてくるのですが、往々にしてその成果物が明示されず、
また過大あるいは過小などあいまいさが残り、結果としてデータモデリングとの
連携を難しくするので注意が必要です。

⑤によって、一般に、特に記述がなくてもIOの目的の大半が読み取れます。
AsIsのIPFチャートにおいて、受領したIOが以後(図の右方で)使用さ
れていないため、この送信を止めたことがありました。またToBeのデータモ
デルを作るとき、関係者でIOの目的を共有することが非常に重要になりますが、
IOをIPFチャート上に記述することによってこれが容易になります。

⑥は、たとえば顧客受注をトリガーにして即DBへの登録や引当業務を起動す
るか、一旦受け止めるにとどめ、別途スケジュールに基づいてこれらの業務を遂
行するか、など処理の緊急度を書き分けようとするものです。こうして、業務担
当者の仕事の進め方を記述することになります。

⑦の業務プロセスは、処理単位を客観的に設定する、方法論PRIDEのサブ
システム概念を拡張した、他の業務フローには見られない独特のものと思われま
す。これはプロセス部品の情報資源管理に、活用することができます。1単位の
業務プロセスを切り出すための、業務プロセストリガーには、次の3種類があり
ます。
 ・カレンダートリガー:毎日10時、毎月25日など
 ・系外IOトリガー :顧客からの注文、納品など
 ・進行状態トリガー :RFP発行、成約など(プロジェクト業務に多い)

以上のように個人差の出ない客観的な業務フロー図の作成を目指しているわけで
すが、プロセスの定型的把握には、限界があるように思われます。これを少しで
も緩和するために次のような配慮を行います。
 ・LS(論理組織)の粒度およびその配列順序は、関係者で協議し、当該
  IPF図において8個以内に収める。
 ・ データモデルのサブタイプ対応の変形を一括して、その業務を書くとI
  PFチャートに分岐が発生し読みにくい。しかし、変形別に書くと別の
  IPFチャートに同じ業務プロセスが冗長に登場することになる。これには
  決め手がないので、関係者の裁量に任せる。
これでも万全とはなりませんが、読むのに支障はなく、またシステムに不整合を
生む原因ともならないようです。

■作成手順
実際の作り方としては、おおむね次のような順序になるかと思われます。
 S1.現在使用されている値の記入されたIOサンプルを集める。
 S2.これを生成順に並べる。
 S3.これを生成・使用する論理組織を調べ、これを適切な粒度に整理し、順序
    付けする。その厳密な基準は無いが、一般に管理者、作業者、社外として
    支障がないようである。
 S4.論理組織をレーンとするIPFチャートの台紙を作り、最上部はDBとし、
    以下S3で決めた論理組織の順にレーンを割り付ける。
 S5.S1で集めたIOを台紙上に配置する。
 S6.IOごとに、その生成トリガーおよびその送信先を調べ、これらを結んでいく。
    当初のIOに抜け漏れがあっても、ここでほとんどが見つかるはずである。
 S7.これで現状のIPFができるが、関係者全員で共有し、現状業務プロセスの問題
    点および改善点をIPFチャート上で確認する。コード体系などデータに関する
    問題はIPFチャートには出にくいが、これは別途問題点/要件定義として記録する。
 S8.必要な論理組織の改廃やIOの改廃、またIO内容の変更によって、新規のIPF
    チャートを作成する。

こうしてToBeのIPFチャートが、一般にはユーザ部門関係者と開発担当関
係者によって、作られるわけですが、DB中心の業務フロー図を共有することに
よるコミュニケーションは、以後非常に大きな効果を発揮するものと思われます。
IO設計の要は、そこに登場すべきデータ項目ですが、この品質はDBの品質に
直結し、手戻りの少ない開発につながるものと思われます。

IPFチャートで書く業務プロセスおよび業務は、処理の中核を作る2つのレベ
ルですが、この上位には業務ドメイン(BD:Business Domain)、および業務
システム(SY:System)があり、これはWBS(Work Breakdown Structure)
として、EXCELなどにより記述するものとしています。また、IOを構成す
るIOデータは、データモデリングの結果得られる属性と連携し、プロセスの世
界とデータの世界をつなぐものになります。

■新入社員教育での活用
なお、私は「IPFチャートの作成を新入社員に担当させる提案をしたい」と考
えています。多くの会社は会社業務を説明できるIPFチャートを用意していま
せん。そこでこれを新入社員に作らせ整備しながら、自社の業務を理解させるわ
けです。3―5人くらいのチームに業務領域を分担させ、発表会を開くと、「会
社の仕事を早くやってみたい」と思っている新人からはかなりの盛り上がりが期
待できると思います。ユーザ部門に配属される人とシステム部門に配属される人
が、一緒に現行のIOサンプルをもとに作業し、DB中心/会社中心の世界観を
持つことで、後々大きなリターンが期待できると考えます。従来の「システム部
門に配属し、まずはプログラムの保守をしながらプログラム言語を覚える」とい
う進め方とは、大きな差が生まれるのではないでしょうか。

IPFチャートは、WBSと並んでビジネスシステムドキュメントのひとつです
が、人間系のためのドキュメントであるため、ついメンテが遅れ、現状と合わな
くなる心配があります。原因は、メンテの担当やトリガーが設定されていないた
めと思われます。このような場合は、新入社員受入という、1/Y(年1回)の
カレンダートリガーを活用するのが妙案と考えます。「実データの記載されたI
Oサンプル一式を綴じたキングファイルを横に、IPFチャートを見ていけば、
会社業務はいつでも分かる」という体制は、メンテや新人教育のほかいろいろな
局面で活用できるのではないでしょうか。