「全部入り」の企画書は、どこで止まるのか：進めて記録する実験の設計書

問いと仮説を先に書く

実験の問いは次の三つに絞ります。

1. 最初に止まるのは、どの機能か。
2. 止まった理由は、どの種類か。
3. 止まる前に、いくつの機能が「半分できた状態」で並んでいたか。

進める前に、各問いへの予想を書いておきます。「たぶんチャットで止まる」「セーブまでは行けるはず」のような一行で十分です。予想を先に書く目的は、後から「最初からわかっていた」と思い込むのを防ぐことです。この実験で得られるのは、止まった場所そのものよりも、予想と実際のズレです。ズレが大きかった場所には、自分の見積もりの癖があります。

予想は紙でもテキストファイルでも構いませんが、開始日の日付を添え、後から書き換えないようにします。

準備するもの

次の四つを用意します。

• 全部入りの企画書：機能を10個以上書きます。ひとり用モード、オンライン対戦、フレンド、チャット、共通スコアランキング、セーブ、実績、日本語と英語の切り替え、BGMと効果音、ステージエディタ、スマホ操作、動きを抑える設定のように、作りたいものを遠慮せず並べます。ここで「現実的に絞る」とこの実験は成立しません。
• 期間と持ち時間：たとえば「2週間、1日1時間」のように、先に決めて途中で変えません。
• 記録台帳：後述の表をそのまま使えます。
• 止まったと判定する条件：開始前に決めます。例を挙げます。
• 同じ機能で3セッション続けて完了条件に近づかない。
• 機能の実績時間が見積もりの2倍を超えた。
• 「今日はやりたくない」が2セッション続いた。

「止まる」の定義があいまいだと、記録が気分に左右されます。定義は少なくとも二つ、数えられる形で決めておきます。

手順

企画書を実験できる形にする

1. 機能を一行ずつ書き出し、各機能に完了条件を一文で付けます。 「チャット機能」ではなく「二人の画面で、送った文が1秒以内に相手に表示される」のように、できたかどうかが判定できる文にします。
2. 依存関係を書きます。 「オンライン対戦はセーブの仕組みより先に必要か」「ランキングは対戦の後か」のように、どの機能がどの機能の前提かを矢印で結びます。
3. 機能ごとに見積もりを分単位で書きます。 「たぶん半日」ではなく分にします。分にすると、後で比較できます。
4. 実行環境の制約を照合します。 アソバースで公開するつもりなら、投稿の条件を企画段階で確認します。たとえば現在の案内では、サーバー用コードやサービスワーカーは投稿の対象外です。オンライン対戦は公式の2作品のみで、投稿作品向けの共通対戦APIは未提供とされています。フレンドとチャット、ゲーム内スコアの共通ランキングも未提供です。クラウドセーブは作品ごとにJSONで128KiBまでです。これらに触れる機能には「環境の制約の可能性あり」と印を付けます。自作で実現できるかは別の問題なので、公開先の現在の案内で確認します。
5. 進める順番は企画書の上から順にします。 普段なら優先順位を付けますが、この実験では付けません。優先順位を付けると、止まりそうな機能を無意識に後回しにして、止まる場所が見えなくなります。
6. 毎セッションの終わりに台帳へ記録します。 作業を終えたら5分で書き、翌日に回しません。
7. 停止条件に達したら、そこで実験を止めます。 止まった時点で、各機能が「未着手・途中・完了」のどれかを一覧にします。

記録の取り方

記録の単位は1セッションです。1日に2回作業したら2行にします。次の列を持つ表を用意します。

• 日付、書くこと：セッションの日
• 機能、書くこと：取り組んだ機能名（1行に1つ）
• 予定分、書くこと：その機能に今日充てるつもりだった分数
• 実績分、書くこと：実際にかけた分数
• 増えた作業、書くこと：企画書にない作業（調べもの、設計やり直し、環境構築など）
• 詰まりの種類、書くこと：下記の分類から選ぶ（なければ空欄）
• 持ち越し、書くこと：次回に残したこと

「詰まりの種類」は、結果を読むときの分類に合わせます。

• 超過：見積もりより単純に時間がかかった。
• 待ち：前提の機能が終わっておらず進めない。
• 環境：公開先や実行環境ではそもそもできない、またはやり方がわからない。
• 検証不能：一人では試せない。たとえば二人で操作しないと確認できない対戦や招待は、ここに入りやすい種類です。
• 意欲：技術的な理由ではなく、手が動かない。

