業務マニュアルの作り方｜「見れば分かるはず」が通じないときに直す5か所

011．最初の一行に「いつ使うか」を書く

「見積書作成マニュアル」という名前だけでは、新規案件用か、契約更新用か分からないことがあります。本文の冒頭で対象を限定しましょう。

例えば「標準プランの新規見積もりを作る手順。個別開発や特別条件がある案件は対象外」。続いて、依頼が来たら無条件で始めるのか、条件がそろってから着手するのかも記載します。「対象サービス、数量、希望時期、送付先の確認後に開始」としておけば、不足情報を抱えたまま書き始めるのを避けられます。

Atlassianの公式ガイドも、手順書では対象範囲や開始・終了地点、利用者を明らかにすることを勧めています。[1] ただし、ここで示す見積もり業務の書式や運用例は、ウリノビ独自の編集案です。

022．「適切に」「必要に応じて」を具体的な条件に変える

経験者にとって便利な言葉ほど、初心者には難しい場合があります。「必要に応じて上長に相談」では、必要かどうかの判断を新人に預けている状態です。

書き直すなら「標準料金表にない項目が含まれる場合は、見積書を送る前に営業責任者へ相談」。あるいは「納期が未確定の場合は、確約せず確認中と記載する」。何を見て判断するか、どこで止めるかを示すと、質問の場所がはっきりします。

相談基準は会社ごとに異なります。金額の閾値や承認者をこの記事から借りるのではなく、実際に判断を担う人と決めてください。まだルールが存在しない箇所は「要決定」と残す。それは書き手の不足ではなく、業務設計で解消したい宿題です。

033．完成した状態を、一つ見せる

手順だけ読んでも、正しく終えられたか不安は残ります。そこで役立つのが、個人情報や取引情報を除いた完成例です。見積書なら架空の会社名や金額を使い、必須項目がそろった見本を用意する。顧客管理表への入力なら、登録済みのサンプル行がよいでしょう。

見本の横には確認項目を置いてみてください。「宛名」「対象サービス」「数量」「有効期限」「承認済みか」のように、実際の社内ルールに沿って確認できる粒度にします。見栄えが整っているかではなく、受け取った人が次の仕事を始められる状態かが基準です。

なお、社内でマニュアルを共有するときも、実際の顧客情報をそのまま見本に使わない配慮が必要です。練習用データに置き換えれば、説明にも使い回しやすくなります。

044．よくある例外だけを、本文から分けて置く

あらゆる例外を最初から盛り込むと、通常の手順が見えなくなります。まずは標準の流れを短く示し、その後ろに頻出する分岐を置く構成がおすすめです。

【例外対応の書き方】
送付先が分からない → 依頼者へ確認。推測で別の宛先に送らない。
料金表にない条件がある → 送付を止め、営業責任者に相談。
承認担当が不在 → 社内で決めた代理担当へ連絡。未承認のまま進めない。
システムで保存できない → エラーの表示内容と発生箇所を記録し、管理担当へ共有。

担当者名を個人名だけで書くと、異動のたびに修正が必要です。役割名を本文に書き、現在の担当者一覧へリンクする方法もあります。実際に誰へ連絡するのか迷わないよう、連絡先と担当者一覧の更新責任も決めておきましょう。

055．更新担当と「変更のきっかけ」を決める

マニュアルが古くなるのは、書き手の熱意だけでは防げません。料金表を変えたとき、入力欄を追加したとき、同じ質問が続いたとき。更新が必要になる場面を、普段の作業と結び付けておきたいところです。

ページの末尾に「管理担当」「最終更新日」「変更点」を置き、最新版の保存場所を一本化します。メールに添付した古い版が残る場合は、本文に最新版へのリンクを明記。資料の数より、使う人が最新版へたどり着けることを優先してください。

06最初の一本は、このひな形から

【一業務・一ページのひな形】
業務名：
目的：この作業によって何をそろえるか
対象／対象外：
始める条件：必要な情報、承認、準備物
手順：1．確認する 2．作成する 3．照合する 4．承認後に共有する
完了条件：誰が何を使える状態になれば終わりか
完成例：練習用データで作った見本へのリンク
迷ったとき：止める条件と相談先
管理担当／最終更新日／変更点：

ひな形を埋めたら、その仕事を知らない人に試してもらいましょう。画面や練習用データを使い、実際の顧客へ送信しない環境で確認すると安心です。説明したくなっても、まずはどこで止まるかを観察。質問された言葉や足りなかったリンクを、次の修正に使います。

「全部書いたか」より「初めての人が次へ進めたか」。この基準で一本ずつ直していけば、マニュアルは保管する資料から、現場で使う道具に変わっていきます。