game-postmortem

AlterLab GameForge -- 事後分析ワークフロー

リリースされたゲームには、そのゲーム自体よりも価値のあるストーリーがあります。事後分析では、そのストーリーを掘り起こし、体系化して、再利用可能な知識へと変換します。事後分析を行わなければ、チームは次のプロジェクトでも同じ過ちを繰り返します。無能だからではなく、記憶は選択的であり、体系化されていない振り返りはパターンよりも物語へと流れがちだからです。

GDC Vaultには、苦い経験から学んだスタジオの事後分析が数多く収録されています。SupergiantはHadesの開発サイクルごとに体系的な振り返りを記録し、その組織的な知見はHades IIの制作パイプラインに直接活かされました。ObsidianがFallout: New Vegasの事後分析で明らかにした「18か月の死の行進」というアンチパターンは、The Outer Worldsの制作で意図的に回避されました。ConcernedApeによるStardew Valleyの事後分析では、個人開発者にとって最大のリスクは技術面ではなく、3.5年間にわたって外部からフィードバックを得る仕組みがなかったことだと判明しました。

優れた事後分析は、誰かを責める場ではありません。勝利を祝う場でもありません。次のプロジェクト、次のスプリント、あるいは次のチームに役立つ知識を生み出すための、体系的なデータ抽出プロセスです。

目的と実施のきっかけ

次のような場合に、このワークフローを使用します：

• プロジェクトがリリースされ、チームが学んだことを記録したい
• 重要なマイルストーン（垂直スライス、アルファ、ベータ、ローンチ）が完了した
• スプリントサイクルが終了し、振り返りよりも踏み込んだ分析を行いたい
• プロジェクトが中止され、活用できる教訓を引き出す必要がある
• 新しいチームメンバーから「前回は何がうまくいかなかったのですか？」と尋ねられた

このワークフローで解決する課題：

• プロジェクトをまたいで同じ制作上のミスを繰り返す
• 成功事例だけが記憶される生存者バイアス
• 失敗を分析せず隠してしまう、非難を重視する文化
• チームメンバーの退職に伴う組織的知見の喪失
• 抽象的すぎて行動につなげられない、曖昧な「学んだこと」のリスト

game-retrospectiveとの関係

game-retrospective スキルは、スプリント単位およびマイルストーン単位の振り返りを扱います。より短く、焦点を絞り、次のスプリントに向けてすぐに実行できる成果を出します。事後分析はより広く、より深く、プロジェクト全体または主要なフェーズを分析し、スプリント固有の問題ではなく、システム全体に見られるパターンを探します。

「次のスプリントでは何を変えるべきか？」には game-retrospective を使用します。 「次のプロジェクトでは何を変えるべきか？」には game-postmortem を使用します。

過去のスプリントの振り返りデータがある場合、パターン分析の入力データとして事後分析に取り込みます（フェーズ3を参照）。

プロジェクトデータ（自動入力）

これらの値は、シェルによる前処理で自動的に挿入されます。感情ではなく事実に基づいて振り返りを行えるよう、プロジェクトの定量データを示します。

