不具合の再現手順を書く：開始状態から結果までを残す

自分の画面では問題が出るのに、相談相手には「こちらでは起きません」と言われる。不具合の再現手順を書くときは、最後に見えた画面だけでなく、そこへ至る前の状態から記録します。

再現とは、同じ条件と操作で現象をもう一度確かめることです。架空の地域資料館の練習ページで、メニューを閉じても本文を覆う領域が残る場面を想定します。実在するサイトの障害報告ではありません。

画面を開いた直後へ戻って、始まりを決める

最初に対象のページと版を記録します。手元の練習ファイルなのか公開URLなのかを区別し、ブラウザー、端末、画面幅など、今回確かめた条件を添えます。まだ原因が分からないため、関係なさそうに見える条件も、まず観察の記録として扱います。

「メニューを閉じる」から書き始めると、相手はメニューをどう開くか探す必要があります。「ページを再読み込みし、メニューが閉じた状態から始める」のように、開始点をそろえます。入力が必要なら実際の個人情報ではなく、同じ現象を試せる仮の値を使ってください。

初めて開いたときと、別ページから戻ったときで違うなら、その二つは別の条件です。いつも同じ状態だと決めず、違いが出るまでに何をしたかを残します。

一行に一つの操作を書く

この模擬例なら、手順は「ページを再読み込みする」「メニューボタンを押す」「閉じるボタンを押す」「本文の展示案内リンクを押す」の四つです。一文に全部詰めず、番号を付けます。

「いつものように操作する」「何度か押す」では、相手が同じ動きを選べません。何回目で起きたか、待った時間が関係しそうならどの段階で待ったかも書きます。ただし測っていない時間を正確な秒数として記入しません。

自分でその手順を読み上げながら、もう一度操作してください。書いていない操作を途中で足したなら、手順も更新します。記憶の中で成立する説明と、記録どおりに実行できる説明を分けるためです。

期待と実際の結果を、原因の予想から離す

期待は「閉じた後は展示案内リンクへ進める」、実際の結果は「閉じた後、本文を押しても移動しない」です。「JavaScriptが壊れた」は原因の予想なので、実際の結果の欄には入れません。

画像を添える場合は、問題の場所を示し、画像だけで伝わらない操作順を文章で補います。今回なら、メニューが閉じた見た目と、本文へ移れない操作結果の両方が必要です。画面が似ていても同じ現象とは限りません。

エラーメッセージが出る場合の読み方は、エラーの名前と場所を分ける記事で扱っています。表示された内容は必要な範囲を記録し、認証情報や個人情報が含まれる部分を共有しないようにします。

記録を一枚にまとめると、次の形になります。これは上の想定を整理した模擬報告です。

対象：練習用の地域資料館ページ、メニュー修正前の版。開始状態：再読み込み直後、メニューは閉じている。操作：①メニューを開く、②閉じる、③本文の展示案内リンクを押す。期待：展示案内へ移る。現象：リンクを押しても移動しない。未記入：端末・ブラウザー・画面幅。原因：未特定。

「未記入」の環境は実際に試した条件で補います。このまま別の人へ渡しても、同じ環境で再現できるとは限りません。

起きなかった条件も、一つだけ残す

例えば広い画面では起きず、狭い画面では起きたなら、両方の幅と結果を書きます。これは原因が画面幅だと確定したという意味ではなく、次に比べる条件の候補です。

毎回起きない場合は、試した回数と起きた回数をそのまま記録します。一度成功しただけで解決としない一方、手順を再確認せず「ランダムな不具合」と結論付けるのも避けます。修正後は、同じ手順で結果が変わったかを確かめます。

記録だけを頼りに、開始状態から再試行する

開始状態、番号付きの操作、期待、実際、起きなかった条件を一枚に書きます。原因の推測は別欄へ移し、記録だけを使って最初から試してください。現象が出なければ、確認できなかった事実を残します。

題材がなければ、上の架空例で記録の形式だけを練習できます。無料レッスンのページで観察した問題を使う場合は、実際に試した操作へ置き換えましょう。完成物は原因の断定ではなく、次の確認を同じ条件から始められる記録です。