process-docs

プロセス文書

使用する場面

創業者またはオペレーターが、チームの誰もが一貫して実行できるよう、社内プロセスを文書化する必要がある場合に使用します。「X の SOP を作成する」「インシデント対応用のランブックを作成する」「オンボーディングのプレイブックを文書化する」「このプロセスを標準化するにはどうすればよいか」などの依頼や、属人的な知識を再現可能な手順にするあらゆる依頼が対象です。

必要なコンテキスト

• **startup-context から：**会社の成長段階、チームの規模、現在使用しているツールやシステム、組織構造、コンプライアンス要件。
• **ユーザーから：**文書化するプロセス、そのオーナーと実行者、現在の問題点や失敗のパターン、実行頻度、関連するツール、および既存の（未文書化の）プロセスを置き換えるのか、新たに作成するのか。

ワークフロー

1. 文書の種類を特定する — 運用 SOP（日常的な手順）、インシデント対応ランブック（事後対応）、オンボーディングプレイブック（段階的な学習手順）のどれに当たるかを判断します。それぞれ異なるテンプレートを使用します。
2. プロセスを最初から最後まで整理する — トリガーとなる事象から完了まで、すべての手順を確認します。入力、出力、判断ポイント、引き継ぎ、エスカレーション経路を特定します。
3. オーナーと RACI を定義する — 単一のオーナー（実行責任者）を割り当て、主要な各ステップについて、承認者、協議先、報告先を特定します。
4. 文書を作成する — 以下の適切なテンプレートを使って記述します。命令形を使用します（「ダッシュボードを開く」。 「ダッシュボードを開いてください」ではありません）。
5. 判断ツリーを追加する — 条件分岐があるステップには、明確な if/then 分岐を作成します。分岐点に曖昧さを残さないでください。
6. 失敗のパターンを含める — 各ステップが失敗した場合の対応を文書化します。エラー処理のないプロセス文書は不完全です。
7. 見直し頻度を設定する — この文書をいつ、誰が見直すかを指定します（例：プロセスオーナーが四半期ごとに見直す）。

出力形式

以下の3つのテンプレートのいずれかに従った、構造化された Markdown 文書です。すべてのプロセス文書にメタデータヘッダーを含め、事前知識のない人でも最初から最後までプロセスを実行できるように本文を記述します。

テンプレート 1：運用 SOP

# [Process Name] — Standard Operating Procedure
**Owner:** [Name / Role]
**Last Updated:** [Date]
**Review Cadence:** [Quarterly / Monthly]
**Version:** [1.0]

## Purpose
Why this process exists and what business outcome it supports.

## Scope
What this SOP covers and explicitly does not cover.

## Prerequisites
Tools, access, permissions, or context needed before starting.

## Procedure
1. Step with specific action
   - Sub-step with detail
   - **Decision point:** If [condition], go to Step X. Otherwise continue.
2. Next step...

## Escalation Path
| Condition | Escalate To | SLA |
|-----------|------------|-----|
| [Trigger] | [Person/Role] | [Timeframe] |

## Success Criteria
How to verify the process was completed correctly.

## Changelog
| Date | Author | Change |
|------|--------|--------|

テンプレート 2：インシデント対応ランブック

# [Incident Type] — Runbook
**Severity:** [P0-P3]
**On-Call Owner:** [Role]
**Last Tested:** [Date]

## Detection
How this incident is identified (alerts, customer reports, monitoring).

## Immediate Actions (First 5 Minutes)
1. Triage step...
2. Communication step...

## Diagnosis
Decision tree for identifying root cause.

## Resolution Steps
Step-by-step fix for each known root cause.

## Post-Incident
Checklist for after the incident is resolved.

テンプレート 3：オンボーディングプレイブック

# [Role/Process] — Onboarding Playbook
**Duration:** [e.g., 2 weeks]
**Buddy/Owner:** [Role]

## Day 1-2: Orientation
Tasks, access setup, key introductions.

## Day 3-5: Core Training
Hands-on exercises, shadowing, tool walkthroughs.

## Week 2: Guided Practice
Supervised execution of real tasks with checkpoints.

