process-documentation

プロセス文書作成スキル

その役割に就いたばかりの人が、質問せずに手順を進められる、明確で構造化されたプロセス文書を作成します。

必要な入力

• プロセス名
• プロセスの説明（大まかなメモでも構いません）
• このプロセスを実施する人（関係する役割）
• 実施頻度（毎日／毎週／毎月／イベント発生時）
• 使用するツール
• 既知の例外ケース

出力構成

---

プロセス：[プロセス名]

担当者： [役割] | 頻度： [頻度] | 所要時間の目安： [所要時間]

---

目的

[このプロセスが存在する理由を1～2文で記述します。実施しない場合、何に支障が出ますか？]

対象範囲

対象範囲内： [対象となる内容] 対象範囲外： [対象とならない内容]

前提条件

• [必要なアクセス権または情報]
• [事前に完了しておく必要がある依存作業]

---

役割と責任

役割	責任
[役割 1]	[担当する作業]

---

プロセスの手順

手順 1：[手順名]

• 担当者： [役割]
• 実施時期： [トリガーまたはタイミング]
• 方法： [番号付きのサブ手順]
• 成果物： [この手順の終了時に存在するもの]
• ツール： [使用するシステム]

[すべての手順について続けます]

---

例外ケースと例外事項

状況	対応方法	問い合わせ先
[例外ケース]	[対応]	[名前／役割]

---

よくある間違い

[初めて実施する人が間違えやすいことを2～4項目]

エスカレーション経路

[名前／役割] → [次の段階] → [最終的なエスカレーション先]

レビュー

次回レビュー日：[日付]

品質チェック

• すべての手順で担当する役割が明記されている（「誰か」や「チーム」ではない）
• 例外ケースと例外事項の表がすべて記入されている
• 初めて実施する人が事前準備できるよう、前提条件が記載されている
• エスカレーション経路が明記されている（「上司」だけでなく、具体的な人または役割）
• レビュー日が設定されている

アンチパターン

• 各手順の担当者を明記せずに手順を書かないでください。全体を通して責任の所在を明確にする必要があります
• エスカレーション経路を省略しないでください。問題が起きた場合の対応を、すべてのプロセスに記載する必要があります
• 実際のプロセスと異なる理想的なプロセスを文書化しないでください。実態を記録し、改善点は別途記載してください
• 例外ケースと例外事項を省略しないでください。プロセスの失敗の多くは、実際にこうした状況で起こります
• レビュー日を記載せずに文書を作成しないでください。日付のないプロセス文書はすぐに不正確になります

トリガーとなるフレーズの例

• 「このプロセスを文書化してください：[説明]」
• 「[ワークフロー] の手順書を作成してください」
• 「[プロセス] の進め方を整理してください」