第4章：優先度とスコープ管理（分割/依存/影響度×緊急度）

この章で学ぶこと

• 大きい Issue を分割し、依存関係を可視化する
• 影響度×緊急度で優先度を決める
• リスクと期限を明文化する

成果物（書けるようになるもの）

• 分割案（子Issue）と依存関係を書ける
• トリアージ判断表を使える（付録: トリアージ）

本文

優先度は「声が大きい順」ではなく、「影響」と「緊急度」で決める。

影響度×緊急度の判断基準（最小）

• 影響度（何がどれだけ困るか）: 利用者影響（件数/割合）、売上/コスト、セキュリティ/法令、運用負荷（当番/問い合わせ）など
• 緊急度（いつまでに必要か）: 期限（リリース/契約/監査）、依存（他タスクのブロック）、時間経過で悪化（再現頻度増加/データ増加）など

判断の根拠は Issue 本文に残す。根拠が未取得の場合は“要確認”とし、収集方法と期限（いつまでに確定するか）を併記する。

Priority と Severity を混同しない

本書の優先度（priority）は「平時タスクの実行順（業務優先度）」を指す。障害対応の Severity（影響度ラベル）とは目的が異なるため、同じ P0/P1 の表記を使う場合でも文脈（平時/障害）を明確にする。

• 平時: priority:*（付録のトリアージ判断表で運用）
• 障害: Severity（incident-response-basics-book の運用に従う）

例（最小）:

• 平時の改善タスク: priority:P1（影響×緊急度で判断理由を添える）
• 障害対応: Severity（影響度ラベル。運用ルールに従う）

分割の観点

• 価値（利用者が確認できる単位、検証できる単位）
• 依存（先に必要なもの）
• リスク（失敗時の影響）
• 検証（確認方法）
• ロールバック（戻し方）

分割すると、進捗もレビューも並列化できる。

親 Issue には“目的/受け入れ条件/非スコープ”を残し、子 Issue には個別の受け入れ条件と依存関係を持たせる（親が単なる TODO リストになると、完了判定が崩れる）。

注意点（失敗例）

• 優先度の理由が残らず、後から“なぜ先にやったか”を説明できない
• 分割が“層（フロント/バック/DB）”単位だけになり、価値と検証が最後まで先送りされる
• “対応しない”判断が記録されず、同じ要望が繰り返し起票される

具体例（悪い例→良い例）

悪い例

Issue: ぜんぶ直す（期限: なるはや）
依存: 不明

良い例

親Issue: 入力フォーム改善
子Issue: 1) バリデーション 2) 文言 3) ログ追加
依存: 1→2 の順
優先度: 影響=中、緊急=高（問い合わせ増加）
リスク: 誤判定で保存不可になる可能性

チェックリスト

• 分割されている
• 依存関係が明記されている
• 優先度が影響×緊急で説明できる
• リスクと検証が書かれている

まとめ

• 優先度は影響度×緊急度で判断し、根拠を Issue に残す
• Priority（平時）と Severity（障害）を混同せず、ラベル運用を分離する
• 分割は価値/依存/リスク/検証/ロールバックの観点で行い、並列化と完了判定を成立させる

次章への接続

• 次章: 第5章