game-scope-check

AlterLab GameForge -- スコープ確認ワークフロー

スコープクリープは、インディーゲームを失敗に追い込む最大の要因です。才能不足でも、アイデアの悪さでも、エンジンの制約でもありません。ゲームは、チームが完成させられる能力を超えて膨らむことで、完成に至らなくなります。「ちょっとした」追加を一つずつ重ねていくうちに、一つ一つはもっともらしくても、積み重なると致命的になります。危険なのは、スコープクリープが進歩のように感じられることです。機能を追加すると生産的な気分になり、削ると失敗したように感じます。このワークフローは、その心理を逆転させるためのものです。削ることこそがスキルであり、スコープを絞り込むことこそが成果です。

Team Cherry は3人で Hollow Knight をリリースしました。ConcernedApe は一人で Stardew Valley をリリースしました。どちらのプロジェクトも、目指すところが小さかったわけではありません。何を含め、何を削るかについて、徹底して規律を守っていました。リリースされるゲームとは、機能リストが最も長いゲームではありません。正直にスコープを見積もったうえで、一つ一つの機能が採用に値すると認められたゲームです。

基本原則は次のとおりです。優れた機能が8つある完成したゲームは、作りかけの機能が20個ある未完成のゲームに勝ります。 このワークフローは、希望的観測ではなく、具体的なツールを使ってこの原則を徹底します。

目的と実施タイミング

次の場合に、このワークフローを使います。

• 前回のスコープ確認以降、機能リストが膨らんでいる
• 誰かが「これを入れられますか？」や「これも追加したらどうでしょう？」と言う
• マイルストーンの期限が近づいているのに、達成できる確信が持てない
• チームが圧倒されているものの、その理由を明確に説明できない
• スプリントのベロシティが、計画した作業能力を継続的に下回っている
• ステークホルダー（自分自身も含む）が、機能の削減に異議を唱える
• プロジェクトで正式なスコープ確認を一度も実施したことがない

解決する課題：

• 増える一方で、決して減らない機能リスト
• 「あと一つだけ」というパターンが積み重なり、期限を逃すこと
• 優先順位を付けたがらないため、すべての機能が「必須」とされること
• 機能と利用可能な作業時間とのつながりが明確でないこと
• 何を削るかを決めるフレームワークがなく、機能の削減を恐れるチーム
• データに基づく判断ではなく、意見のぶつけ合いに終始するスコープの議論

重要なルール

1. 一つ追加したら、一つ削る。 機能を追加するには、同等の作業量に相当する機能を削る必要があります。例外はありません。「もっと頑張ります」も、「何とかします」も認められません。予算は固定です。機能を「対象外」から「あるとよい」に移すなら、別の機能を「あるとよい」から「対象外」に移します。Team Cherry は期限どおりにリリースするため、Hollow Knight からエリア全体を削りました。その結果、残った各エリアは鏡のように磨き上げられ、ゲームはより良いものになりました。

2. 割合は厳守です。 MoSCoW の配分を守る必要があります。「必須」は総作業量の60％、「あるとよい」は25％、「あればよい」は15％を占めます。「必須」が60％を超えた場合、個々の機能がどれだけ重要に感じられても、プロジェクトはリスクにさらされています。

3. 議論するのではなく、採点します。 機能スコアリングマトリクスを使い、意見を算術に置き換えます。機能はインパクト、実現可能性、リスクに基づいて採点します。判断は計算結果に委ねます。チームメンバーが異議を唱える場合は、結果ではなく個々のスコアに異議を唱えます。

4. バッファは必須です。 バッファが20％未満のスケジュールでは、期限に間に合いません。バッファは予期せぬ事態を吸収するためのものであり、ゲーム開発では予期せぬ事態が起こるのは当然です。バッファは神聖なものとして扱ってください。「機能追加のための余分な時間」ではありません。

5. 凍結日は厳守します。 すべてのマイルストーンの3日前に、機能追加を凍結します。凍結後に認められるのは、バグ修正と磨き込みだけです。凍結を破るには、プロデューサーレベルの承認と、別の箇所での相応の削減が必要です。

6. 見積もりは正直に出します。 これまでに同様のシステムを作ったことがない場合は、見積もりを2倍にしてください。技術に不慣れな場合は、3倍にしてください。楽観的な見積もりは、スコープクリープを育てる肥料です。

ワークフロー

---

🧠 フェーズ 1：機能の洗い出し

目標：現在計画中、進行中、または要望されているすべての機能をリストアップします。

