「あとで直す」メモは何割が直されるのか：ゲーム制作の後回しリストを数える実験の設計書

問いを「何割が、いつ直ったか」に分解する

「メモが残り続ける」を測れる形にするため、問いを四つに分けます。

1. 週ごとに、メモは何件増え、何件閉じられ、何件が残っているか。
2. 直されたメモは、書いてから何日で直されたか。
3. 直されやすさは、種類（バグ、見た目、バランス調整、コード整理、調べもの）で違うか。
4. 直されやすさは、見込み時間（5分、30分、半日以上）や、遊びへの影響の有無で違うか。

1が「後回しの一覧がどう増えるか」、2〜4が「どれが実際に直されたか」に対応します。仮説を一つ決めておくと、結果を読むときに自分の思い込みと照らせます。たとえば「5分で済むメモほど先に直される」「遊びに影響するメモほど後回しにされない」といった予想を、実験の前に紙に書いておきます。

準備と手順：置き場を一本にして、三つの動作だけ決める

準備するもの

• 対象のゲーム一つ。2〜4週間で区切れる規模のものが向いています。期間が短すぎると、直す機会そのものが少なくなります。
• 後回しメモの置き場を一か所に決めます。コード内のTODOコメント、メモ帳、付箋などが散らばっている場合は、記録票に転記する運用にして、入口を一本にします。
• 記録票。表計算ソフトでもテキストファイルでも構いません。列は次のとおりです。

• ID、内容：通し番号。欠番にしません
• 書いた日、内容：年-月-日
• 種類、内容：バグ／見た目／バランス／整理／調べもの
• 見込み時間、内容：5分／30分／半日以上。書いた時点の見積もり
• 遊びへの影響、内容：あり／なし。書いた時点の判断
• 解決日、内容：空欄可
• 状態、内容：未着手／直した／やめた／不要になった

見込み時間と影響の有無は、書いた時点の見立てを記録します。直したあとで書き換えると、見立てが当たっていたかを検証できなくなります。

手順

動作は三つだけです。

1. 書く：「あとで直す」と思った瞬間に、記録票へ一行追加します。コード内にコメントを書く場合も、IDを添えて同じ行を作ります。
2. 閉じる：直したら、行を消さずに解決日と状態を入れます。直さないと決めたら状態を「やめた」にします。仕様変更で意味がなくなったら「不要になった」にします。
3. 棚卸し：週に一度、曜日を固定して未着手の件数を数え、その週の追加数・完了数・残数を別シートに書き写します。所要は数分で済ませます。

棚卸しの場で、メモを直すか直さないかを無理に決める必要はありません。この実験は直す行動を促すものではなく、普段どおりに作ったときの記録を取るものです。

集計：寿命の中央値と完了率を出す

期間の終わりに、次の数字を出します。

• 週ごとの「追加」「完了」「残数」（残数＝前週の残数＋追加−完了。やめた・不要になったも、閉じた件数として別に数えます）
• 種類別、見込み時間別、影響別の完了率（直した件数÷書いた件数）
• 直したメモの寿命（解決日−書いた日）の中央値

記録票をCSVに書き出せるなら、次の短いコードで種類別の完了率と寿命の中央値が出せます。自分のパソコンで開くだけの小さなHTMLで、外部通信はしません。1行の形式は「ID,書いた日,解決日,種類,状態」です。下の入力例は動作確認用の仮の行で、実験の結果ではありません。

