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

[谷口功，＠IT]

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

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

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

悪い例

1．システムの起動手順

2．機能Aの操作手順

3．機能Bの操作手順

9．機能Nの操作手順

10．システムの終了手順

↓

良い例

1．システムの起動と終了

1-1．システムの起動手順

1-2．システムの終了手順

2．機能Aの操作手順

3．機能Bの操作手順

機能の全体像を示す

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

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

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

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

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

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

I（修正前）

1. 新規情報登録

1.1 新規会員登録

1.2 新規採用講座登録

1.3 新規講師登録

2. 情報保守

2.2 会員情報保守

2.2 講座情報保守

2.3 講師情報保守

3. 情報削除

3.1 退会会員抹消

3.2 廃止講座削除

3.3 退職講師削除

↓

II（修正後）

1. 会員情報管理

1.1 新規会員登録

1.2 会員情報保守

1.3 退会会員抹消

2. 講座情報管理

2.2 新規採用講座登録

2.2 講座情報保守

2.3 廃止講座削除

3. 講師情報管理

3.3 新規採用講師登録

3.2 講師情報保守

3.3 退職講師削除

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

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

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

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

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

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

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

I（修正前）

1. 受注業務

2. 製造管理業務

3. 在庫管理業務

4. 購買管理業務

↓

II（修正後）

1. 受注業務

1.1 営業担当者の作業

1.2 経理担当者の作業

2. 製造管理業務

2.1 営業担当者の作業

2.2 製造管理担当者の作業

2.3 製造現場担当者の作業

3. 在庫管理業務

3.1 製造管理担当者の作業

3.2 在庫管理担当者の作業

3.3 購買担当者の作業

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

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

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

I（修正前）

規定外のデータ構造の文書データを保存しようとするとエラーになる。

↓

（対応法の記述）

↓

II（修正後）

作成した文書データを保存できず、エラーメッセージ「文書を保存できませんでした」が表示される。

↓

（対応法の記述）

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

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

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

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

I（修正前）

1. データベース管理の不具合による障害

1.1 権限に関連する不具合による障害

1.2 データ構造が原因の障害

1.3 アプリケーションの不具合による障害

↓

II（修正後）

1. 会員情報管理機能での障害

1.1 新規会員登録機能での障害

1.2 会員情報保守機能での障害

1.3 退会会員抹消機能での障害

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

著者紹介

谷口　功　（たにぐち　いさお）

フリーランスのライター、翻訳家。企業にて、ファクシミリ通信網を使ったデータ通信システム、人工知能、日本語処理関連のソフトウェア開発、マニュアルの執筆などに関わる。退職後、コンピュータ、情報処理、通信関連の書籍の執筆、翻訳、各種マニュアルや各種教材の執筆に携わる。また、通信、コンピュータ関連のメールマガジンの記事、各種雑誌においてインターネット、パソコン関連の記事やコラムなども執筆。コンピュータや通信に関連する漫画の原作を執筆することもある。 主な著作は、『SEのための　図解の技術、文章の技術』（技術評論社）、『ソフト契約と見積りの基本がよ〜くわかる本』『よくわかる最新　通信の基本と仕組み』（秀和システム）、『図解　通信プロトコルのことがわかる本』『入門ビジュアルテクノロジー　通信プロトコルのしくみ』（日本実業出版社）、『図解　ネットワークセキュリティ』『マスタリングTCP/IP　IPsec編』[共著]（オーム社）など。

「次回」へ

「誰にでも分かるSEのための文章術」バックナンバー

• システム開発を成功させたいSEに送る、「文書執筆のおきて」まとめ
• マニュアル執筆が怖くなくなる、12の執筆ポイント
• 「目次」の良し悪しが、すべてのマニュアルの良し悪しを決める
• 知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
• 「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？
• 論理的なプログラムを書くプログラマは、論理的な文章も書けるか？
• 文書ごとに最適な「構成のフレームワーク」は異なる
• さらば、翻訳調の文章！ 技術者向け校正ルール
• 専門用語は徹底的に「読み手指向」で書くべし
• 読みやすい文章の極意は「修飾語」にあり
• ドキュメントの質を確実に上げる6つの文章作法
• 「要件定義書のアウトライン作成」完全マニュアル
• 分かりやすい提案書はアウトラインが美しい
• ヒアリング現場で使えるコミュニケーション力
• 開発工程でSEが書く文書の基本