マガジン

1時間で作って公開するまでを時計で測る

遊びをつくる

執筆にClaudeを使用しています。

箱に収めたゲーム模型を三段の台へ取り出し、ファイル投稿での公開を表したイラスト。
記事のテーマをもとに制作したAI生成イラスト。

ゲームを1時間で作って公開する場面を考えてみます。タイマーを60分にセットして、企画を立て、コードを書き、動かして確かめ、投稿画面に作品を入れます。終わってみると「制作に時間がかかった」という印象だけが残ります。ところが、実際にそうだったかどうかは記録がなければわかりません。 この記事が確かめるのは、1時間のうち企画・制作・確認・投稿のどこに時間が流れていくかです。結果は書きません。代わりに、計り方、記録の取り方、数字の読み方を設計書として示します。読者が自分の1時間で実施すれば、自分の時間配分が出ます。 計測の対象は作品の出来ではなく、時間の使い方です。面白い作品が1時間でできたかどうかとは別の問いで、先に「どこで止まりやすいか」を知っておくと、次の制作で削る場所を選べます。

この記事の目次
  1. 「1時間」と「公開」の定義を先に決める
  2. 準備:区間タイマーと投稿の下ごしらえ
  3. 手順:5つのボタンで1時間を進める
  4. 記録の読み方:数字をどう判断に変えるか
  5. 起こりやすい誤り
  6. 次の行動

「1時間」と「公開」の定義を先に決める

計測では、始まりと終わりの定義が曖昧だと数字が比べられなくなります。次の3点を、始める前に紙に書いて固定します。

  • 開始:お題や制約を見た時点ではなく、「企画」ボタンを押した時点です。
  • 終了:アソバースの投稿画面で公開の操作を終え、公開された作品ページを開いて起動できた時点です。
  • 対象の範囲:1時間以内に終わらなかった場合も、打ち切らずに最後まで測ります。60分を超えた分も記録し、「60分時点でどこまで進んでいたか」は別にメモします。

アソバースの投稿は、入力、表示の確認、公開の3段階です。この3段階をすべて「投稿」の区間に含めます。公開内容の更新や非公開化は計測の対象外にします。

固定する条件は、あと2つあります。

  • 紹介文と遊び方:投稿画面の「紹介文と遊び方を作成」を使うかどうかを決めます。この機能は公開済みURLまたは本人の検証済みアップロードを読み取って下書きを作り、「この文章を使う」を押したときだけ反映されます。使うなら、その時間も投稿区間に入れます。利用は1時間3回までなので、何度も試す前提にはしません。
  • お題:毎回違うジャンルにすると、時間の差が作品の種類によるものか進め方によるものか区別できません。「ボタンを押して遊ぶ1画面の小品」のように、種類をそろえます。

準備:区間タイマーと投稿の下ごしらえ

区間を5つに分ける

記録する区間は「企画」「制作」「確認」「投稿」「迷い・待ち」の5つです。最後の「迷い・待ち」は、手が止まって次に何をするか決まっていない時間、または読み込みなど何かを待っている時間です。ここを独立させると、4つの作業区間に迷いが混ざらず、時間が漏れる場所が見えます。

区間は順番どおりに進むとは限りません。確認で不具合に気づいて制作に戻る場面は普通にあります。そのため、各区間の合計時間に加えて「その区間に入った回数」も記録します。回数が多い区間は、行き来が多い区間です。

記録用の最小タイマー

ストップウォッチを手で止めて紙に書くと、記録の手間が計測の邪魔になります。次のHTMLを1ファイルで保存してブラウザで開くと、ボタンを押すたびに区間が切り替わり、区間ごとの合計時間と入った回数が表示されます。外部通信は使いません。画面を閉じると記録は消えるので、終了ボタンを押したら表示を書き写してください。

html
<!doctype html>
<meta charset="utf-8">
<title>区間タイマー</title>
<p id="clock">0:00</p>
<div id="btns"></div>
<ul id="sum"></ul>
<button id="endBtn">終了</button>
<script>
const names=["企画","制作","確認","投稿","迷い・待ち"];
const total=names.map(()=>0), count=names.map(()=>0);
let cur=-1, since=0, startAt=0;
const $=id=>document.getElementById(id);
const fmt=s=>Math.floor(s/60)+":"+String(Math.floor(s%60)).padStart(2,"0");
const flush=()=>{ if(cur>=0) total[cur]+=Date.now()-since; since=Date.now(); };
const show=()=>{ $("sum").innerHTML=names.map((n,i)=>
  "<li>"+n+" "+fmt(total[i]/1000)+"("+count[i]+"回)</li>").join(""); };
names.forEach((n,i)=>{
  const b=document.createElement("button");
  b.textContent=n;
  b.onclick=()=>{
    if(!startAt) startAt=Date.now();
    flush();
    if(cur!==i) count[i]++;
    cur=i; show();
  };
  $("btns").appendChild(b);
});
$("endBtn").onclick=()=>{ flush(); cur=-1; startAt=-1; show(); };
setInterval(()=>{ if(startAt>0){
  $("clock").textContent=fmt((Date.now()-startAt)/1000); flush(); show(); } },500);
</script>

使い方は単純で、作業が変わるたびに該当のボタンを押すだけです。手が止まったと気づいたら「迷い・待ち」を押し、作業を再開したらそのボタンを押します。

