« 業務マニュアルの作り方 | トップページ | 機能モデルのデータモデル »

2006.04.30

業務マニュアルのデータモデル

 前回説明したように、業務マニュアルはさまざまな情報が複合してできている。それをRDBやXMLといったストア形式で維持したいのであれば、事前に業務マニュアルをデータモデリングしておく必要がある。

 XEADは、データモデル(基本設計レベルのテーブル定義書)、機能モデル(基本設計レベルのプログラム仕様書)、業務モデル(基本設計レベルの業務マニュアル)といった「業務システムの3要素」を管理するためのシステム設計支援ツールである。したがって、このツールで編集したコンテンツデータは「データモデルのデータモデル」、「機能モデルのデータモデル」、「業務モデルのデータモデル」にもとづいて構造化されている。今回は前回のエントリーに関連して「業務モデルのデータモデル」を説明しよう。(参考記事「データモデルのデータモデル」)

◆「職務」と「業務」

 「職務」とは「営業担当者」や「物流担当者」といった、職場での「役割(role)」のことだ。ひとつの職務にはいくつかの「業務」を担当する権限が与えられていて、職務を遂行するための規定の能力が求められる。それぞれの職務はいずれかの部署に所属することが多いが、「本社営業部」と「大阪営業部」とで同一の職務が割り当てられる、などということもある。ひとりの社員がひとつ、または複数の職務を担当する。

 「業務」は、いずれかの職務を帯びた職員によって実施される「仕事の単位(task)」である。例としては「注文受付」や「月末請求締め」などいろいろある。それぞれの業務は、何らかのきっかけで始められ、それを「イベント」と呼ぶ。「毎週月曜の11時になった」とか「月末締め日」とか「注文書を受け取った」などが代表的なイベントの例だ。

 データモデルを示す。インスタンスを併記した部分に注目。

Image1

◆「業務プロトコル」と「アクション」

 上述したように、業務は何らかのイベントをきっかけとして始まり、ひとつか複数の「手順(アクション)」が実行される。「アクション」とは「…ならば、…を…する」で表される行為の1単位に相当する。

 前回のエントリーでも説明したように、アクションは「連接」、「分岐」、「繰り返し」の基本ロジックで構造化される。そのまとまりのことをXEADでは「プロトコル(規定手順)」と呼んでいる。

 同様に、モデルにインスタンスを示す。アクションを構造化するための基本ロジックは、XEADでは「アクションツリー」というロジック表記形式をとるため、各アクションの「実行条件」、「実行順序」、「インデントレベル」の組み合わせとして表現される。

Image2

◆「アクション」と「入出力フォーム」

 「アクション」を実行するためにはしばしば「道具立て」が必要になる。事務仕事の現場では、ゼロ、またはひとつか複数の「入出力フォーム」が利用される。「入出力フォーム」とは要するにPCのパネルや伝票等の印刷物のことで、これらは「機能定義」の一部を構成する。入出力フォームの「使い方」には、フォームそのものの仕様情報と、特定のアクションにおける使い方の2つの異なる次元がある。機能定義から継承される情報は前者だ。

 これもしつこくインスタンスで確認してほしい。「機能」のテーブルの先にはもっと関連が広がっているのだが、ここでは省略されている。

Image3

 以上のデータモデルにもとづいて、XEADのコンテンツファイル中で業務マニュアル情報が保持されている(ストア形式としてはRDBでもよかったのだが「XEADのXは、XMLのX」で説明した理由でXMLとしてある)。XEAD以外のモジュールからコンテンツを参照するのも簡単だ。じっさい、5月のバージョンアップの際にXEADにバンドルされるAjaxモジュール「業務マニュアルブラウザForXEAD」も、「業務マニュアルのデータモデル」が明快だったので開発は容易だった。

 なお、入出力フォームは機能定義の一部でもあると説明したが、「機能」はパネルや印刷スプールといった入出力の他に、「テーブル」との入出力を持つ。そのあり方を三要素分析法では「機能モデル」と呼ぶが、「機能モデルのデータモデル」については次回に説明しよう。

|

« 業務マニュアルの作り方 | トップページ | 機能モデルのデータモデル »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 業務マニュアルのデータモデル:

« 業務マニュアルの作り方 | トップページ | 機能モデルのデータモデル »