スコープを評価するには、全体像を把握する必要があります。このフェーズでは、漏れのないリストを作成します。まだ絞り込まないでください。削除することになりそうな機能も、すべてリストに加えます。

FEATURE INVENTORY
-------------------------------------------------
ID   | Feature             | Status        | Requestor    | Est. Hours
-------------------------------------------------
F01  | [feature name]      | [planned/     | [who asked]  | [honest
F02  | [feature name]      |  in-progress/ |              |  estimate]
F03  | [feature name]      |  complete/    |              |
...  |                     |  requested]   |              |
-------------------------------------------------

Capture rules:
- Include features already in progress (sunk cost does not protect them)
- Include features someone mentioned casually ("wouldn't it be cool if...")
- Include features assumed but never written down (save system, settings menu)
- Estimate in hours, not days. Hours force specificity.
- If you cannot estimate a feature, mark it [UNKNOWN] -- that is itself a red flag

ユーザーに、計画中の機能をすべて説明してもらいます。見落とされている機能がないか、掘り下げて確認します。「設定メニューはありますか？ セーブシステムは？ チュートリアルは？ オプション画面は？ コントローラー対応は？」こうした当然あると思われがちな機能は、多くの時間を消費するにもかかわらず、リストに載っていないことがよくあります。

---

🎯 フェーズ 2：MoSCoW による分類

目標：すべての機能を、割合の制約を設けた 4 つの優先度に分類します。

MoSCoW は、希望を並べる作業ではありません。リソース配分のフレームワークです。割合は目安ではなく、制約です。