集計を手作業で行うのが面倒なら、次の最小のHTMLをブラウザで開いて使えます。数字は書式を示すための仮の値で、何かの結果ではありません。自分の台帳の値に置き換えます。

<!doctype html>
<meta charset="utf-8">
<title>停止点ログ集計</title>
<pre id="out"></pre>
<script>
// 機能ごとの見積もり（分）。値は書式を示す仮のものです
const est = { "ひとり用": 120, "セーブ": 60, "チャット": 90 };
// [機能, 実績分, 詰まりの種類]
const sessions = [
  ["ひとり用", 50, ""],
  ["ひとり用", 60, "超過"],
  ["セーブ", 40, ""],
  ["チャット", 30, "検証不能"],
];
const sum = {};
for (const [f, m, kind] of sessions) {
  sum[f] ??= { act: 0, kinds: {} };
  sum[f].act += m;
  if (kind) sum[f].kinds[kind] = (sum[f].kinds[kind] || 0) + 1;
}
let text = "";
for (const f in est) {
  const a = sum[f]?.act || 0;
  const r = (a / est[f]).toFixed(2);
  const k = JSON.stringify(sum[f]?.kinds || {});
  text += `${f}: 実績${a}分 / 見積${est[f]}分 = ${r}倍 ${r > 2 ? "【要注意】" : ""} ${k}\n`;
}
document.getElementById("out").textContent = text;
</script>

記録で大切なのは、不本意な行も消さないことです。進まなかった日の「0分」も、一行として残します。

結果の読み方

停止条件に達したら、台帳を次の三つの観点で読み返します。

最初に止まった機能の位置

止まった機能が依存関係の根元にあったのか、末端にあったのかを見ます。根元の機能（セーブの仕組みなど）で止まったなら、企画全体が止まる構造だったと読めます。末端（実績やエディタなど）で止まったなら、そこを切り落とせば企画の核は進められた可能性があります。

止まりの種類の偏り

詰まりの種類を数えます。偏り方で、次の手が変わります。

• 超過が多い：見積もりの癖の問題です。次の企画では、自分の実績比（実績÷見積）を係数として掛けて見積もります。
• 待ちが多い：進める順番や依存の置き方の問題です。前提の機能を先に小さく作ってから広げます。
• 環境が多い：企画段階の制約確認の問題です。公開先で提供されていない仕組みを前提にしていないか、機能を書く時点で照合します。
• 検証不能が多い：一人で確認できない機能を入れすぎています。二人以上が必要な機能は、テスト相手を確保できるかを先に決めます。
• 意欲が多い：技術より、企画の中心がどこにあるかがぼやけている可能性があります。

並行して「途中」だった機能の数

停止時点で「途中」の機能が何個あったかを数えます。目安として、3つ以上が同時に途中なら、並行しすぎで切り替えの負担が大きかった可能性があります。この数字は絶対的な基準ではなく、複数回実験したときに自分の中で比較する物差しです。

最後に、冒頭で書いた予想と見比べます。予想と実際の止まり方が一致した場合は、自分の見立ては正確だったと読めます。ずれた場合は、ずれた機能の見積もり根拠を見直します。

起こりやすい誤り

• 止まった後で定義を変える：「あれは止まったのではなく休んだだけ」と判定を緩めると、実験になりません。停止条件は開始前のものを使います。
• 見積もりを実績に合わせて書き換える：後から見積もりを直すと、超過が消えます。見積もりは最初の値を残し、修正したいなら別の列に書き足します。
• 半分できた機能を完了に数える：完了は、手順1で書いた完了条件を満たしたときだけです。
• 記録を翌日にまとめて書く：記憶は都合よく整います。作業直後の5分で書きます。
• 根性で突破した詰まりを記録しない：深夜に押し切って進んだ日こそ、本来は止まるはずだった場所です。詰まりの種類を空欄にせず書きます。
• 実験と本制作を混ぜる：この実験で作ったものは、実験用の試作です。きれいに仕上げ始めると、記録より成果物に意識が移ります。

次の行動

まず、作りたい機能を12個書き出し、それぞれに完了条件を一文で付けてください。次に、停止条件を二つ決めて日付入りで残し、最初の1セッションを始めます。止まったら、台帳の分類と並行数を読み返し、次の企画書に残す機能と切り落とす機能を決めます。その絞った企画を、作品として公開するところまで進めてみてください。