## Graduation Criteria
What the person must demonstrate to be considered onboarded.

フレームワークとベストプラクティス

• 「バス係数」テスト。 通常このプロセスを担当する人が不在でも、他の人がこの文書だけを見て実行できますか？できない場合は、詳細を追加します。
• 命令形のみを使用する。 すべての手順は動詞から始めます。「デプロイボタンをクリックする」であり、「デプロイボタンをクリックする必要があります」ではありません。
• 1つの手順につき1つのアクション。 1つの手順に「そして」が含まれる場合は、2つの手順に分けます。複数のアクションを含む手順は、飛ばされたり、一部だけ実行されたりします。
• 判断ポイントを明示する。 明確な条件を示し、if/then 形式を使用します。「エンタープライズプランの顧客の場合は、ステップ 7 に進む」とし、「エンタープライズの顧客には別の対応をする」とはしません。
• 所要時間は重要です。 各主要フェーズの想定所要時間を記載します。これにより、担当者が計画を立てやすくなり、問題が発生した際にも気づけます（ステップの所要時間が想定の3倍になった場合はエスカレーションします）。
• スクリーンショットはすぐに古くなります。 再設計のたびに使えなくなるスクリーンショットよりも、UI の操作経路（設定 > インテグレーション > Slack）のテキスト説明を優先します。スクリーンショットは、実際に複雑なインターフェースに限って使用します。
• すべてにバージョンと日付を記載する。 最終更新日がないプロセス文書は、誤っているものと見なされます。
• 段階的に詳細を示す。 各セクションの冒頭に1行の概要を記載してから、詳細を展開します。経験豊富なオペレーターは要点に目を通し、新入社員はすべてを読みます。どちらにも役立つようにします。
• 複製せず、リンクする。 別の SOP がサブプロセスを扱っている場合は、手順をそのままコピーせずにリンクします。重複すると内容にずれが生じます。
• 初めての人に試してもらう。 最も効果的なレビュー方法は、プロセスに不慣れな人に文書どおりに実行してもらい、どこでつまずくかを記録することです。

関連スキル

• support-docs — 文書化するプロセスが顧客向けで、対応するヘルプセンター記事やトラブルシューティングガイドが必要な場合に連携します。
• board-update — 運用プロセスを投資家向けまたは取締役会向けの報告用に要約する必要がある場合（例：「インシデント対応の成熟度について」）に連携します。

例

例 1：運用手順書

ユーザー：「顧客への返金処理手順書を作成してください。」

出力例：

手順

1. Zendeskで返金リクエストを開きます。チケットに注文 ID、返金理由、顧客のメールアドレスが含まれていることを確認します。
2. Stripeで返金対象かどうかを確認します。
   • **判断ポイント：**注文から30日を過ぎている場合は、顧客の状況を説明するメモを添えてサポートリードにエスカレーションします。返金処理は行いません。
   • 30日以内の場合は、ステップ3に進みます。
3. Stripe Dashboard > Payments > [Order ID] > Refundから返金を実行します。サポートリードが一部返金を承認していない限り、「Full refund」を選択します。
4. Stripeの返金 IDを記載してチケットを更新し、ステータスを「Solved」に設定します。
5. Refund Trackerスプレッドシートに返金を記録します（A列：日付、B列：注文 ID、C列：金額、D列：理由コード）。

**所要時間：**返金1件あたり5～8分。

例 2：インシデント対応手順書

ユーザー：「決済処理が停止した場合の対応手順書が必要です。」

出力例：

初動対応（最初の5分）

1. 再エスカレーションを停止するため、PagerDutyでアラートを確認します。
2. Stripe Status Page（status.stripe.com）を確認します。Stripeが障害を報告している場合は、「External Provider Outage」セクションに進みます。
3. #incidents Slackチャンネルに投稿します：「決済処理の失敗を調査中です。15分ごとに更新します。DRI：[あなたの名前]。」
4. Admin > Feature Flags > payment_maintenance_mode = trueからメンテナンスバナーを有効にします。これにより、生のエラーではなく「決済を一時的にご利用いただけません。しばらくしてからもう一度お試しください」とユーザーに表示されます。