設計者の発言

　「ユーザマニュアル」という言い方があるが、業務システム開発の文脈でこの表現は使わないほうがいい。「ユーザマニュアルを作りなさい」では、「操作マニュアルを作りなさい」なのか「業務マニュアルを作りなさい」なのか判然としないからだ。いずれも重要な設計要素ではあるが、内容も目的も異なっている。

　まず「操作マニュアル」とは、パネルやページの操作方法を説明したものだ。たとえば「パネルＡが表示されたなら、ボタンＢを押してください。するとデータが一覧されるので、一覧のいずれかを選択状態にしてエンターキーを押せば、続くパネルＣが表示されます」といった説明は「操作マニュアル」にありそうな記述だ。文章だけでなく、関連するスクリーンショットを伴うことが多い。

　いっぽう「業務マニュアル」とは、文字通り「個々の業務の説明書」のことである。ここで言う「業務」とは、「受注登録業務」や「出荷指示業務」や「実棚報告業務」といった、特定の担当者によって実施される一連の作業のまとまりのことだ(*1)。これらについて、個々に「どんな状況でそれを実施すべきか（起動イベント）」や「いかにそれを実施するか（プロトコル）」をまとめたものが「業務マニュアル」である。

　多くの事務作業はコンピュータ上のＵＩを用いながら実施される。それゆえ、たいていの業務マニュアルは、操作マニュアルが取り込まれた形でまとめられる。業務手順（プロトコル）はいくつかのアクションで構成されるが、それらのアクション毎に、ひとつか複数のパネル（機能）の操作マニュアルがリンクされる。

　ここで注意してほしいのは、業務マニュアルと操作マニュアルとが相互に関係しながらも独立した形で定義されている点だ。たとえばパネルＤの操作マニュアルは、業務Ａの業務マニュアルにも業務Ｂの業務マニュアルにも現れたりする。また業務Ａ向けの業務マニュアルには、パネルＤの操作マニュアルだけでなくパネルＦの操作マニュアルがリンクされていたりする。ようするに相互に「多対多」であって、両者は直交する定義要素である。

　これはつまり、「機能のあり方(*2)」や「業務のあり方」のいっぽうだけをまとめて眺めているだけでは、それが正しいかどうかわからないということだ。上述したように相互に組み合わせて破綻しないことまでを確認しないと、個々の要素の妥当性は見えてこない。

　じつは「機能のあり方」と「業務のあり方」の他にも摺りあわされるべき要素が存在する。業務システムが扱う「帳簿組織（データのあり方）」だ。これらの３要素を明らかにして、相互の整合性が検証されなければいけない。「マニュアル」は重要ではあっても、確立・検証されるべき設計要素のごく一部でしかないのである。（次の記事につづく）

*1.「業務」を遂行する主体は人間とは限らない。定時処理やＰ２Ｐの通信処理など、コンピュータによって実行される業務もある。人間が担当する業務では「対話型機能」が道具として用いられるが、コンピュータが担当する業務では「非対話型（バッチ型）機能」が用いられる。
*2.業務マニュアルとの兼ね合いにおいて問題にされるのは「機能のあり方」の中でも「ＵＩ」やその「使い方」が中心となるが、本来はそれらの他に機能の内部構造までが検討されていなければいけない。設計フェーズでこのとりまとめ作業を効率的に進めるためには、「機能の類型化」と「業務ロジックのＤＢ側への移行」の２点が鍵だ。