手順書が操作名だけの一覧だと、初めての人は開始条件や正しい結果を判断できません。目的、準備、操作、確認、例外の順に整理し、小さな作業で実際に使えるか確かめましょう。
執筆：マトリバ編集部 ／ 最終更新：2026年10月12日 ／ 公開：2026年10月3日
作業手順を整理する実践ガイドです。本文の記入例・数値例は架空の例です。
1. 対象と完了条件を先に書く
何のために行う作業か、どの範囲まで手順書に含めるかを示します。「請求処理」全体では広すぎる場合、「必要なデータを一覧に記録する」工程から始められます。
完了条件は「作業を行った」ではなく、一覧に対象の記録が入り、件数を照合したなど、確認できる状態で書きます。承認が必要な仕事は、その工程も明記します。
2. 準備物と必要な権限を分ける
入力に使う資料、保存先、必要なアカウント、担当窓口を記録します。パスワードや認証コードを手順書へ書かず、仕事先の認証管理ルールに従ってください。
権限が足りない場合の連絡先も用意します。エラーが出た人に保護設定を外すよう促すのではなく、必要な担当者へ確認する流れにします。
3. 一つの工程に、操作と期待結果を書く
「保存する」だけでなく、「案件フォルダへ保存し、一覧でファイル名を確認する」と結果まで含めます。分岐がある場合は、どの条件なら別の操作へ進むかを書きます。
画面の図やスクリーンショットは、実際のデータが見えない状態で作ります。画面が変わるサービスでは、更新日と対象環境を添え、古い画像を現在の画面として使わないようにしてください。
| 手順の要素 | 書く内容 | 確認の例 |
|---|---|---|
| 準備 | 入力資料と保存先 | 最新版を用意した |
| 操作 | 具体的な動作 | 指定の一覧へ記録した |
| 結果 | 正しい状態 | 件数と内容が一致した |
| 例外 | 停止条件と連絡先 | 重複時は担当へ確認 |
4. 例外は、止める条件と連絡先を残す
入力漏れ、重複、対象外の資料など、起きやすい例外を列挙します。「適宜対応」では、判断できる人しか作業を進められません。迷う場合の停止条件を具体化します。
外部への送信や削除を含む工程は、どこで人が確認するか決めます。取り消しが難しい操作を、慣れていない人が推測で進めない構成にしましょう。
5. 別の人に使ってもらい、迷う箇所を直す
作成者は前提を知っているため、説明の抜けに気づきにくいことがあります。架空のデータを使い、手順だけを見た人が進められるか確認します。
質問された箇所、期待と違った結果、更新が必要な図を記録します。全部を詳しくするのではなく、実際に迷った工程から直し、改訂日と担当者を残してください。
短い作業手順書の完成例
架空の受領資料を案件一覧へ登録する手順です。操作と正しい結果、止める条件を同じ順に書きます。
編集部の架空の作例です。実際の案件・サービスの実測結果ではありません。
目的：受領した資料を、担当が見つけられる状態にする 準備：資料、案件ID、登録先一覧。登録権限がなければ担当へ連絡 手順1：案件IDで既存行を探す→同じIDの有無を確認 手順2：新規なら資料名・受領日・原本リンクを入力→必要欄が埋まる 手順3：リンクを開いて資料名を照合→原本と一覧が一致 完了：登録した行と原本を担当が確認 例外：ID重複・資料不明なら登録を止め、窓口へ確認 改訂：10月3日／更新担当：Bさん
コピーして使えるひな形
作業名・目的： 対象と完了条件： 準備物・必要な権限： 手順／期待する結果： 例外と止める条件： 確認・承認する担当： 改訂日と更新担当：
手順書を初めて読む人に試してもらう方法
以下は手順書の点検方法の提案です。説明した本人が実行できることだけでは、初めての人が迷わないかは分かりません。
試す条件・記録：対象：架空の資料1件を試験用一覧へ登録する手順／本番一覧は使わない
- 試験用の資料、一覧、必要な権限を用意し、実行前に変更してよい範囲を伝える。
- 実行者が止まった箇所を記録する。補足を口頭で伝えた場合は、その内容も記録する。
- ID重複の試験も行い、『登録を止めて担当へ確認』の分岐に進めるか確認する。
判断の目安：口頭の補足がなければ進めなかった箇所は、手順書へ反映する候補です。手順の完了条件と、例外で止める条件の両方を点検します。
2026年10月12日：判断例・確認手順を追記。AIと運営者の役割・確認範囲。
最後に確認すること
- 開始条件と完了条件がある。
- 認証情報を本文に載せていない。
- 例外の連絡先が分かる。
- 別の人が架空のデータで試した。
コメントを残す