MoSCoW CLASSIFICATION
-------------------------------------------------
MUST HAVE (60% of total effort)
  The game literally does not function or ship without these.
  Test: "If this feature is missing, is the product broken?"
  - F01: [feature] -- [hours] -- Reason: [why it's essential]
  - F03: [feature] -- [hours] -- Reason: [why it's essential]
  Subtotal: [X hours] / Target: [60% of total hours]

SHOULD HAVE (25% of total effort)
  Significantly improves the game but it ships without them.
  Test: "Would a reviewer notice this is missing?"
  - F04: [feature] -- [hours] -- Reason: [why it matters]
  Subtotal: [X hours] / Target: [25% of total hours]

COULD HAVE (15% of total effort)
  Nice to have. First to be cut when time runs short.
  Test: "Would anyone outside the team notice this?"
  - F07: [feature] -- [hours] -- Reason: [what it adds]
  Subtotal: [X hours] / Target: [15% of total hours]

WON'T HAVE (0% -- explicitly deferred)
  Documented and deferred. Not forgotten, just not now.
  These protect the team from revisiting already-made decisions.
  - F09: [feature] -- Reason: [why it's deferred]
  - F10: [feature] -- Reason: [why it's deferred]
-------------------------------------------------

RED FLAGS:
- Won't Have is empty --> Every feature cannot be essential. Be honest.
- Must Have exceeds 60% --> Either the game is too ambitious or the
  classification is too generous. Demote features.
- All features are "Must Have" --> This is not prioritization. Start over.
  Force-rank the Must Haves against each other.

---

🚨 フェーズ 3：機能のスコアリングマトリックス

目標：主観的な議論を、各機能の定量的なスコアに置き換えます。

「実施しない」のラインより上にあるすべての機能を採点します。計算式は次のとおりです。 スコア = （影響度 x 実現可能性） / リスク

FEATURE SCORING MATRIX
-------------------------------------------------
Feature    | Impact | Feasibility | Risk  | Score  | Verdict
           | (1-5)  | (1-5)       | (1-5) |        |
-------------------------------------------------
[F01]      | [  ]   | [  ]        | [  ]  | [  ]   | [Keep/Evaluate/Cut]
[F02]      | [  ]   | [  ]        | [  ]  | [  ]   | [Keep/Evaluate/Cut]
...        |        |             |       |        |
-------------------------------------------------

SCORING GUIDE:
  Impact (1-5):
    5 = Core loop depends on it. Game is broken without it.
    4 = Major enhancement to player experience.
    3 = Noticeable improvement. Reviewers would mention it.
    2 = Minor polish. Players might notice if told.
    1 = Developer-facing. Players never see it directly.

  Feasibility (1-5):
    5 = Team has built this exact thing before. Hours are certain.
    4 = Similar to past work. Minor unknowns.
    3 = New territory but understood conceptually. Moderate unknowns.
    2 = Significant unknowns. Requires research or prototyping.
    1 = Nobody on the team has done this. Major technical risk.

  Risk (1-5):
    5 = Could derail the project if it goes wrong.
    4 = Could delay the milestone significantly.
    3 = Could cause a sprint to slip.
    2 = Might need rework but recoverable.
    1 = Low consequence if it fails.

VERDICT THRESHOLDS:
  Score >= 3.0  -->  KEEP. Feature earns its place.
  Score 2.0-3.0 -->  EVALUATE. Discuss. Can risk be reduced? Can scope shrink?
  Score < 2.0   -->  CUT. Move to Won't Have. Do not negotiate.

---

📋 フェーズ 4：スケジュールの妥当性確認

目標：残作業と残り時間を比較し、バッファを計算します。

ここでは、楽観的な見通しを算術で検証します。数字は意気込みに左右されません。

TIMELINE SANITY CHECK
-------------------------------------------------
CAPACITY CALCULATION:
  Team members:           [N]
  Available hours/week:   [X hours per person]
  Weeks remaining:        [Y weeks to milestone]
  Gross capacity:         [N x X x Y] hours
  Overhead deduction:     [-15% for meetings, admin, context switching]
  Net capacity:           [result] hours

WORK REMAINING:
  Must Have (incomplete):  [hours]
  Should Have (planned):   [hours]
  Could Have (planned):    [hours]
  Total planned work:      [hours]

BUFFER CALCULATION:
  Available buffer:        [Net capacity - Total planned work]
  Buffer percentage:       [buffer / net capacity x 100]%

  >= 30% buffer  🟢  HEALTHY. Room for surprises. Ship with confidence.
  20-30% buffer  🟡  CAUTION. Tight but manageable if no major surprises.
  10-20% buffer  🟠  WARNING. One surprise away from missing the deadline.
  < 10% buffer   🔴  CRITICAL. The deadline will be missed. Cut scope now.
  Negative buffer 💀  OVER-COMMITTED. The math says this is impossible.
                      Cut aggressively or extend the deadline.
-------------------------------------------------

REALITY ADJUSTMENTS:
  - Solo dev? Multiply estimates by 1.5 (context-switching overhead)
  - First game? Multiply estimates by 2.0 (learning curve)
  - Part-time team? Use actual committed hours, not aspirational hours
  - Unfamiliar engine? Add 15-25% to all estimates

---

📊 フェーズ 5：スコープクリープの検出

目標：スコープが制御不能に拡大している兆候を特定します。

スコープクリープには、特徴的な症状があります。以下の警告サインを確認してください。

SCOPE CREEP DETECTION CHECKLIST
-------------------------------------------------
Signal                                          | Present?
-------------------------------------------------
Feature list has grown since last check         | [Y/N]
No items in Won't Have category                 | [Y/N]
All features are classified "Must Have"         | [Y/N]
"Just one more thing" has been said recently    | [Y/N]
Features added without equivalent cuts          | [Y/N]
Estimates trending upward on existing features  | [Y/N]
New features appearing from casual conversation | [Y/N]
Buffer percentage decreasing sprint over sprint | [Y/N]
Team morale declining despite "progress"        | [Y/N]
Milestone dates have shifted more than once     | [Y/N]
-------------------------------------------------

SEVERITY:
  0-2 signals  🟢  Healthy scope management.
  3-4 signals  🟡  Early warning. Address now before it compounds.
  5-7 signals  🟠  Active scope creep. Immediate intervention needed.
  8-10 signals 🔴  Project at risk. Full scope reset required.

---

🛠️ フェーズ 6：変更凍結プロトコル

目標：マイルストーンの期限に対して、厳格な境界を設定します。

機能の追加は、どのマイルストーンでも 3 日前に凍結します。これは任意ではありません。

CHANGE FREEZE PROTOCOL
-------------------------------------------------
Milestone:          [name]
Milestone date:     [date]
Freeze date:        [milestone date - 3 days]

AFTER FREEZE, PERMITTED:
  - Bug fixes for existing features
  - Polish on existing features (animation, juice, audio)
  - Documentation and store page updates
  - Build and deployment pipeline work

AFTER FREEZE, PROHIBITED:
  - New features of any size
  - "Small" additions ("it'll only take an hour")
  - Scope changes to existing features
  - New art assets for unreleased features

FREEZE BREAK PROCEDURE (emergency only):
  1. Producer (or project lead) formally approves
  2. Equivalent-effort feature is cut simultaneously
  3. Decision is documented with rationale
  4. This counts as a scope creep signal in the next detection check
-------------------------------------------------

出力形式

このワークフローでは、スコープ評価レポートを作成します。

# Scope Assessment Report

## Traffic Light Status
[🟢 HEALTHY / 🟡 CAUTION / 🟠 WARNING / 🔴 CRITICAL]

## Summary
[2-3 sentences: overall assessment, key concern, recommended action]

## Feature Inventory
[Total features: N | Scored: N | Cut: N | Deferred: N]

## MoSCoW Breakdown
| Category    | Features | Hours | % of Total | Target % | Status |
|-------------|----------|-------|------------|----------|--------|
| Must Have   | [N]      | [X]   | [Y%]       | 60%      | [OK/OVER] |
| Should Have | [N]      | [X]   | [Y%]       | 25%      | [OK/OVER] |
| Could Have  | [N]      | [X]   | [Y%]       | 15%      | [OK/OVER] |
| Won't Have  | [N]      | --    | --         | --       | [populated/empty] |

## Feature Scores
[Sorted by score descending. Features below 2.0 marked for cut.]

## Timeline Assessment
- **Net capacity:** [hours]
- **Planned work:** [hours]
- **Buffer:** [hours] ([X%])
- **Buffer status:** [🟢/🟡/🟠/🔴]

## Scope Creep Signals
[N of 10 signals detected. List active signals.]

## Change Freeze
- **Next milestone:** [name] on [date]
- **Freeze date:** [date]
- **Days until freeze:** [N]

## Recommended Actions
1. [Most urgent action]
2. [Second priority]
3. [Third priority]

## Features to Cut (Recommended)
[List with rationale for each cut]

## Features to Keep (Confirmed)
[List with score and pillar alignment for each]

品質基準

スコープチェックが適切に行われたといえるのは、以下のすべてを満たす場合です。

• 計画中のすべての機能について、現実的な所要時間が見積もられている
• MoSCoW の割合が目標値（60/25/15）から 5% 以内に収まっている
• 「実施しない」カテゴリに少なくとも 2 項目が含まれている（空の場合、チェックは正直に行われていません）
• バッファの割合が計算され、信号機のステータスとともに報告されている
• 2.0 未満のスコアの機能が、「必須」または「実施すべき」カテゴリに残っていない
• セッション中に追加された項目に対して、「1 つ追加するなら 1 つ外す」ルールが適用されている
• スコープクリープの兆候が確認され、その件数が報告されている
• 次のマイルストーンの変更凍結日が設定されている
• レポートが実行可能な内容になっており、チームが何を作り、何を見送るべきかを正確に把握できる
• すべてのスコープ判断が意見ではなく、スコアとキャパシティの計算に基づいている

相互参照

• @docs/game-design-theory.md -- 機能が沿うべきデザインの柱
• @docs/collaboration-protocol.md -- 役割をまたいでスコープ変更を伝える方法
• @docs/coordination-rules.md -- スコープの衝突が発生した場合のエスカレーション経路
• @templates/sprint-plan.md -- スコープチェックの出力を取り込むスプリント計画テンプレート
• ワークフローの引き継ぎ：game-brainstorm または game-design-review から入力を受け取り、実行計画のために game-sprint-plan へ引き継ぎます

アンチパターン

スコープの確認で次のようなパターンが見られる場合、確認はうまく機能していません。

• ゴム印： 誰も対立を望まないため、すべてが通ります。確認で少なくとも1つの機能を削れなかったなら、十分に厳密ではありません。
• 人質になった機能： 「もう着手したのだから、削れません」。サンクコストは続行する理由にはなりません。残りの作業量が機能の価値を上回るなら、削除してください。Supergiantは『Hades』の開発途中で、当初の盾のメカニクスを廃止し、キャストシステムに置き換えました。盾には数か月分の作業が費やされていました。キャストによってゲームはより良くなりました。
• こっそり追加： 機能がMoSCoW分類を経ずに紛れ込みます。どんなに小さな機能でも、すべてマトリックスに通してください。
• 終わりのない必須機能： チームが「自分が欲しい」と「ゲームに必要」を混同するため、すべての機能が「必須」になります。容赦なく順位を付けてください。
• バッファ不足： 「バッファは必要ありません。もっと頑張ればいいだけです」。バッファは怠惰への保険ではありません。現実への保険です。ConcernedApeの『Stardew Valley』の開発には数年を要し、そのスケジュールには大幅なバッファが含まれていました――そして、その時間をすべて使い切りました。

AlterLab GameForge — インディーゲーム開発スキルスイートの一部です。