<textarea id="t" rows="8" cols="50">
1,2026-11-01,2026-11-03,バグ,直した
2,2026-11-01,,見た目,未着手
3,2026-11-02,2026-11-09,整理,直した
</textarea>
<button onclick="run()">集計</button>
<pre id="o"></pre>
<script>
function run(){
  const day=s=>new Date(s).getTime()/864e5;
  const by={}, life=[];
  document.getElementById('t').value.trim().split('\n').forEach(l=>{
    const [id,w,d,k,s]=l.split(',');
    by[k]=by[k]||{n:0,done:0};
    by[k].n++;
    if(s==='直した'){by[k].done++; life.push(day(d)-day(w));}
  });
  life.sort((a,b)=>a-b);
  const m=life.length>>1;
  const med=life.length%2?life[m]:(life[m-1]+life[m])/2;
  let out='寿命の中央値(日): '+(life.length?med:'なし')+'\n';
  for(const k in by) out+=k+': '+by[k].done+'/'+by[k].n+'\n';
  document.getElementById('o').textContent=out;
}
</script>

このコードを、アソバースへ投稿するゲームの中には入れないでください。記録用の道具であり、作品の一部ではありません。ブラウザで開くだけの手元のファイルとして使います。

結果の読み方：数字から何を判断するか

数字が出たら、次のように読みます。いずれも「こうなったら、こう疑う」という判断基準であり、結果の予言ではありません。

• 残数が週ごとに増え続けている場合：追加の速さが完了の速さを上回っています。書く基準が緩いのか、直す時間を確保できていないのか、追加の内訳（種類）を見て切り分けます。
• 見込み時間が5分のメモが残っている場合：直せない理由は作業量ではなく、「いつやるか」が決まっていないことかもしれません。棚卸しの場で5分のものだけを先に片づける運用を、次回の実験で試す手がかりになります。
• 見込み時間が半日以上のメモの完了率が低い場合：メモという形式が合っていない可能性があります。大きな作業は、メモではなく独立したタスクとして日程に入れる方が自然かもしれません。
• 「遊びへの影響あり」でも完了率が低い場合：影響度の見立てが当たっていたかを疑います。書いた時点の判断が甘かったのか、直す前に仕様が変わったのかを、状態の内訳（やめた／不要になった）で確かめます。
• 寿命が短い順に直されている場合：手が空いたときに近くの作業を片づける動きが出ている可能性があります。逆に、締切の直前に件数が集中して閉じられている場合は、期限が行動を決めています。

完了率や中央値の差が数件分の違いでしかないときは、傾向とは呼ばず、「この規模では判断できない」と記録するのが誠実です。

起こりやすい誤り：数え方で結果が歪む

数える実験には、数え方による歪みがつきものです。次の点を事前に確認します。

• 未完了を寿命の計算から外してしまう：寿命の中央値は、直ったメモだけで出すと短く見えます。まだ残っているメモの「書いてから経過した日数」も別に出し、並べて読みます。
• メモを消してしまう：消すと、完了率が実際より高く見えます。不要になったものも行を残し、状態だけを変えます。
• 計測がメモの書き方を変える：記録票に書くのが面倒で、メモを書かずに頭の中で済ませるようになると、母数が減ります。書く手間を最小に保ち、期間の途中で書式を変えません。
• 「直した」の定義がぶれる：一部だけ直したものをどう扱うか、先に決めておきます。たとえば「元のメモの趣旨が満たされたときだけ直したと数え、一部のみなら分割して別IDにする」という具合です。
• 期間が短すぎる・件数が少なすぎる：書いたメモが十数件では、種類別に分けると各項目が数件になります。種類別の比較は参考程度にとどめ、必要なら同じ手順で次のプロジェクトも記録して件数を増やします。
• 締切の影響を見落とす：公開日が決まっていると、直前に件数が動きます。公開日を記録の脇に書いておくと、締切の効果を読み分けられます。

次の行動

次に作るゲームの制作を始める日に、記録票の列だけを作り、棚卸しの曜日を決めてください。最初の一行目は、いま頭に浮かんでいる「あとで直す」で構いません。期間が終わったら、上のコードで種類別の完了率と寿命の中央値を出し、実験前に書いた予想と見比べてみます。公開後に直す場合は、アソバースでは公開内容の更新ができるので、「公開前に閉じるもの」と「公開後の更新で直すもの」に残りのメモを仕分ける欄を、記録票にもう一列足してみるのも一案です。