« MIDIソフト「ソルファノート」公開 | トップページ | 複数の視点で描かれた図面同士の牽制が重要 »

2005.10.15

業務単位は「疎結合」されている

 業務のあり方には「ロジックで制御される性質」と「イベントで駆動される性質」とが混在している。しかしこれらは業務の記述を階層化することで、別個の性質として取り扱える。階層化せずに記述すれば、それらの性質が渾然一体となってわかりにくくなるか、職場の実態を表さないものになってしまう。

◆ロジック制御とイベントドリブン

 朝起きて顔を洗う。それを「眠りにつく」に後続する活動と考えれば、「活動が実施される順序」を表す矢印を用いて次のように表記できる。何も問題はなさそうだ。

 眠りにつく → 起きて顔を洗う

 では、業務システムに含まれる活動として、「受注」と「出荷」を例にして同様のことを考えてみる。「受注してから出荷する」と言って間違いではないので、次のように表記できそうに思える。

 受注する → 出荷する

 しかし、現実にはほとんどの受注・出荷活動はこのような「ロジック」で制御されているわけではない。誰かが新規受注を登録したかどうかに関係なく、出荷作業の担当者は固有のルール(15時になったら実施することになっている、等)にもとづいて出荷作業を始める。受注情報が記録されているストレージ(データやモノを保管しておく場所のこと)を覗いて、出荷対象の受注があれば出荷するし、なければそのまま出荷業務が終わる。受注業務も、何らかの先行する活動に後続する形で実施されているのではなく、「注文書を受け取ったら行うことになっている」などといったルールに沿って実施されている。

 つまり、これらの業務はそのようなルールやストレージの工夫にもとづいて「分離されつつ連係」している、すなわち「疎結合」されている。業務の現場においては、順序の矢印などで安直に結合して示せる形にはなっていないのが実態だ。

 では、なぜそのような分離が生じるのか。それは、「担当する要員」と「処理される対象のバッチサイズ」が異なるからだ。注文を受けたまとまりで出荷作業や売上計上を行うやり方では、処理量が多いほど非効率になる。それぞれの作業で効率的になるような情報のバッチサイズを選んで、しかもそれぞれの作業の固有な事情に通じている要員やコンピュータに作業をまかせたほうが、全体としてはずっと効率的だ。

 そのような分業体制を実現するための制御の枠組みが「イベントドリブン」である。ここで言う「イベント」とは、「注文書を受け取った!」とか「15時になった!」とかいった「担当者の意思と関係なく勃発する事態」のことだ。イベントの勃発を認識できること(つまり「イベントリスナー」になれること)と、その認識にともなって規定の手順を実行できることが、担当者の能力要件となる。

◆イベントドリブンを表記するための図法

 ところが、業務分析においてイベントドリブンが意識されることはあまりない。業務フローの表記法は数あれど、イベントドリブンな業務のあり方を捉えられるようになっているものは少ない。本来はロジックを表記するための表記法である「フローチャート」に、担当部署を示す「スイムレーン」を組み込んだ昔ながらの表記法がいまだに幅をきかせている。

 そのような表記法を使うといろいろと都合の悪いことが起こる。イベントドリブンを業務分析の枠組みとして利用できるのは「受注業務」とか「出荷業務」といった粒度の問題を扱う階層においてである。もう一段階詳細なレベルに降りると、そこには「ロジック」で制御された「業務手順(プロトコル)」の世界が広がっている。ロジック主体の表記法を用いると、イベントドリブンな世界にロジックの世界のあり方を同居させた形になりがちだ。結果的に、業務単位が見えにくくなるし、これを分析する設計者に同時に多くのこと考える負担を強いることにもなる。

 これを避けるために筆者が提唱しているのが、「イベントドリブンなあり方を示すための図法」と「ロジック主導な図法」とを階層に応じて使い分けるやり方だ。イベントドリブンな階層については「データフローダイアグラム(DFD)」で表記する。DFDの上に置かれた業務単位(プロセス)には、それが起動されるべき「イベント」を書き添えるようにする。そして、プロセスの内部については「アクションツリー(フローチャートでもいいが、こちらのほうがユーザーにはなじみやすい)」で表記する。たとえば次のようになる。

image

 2種類の図の「矢印」の意味に注意してほしい。DFD上の矢印は「入出力の方向」を表している。いっぽう、プロセス毎の内部構造を表すアクションツリーにおける矢印は手順間の「ロジック」、すなわち「実行順序」や「条件分岐」を表している。2つの階層で扱われる要素はまったく異質で、これらを同一平面で扱うことのややこしさも理解できると思う。

 なおXEADでは、DFD上のプロセスを時系列に沿って「ぱらぱらマンガ」風にプレゼンテーションできるようになっている。イベントドリブンな階層なのだから、本来はプロセス間に時系列なんて存在しない。しかし、便宜上の時系列を持ち込んだほうが、業務体制を管理者に理解してもらう際にはずっと効果的なのだ(節操ないよね)。

|

« MIDIソフト「ソルファノート」公開 | トップページ | 複数の視点で描かれた図面同士の牽制が重要 »

コメント

私にDFDを説明してくれた人は、それをまるきりフローチャートのごとく説明してくれました。それゆえ、私にはDFDの必要性はまったくちんぷんかんぷんでしたが、この説明を見てやっと理解できた気がします。また、イベントドリブンなものの表記の説明も大変参考になりました。ありがとうございました。

投稿: kuro | 2005.10.20 18:03

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 業務単位は「疎結合」されている:

« MIDIソフト「ソルファノート」公開 | トップページ | 複数の視点で描かれた図面同士の牽制が重要 »