「目次」の良し悪しが、すべてのマニュアルの良し悪しを決める：誰にでも分かるSEのための文章術（13）（2/2 ページ）

マニュアル構成：操作マニュアル編

システムの「起動」「終了」を最初に記述

　「操作マニュアル」には、各機能の使い方や操作手順のほかに、システムの起動手順や終了手順を記述します。「起動」「終了」手順を続けて記述することが理想です。

機能の全体像を示す

　システムの起動と終了手順を書いたら、さあ各機能の説明……とはいきません。その前に、システムが備える機能の全体像が分かるように、「機能一覧とその概要」を記述します。この機能一覧は、目次に対応した表現でなければなりません。次のようにします。

• 機能の名称は同じものを使う
• 一覧における記述順序は目次の順序と一致させる
• 機能の構成（上位の機能から下位の機能への階層構成）は目次構成と一致させる

機能操作の構成は「階層構造」に

　いよいよ、機能操作の説明です。操作マニュアルの目次は、顧客が「この機能の操作法を知りたい」と考えたとき、すぐに所望のページが開けねばなりません。そのため、操作方法は「階層構造」にします（第3回「分かりやすい提案書はアウトラインが美しい」参照）。

　ただし、この階層構造は「機能」の観点からではなく、「顧客」の観点からの構成である必要があります。そこで、業務の流れや顧客が行う作業、仕事の手順などをベースに、各機能を関連・関係づけて階層構成にします。

　下記の例は、カルチャーセンターにおける会員や講座、講師などの情報を管理するシステムのマニュアル構成（一部）です。機能の観点から構成すると I のようになりますが、顧客の観点から構成すると II のようになります。II の方が、顧客にとって使いやすいマニュアルです。

マニュアル構成：業務マニュアル編

業務フローを構成項目にする

　「業務マニュアル」は、業務作業の手順に沿って、どこでどの機能を使用するか顧客に伝えるものです。そのため、業務マニュアルは1つひとつの業務で区分した構成にします。実際には、「要件定義書」の「システム導入後の業務フロー」で定義した1つひとつの業務フローを構成項目にします。

担当者ごとに作業を分解する

　ただし、1つの業務作業に異なる部門の担当者が関与する場合は、注意が必要です。例えば、担当者間で作業を受け渡しながら業務を進めていく場合、担当者間の作業のコラボレーションで一連の業務を完了させる場合などが考えられます。

　上記の場合で1つの業務を構成項目とすると、マニュアルは複数名の担当者がやる作業を含むことになります。すると、担当でない作業の説明にも目を通す面倒が顧客側に発生します。

　そこで、異なる部門の担当者がかかわる業務については、担当者ごとの作業に分解し、それぞれの作業を業務の下位項目として構成します。Iのように、単純に業務を項目にした構成にするのではなく、II のような階層構成にしましょう。ただし、顧客にとって、業務全体の作業の流れを概観することは重要なことです。そこで、IIの場合、まず「1. 受注業務」において受注業務全体の流れを示すとよいでしょう。

マニュアル構成：障害対応マニュアル編

マニュアルの「柱」は「障害状況」

　「障害対応マニュアル」は、障害の状況から対応策を見つけ出せる構造にします。理由は、障害発生時に顧客に見えているものが「発生している障害状況」だけだからです。I のように抽象的な文言にするのではなく、II のように実際のエラーメッセージなどをしっかり記述します。

操作マニュアルと対応させる

　障害は、必ず顧客が何らかの機能を使っているときに発生します。顧客は「この機能を使用しているときに発生した障害の対応法を知りたい」と考えるでしょう。

　そこで、障害対応マニュアルの構成は、操作マニュアルで「機能」について書いた階層構成と対応させます。機能ごとの障害状況を基軸として、対応策を記述します。

　I は「原因の種類」を項目とした構成ですが、これでは欲しい情報にたどり着けません。そのため、II のように「機能」を項目とした構成にします。

　同じ障害が、複数の機能で発生する場合はどうすればよいでしょうか。このような障害については、発生する可能性のある機能すべてで、障害状況と対応法を記述するとよいでしょう。エンジニアにとって「同じ障害」と見えても、顧客は異なる機能で生じた障害はそれぞれ異なる障害とみなすからです。