« 「お風呂本」は気宇壮大をもってよしとす | トップページ | 業務マニュアルのデータモデル »

2006.04.22

業務マニュアルの作り方

業務マニュアルをまとめるのは想像以上にやっかいな仕事である。とくに、コンピュータを用いて進める業務の場合、パネルや帳票(これらを合わせて入出力フォームと呼んでおく)の使い方を盛り込む必要があるのでややこしい。仕事の手順の軸、入出力フォームに関する説明の軸、および各手順における入出力フォームの使い方の軸とが複雑に交錯する。コンピュータ上の業務システムの仕様を巻き込んで周到に構造化しない限り、使いやすく保守しやすい業務マニュアルは生まれない。

◆業務フローと業務マニュアル

 そもそも業務マニュアルとは何か。それはいわゆる「業務フロー」とはどう違うのか。まず、筆者が提唱する三要素分析法での、業務フローと業務マニュアルの位置づけを確認しておく。データフローダイアグラム(DFD)で描かれた業務フローには、いくつかの「業務プロセス(個々の仕事の単位のこと)」が載っているが、それぞれの業務プロセスのあり方を個別に説明したものが業務マニュアルである。つまり、業務マニュアルとは要するに「個々の仕事の仕様書」に他ならない。

 いっぽう、「業務フロー」はいくつかの仕事の「連係」を図式化したものだ。ただし、DFDで描いた業務フローには連係にともなう「ロジック」は示されない。そこでは、「帳簿」や「伝票」や「倉庫」といったストレージ(保管媒体)を介したプロセス間の連係様式、および、個々の仕事が起動されるべききっかけである「イベント」が示されるだけだ。

Jobflow_1

 各担当者が仕事を遂行するためには、この業務フローではあきらかに情報が足りない。しかし、「仕事の担当者」ではなく「業務プロセスの改善責任者」にとってはこれで充分なのである。なぜなら、業務フローというものが、さまざまな部署の人々がどのように連係して仕事を進めてゆくかを示す図面だからだ。

 いっぽう個々の仕事の担当者にとっては、他の担当者がどんな仕事をやっているかとか、自分の仕事が他の仕事とどう連係しているかは本来はわからなくてもいい。それがわからなければ自分の仕事を遂行できないとしたら、業務設計上もコンプライアンス上も不適切である。ゆえに、個々の担当者にとっては「業務フロー」は不要で(あっても邪魔にはならないが)、個々の仕事向けにまとめられた「業務マニュアル」、すなわち「個々の業務プロセスの仕様書」が必要になる。

 おわかりだろうか。業務フローは「業務プロセスの改善責任者」のための図面で、業務マニュアルは「個々の仕事の担当者(業務担当者)」のための図面なのである。

◆業務マニュアルの構成要素

 では、業務マニュアルとは具体的にどんなものなのだろう。三要素分析法では、個々の業務プロセス向けにまとめられた1個の業務マニュアルには以下の要素が含まれる。

・仕事の手順
・入出力フォームの説明
・入出力フォームの使い方

 「仕事の手順」とは「□□□□ならば、○○○○を△△△△△する」の形でまとめられる個々の「アクション」を「連接」、「分岐」、「繰り返し」の基本ロジックで構造化したものだ。その内容は有名なロジック表記図法である「フローチャート」を用いて正確に表せる。しかし、フローチャートよりも筆者が「アクションツリー」と読んでいる次の図法のほうがユーザにはウケがよい。ふたたびXEADでの例を示す。

