テストを一度もしない制作では、公開後の初日に何件の不具合が見つかるか：実験の設計書

「テストをしない」を先に定義する

この実験で最初に決めるのは、何を「確認」とみなすかです。曖昧なままだと、途中で「ちょっと動かしただけ」が入り込みます。次のように線を引いておきます。

• 確認とみなす行為：ブラウザでゲームを開く、ボタンを押す、最後まで遊ぶ、別の端末で開く
• 確認とみなさない行為：コードを書く、ファイルを保存する、投稿画面の入力を埋める
• 扱いを決めておく行為：投稿の「入力→表示の確認→公開」にある表示の確認。画面を見るだけで操作しないと決め、見た事実を記録表に書きます

「コードを読み返す」も迷うところです。読み返しは確認ではないと割り切るか、禁止にするか、事前に決めて記録表の先頭に書いてください。決めた内容より、決めたことを最後まで守ったことが大切です。

もう一つ、安全面の条件があります。実際の遊び手に触れてもらうので、壊れても困らない内容にします。個人情報の入力欄、課金や外部への送信、長く遊ばないと進行を失う仕組みは入れません。紹介文には「未確認の試作です。不具合があれば教えてください」と書き、遊び手に前提を伝えます。

用意するもの

試作の大きさ

1〜2時間で作り終える規模にします。1画面、操作は1〜2種類、終わりがあるものが適しています。次のような最小構成を例に、自分の作品に置き換えてください。

<!doctype html>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>30秒タップ</title>
<button id="b" style="font-size:2rem;padding:1rem 2rem">スタート</button>
<p id="t">残り 30 秒</p><p id="s">0 点</p>
<script>
let score = 0, left = 30, timer = null;
const b = document.getElementById("b");
b.onclick = () => {
  if (!timer) {
    score = 0; left = 30; b.textContent = "タップ！";
    timer = setInterval(() => {
      left--;
      t.textContent = "残り " + left + " 秒";
      if (left <= 0) {
        clearInterval(timer); timer = null;
        b.textContent = "もう一度";
      }
    }, 1000);
  } else { score++; }
  s.textContent = score + " 点";
};
</script>

この例のような小さなコードでも、遊び手の端末や使い方によっては思わぬ点が報告されます。仕込んだ不具合は入れないでください。実験の対象は、作り手が気づかずに残した問題だけです。

報告の受け口

遊び手が問題を伝える経路を、公開前に決めます。アソバースで確認済みの範囲では、次の2つが使えます。

• レビュー：1〜2,000文字で書けます。ただしメールアドレスの確認が必要で、自作の作品は評価できません。
• プロフィールの問い合わせページ：本人が明示的に公開を選んだときだけ表示されます。使う場合は、問い合わせ先のHTTPS URLを事前に用意します。

フレンドやチャットの機能はありません。身近な人に遊んでもらうなら、報告の返し先を別に伝えておきます。経路ごとに集まり方が違うため、記録表には「どの経路で届いたか」の列を必ず作ります。

記録表

表計算でも紙でも構いません。列は次のとおりです。

• 受領日時、内容：報告を読んだ時刻ではなく、届いた時刻
• 経路、内容：レビュー、問い合わせページ、口頭など
• 原文の要約、内容：一文程度。解釈を足さない
• 分類、内容：後述の8分類から一つ
• 重さ、内容：遊べない／遊びづらい／気になる
• 再現、内容：再現できた／できない／未確認
• 原因の番号、内容：同じ原因の報告は同じ番号

手順

1. 試作を作ります。作っている間も、ブラウザで開いて動かしてはいけません。
2. 実験の条件を書き出します。確認の定義、観察する時間の長さ（公開から24時間が目安です）、時刻の基準（日本時間かUTCか）を記録表の先頭に書きます。
3. 紹介文に「未確認の試作」と書き、報告の返し先を案内して公開します。
4. 公開した時刻を記録します。以後24時間は、コードを直さないと決めます。直す場合は、直した時刻と内容を別に記録し、その後の報告は「修正後」として区別します。
5. 報告が届くたびに、記録表の1行を埋めます。分類と重さは、その場では仮置きで構いません。
6. 24時間たったら受付を締め、その時点の行数を確定します。ここで初めて自分の手で試作を動かし、再現できるかを確かめます。
7. 再現した結果を「再現」の列に書き込み、同じ原因の報告をまとめて原因の番号を振ります。

