学校のある日にテストが全滅した話：M4 MacとiPad miniで進めたデバッグ日記

「テストが全部赤になった日」を、ちゃんと攻略してみた

どうも、Kazuです。

この記事は、
「テストがほぼ全部赤になった平日」を、どうやって最後まで攻略したかをまとめたデバッグ日記です。

• 学校は普通にある

• 授業も課題もいつも通りある

• でも、家に帰ったら“バグの山”が待っている

そんな一日を、できるだけ冷静に分解してみました。

きっかけ：朝イチでレポートを開いたら、一面の赤

その日の朝、いつも通りブラウザを開いてテストレポートを確認した瞬間に、状況はだいたい分かりました。

• ユニットテスト：かなりの数が赤

• ログ：1回の実行でスクロールが止まらないレベル

• 直感：原因は浅くなさそう

ここで無理に「今日中に全部直す」とは決めませんでした。
代わりに決めたのは、もう少し現実的なラインです。

完璧に直す、ではなく、
「原因の輪郭をはっきりさせる日」としてスタートしました。

授業の合間にやったのは「コード」じゃなくて「整理」

平日なので、もちろん一日は授業メインで進みます。
だからこそ、授業の合間や休み時間にできることは限られています。

この日は、“コードを書く”のではなく、
「夜の自分のための整理」だけをやることにしました。

やったのは主に3つです。

1. 落ちているテストケースをざっと眺める

   • どの機能に集中して失敗が出ているかだけを見る

   • 「全部のエッジケース」ではなく「よく落ちているところ」に絞る

2. 失敗しているテスト名・関数名をメモる

   • ノートアプリに
     「テスト名 → 関連しそうなモジュールや関数」を1行ずつ書く

   • ここではまだ“正解”は考えない

3. 「いま気になっていること」を日本語で書き出す

   • 例：

     • 状態の持ち方が悪そう

     • 非同期のタイミングを疑ったほうがよさそう

     • テストデータの作り方が雑かもしれない

コードは一行も書かずに、
「頭の中にあるモヤモヤを、夜に読めるメモに変えておく」だけ。

これだけでも、
放課後にエディタを開いたときの「何からやるんだっけ？」がだいぶ減りました。

放課後：M4 MacBook Proを開いてからやったこと全部

家に帰って、M4 MacBook Proとトラックボールをセット。
ここからようやく“デバッグ本番”です。

やったことを順番に並べると、こんな感じでした。

1. まずは“素の状態”でテストを全部流す

   • 変なログを仕込む前に、一度フルで落とす

   • どのテストが「必ず」落ちて、「たまに」落ちるのはどれかを分ける

2. 「必ず落ちるテスト」だけに絞る

   • 再現性100％のバグだけを相手にする

   • たまにしか落ちないやつは、一旦横に置いておく

3. VS Codeで「壊れていそうな行」にだけブレークポイントを置く

   • いきなり全体を追いかけない

   • “この値が変になり始める境目”だけを見る

4. ログの量を“必要最低限”に絞る

   • なんでもかんでもconsole.logしない

   • 「この値が正しければ、ここから先は一旦OK」と思えるポイントだけ出す

やっていること自体はかなり地味ですが、
「全部を見る」のをやめて「おかしくなり始めた瞬間だけを見る」ようにしただけで、
頭の疲れ方がだいぶマイルドになりました。

iPad mini 6は“ログとメモの避難所”として使う

この日は、iPad mini 6 を完全に「読むものと書くものの避難所」として使いました。

• ブラウザ：仕様書・課題ページ・APIドキュメントを開きっぱなし

• メモアプリ：
  「いま試したこと」「観察できたこと」を1行ずつ積み上げる

• 必要に応じて、処理の流れをざっくり図解

Macの画面は、

• VS Code（コードとテスト）

• 必要なときだけブラウザのDevTools

だけにしておいて、
「ログやテキストの海」は全部mini側に逃がすイメージです。

これをやるだけで、

• Alt＋Tabやウィンドウ切り替えが減る

• 「さっきの実験、どうだったっけ？」をメモで一瞬で振り返れる

• 脳内メモリの一部を“外部ストレージ”に任せられる

みたいな、小さいけれど効く省エネが積み重なりました。

夜の締め作業：バグが解けたあとのミニ振り返りノート

その日の“メインのバグ”がなんとか片付いたところで、電源を落とす前にやったのが、
5分だけの「ミニ振り返りノート」です。

フォーマットはこんな感じで固定しています。

• どんな症状だったか（1〜2行）

• 原因はどこだったか（1〜2行）

• どう直したか（コードの要約）

• 明日の自分に一言メモ

たとえば、

この4行を書いておくと、

• 数週間後に似たバグを踏んだとき

• レポートや記事を書くとき

• 成長を振り返るとき

に、「あのとき何をやっていたか」がちゃんと掘り起こせます。

情報科的「デバッグフルコース」の型

この一日を“型”にしてしまうと、
エンジニア目線ではこんな「デバッグフルコース」になります。

1. 朝〜スキマ時間

   • テスト結果をざっと眺める

   • 再現条件と“怪しい場所”を日本語でメモる

2. 帰宅後（前半戦）

   • テストを何度か流して「必ず落ちるテスト」を特定

   • ブレークポイントと最小限のログで「どこから壊れているか」を狭める

3. 帰宅後（後半戦）

   • 原因候補を3つまでに絞る

   • 1つずつ潰して、そのたびにテストをフルで流す

4. 締め

   • 原因・対処・学びをノートに3〜4行だけ残す

特別なことはしていないけれど、
「学校のスケジュールに合わせながらでも、ちゃんと前に進める流れ」にはなっていると思います。

おわりに：バグは“才能テスト”じゃなくて“段取りテスト”

この日をまるっと使ってデバッグと向き合ってみて、一番強く感じたのは、

• 朝の数分で「どこから見るか」を決められるか

• 授業の合間に「考えるだけ」の時間をちょっと差し込めるか

• 帰宅後90分を“デバッグだけ”にちゃんと使えるように予定を組めるか

このあたりを整えておくだけで、
同じくらい難しいバグでも、精神的なダメージがだいぶ軽くなります。

この記事が、
「今日はテスト全部赤なんだけど？」という日の、
ちょっとした取扱説明書になればうれしいです。