マニュアルが誰にも読まれないのは、更新されてないからじゃない。「読む理由」が無いからだよ
業務マニュアルが形骸化する構造を分析し、実際に参照されるドキュメントにするための設計と運用のルールを解説します。
立派なマニュアルを作った。フォルダに置いた。半年後、誰も開いていない。新人は結局、先輩に口頭で聞いている。これはドキュメントの質の問題ではなく、参照される設計になっていないという問題だ。
人は「困ったとき」にしか読まない
前提として、マニュアルを通読する人はいない。読まれるのは特定の困りごとが発生した瞬間だけだ。
だから設計の要件はこうなる。
- 困った瞬間に、たどり着けること
- たどり着いた先で、答えが即座に見つかること
この2つが満たされないと、人は3秒で諦めて人に聞く。そして一度「聞いたほうが速い」と学習すると、二度と開かない。
読まれないマニュアルの特徴
1. 目次が業務の流れ順になっている
「1. 概要」「2. 事前準備」「3. 手順」という構成は、書く側には自然だが、読む側の困り方と一致していない。
読む人は「エラーが出た」「この場合どうする」という状況から入る。だから、よくある困りごとを見出しにするほうが、たどり着きやすい。
2. 検索できない
PDFで配布されている、共有フォルダの奥深くにある、ファイル名が「業務手順書_最新版_v3_確定.pdf」。探せない場所にあるドキュメントは、存在しないのと同じだ。
全文検索できる形式で、検索できる場所に置く。これだけで参照率は変わる。
3. 情報が古いかどうか分からない
最終更新日が書かれていないドキュメントは、信用されない。「これ、まだ有効なのか」が分からないと、結局人に確認することになる。それなら最初から人に聞く。
4. 分量が多すぎる
網羅性を優先すると、読む側の負担が増える。1つの困りごとに対して1ページに分割するほうが、参照されやすい。
参照されるドキュメントの作り方
質問から作る
最初からマニュアルを書こうとしない。実際に受けた質問を、そのまま見出しにする。
「請求書の締め日を過ぎた場合、どうすればいい？」
「システムにログインできないときの確認順は？」
「◯◯社の案件だけ、なぜ処理が違うの？」
これなら、書く内容も明確で、読む側の検索語とも一致する。質問がなければ、そのページは不要ということでもある。
1ページ1トピック
大きな文書を1つ作るのではなく、小さなページを多数作る。検索でピンポイントに到達でき、更新も部分的に済む。
更新日と担当者を明記する
ページの先頭に「最終更新: 2026年◯月◯日 / 担当: ◯◯」と書く。古い情報でも、古いと分かれば判断ができる。分からないのが一番困る。
更新が続く仕組み
マニュアルが陳腐化する最大の理由は、更新が誰の仕事にもなっていないことだ。
効果的なのは、更新のタイミングを業務に紐づけることだ。
- 質問を受けたら、答えると同時にドキュメントに追記する: 同じ質問が2回来た時点で書く、というルールにする
- 手順が変わったら、変更した本人がその場で直す: 後で誰かがまとめて直す、は実現しない
- 誰でも編集できる状態にする: 承認フローを挟むと、更新されなくなる。間違いは後から直せばいい
最後の項目が重要だ。品質管理を厳しくするほど、鮮度は落ちる。このトレードオフでは、鮮度を優先したほうが実用的なことが多い。
それでも口頭で聞かれるなら
ドキュメントがあるのに聞かれる場合、次のどれかだ。
- 存在を知らない → 質問されたら、答えではなくリンクを返す。「ここに書いてあります」を繰り返すと定着する
- 探したが見つからなかった → 検索語と見出しが一致していない。相手が使った言葉で見出しを付け直す
- 読んだが理解できなかった → 前提知識を書きすぎ、または書かなさすぎ
どのケースなのかを聞けば、改善点が分かる。質問は、ドキュメントの不具合報告として扱うのが正しい。
まとめ
- マニュアルは通読されない。困った瞬間に参照されるだけ
- 見出しは業務の流れではなく、困りごとの形にする
- 検索できる場所・形式に置く。更新日を明記する
- 実際に受けた質問から作る
- 誰でも編集できる状態にして、鮮度を優先する
参考・出典
※制度・統計・ガイドラインは改定されることがあります。実際の手続きや判断にあたっては、各機関の公式サイトで最新の内容をご確認ください。（リンク最終確認: 2026年9月1日）
