0から1への最後の一歩：次の作品に生かせる振り返りの進め方

本当に役立つ振り返りは、祝勝会でも責任追及の場でもなく、計画、実績、証拠、次回のルールを結び付けるものだ。最終的に生み出すべき資産は三つある。継続する取り組み、変えるべき仕組み、次のプロジェクトの着手前に検証する仮説だ。担当者と実行のきっかけがない「教訓」は、すぐに忘れられてしまう。

二回に分けて実施してもよい。公開から数日後に運営の振り返りを行い、進行を妨げる問題や連携の負担に対応する。数週間後、売上、完了状況、フィードバックが比較的安定した時点で、プロジェクト全体を振り返る。毎回、時系列、予算、バージョン、不具合、テスト、データ、ユーザーに関する証拠を事前に集め、会議で記憶を頼りに議論しないようにする。

各職種の担当者には、まず個別に書いてもらう。当初の目標、実際の結果、最大の想定外、残すべきこと一つ、変えるべきこと一つだ。扱いの難しい問題を匿名で集めれば、権力関係の影響を減らせる。ただし、結論ではプロセスの責任者への責任の割り当てを公開し、匿名のまま消えてしまわないようにする。

企画承認時のプレイヤーへの約束、範囲、やらないことのリスト、予算、成功指標を取り出し、一項目ずつ比較する。何を実現し、何を意図的に修正し、何が意思決定なしにひそかにずれたのか。結果のよいプロジェクトでも、その過程は再現できないかもしれない。市場での成果が平凡でも、重要な仮説を検証できた場合がある。

アウトプットと成果を区別する。200分撮影したことはアウトプットであり、プレイヤーが理解して再プレイしたいと思うことが成果だ。12種類のエンディングを作ったことはアウトプットであり、エンディングで選択の意味が回収されることが成果だ。振り返りでは成果を軸に、アウトプットを作る価値があったかを説明する。

題材選び、コアループ、脚本、プロトタイプ、プリプロダクション、撮影、ポストプロダクション、組み込み、テスト、リリース、運営まで、段階ごとに確認する。各問題について、少なくとも次を問い直す。最初に確認できる兆候はいつ現れたか、なぜその時点で対処しなかったか、どのプロセスやインセンティブが問題を存続させたか、最終的にどのような影響を及ぼしたか。

仕組みの問題を「誰かの注意不足」で片付けない。安定したID、自動検証、明確な正本となる一覧がないためにファイルの接続を間違えたのなら、個人に注意するだけでは次のプロジェクトでも繰り返す。逆に、「プロセスの問題」という言葉で実際の意思決定を曖昧にしてもいけない。誰が、いつ、それを変える権限を持っていたかを記録する。

創作では、選択肢の理解、キャラクターのつながり、テンポ、エンディング、再プレイを見る。制作では、重複を除いた固有映像の分数、撮影効率、追加撮影、手戻り、アセットの誤りを見る。技術では、切り替え、セーブ、性能、ツールを見る。事業では、ストアのコンバージョン、ウィッシュリスト、返金、レビュー、サポート費用を見る。四つを同じ時系列に並べてこそ、因果関係が見えてくる。

例えば、プレイヤーが分岐に意味がないと不満を述べる原因は、脚本の分岐が早すぎる段階で合流していることかもしれない。予算の都合で反応を示すカットを削った、現場で分岐の出口を撮り忘れた、プログラムの読み込みエラーで常に同じ動画に進む、といった可能性もある。振り返りで、最後に問題に触れた職種だけに責任を押し付けてはいけない。

続ける項目には適用条件を明記する。例えば、「技術面の不確実性が高いときは、3分間のバーティカルスライスを続ける」。やめる項目には代替策を示す。例えば、「グループチャットでの素材確認をやめ、チェックサム付きのアセット一覧を使う」。試す項目は検証可能な実験として書く。例えば、「次のプロジェクトでは、まず五つのノードで縦画面の選択肢レイアウトをテストする」。

各項目に担当者、実行時期、完了の証拠を指定する。「コミュニケーションを強化する」を、「脚本を確定するたびにプロデューサーが影響表を公開し、四つの職種が24時間以内に確認する」に変える。具体的であるほど、次回の行動を変えやすい。

ノードカード、変数表、分岐予算、状態カード、撮影記録表、エンコードプリセット、テストマトリクス、リリースチェックリストを更新する。テンプレートにはバージョン、出典プロジェクト、使用条件を明記する。次のプロジェクトを始めるときは、今も適用できるかをまず問い直す。ベストプラクティスは現時点の証拠に基づく初期値であり、永遠の法則ではない。

最終ビルド、ソースファイル、ライセンス、セーブデータのサンプル、データ辞書、ダッシュボードの定義、重要な意思決定をアーカイブする。元の担当者だけが特定のクラウドストレージのフォルダを知っている状態にせず、新しいメンバーも見つけて理解できるようにする。

答えが得られなかった問いを列挙する。縦画面のユーザーは短い選択肢を好むのか。二つのプレイヤーは低性能端末でも安定するのか。特定の種類のエンディングは再プレイを促すのか。影響と不確実性で優先順位を付け、最上位の項目を次のプロジェクトのプロトタイプに入れる。いきなり大規模な制作に進めない。

反証された仮説も記録し、名前を変えてチームが再び投資するのを防ぐ。反証は失敗ではない。次回の範囲をより明確にするものだ。

会議が終わっただけでは完了ではない。二週間以内に振り返り文書を公開し、テンプレートとプロセスを更新し、担当者が追跡できるアクション項目を作る。そして次のプロジェクトの企画承認会議で、一項目ずつ採用されたかを確認する。ある決定を実行しなくなった場合は、黙って忘れるのではなく、新たな理由を記録する。

最後に、一ページのプロジェクトマップを残す。一文のプレイヤーへの約束から完成品まで、最も重要な五つの決定、最大の三つのずれ、次回最優先で検証することをまとめる。何十ページもの時系列記録よりも、新しいチームが経緯を理解する助けになる。

次のステップ：二時間のプロジェクト振り返り会議を設定し、全員に事前の証拠提出を求める。会議では、続ける、やめる、試す項目のうち最も重要な五つだけを決め、次のプロジェクトのテンプレートと着手条件に直接書き込む。