sop-creator

SOP と Runbook の作成

人々が実際に従う、実用的なドキュメントを作成します。

基本方針

50 ページのドキュメントは誰も読みません。 ざっと目を通せて、実行に移しやすく、誤解の余地がないものにします。

基本原則：

• ざっと目を通せる - 見出し、箇条書き、表を使います。長文の羅列は避けます。
• 実行に移せる - 各ステップは「検討する」ことではなく、実際に行うことにします。
• 具体的 - 数値、名前、しきい値を記載します。「必要に応じて」や「適切なタイミングで」は使いません。
• 検証可能 - 明確な成功基準を設けます。どうすれば成功したとわかるでしょうか？
• 保守されている - 担当者、最終更新日、レビュー予定を記載します。

SOP のカテゴリ

用途に合った形式を選びます。

技術／エンジニアリング

種類	使用する場面
Runbook	緊急対応、インシデント、オンコール
デプロイ手順書	リリース、移行、メンテナンス
トラブルシューティングガイド	デバッグ、診断フロー
操作ガイド	単発のセットアップ、設定
ADR	アーキテクチャ上の決定

オペレーション／ビジネス

種類	使用する場面
業務プロセス SOP	繰り返し行う業務ワークフロー
チェックリスト	品質管理、確認
決定木	複雑な if/then シナリオ
引き継ぎドキュメント	役割の移行、シフト交代

コンテンツ／クリエイティブ

種類	使用する場面
制作ワークフロー	コンテンツ制作パイプライン
レビュープロセス	承認ワークフロー
公開チェックリスト	公開前の確認

一般

種類	使用する場面
標準 SOP	繰り返し行うあらゆるプロセス
クイックリファレンス	長い SOP の要約版
オンボーディングガイド	新しいメンバーの立ち上がり支援

共通の構成

すべての SOP には、最低限、次の項目が必要です。

# [What This Does]

> **TL;DR:** One sentence - what, when, who.

## Definition of Done

This is complete when:
- [ ] [Primary outcome]
- [ ] [Verification step]
- [ ] [Any handoff/notification]

## When to Use This
[Trigger conditions]

## Prerequisites
[What you need before starting]

## The Process
[Numbered steps - the actual work]

## Verify Completion
[Return to Definition of Done, confirm all checked]

## When Things Go Wrong
[Common issues and fixes]

## Questions?
[Who to contact]

完了の定義は最も重要なセクションです。 冒頭近くに配置し、チェックリスト形式で具体的に記載します。

執筆ルール

具体的に書く

書かない表現	代わりに書く表現
「チームに連絡する」	「#ops-team で @sarah にメッセージを送る」
「準備ができるまで待つ」	「ステータスに「Complete」と表示されるまで待つ（約 5 分）」
「注意深く確認する」	「ダッシュボードで項目 A、B、C を確認する」
「適宜」	「値が 100 を超える場合」
「定期的に」	「毎週月曜日の午前 9 時」
「なるべく早く」	「2 時間以内」

行動を先に示すステップ

# Bad
"The report should be reviewed before sending to ensure
accuracy and completeness of all data fields."

# Good
1. Open the report in [System]
2. Verify these fields are populated:
   - [ ] Customer name
   - [ ] Amount
   - [ ] Date
3. Click "Send"

警告を先に示す

# Bad
1. Delete the old records
   Note: This cannot be undone

# Good
> **WARNING:** This permanently deletes records. Export first if needed.

1. Delete the old records

判断ポイントを明確にする

# Bad
"Handle the request based on priority level"

# Good
**If priority is:**
- **Critical:** Drop everything, handle now, notify manager
- **High:** Handle within 4 hours
- **Normal:** Handle within 24 hours
- **Low:** Add to weekly batch

形式の選び方

次の点を確認します。

1. 緊急時に使うものですか？ → Runbook
2. 複数の段階からなる複雑なプロジェクトですか？ → 手順書
3. 簡単な反復タスクですか？ → 標準 SOP またはチェックリスト
4. if/then の分岐が多くありますか？ → 決定木
5. デバッグ用ですか？ → トラブルシューティングガイド
6. 決定事項を記録するものですか？ → ADR
7. 新しいメンバー向けですか？ → オンボーディングガイド

メタデータ（簡潔に）

---
title: [Clear name]
owner: [Person or team]
last_updated: [Date]
review_schedule: [quarterly/annually/as-needed]
---

以上です。実際に必要な場合を除き、ドキュメント ID、バージョン一覧、承認フローは不要です。

テンプレート

各テンプレートは references/ にあります。

テンプレート	用途
runbook.md	インシデント、緊急事態、オンコール
standard-sop.md	繰り返し行うあらゆるプロセス
how-to-guide.md	単発のタスク、セットアップ
onboarding-guide.md	新しいメンバーの立ち上がり支援
decision-tree.md	複雑な if/then フロー
checklist.md	品質管理、確認

すべてのテンプレートで、「完了の定義」を主要な成功基準として扱います。

品質チェックリスト

公開前に確認します。

• 初めて読む人でも、これに従って作業できますか？
• すべてのステップが実行可能ですか（説明ではなく動詞で書かれていますか）？
• 名前、数値、しきい値などが具体的に示されていますか？
• 明確な「完了」の状態がありますか？
• 担当者／連絡先情報は最新ですか？
• 最近テストされていますか？

アンチパターン

次の表現は避けてください：

• 「会社の方針により……」（何をすべきかをそのまま書いてください）
• 「……することをお勧めします」（「X をしてください」と書いてください）
• 「必ず……してください」（「X を確認してください」と書いてください）
• 受動態（「フォームを提出してください」ではなく、「フォームを提出する必要があります」など）
• 実際に示さず、何をすべきかを説明する
• 構成のない長文
• 1 か月後には古くなるスクリーンショット

次のことを実践してください：

• 最も一般的な手順から始める
• 例外的なケースは最後に記載する
• 関連ドキュメントへのリンクを使い、内容の重複を避ける
• 参照情報には表を使う
• 確認手順にはチェックリストを使う
• 「行き詰まった場合」の対処方法を用意する