詰まったときのセルフデバッグ・ガイド

研究をしていると、ある日突然「手が動かない」状態に陥ることがあります。

机に向かっても作業が進まない。タスクを開いても閉じてしまう。気づけば数日、数週間、何も触れていない。そして「自分はダメだ」「やる気がない」と自分を責め始める。

これは、あなたが弱いわけでも、研究に向いていないわけでもありません。ほぼすべての研究者が一度は通る、構造的に発生する現象です。原因は複数あり、それぞれに既知のデバッグ手順があります。バグレポートを書くつもりで、自分の状態を観察してみてください。

「手が動かない」を意志の問題として処理し続けると、対策はほぼ「もっと頑張る」しかなくなります。でも、頑張ろうとして頑張れた、という経験は、振り返ってみるとそう多くないはずです。手が動かないのは、たいてい 設計のどこかがズレている ことの結果です――タスクの粒度、報酬の見え方、納得の有無、その時間に残っている頭の余力。このどれかがいまの自分にフィットしていないだけで、フィットさせれば動きます。以下の切り分けは、そのズレが起きている場所を見つけるための道具だと思って読んでください。

この章の目的は、あなたが 自分で自分を立て直すための道具 を持っておくことです。指導教員や仲間に頼るな、という意味ではありません。むしろ、自分の状態を言語化できれば、相談そのものもうまくなります。

まず切り分ける

「手が動かない」を一括りにせず、原因を切り分けます。下の表を上から見て、当てはまるものの節に進んでください。複数当てはまることもあります。

各節の「いますぐやること」は、最初の一手が「 今日の30分で実行できる 」サイズになるように書いています。読んだら閉じて、すぐ手を動かしてみてください。

症状①：タスクが大きすぎて手がつけられない

見分け方：

• いまやるべきことを聞かれて、「論文を書く」「実験を進める」レベルでしか答えられない
• 「次の30分で何をするか」が即答できない
• タスクを思い浮かべると、漠然とした重さを感じる

なぜ起きるのか： タスクの粒度がデカすぎるだけです。「論文を書く」「実験を進める」は、そのままでは手のつけようがありません。漠然とした重さは、対象が大きすぎることのサインです。

いますぐやること：粒度を強制的に下げる

1. 今のタスクを紙かエディタに書き出す
2. それを「今の自分が30分で終わらせられる」サイズまで分解する
3. 30分サイズに収まらなかったら、それは まだタスクではなく目標 。さらに分解する
4. 分解した中で、一番小さいものをいまやる

例：「論文を書く」→「Introductionを書く」→「Introductionの第1段落を書く」→「第1段落の最初の3文を、雑でいいから書く」。

雑でいい。直すのは後の自分の仕事です。

症状②：失敗が確定するのが怖い

見分け方：

• 手を動かせば結果が出るが、その結果がダメだったらと思うと動けない
• 「いまやらなければ、まだ可能性がある」という感覚がある
• アイデアを温めている時間が長く、検証フェーズに入れない

なぜ起きるのか： 研究は仮説検証であって、自分の能力テストではありません。仮説が外れることは情報であって、あなた個人の評価ではありません。この2つが混ざると、手を動かすこと自体が自己評価の賭けになり、動けなくなります。

いますぐやること：失敗のコストを下げる

1. 「これがダメだったら何が起きるか」を紙に書き出す
2. たいてい、書き出すと「思ったほどヤバくない」ことに気づく
3. それでも怖いなら、 失敗してもいい小さな実験 として再設計する
4. 「本番の前のパイロット」「練習」と名前を変えるだけでも効く

症状③：そのタスクに納得していない

見分け方：

• 言われたからやっているが、なぜやるのかが腹落ちしていない
• このタスクが自分の研究のどこに繋がるか説明できない
• 「やらされている感」が強い

なぜ起きるのか： 僕は自分の研究室では「納得していないタスクをやれ」と言わないようにしています。納得できないなら、それは説明不足のサインで、指導側の責任なので。つまりこれは、あなたの気力の問題ではなく、説明が届いていないという状態です。

いますぐやること：納得を取りに行く

1. 「なぜこのタスクをやるのか」を自分で説明できるか試す
2. 説明できないなら、 それは指導側が答えを持っている問題 。30分以内に指導教員か先輩に聞く
3. 「言われたからやってる」状態のまま続けるのが、一番効率が悪い
4. 聞くのは恥ずかしいことではない。むしろ、納得して動けるほうが圧倒的に早い