Manual

 ひとつの仕事にはいくつかの「アクション」が含まれる。そして、それぞれの「アクション」において、担当者はひとつか複数の「入出力フォーム」を用いる。「入出力フォーム」を使うためには、事前に用意された「入出力フォームの説明」が必要になる。その情報は、ようするにプログラム仕様書に含まれる「入出力設計」に相当する。そこでは、どこにどんなボタンがあって何をどうすれば何が起こるかがイメージ付きで説明されている。業務マニュアル上では、利用される「入出力フォーム」毎にその情報が示されなければいけない。

 やっかいなことに、個々の「入出力フォーム」は単一の業務でのみ利用されるとは限らない。いくつもの業務で利用されるプログラムはいくらでも存在する。ということは、「入出力フォームの説明」がプログラム毎に固有な情報であるいっぽう、「入出力フォームの使い方」はプログラムと業務との組み合わせ毎に定まる情報であるということだ。「入出力フォームの説明」と「入出力フォームの使い方」とは似て非なる要素で、業務マニュアル上では明確に区別されなければならない。

◆業務マニュアルを印刷するのは非効率

 上述した3つの要素の関係をまとめてみよう。ひとつの業務マニュアルには、複数の「アクション」で構成された「仕事の手順」が示される。そして、それぞれのアクションには、それを遂行するために用いるべき入出力フォームが複数対応する。それぞれの入出力フォームには「説明」と「使い方」がひとつずつ対応する。たとえば次のようになる。

 <1>○○担当者XX業務マニュアル

 (1)まず、○○○○を△△△△△する
   ○○担当者メニューから、オプションAを選択する。
   表示されたパネルA1でどやこやすると、パネルB1
   が現れるのでそこでどやこやする。...

       (パネルA1とB1の説明とキャプチャーイメージ)

 (2)次に、□□□□を☆☆☆☆☆する
   ○○担当者メニューから、オプションCを選択する。
   表示されたパネルC1でどやこやすると、パネルD1
   が現れるのでそこでどやこやする。...

       (パネルC1とD1の説明とキャプチャーイメージ)

 上記のような内容を含む業務マニュアルのまとまりを印刷することを考える。上述したように「入出力フォームの説明」には文章だけでなくフォームのイメージも含まれるため、印刷すればそれだけで1ページを軽くとってしまう。上記の例では「アクション」は2つだけだが、これが増えてゆくとページ数はどんどん増えてゆく。

 業務マニュアルの内容は業務プロセスの設計者や業務担当者自身によって改善されてゆく。また、入出力フォームもさまざまな理由で仕様が変わる。そのことを考えても、業務マニュアルをいちいち印刷して利用するのは非効率すぎる。システムの設計情報といっしょにサーバ上に置いて一元管理しながら、最新のものをいつでも手元のPCからダイナミックに参照できるようにしたほうがよい。

◆業務マニュアルの作成は設計者の仕事

 三要素分析法向けのモデリングツールであるXEADにおいて、業務マニュアルはデータモデルや業務フローといったさまざまな基本設計情報の一部として位置づけられている。したがって、XEADのコンテンツファイルをイントラネットのWEBサーバに置くだけで、各クライアントで業務マニュアルとしてブラウズできるようになっている。ゆえに、XEADを用いている開発プロジェクトにとって「業務マニュアルの作成」は片手間にやれる単純作業でしかない。

 言い方を変えると、システムの基本設計作業が完了した時点で、業務マニュアルも出来上がっていなければいけない。考えてみればあたりまえのことで、使い方が明らかでないシステムの仕様の正しさなんて誰も言えるわけがない。筆者自身、恥ずかしながら昔は「我々はプログラムとデータベースを作るので、業務マニュアはそちらで作ってください」とエンドユーザに依頼していたものだ。しかし今では、少なくとも初版の業務マニュアルの作成は、データモデリングや入出力フォームのデザインと同様、基本設計担当者の仕事だと考えている。

<本ブログでの関連記事>
「Ajaxで業務マニュアルサーバ」
メニューは「権限のインタフェース」である
「業務マニュアル」と「操作マニュアル」の違い

|

« 「お風呂本」は気宇壮大をもってよしとす | トップページ | 業務マニュアルのデータモデル »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 業務マニュアルの作り方:

« 「お風呂本」は気宇壮大をもってよしとす | トップページ | 業務マニュアルのデータモデル »