投稿の下ごしらえ

投稿区間が膨らむ原因の多くは、制作とは関係のない準備不足です。計測の開始前に、次を済ませておきます。

  • メールアドレスの確認:公開にはメールアドレスの確認が必要です。確認メールが届くまで待つ時間が、投稿区間に入ってしまいます。
  • ファイル構成の確認:HTMLを直接アップロードするか、ZIPにするかを決めます。ZIPなら入口は直下の index.html で、素材は相対パスで参照します。サーバー用コードやサービスワーカー、SharedArrayBufferを使うマルチスレッドは対象外です。サイズの上限などは投稿画面の案内で確認してください。
  • 試し投稿を使いすぎない:アップロードには1人あたりUTCの1日10回までという回数の制限があります。計測のたびに何度もアップロードし直す設計にはしません。

手順:5つのボタンで1時間を進める

準備ができたら、次の順で進めます。時間の目安は書きません。配分を決めずに進めたほうが、自然な配分が記録に出ます。

  1. 区間タイマーを開き、お題と終了条件を手元に置いて「企画」を押します。
  2. 企画では、遊び方を1文で書き、操作を決め、勝ち負けか終わり方を決めます。紙でも画面上でも構いません。決まったら「制作」に切り替えます。
  3. 制作中は、作業が変わるたびにボタンを押します。コードを書く時間は「制作」、画面を開いて動かす時間は「確認」です。この線引きを守ると、確認が制作に埋もれません。
  4. 手が止まったら「迷い・待ち」を押します。止まった理由を、1語だけ紙に書きます。たとえば「見た目」「バグ」「仕様」「ファイル」のような語です。
  5. 公開用のファイルがそろったら「投稿」に切り替え、入力、表示の確認、公開まで進めます。公開後に作品ページを開いて起動できたら「終了」を押します。

同じ条件で2〜3回繰り返すのがおすすめです。1回目は、どこで迷うかを知らない状態の記録です。2回目以降は、1回目を知ったうえでの記録です。違いが出れば、それが学習の効果です。

記録の読み方:数字をどう判断に変えるか

終了したら、各区間の時間を全体の時間で割って割合にします。絶対時間より割合のほうが、制作の規模が違う回どうしでも比べられます。次の表は、判断の目安です。数字は結果ではなく、読み方の基準として置いています。

  • 「迷い・待ち」が全体の2割を超える、疑うこと:仕様が固まらないまま作り始めている、次に試すこと:企画で「やらないこと」を3つ書く
  • 「企画」が短く、制作中の迷いが多い、疑うこと:企画で決め込みが足りない、次に試すこと:企画の終了条件を「操作・終わり方が決まった」にする
  • 「確認」の回数が多く1回が短い、疑うこと:小刻みに確認できていて健全、次に試すこと:制作中の確認頻度を保つ
  • 「確認」が1〜2回で長い、疑うこと:最後にまとめて確認している、次に試すこと:動く最小形を早めに作り、足しながら確認する
  • 「投稿」が制作と同程度に長い、疑うこと:下ごしらえの不足、次に試すこと:準備の項目を見直し、紹介文の下書きも先に用意する
  • 制作への戻りが多い、疑うこと:確認で見つかる不具合が多い、次に試すこと:戻る原因を「迷い」の1語メモと照らす

見る順番は次のとおりです。まず、最も長い区間を1つ選びます。次に、その区間の回数を見ます。回数が少なくて長いなら、1回の作業が重い区間です。回数が多くて長いなら、行き来が多い区間です。対処がまったく違うので、合計だけで判断しないでください。

「迷い・待ち」の1語メモは、集計して種類ごとに数えます。「仕様」が多ければ企画の改善、「バグ」が多ければ確認の頻度の改善、「ファイル」が多ければ投稿前の準備の改善、というように、メモの語が次の一手を指します。

2〜3回の記録は、割合の並びを見比べます。平均を出すより、「毎回同じ区間が最大か」「回ごとに入れ替わるか」を見てください。毎回同じなら構造的な課題で、入れ替わるなら作品ごとの偶然が大きいと読めます。

起こりやすい誤り

計測そのものを歪める誤りがいくつかあります。

  • ボタンを押し忘れる:作業に集中すると、切り替えを忘れます。忘れたと気づいた時点で押し、紙に「何分ごろ切り替え忘れ」と書いておきます。後から補正はしません。
  • 「確認」を作業に混ぜる:制作中に画面を開く時間が長くなると、制作と確認が区別できなくなります。ブラウザのタブを切り替えるたびにボタンを押す、と決めておくと防げます。
  • 打ち切って成功にする:60分で止めて「ほぼ公開」と記録すると、投稿区間が空白になります。最も情報が多いのは、公開まで測った記録です。
  • 一度の記録で結論を出す:1回の数字は、その回のお題や体調の影響を強く受けます。2〜3回の並びで見ます。
  • 作品を盛りすぎる:計測を意識して無理に規模を増やすと、制作が膨らみます。お題を固定し、機能追加は終了後に回します。

次の行動

まず区間タイマーを保存し、お題を1つ決めて、定義の3点を紙に書いてください。次に、メール確認とファイル構成の下ごしらえを済ませて、1回目の1時間を測ります。終わったら、最も長い区間とその回数を見て、「迷い・待ち」の1語メモと照らしてください。そこから、2回目に変える点を1つだけ決めます。