1.はじめに

RUNTEQ68期のおぴよです。
RUNTEQ Advent Calendar 2025
『みんなにおすすめしたい〇〇tips』ですが、何を書こう…といろいろ考えました。

私は沼ったエラーの時に
とにかくエラーから抜け出したい！！！！！！
とAIに頼り切りで、理解を置いてきぼりにすることが多々あります。

エラー抜けた後も、AIに頼りっきりで色々やりすぎて何が原因だったかわからない時に、振り返りも含めて、言語化するために技術記事を書くようにしました。

そこで、今日伝えたいtipsは 「エラーのときこそ記事を書くべき」な理由にしました。

2. エラーとの向き合い方

プログラミングをしていると、
だいたいの時間はエラーと向き合っていませんか？

正直、「こんなの記事にするほどでもないし…」「単なる自分のちょっとしたミスだし…」
と思ってしまうこともあると思います。

でも、最近思うのは
エラーのときこそ記事を書く価値が一番高い ということです。

完成したコードって、実は情報としては弱い。

なぜなら、

でもエラー対応は違う。

これはその人の思考のログ。

同じエラーに遭遇した人が一番知りたいのは
「正解」よりも「どうやってそこに辿り着いたか」。

記事にしようとすると、必ずこうなる。

「あれ…これってなんでこうなるんだっけ？」

この瞬間が超大事。

エラー記事を書くと理解が曖昧な場所が全部あぶり出されます。

結果として、

開発をしていると、同じエラーがでたときに、

「え、これ前にも同じエラーでなかったけ？」って思うことありませんか？

振り返りメモや技術記事がないと、似たようなエラーには出会った記憶はあるものの、どう解消したかまではわからない…。
技術記事をかいていれば、過去の自分が書いたエラー記事を見て助けられることもあります。

全部そこに書いてあるから、
今のエラーが少し早く解決するきっかけになるかもしれないです。
特にRails 8のような新しい技術は情報が少ないため、あなたのエラー記事が誰かの救いになる可能性も高いです。

エラー記事は、

大事なのは、「この状況で、こうハマって、こう直した」

それだけ。

ただ、他の人が見る分、言語化が丁寧になるし、「なぜこの方法で直ったのか」を考えることで理解が深まります。

エラーはつらい。
でも、沼ったエラーこそ、自分自身が成長するチャンスです。

直した瞬間に終わらせず、「何が起きてたか」を残すことで

だから、

エラーのときこそ記事を書くべきなのです。

おすすめは エラー解決直後。

「後で書こう」は、だいたい書かない。
解決した瞬間の熱量を逃さずに記事にしてみてください！