公開後に緊急で止めたいときは、非公開化を使えます。ただし使った時点で観察は中断になります。時刻と理由を記録に残してください。なお、アップロードは1人につきUTCの1日10回までという上限があります。修正版を何度も出し直す前提の計画は避けてください。

記録の取り方と分類

数える単位は三つあります。混ぜると読み違えるので、別々に集計します。

• 報告件数：届いた行の数です。
• 原因件数：同じ原因の報告をまとめた数です。同じ不具合を5人が書いても、原因は1件です。
• 報告者の種類：端末や遊び方が異なる人が何通りいたかです。人数の正確な把握はできないため、分かる範囲で構いません。

分類は、実験の前に次の8つに固定します。途中で増やすと比較できなくなります。

• 起動・表示、例となる報告の傾向：開かない、文字が切れる、画面に収まらない
• 操作、例となる報告の傾向：タッチやキーボードで反応しない、押しにくい
• 進行、例となる報告の傾向：先へ進めない、終わらない、やり直せない
• ルールの伝わりにくさ、例となる報告の傾向：何をすればよいか分からない
• 環境依存、例となる報告の傾向：特定の端末やブラウザだけで起きる
• 音と動き、例となる報告の傾向：音が出ない、動きが激しすぎる
• 記録・保存、例となる報告の傾向：点数が消える、続きから遊べない
• 感想・要望、例となる報告の傾向：不具合ではなく好みや提案

最後の「感想・要望」は、不具合の件数から除くために置いています。「つまらない」という感想を不具合に数えると、件数が膨らみます。判断に迷った行は、分類を決める前に再現の列を埋め、再現できないものは仮置きのままにして集計します。

プレイ回数は、見られる範囲で併記すると役立ちます。ただし、これは作品を起動した回数です。人数ではなく、同じ端末・同じ作品の30分以内の再起動は重複として除かれます。「報告件数÷プレイ回数」を出すなら、人あたりの割合ではなく、起動あたりの目安として扱ってください。

結果の読み方と誤りやすい点

集計できたら、件数の多さより分布を見ます。読み方の目安は次のとおりです。

• 「ルールの伝わりにくさ」が多い：作り手には当然の手順が、画面に出ていません。最初の10秒で何をすればよいかを、文字か動きで見せる必要があります。
• 「操作」や「環境依存」が多い：作り手が使う端末や入力方法に偏って作っています。別の端末で開く手順を、公開前の習慣にする価値があります。
• 「進行」が少数でも重い：件数が少なくても、遊べなくなる問題は優先度が高くなります。重さの列を先に見てください。
• 報告がほとんどない：不具合がないとは言えません。見つけた人がいなかった、見つけても書かなかった、という可能性が残ります。

誤りやすい点は次のとおりです。

• 1回の結果を一般化する。別の試作で同じ分布になるとは限りません。
• 報告者に偏りがある。身近な人だけが遊べば、同じ環境の報告ばかりになります。
• 修正を挟んで件数を混ぜる。修正の前後は別の集計にします。
• 後から分類を作り直す。結果に合わせた分類は、実験になりません。

より確かな比較が欲しいなら、同じ規模の試作を二つ作り、片方だけ公開前に決まった確認項目で10分遊んでから公開する方法があります。比べるのは総件数ではなく、どの分類が減ったかです。減らなかった分類は、その確認項目では見つけられない種類の問題を示しています。

次の行動

まず、1〜2時間で作れる試作を決め、「確認とみなす行為」を紙に書いてください。次に、8分類と記録表の列を用意してから作り始めます。結果を見てから分類を変えないことだけは、実験の前に決めておきます。