立派なマニュアルを作ったのに、誰も見ない。新人は結局ベテランへ質問し、担当者が替わるたびに引き継ぎがやり直しになる。原因は文章量ではなく、仕事の現場とマニュアルが切り離されていることです。
使われるマニュアルには五つの要素があります。
- 入口が明確。「いつ、何をきっかけに始める業務か」を書きます。
- 完了条件が明確。「何ができれば終了か」を示します。
- 判断基準がある。分岐条件と、迷った場合の確認先を記載します。
- 例外と証跡がある。トラブル時の動きと、残す記録を決めます。
- 更新者が決まっている。現場でズレを見つけた人が、誰へ修正を依頼するかを明示します。
画面操作を一枚ずつ説明しても、判断が書かれていなければ仕事は止まります。反対に、判断と完了条件が明確なら、ツールの画面が多少変わっても対応できます。
作り方は、詳しい人へ長文を書いてもらうより、実際の作業を横で見ながら質問する方が効果的です。「次に何を見ていますか」「どの状態なら止めますか」「過去に困った例はありますか」と聞き、作業と判断を分けて記録します。
公開後は、新人または別担当者に実行してもらいます。質問が出た箇所は、利用者の理解不足ではなくマニュアルの改善点です。更新日と変更理由を残し、短い周期で直します。
マニュアルの目的は、知識を保存することだけではありません。誰が担当しても、一定の品質で仕事を再現できる状態をつくることです。最初から全業務を対象にせず、質問が多い、ミスの影響が大きい、引き継ぎ予定がある、のいずれかに当てはまる一業務から始めましょう。
そのまま使える業務マニュアルの記入例
例えば「見積書を作成し、顧客へ送付する」という業務では、画面操作に入る前に次の情報を揃えます。
| 記入欄 | 記入例 |
|---|---|
| 目的 | 顧客が判断できる条件と金額を示す |
| 開始条件 | 要件・希望納期・連絡先が確認できた |
| 完了条件 | 承認済み見積を送付し履歴を保存した |
| 通常処理 | 標準単価表を参照し、担当者が作成する |
| 判断が必要な条件 | 標準外の値引き・契約条件・納期変更 |
| 承認先 | 権限表で定めた上長。判断期限も記載する |
| 例外時の記録 | 理由、判断者、結果、顧客合意 |
| 更新責任者 | 業務の管理者と見直し予定日 |
記入例は架空のものです。金額条件や承認範囲は実際の契約・社内規程に合わせてください。
公開前に確認する3つのテスト
- 担当者交代テスト：作成者以外がマニュアルだけで通常処理を完了できるか。
- 判断テスト：イレギュラーな依頼を受けたとき、判断条件と相談先が分かるか。
- 更新テスト：運用が変わったとき、誰が何を修正すべきか分かるか。
マニュアルが使われない原因を整理する前に、業務棚卸しの進め方で対象業務を一つ選ぶと、作成範囲が膨らみにくくなります。
仕組化ラボでは、作業手順だけでなく判断基準・役割・記録の設計を支援しています。
この記事に関連するおすすめ
図解 いちばんやさしく丁寧に書いた業務マニュアルの作成
業務の洗い出しからマニュアルの作成、更新、運用までを具体的に確認したい方に向く実務書です。使われ続けるマニュアルへ直す際の手元の参考になります。
【広告】本記事にはAmazon・楽天市場などのアフィリエイトリンクを含みます。
仕組化ラボでは、業務を工程に分け、作業、判断、役割、記録を整理し、現場で実際に回して定着するまで支援します。
仕事で起きるITの困りごとを、症状や状況から無料で検索できます。