この記事は、Progate Path コミュニティ Advent Calendar 2024 の2日目の記事です。
さて、「記事を書くのは大変」「めんどくさい」「こわい人から怒られるかもしれない」という認識があるような気がします。現に友人と技術記事の認識について話したとき、自分なんかに技術記事が書けるわけない、自分が知っていることはすでに誰かが記事にしている、と言っていました。
私は記事を書き始めてだいたい5年になりますが、テーマが完全に被らなかった記事なんて指折り数えるほどしかありません。誰かの記事を参考にしながら記事を書くこともありますし、まったく同じ内容を書いてある記事を書いてから見つけることもあります。
それでも、わざわざ記事を書く理由はあると思います。ここでは僕が記事を書くときにぼんやり考えていることを言語化していきます。
じぶんのために書く
僕の記事のほとんどは、未来の自分のための記事です。
たとえばバグに遭遇したとき、将来同じような状況で困らないように記録します。これとか↓
記事として公開するのに抵抗があるのであれば、Notion などにまとめておくのも手だと思います。僕は公開することによって他の人から見てもらうことも意識し、ていねいに書くための動機付けとして活用してます。
ウケはきにしない
自分のための記事なので、他人の目を気にする必要はありません。いい記事がインターネットの奥底に眠っていた、みたいなのはよくあることなので。
ただ、指摘やアドバイスに対しては真摯に向き合うのをオススメします。多くの人たちは内容の間違いに気づいてもブラウザバックするだけで済みますが、一部の優しい人はコメントで伝えてくれる場合があります。そういう場合、まずは肩の力を抜いて、感謝から伝えるとよいと思います。
まずは小さく書く
これは昔の僕の癖ですが、大きい記事を書こうとしがちな癖がありました。起承転結があり、すべての見出しの細部まで細かく書かれているような記事は素敵だと思いますが、少なくとも最初のうちは必要ありません。
まずは、日々のコーディングで見つけたコツをまとめていくことをオススメします。こんな感じ↓
基本的には、「課題」と「解決方法」のふたつがあればオッケー。
余裕があれば、解説なんかも書いてあげるとグッドですね。
ここまで書ければりっぱな技術記事です。未来のあなたも拍手していることでしょう。
正確性には気を付けよう
技術記事で一番気を付けないのはココです。逆にココさえ押さえていれば（たぶん）大丈夫です。
記事として書く場合、書いた情報が正しいかをしっかり確かめるようにしましょう。たとえば JavaScript の記事を書く場合は、MDN のように信ぴょう性のあるソースを添えてあげると親切です。
また、どれだけ気を付けていても間違ったことを書くことがあります。僕もとらえ方によっては誤解を招くような書き方をしてしまって、指摘をもらったことが何度かあります。そういう時は、指摘してもらった人に感謝し、ササっと修正するようにしましょう。嘘を意図的にバラまく姿勢がないことが伝われば OK です。
やさしく書こう
最後に、ちょっとだけ私情を挟みます。
技術記事は、どうしても言葉が怖くなりがちです。日本語の中に急に英単語が出てきたり、知らない略称がポンポン出てきたり、「これくらい知ってて当然でしょ？」とばかりに難しく書かれた記事がたくさんあります。
そういう記事は、きっとそういう強い人たち向けに書かれた記事なわけです。僕らはよわいエンジニアなので、背伸びしてむずかしく書く必要はありません。むしろ未来の自分のために噛み砕いて解説したり、みやすい記事構成にしたりしていくべきです。