業務マニュアル作成

「できる人の頭の中」を、その人がいなくても同じ手順で作業できる文書にする。

入力として受け取るもの

次のいずれか、または組み合わせ。

• 作業手順のメモ、既存の手順書
• 作業画面のスクリーンショット、操作を録画した動画
• 作業者へのヒアリング（このスキル自身が質問して引き出す）

素材が断片的でも作業は始められる。足りない部分は下記の質問で埋める。

手順

1. 業務の輪郭を確定する。 次の3つを最初に確認する。
   • この作業はいつ発生するか（毎月○日、依頼を受けたとき、など）
   • 作業を始める前に手元にそろっている必要があるもの
   • どうなったら「終わり」か
2. 手順を1動作ずつに割る。 「確認して登録する」は「確認する」「登録する」の2手順に分ける。1手順に2つ以上の動作が入っていると、途中で止まったときにどこまで終わったか分からなくなる。
3. 判断が必要な箇所を分岐として書き出す。 ここが手順書の価値を決める。下記の「引き出す質問」で必ず確認する。
4. つまずきポイントを聞き出す。 新人が必ず間違えるところ、過去に事故になったところ。
5. 手順書を組み立てる。 下記フォーマットに従う。
6. 未確認の箇所を明示する。 聞き取れなかった手順は、推測で埋めずに 要確認 として残す。

引き出す質問

作業者へのヒアリングでは、手順そのものより次を優先して聞く。慣れた人ほど、判断の部分を無意識に飛ばして説明する。

出力フォーマット

# <業務名> 手順書

| 項目 | 内容 |
|---|---|
| 目的 | <この作業で何が達成されるか> |
| 実施タイミング | <毎月○日 / 依頼を受けたとき> |
| 所要時間 | <目安> |
| 担当 | <部署・役割> |
| 最終更新 | YYYY-MM-DD |

## 事前に用意するもの

- <必要なファイル、アカウント、権限、承認>

## 手順

### 1. <動作を表す見出し>

1. <画面名> を開く
2. <ボタン名> を押す
3. <入力欄> に <値> を入力する

> 判断: <条件> の場合は手順 4 へ、そうでない場合は手順 6 へ

注意: <間違えやすい点。間違えるとどうなるか>

### 2. <次の動作>

...

## 完了の確認

- <この状態になっていれば完了、という確認方法>

## 例外パターン

| 状況 | 対応 |
|---|---|

## よくあるつまずき

| 症状 | 原因 | 対処 |
|---|---|---|

## 困ったときの連絡先

| 内容 | 連絡先 |
|---|---|

## 要確認

- <聞き取れなかった手順・判断基準>

守るべきルール

• 画面名・ボタン名は実物のとおりに書く。 「登録ボタン」ではなく「保存して次へ」。表記が違うと、読み手は自分が間違えたのかシステムが変わったのか判断できない。
• 1手順1動作にする。 例外は「同じ画面で連続して入力する項目」だけ。
• 判断基準を必ず書く。 「状況に応じて」「適宜」と書かない。何を見て、どう決めるかを書く。書けない場合は、書けないこと自体を 要確認 に残す。
• 手順を推測で埋めない。 聞き取れなかった箇所を「おそらくこうする」と書くと、その手順書は一度事故を起こしてから信用されなくなる。
• 「なぜ」を1行添える。 理由が書かれていない手順は、状況が変わったときに勝手に省略される。
• 更新日と担当を必ず入れる。 誰も更新しないマニュアルは、古い手順で作業される分だけ有害になる。

自社用にカスタマイズする

• templates/ に自社の手順書テンプレート（表紙、改訂履歴、承認欄）を置く
• システム名・画面名の正式表記を references/glossary.md にまとめる
• 手順書の保管場所と、更新のルール（誰が、いつ見直すか）を追記する
• 作業の実施ログを残す欄が必要な場合は、フォーマットに追加する