1.はじめに
RUNTEQ68期のおぴよです。
RUNTEQ Advent Calendar 2025
『みんなにおすすめしたい〇〇tips』ですが、何を書こう…といろいろ考えました。
私は沼ったエラーの時に
とにかくエラーから抜け出したい！！！！！！
とAIに頼り切りで、理解を置いてきぼりにすることが多々あります。
エラー抜けた後も、AIに頼りっきりで色々やりすぎて何が原因だったかわからない時に、振り返りも含めて、言語化するために技術記事を書くようにしました。
そこで、今日伝えたいtipsは 「エラーのときこそ記事を書くべき」な理由にしました。
2. エラーとの向き合い方
プログラミングをしていると、
だいたいの時間は エラーと向き合っていませんか？
正直、「こんなの記事にするほどでもないし…」「単なる自分のちょっとしたミスだし…」
と思ってしまうこともあると思います。
でも、最近思うのは
エラーのときこそ記事を書く価値が一番高い ということです。
3.なぜ価値が高いのか
① エラーは「思考のログ」だから
完成したコードって、実は情報としては弱い。
なぜなら、
- 正解はそこに書かれたコード1つ
- ドキュメントにも載っている
- AI でも生成できる
でもエラー対応は違う。
- どこでハマったか
- 何を疑ったか
- 原因だと思ったことが原因じゃなかったとき
これは その人の思考のログ。
同じエラーに遭遇した人が一番知りたいのは
「正解」よりも「どうやってそこに辿り着いたか」。
② 自分の理解が浅い場所が見える
記事にしようとすると、必ずこうなる。
「あれ…これってなんでこうなるんだっけ？」
この瞬間が超大事。
- なんとなく動かしていた
- 雰囲気で理解していた
- コピペで済ませていた
エラー記事を書くと理解が曖昧な場所が全部あぶり出されます。
結果として、
- 次に同じエラーで詰まりにくくなる
- 説明できるレベルまで理解が上がる
③ 「未来の自分」に刺さる
開発をしていると、同じエラーがでたときに、
「え、これ前にも同じエラーでなかったけ？」って思うことありませんか？
振り返りメモや技術記事がないと、似たようなエラーには出会った記憶はあるものの、どう解消したかまではわからない…。
技術記事をかいていれば、過去の自分が書いたエラー記事を見て助けられることもあります。
- 自分の環境
- どんなエラーだったか
- 解決方法
全部そこに書いてあるから、
今のエラーが少し早く解決するきっかけになるかもしれないです。
特にRails 8のような新しい技術は情報が少ないため、あなたのエラー記事が誰かの救いになる可能性も高いです。
④ 完璧じゃなくていい
エラー記事は、
- 文章が雑でもいい
- 構成が荒くてもいい
- 結論が短くてもいい
大事なのは、 「この状況で、こうハマって、こう直した」
それだけ。
ただ、他の人が見る分、言語化が丁寧になるし、「なぜこの方法で直ったのか」を考えることで理解が深まります。
4. おわりに
エラーはつらい。
でも、沼ったエラーこそ、自分自身が成長するチャンスです。
直した瞬間に終わらせず、「何が起きてたか」を残すことで
- よくわからないままにせず深掘りできる
- 将来同じエラーにハマった時に振り返れる
- 他の人が同じエラーになった時に参考にしてもらえる
だから、
エラーのときこそ記事を書くべきなのです。
5. いつ書くのがベスト?
おすすめは エラー解決直後。
- 思考の流れが鮮明
- どこでハマったかを覚えている
- 感情も含めて記録できる
「後で書こう」は、だいたい書かない。
解決した瞬間の熱量を逃さずに記事にしてみてください！