症状④：フィードバックが遅すぎて報酬が来ない

見分け方：

• 手を動かしてから結果が見えるまで数週間〜数ヶ月かかる
• 進んでいる実感がなく、徒労感が強い
• 短期的に「できた」と思える瞬間がない

なぜ起きるのか： 研究は本質的に報酬が遅い。放っておくと、手を動かしてから「できた」と思えるまでのあいだに、気力のほうが先に切れます。だから、報酬は 設計 する必要があります。

いますぐやること：短いフィードバックループを人工的に作る

1. 週次で「今週やったこと」を一行でいいから書き残す（週報のような形でOK）
2. 中間成果物を週1回、誰かに見せる枠を作る（ゼミ、Slack、ペアでも可）
3. 大きな成果（論文採択など）ではなく、 小さな更新（コードが動いた、図が描けた） を意識的に祝う
4. 過去ログを見返して「半年前の自分より進んでいる」を確認する

症状⑤：単純に疲れている

見分け方：

• 睡眠が6時間を切る日が続いている
• 休日も研究のことが頭から離れず、回復していない
• 集中しようとしても文字が頭に入ってこない

なぜ起きるのか： 「休むのは甘え」ではありません。脳がエネルギー切れを起こしているときに意志で殴っても、効率は最悪です。回復は研究活動の一部です。

いますぐやること：回復を最優先にする

1. 今日は研究を諦める。寝る
2. 7時間以上寝る日を3日続ける
3. それでも戻らないなら、休日を完全にオフにする週を作る
4. 慢性的に疲れているなら、指導教員や信頼できる人に相談する

症状⑥：完璧主義で一歩目が出ない

見分け方：

• 「ちゃんとやらなきゃ」が強く、雑に始められない
• 最初の一行・一実験のクオリティを気にしすぎる
• 準備ばかり整えて、本番に入れない

なぜ起きるのか： 完璧な一歩目は存在しません。雑な一歩目を直す回数が、最終的なクオリティを決めます。一歩目でクオリティを出そうとすると、直す回数がゼロのまま止まります。

いますぐやること：「雑に始める」を自分に許可する

1. タイマーを15分セットする
2. その15分は「 世界で一番ひどい初稿を書く 」と決める
3. クオリティを一切気にせず、とにかく形にする
4. 15分後、雑な何かが手元にある。それを直すのは次のタスク

詰まる前の早期警告シグナル

症状が出てから対処するのは大変です。 前駆症状 の段階で気づけるよう、以下のシグナルを覚えておいてください。

これらは「あなたがダメ」というサインではなく、「システムにバグが出ている」というログです。早く検知できるほど修正コストは低い。

助けの求め方プロトコル

「相談していい」と言われても、 いつ・どう相談すればいいか がわからないと、結局抱え込みます。閾値を下げるために、いくつかの定型を持っておくと便利です。

レベル1：軽い詰まり

Slackなどのチャットツールに一言投げる：

「○○で詰まりかけてます。明日のゼミで5分もらえますか」

これだけでOK。詳細は対面で話せばよい。

レベル2：中程度の詰まり

週報や進捗ノートの「今週詰まったこと」欄に書く：

「○○の実装で詰まった。原因は△△だと思うが確信がない」

進捗報告の中に「詰まり欄」を持っておく理由は、 書きやすくするため です。「順調です」だけ書く必要はありません。

レベル3：深刻な詰まり

個別ミーティング（1on1）をお願いする：

「研究全体について少し話したいです。30分ください」

理由を詳しく書く必要はありません。「話したい」だけで十分です。

NGパターン

• 一人で抱えて数週間放置 → 一番コストが高い
• 「もう少し頑張ってから相談しよう」 → たいていもっと深く沈む
• 「こんなことで相談していいのかな」と迷う → 迷ったら相談する側を選ぶ

相談されて困る教員はほぼいません。相談されずに気づかないほうがよっぽど困る。 これは、自分が指導側に立って強く感じていることです。

おわりに

研究は長距離走です。詰まることは異常ではなく、デバッグできるイベントです。自分のシステムをよく観察して、長く走り続けられるように整備していきましょう。

姉妹章「自己正当化パターン辞典」と併せて使うと効果的です。症状（手が動かない）から入ってもいいし、言葉（正当化）から入ってもいい。どちらの入口からも、同じ場所にたどり着きます。