デバッグで観察事実と推測を分ける

「ログインが壊れた」は結論に見えますが、実際には推測です。調査では、誰が見ても確認できる事実と、原因についての仮説を分けます。

同じ画面、値、手順で別の人も確認できるものが観察事実で、その理由の説明が推測です。事実を集めた後に一つの仮説を試す手順は仮説駆動debugへ分けます。

POST api loginが401などの観察事実と、期限切れかもしれないという推測を分け、次に有効期限を確認する図

書き分けの例

「APIが壊れている」は、まだ確認していない原因を含みます。先にstatus、時刻、再現手順、画面表示を書きます。

401の例なら「POST /api/loginが401」「同じテスト用アカウントで3回再現」「レスポンスはinvalid_token」までが事実です。「セッション期限切れ」は、期限を確認する前は仮説として書きます。

起きたこと（観察事実）:
再現する条件:
確認済みのこと:
仮説:
次に一つ確認すること:

仮説を複数並べるより、確かめられる一つを選びます。結果が違えば仮説を捨て、次の観察から作り直します。

Networkパネルでは、URL、HTTP status、リクエスト時刻、レスポンス、失敗したリクエストを確認できます。トークン、パスワード、個人情報をメモや共有画面に含めないようにします。

別の人が同じ手順で再現でき、未確認の原因へ「仮説」とlabelを付け、次に確認する項目を一つ選べれば成功です。error文の要約だけ、原因の早期断定、複数変更の同時実行、秘密値の貼り付けは避けます。

観察事実は「何が起きたか」、推測は「なぜ起きたか」です。二つを分けると、他の人も同じ順番で確認でき、誤った前提を早く直せます。