• コミット総数：!git rev-list --count HEAD 2>/dev/null || echo "No git history"
• プロジェクト期間：!echo "First commit: $(git log --reverse --format='%ai' 2>/dev/null | head -1 || echo 'unknown') / Latest commit: $(git log -1 --format='%ai' 2>/dev/null || echo 'unknown')"
• 直近12週間のコミット頻度：!git log --since="12 weeks ago" --format="%aW" 2>/dev/null | sort | uniq -c | sort -rn | head -12 || echo "No recent history"
• コントリビューター：!git shortlog -sn --no-merges 2>/dev/null || echo "No contributor data"
• ファイルの変更頻度（変更回数が多いファイル）：!git log --pretty=format: --name-only 2>/dev/null | sort | uniq -c | sort -rn | head -15 || echo "No file history"
• タグ／マイルストーンの履歴：!git tag -l --sort=-creatordate --format='%(refname:short) %(creatordate:short)' 2>/dev/null | head -10 || echo "No tags"
• オープン中のイシュー：!gh issue list --limit 20 --state open 2>/dev/null || echo "No GitHub issues accessible"
• クローズ済みのイシュー：!gh issue list --limit 20 --state closed 2>/dev/null || echo "No GitHub issues accessible"
• 振り返りメモ：!ls production/sprints/*retro* production/sprints/*retrospective* 2>/dev/null || echo "No retrospective files found"
• スプリントデータ：!ls production/session-state/last-sprint.json production/session-state/velocity.json 2>/dev/null || echo "No sprint state data"

重要なルール

1. 個人を責めず、パターンに注目します。 失敗の原因として個人を名指しする振り返りは、率直な振り返りにはなりません。問題の原因はプロセス、意思決定、システム上の状況に求め、決して人に帰属させないでください。「レンダリングパイプラインにはコードレビューのゲートがありませんでした」は実行可能な指摘です。「Dave がひどいシェーダーを書きました」は有害で、役に立ちません。

2. 感情よりデータを優先します。 主観的な振り返りに移る前に、定量データ（コミット履歴、ベロシティの推移、バグの件数）から始めます。数値を基準にすることで、会話の軸を定め、記憶の書き換えを防ぎます。上記の自動入力データは出発点であり、飾りではありません。

3. 成功と失敗を同等に扱います。 失敗しか分析しないチームは、学習性無力感に陥ります。成功を称賛するだけのチームは、盲点を抱えるようになります。振り返りでは、両方に構造化された時間を割り当てます。

4. 抽象論ではなく具体策を示します。 「もっとよくコミュニケーションを取るべきです」は教訓ではありません。「各スプリントの開始時に15分間の同期ミーティングを行い、アートとコードの優先順位をすり合わせるべきです」は教訓です。すべての指摘から、具体的で実行可能なアクション項目を導き出してください。

5. 成果をアーカイブします。 振り返り文書は production/milestones/ または design/postmortems/ に保存し、今後のプロジェクト設定時に参照します。フォルダーに置かれたまま二度と読まれない振り返りには、価値がありません。

ワークフロー

振り返りは5つのフェーズで進めます。各フェーズには、それぞれ固有の入力、活動、成果物があります。各フェーズは相互に積み重なるため、フェーズを省略したり、順序を入れ替えたりしないでください。

---

フェーズ1：データ収集

プロジェクトまたはマイルストーン期間について、定量データと定性データを収集します。

定量データ（自動入力フィールドと手動収集によるデータ）：

• 開発期間の総計（最初のコミットからリリース／マイルストーンまで）
• コミット頻度のパターン（繁忙期や停滞期はありましたか？）
• ファイル変更頻度の分析（最も変更されたファイルはどれですか？ それらは複雑さの集中箇所です）
• バグの推移（バグ件数は時間とともに増加しましたか、減少しましたか？）
• スプリントベロシティの履歴（production/session-state/velocity.json にデータがある場合）
• スコープの変更（当初の計画後に追加された機能、削除された機能） 定性的データ（チームまたは個人開発者の振り返りから収集）：
• 当初のビジョンは何でしたか？リリースした製品はそれと比べてどうですか？
• 設計の柱として掲げていたものは何でしたか？それらは守られていましたか？
• 当時は正しいと思えたものの、後になって間違いだと分かった判断は何でしたか？
• 開発に影響を与えた外部要因（市場の変化、個人的な事情、ツール）は何でしたか？
• プロジェクトを通じて、チームの士気はどのように推移しましたか？

個人開発者の場合、定性的データは自己省察から得られます。開発者は、自分自身のコミットメッセージ、TODO コメント、個人的な開発ログを見直してください。

---

フェーズ 2：チームの振り返り

具体的で回答可能な質問を用いて、体系的に振り返ります。これらの質問は、ノイズから有用な情報を抽出するためのものです。

うまくいったこと（維持し、強化する）：

1. プロジェクトに最も良い影響を与えた判断を一つ挙げると、何ですか？
2. 今後も必ず使いたいツール、プロセス、プラクティスは何ですか？
3. 異なる専門分野の間で、最も良かった協力の瞬間は何でしたか？
4. 予想よりも当初のビジョンに近い形でリリースできた機能は何ですか？その理由は何ですか？
5. チームが早期に特定し、うまく軽減できたリスクは何ですか？

うまくいかなかったこと（理解し、改善する）：

1. 手戻りや時間の浪費を最も招いた判断を一つ挙げると、何ですか？
2. 早い段階で見えていたのに、対処が遅れた問題は何ですか？
3. 専門分野やチームメンバー間で、コミュニケーションが途切れたのはどこですか？
4. 当初の設計から最も逸脱した機能は何ですか？逸脱の原因は何でしたか？
5. 意図的に蓄積した技術的負債は何ですか？そのトレードオフに見合う価値はありましたか？

予想外だったこと（想定外から学ぶ）：

1. 見積もりより大幅に長く（または短く）かかったタスクは何ですか？その理由は何ですか？
2. プレイヤーやテスターからのフィードバックで、最も予想外だったものは何ですか？
3. 期待どおりの性能を発揮しなかったツールや技術は何ですか（期待以上、または期待以下）？
4. プロジェクトのスケジュールや範囲に最も影響した外部の出来事は何ですか？
5. 間違いだと分かった前提は何ですか？

回答ごとに、「次回に向けて、これに対処する具体的な変更は何ですか？」と追加で尋ねてください。曖昧な回答には、具体的な行動につながるまで、曖昧な追加質問を重ねてください。

---

フェーズ 3：パターン分析

フェーズ 1 のデータとフェーズ 2 の振り返りを照合し、全体に共通するパターンを特定します。個々の出来事は症状です。パターンは病気です。

確認するパターンのカテゴリ：

見積もりのパターン：

• タスクは一貫して過小に見積もられていましたか？その倍率はどのくらいでしたか？
• 特定の専門分野は、他より見積もりの精度が低かったですか？
• プロジェクトを通じて見積もりの精度は向上しましたか？それとも横ばいでしたか？
• 利用可能であればスプリントのベロシティデータを比較してください。チームの見積もりバイアスは一定でしたか？

依存関係のパターン：

• 専門分野をまたぐ引き継ぎのうち、最も遅延を招いたものは何ですか？
• 繰り返し発生するボトルネック（常にアートを待っている、常にコードレビューを待っているなど）はありましたか？
• チームは依存関係を早期に特定していましたか？それともスプリントの途中で発見していましたか？

スコープのパターン：

• 機能のクリープはどの程度発生しましたか？当初のスコープ確定後に追加された機能を追跡してください。
• 機能の削減は先回りして（プレッシャーがかかる前に）行われましたか？それとも後手に回って（プレッシャーがかかってから）行われましたか？
• 削減した機能はそのまま削減されたままでしたか？それとも再び追加されましたか？

品質のパターン：

• バグはいつ混入し、いつ発見されましたか？その間にはどのくらいの遅れがありましたか？
• 特定のシステムで一貫してバグが多く発生していましたか？その理由は何ですか？（複雑さ？不明確な仕様？新しい技術？）
• 品質ゲート（コードレビュー、プレイテスト、QA）は問題を検出しましたか？それとも問題はプレイヤーにまで届きましたか？

コミュニケーションのパターン：

• 判断は文書化されていましたか？それとも口頭で伝えられていましたか？
• 判断が再検討または覆される頻度はどのくらいでしたか？
• すべてのチームメンバーに必要な情報が共有されていましたか？それとも情報のサイロ化が起きていましたか？

以前のスプリントの振り返りメモがある場合（自動入力されたデータから）、それを読み、繰り返し現れるテーマを探してください。連続する 3 回のスプリントの振り返りで問題として取り上げられたにもかかわらず、解決されなかった問題は、スプリント単位の問題ではなく、全体に関わる失敗です。

---

フェーズ 4：教訓の抽出

パターンを教訓に変換します。各教訓は、次の形式に従います。

LESSON FORMAT
---------------------------------------------------------------
Pattern observed: [what happened, with supporting data]
Root cause: [why it happened, traced to a process or decision]
Impact: [what it cost in time, quality, morale, or scope]
Lesson: [one sentence statement of what was learned]
Action item: [specific, implementable change for next project]
Owner: [who is responsible for implementing the change]
Verification: [how to check if the change was implemented]
---------------------------------------------------------------

浅い内容を20個作成するよりも、質の高い教訓を5〜10個目指しましょう。それぞれの教訓について、6か月後にチームが「ポストモーテムを受けてこれを変更し、その結果はこうなりました」と言えるものにしてください。

教訓を分野別に分類します。

• プロセスに関する教訓（チームの働き方）
• 技術に関する教訓（アーキテクチャ、ツール、エンジンの選択）
• デザインに関する教訓（メカニクス、コンテンツ、プレイヤー体験）
• 制作に関する教訓（スコープ、スケジュール、リソース配分）
• コミュニケーションに関する教訓（引き継ぎ、ドキュメント、意思決定）

---

フェーズ5：アクションアイテムとアーカイブ

教訓を具体的なアクションプランに落とし込み、ポストモーテムをアーカイブします。

アクションアイテムの形式：

ACTION ITEM
---------------------------------------------------------------
ID: PM-[project]-[number]
Lesson: [reference to lesson from Phase 4]
Action: [specific change to implement]
Owner: [responsible person or role]
Deadline: [when this should be in place — ideally before next project]
Status: [ ] Not started / [ ] In progress / [ ] Complete
Verification: [how to confirm it was done]
---------------------------------------------------------------

アーカイブ：

• 完成したポストモーテムを production/milestones/postmortem-[name].md に保存します
• 出力テンプレートとして @templates/post-mortem.md を参照します
• プロジェクトの README またはデザインドキュメントのインデックスに概要を追加します
• 教訓が共有プロセスに影響する場合は、該当する内容に応じて @docs/collaboration-protocol.md または @docs/coordination-rules.md を更新します

出力形式

このワークフローでは、次の構成のポストモーテムレポートを作成します。完全なテンプレートについては @templates/post-mortem.md を参照してください。

# Post-Mortem Report: [Project/Milestone Name]

**Date:** [date]
**Period covered:** [start date] to [end date]
**Team size:** [number]
**Project duration:** [weeks/months]
**Scope:** [project | milestone: name]

## Executive Summary
[3-5 sentences: what was built, whether it met its goals, and the top 3 lessons]

## Quantitative Overview
| Metric | Planned | Actual | Delta |
|--------|---------|--------|-------|
| Duration | [weeks] | [weeks] | [+/- weeks] |
| Features | [count] | [count] | [+/- count] |
| Bugs at ship | [target] | [actual] | [+/- count] |
| Sprint velocity avg | [planned] | [actual] | [+/- %] |

## What Went Well
1. [Finding with supporting evidence]
2. [Finding with supporting evidence]
3. [Finding with supporting evidence]

## What Went Wrong
1. [Finding with root cause analysis]
2. [Finding with root cause analysis]
3. [Finding with root cause analysis]

## Surprises
1. [Unexpected finding and what it revealed]
2. [Unexpected finding and what it revealed]

## Pattern Analysis
### Estimation Accuracy
[Analysis with data]

### Dependency Bottlenecks
[Analysis with data]

### Scope Management
[Analysis with data]

### Quality Trajectory
[Analysis with data]

## Lessons Learned
### Lesson 1: [Title]
- **Pattern:** [what happened]
- **Root cause:** [why]
- **Impact:** [cost]
- **Action:** [what to change]

### Lesson 2: [Title]
[repeat format]

## Action Items
| ID | Action | Owner | Deadline | Status |
|----|--------|-------|----------|--------|
| PM-001 | [action] | [owner] | [date] | Not started |

## Appendix
- Sprint retrospective summaries (if available)
- Commit frequency charts
- File churn analysis
- Bug trajectory data

品質基準

ポストモーテムが次のすべてを満たしていれば、成功です。

• 定量データがあり、定性的な分析を裏付けている
• 根拠を伴う「うまくいったこと」と「うまくいかなかったこと」が、それぞれ少なくとも3つある
• 個別の事案にとどまらず、少なくとも2つのシステム的なパターンが特定されている
• すべての教訓から、担当者が明確な、具体的で実行可能なアクションアイテムが導き出されている
• 個人を責める表現がない
• 文書が見つけやすい場所にアーカイブされている
• アクションアイテムに期限と検証基準がある
• 予想外だったことや、率直に語りにくいことについても正直に記載されている

使用例

1. 「ゲームをリリースしました。ポストモーテムを実施しましょう。」 5つのフェーズすべてを実施するワークフローです。利用可能なすべての Git データ、スプリント履歴、振り返りのメモを取り込みます。次のプロジェクトの準備に役立つ教訓を含む、プロジェクト全体を対象とした包括的なポストモーテムを作成します。

2. 「アルファのマイルストーンが完了しました。何を学びましたか？」 マイルストーンを対象としたポストモーテムです。データ収集の対象をプロジェクト開始からアルファまでの期間に絞ります。アルファの成果物を当初のアルファ目標と比較します。ベータの前に適用できる教訓を抽出します。

3. 「このプロジェクトは中止になりました。何か活かせるものはありましたか？」 中止後のポストモーテムです。プロジェクトが失敗した理由を理解するため、フェーズ3（パターン分析）を特に重視します。アクションアイテムでは、同じ結果を避けるために次のプロジェクトで変更すべきことに焦点を当てます。正直でありながら建設的な内容にします。

4. 「私は個人開発者で、初めてのゲームを完成させました。何を変えるべきでしょうか？」 個人開発者向けのポストモーテムです。フェーズ2を自己省察として進めます。コミット頻度のパターンから、働き方の習慣がわかります（過度な追い込みや、燃え尽きによる空白期間があったか）。タスクごとの見積もり精度から、個人的な偏りのパターンがわかります。アクションアイテムは、個人のプロセス改善とします。

5. 「新しいプロジェクトを始めるところです。前回のプロジェクトのポストモーテムには何が書かれていましたか？」 ポストモーテムを取得して活用します。アーカイブ済みのポストモーテムを読み、アクションアイテムを確認し、実施済みのものと未実施のものをチェックします。対処されていない教訓を、新しいプロジェクトの game-start ワークフローに反映します。

エージェントプロトコル

• 対話の標準については @docs/collaboration-protocol.md を読み込みます
• エスカレーション経路については @docs/coordination-rules.md を読み込みます
• 出力テンプレートとして @templates/post-mortem.md を参照します
• 完成したポストモーテムを production/milestones/postmortem-[name].md に保存します
• スプリントの振り返りデータがある場合は、フェーズ3で取り込みます
• ベロシティデータがある場合は、定量的な概要に含めます
• game-retrospective の実施後に実行する場合は、その振り返りの出力をフェーズ2の入力として使用します

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