自分が続けてる技術ブログ( https://wp-kyoto.net )が開始10年を経過したので、「なんで10年も続けることができたのか？」を振り返ってみているシリーズです。今回は「書いた記事の2〜3倍は下書きだけで終わった記事がある」話をしようかと思います。
まとまった時間が作れない時は、段階を分けて記事を書こう
ブログ記事の書き方を知っても、「実際に記事を書く時間」が作れなくてブログを始める・続けることができなかった・・・という方は少なくないのではと思います。特に開発の現場といった手を動かす必要がある場面では、「そんなものを書いている時間はない」となることの方が多いでしょう。また、子育て中などでまとまった時間を作ることが難しいこともあると思います。そんな時にお勧めしたいのが、「一度に記事を完成させることをやめる事」です。今回は「少しずつ記事を作るメリットと方法」を紹介します。
個人ブログに締切はない
会社のブログや技術広報としての取り組みであれば、「この製品リリースに合わせて記事を出して」のような締め切りがあります。ですが個人ブログであれば、締切はありません。個人のブログや覚書用のDBでは、どれだけ下書きを作って放置しても、誰も何も言いません。流石にDBの容量が無くなったら対処が必要ですが、DBの容量が無くなるまで下書きを作るのは、botでも使わない限り至難の業でしょう。
実際このブログや( https://wp-kyoto.net )、そしてQiitaにはそれぞれ常に10〜20記事程度の下書きやメモを残しており、その中の3・4記事は「情報が古くなったから、公開しなくてもいいか」とお蔵入りしていたりします。それでも残りの6割程度の下書きは、出張の道中や他の業務が落ち着いたタイミング・年末のアドベントカレンダーなどでまとめて放出しており、下書きの数自体の変動はあまりなくとも、新陳代謝は多少なりとも起きている状態を維持しています。
とりあえずメモを残しておいて、気が向いたら記事にする。そんな気持ちでやればいいのが個人ブログのよいところです。
コードやログだけメモしておく
時間がない時は、まずコードやログ、手順だけメモしましょう。メモを残すことで、あとで記事を仕上げる時に思い出す手間や不具合をわざわざ再現させる手間が省けます。このメモの理想系は、次回同じエラーが起きた時に自分が読んでやったことを思い出せるレベルを目指すことです。このレベルのメモは、記事にせずともNotionやZennのスクラップに残しておくだけでもとても価値のあるものとなります。
メモに説明を加える
時間に余裕ができた時にやることは、メモを報告書にすることです。前の記事で紹介したフォーマットにコードやログを整理して、背景や感じたこと、コードの注意点などの説明を追加しましょう。これでシンプルな技術記事が完成します。
振り返りとしての記事化
残したメモを記事にするのは、ひとつの振り返りでもあります。書いたコードやログ・手順を見返すことで、その時の実装について振り返りを行います。もしかすると、メモを残した後に知った知識で、別のやり方を思いつくかもしれません。その時は記事に「その時はこう考えてこの対応にした。しかし今やるならこのやり方にするかもしれない」のように両方紹介すると良いでしょう。
下書きがたまっても気にしない
もし繁忙期で生地に仕上げる余裕がなくても心配しないでください。自分用のコンテンツとして運用しているのであれば、下書きで残すだけでも十分です。多くのCMSには管理画面の記事検索機能があり、下書きの記事も対象にして検索ができます。つまり自分が読みたい時は、管理画面から下書きのメモを読めば良いのです。記事として整形するのは、読みやすさや思い出しやすさが上がるメリットがありますし、振り返りを行う機会としても良い取り組みです。ですが、それをやらなければという気持ちでしんどくなるくらいならば、２〜３年塩漬けするくらいの気持ちで下書きを山積みにするだけでも大丈夫です。
記事ネタのストックを作ろう
まずはメモからで大丈夫です。コードやスクショだけ貼っておくだけの下書きやNotionなどのメモ・Zennのスクラップとかでも十分なスタート地点だと思います。それだけでも、記録しておくことで、あとでメモから過去の挑戦を振り返ることができますし、振り返りながら記事に整理していくことも可能です。
実装作業など、記事ネタができる現場ではほとんどの場合詳細な記録や記事をその場で作る時間はありません。ですが振り返りのメモや、将来の自分が参照するための覚書として情報を記録しておくことで、そこからブログ記事を書き始めるきっかけにもなります。