【エンジニア必見！】いつ技術記事を書く？発信を続けるためのコツ📈
※ この記事はすべて無料でお読みいただけます。
はじめに
皆さま、こんにちは！都内でHR系の自社開発プロジェクトに携わるエンジニア、Takeです。私の経歴やこれまでの仕事についてもっと知りたい方は、ぜひ以下のnoteをクリックください！
さて、本題に移りましょう。技術記事の執筆は、エンジニアのキャリア形成を助ける貴重なスキルの1つと実感しています。しかし、多忙な日々の中で、記事を書き始めても継続するのが難しいと感じることは多々あります。私自身も以前はそうでした。そこで今回は、技術記事の発信を始めてから約2週間以上、毎日投稿を続けている私の経験をもとに、実践して効果的だった方法や、役立った情報源について共有します。特に、技術記事の執筆を始めたい初心者や、一度はじめたものの途中で挫折してしまった方々を対象に記載していきますので、参考にしていただければ幸いです。
主な対象者
技術記事の執筆をこれから始めていきたい方
一度はじめたものの途中で挫折してしまった方
なぜ技術記事を書くのか？
執筆を始める前に、なぜ記事を書くのかを自問自答してみましょう。技術の共有、キャリアの構築、または個人的な理解を深めるためかもしれません。目的が明確であれば、モチベーションを保ちやすくなります。ちなみに、私の技術記事を書く目的の3つで、①学びの共有、②アウトプットベースの学習の実践、③人生ログです。中でも③は、自分が行ったことの記録として振り返ることができる点に魅力を感じています。「そんなものないよ」という方は、一度以下の動画を視聴することをオススメします。私自身も以下の動画を視聴し、「とりあえず始めてみよう」と気持ちになり、実際に技術記事を作成していく段階で上記3点の目的を1個ずつ見つけていきました。
自分なりに技術記事を書く目的を決めると続きやすい
以下動画の発信に関する誤解2点は特に参考になる（この部分は約5分で視聴可能）
適切なプラットフォームを選ぶ
記事を書く媒体も重要です。技術コミュニティに特化した「Zenn」や「Qiita」、幅広いトピックを扱う「note」、個人的なブログとしての「はてなブログ」や「WordPress」など、目的に応じてプラットフォームを選びましょう。ここでのポイントは、エンジニアなので、ゼロからサーバーを構築して〜といった手順を踏むのは良いことだと思いますが、ここでのポイントはすでにユーザーが存在するプラットフォームを利用することだと思います。これは以下「なぜ、あなたの記事は読まれないのか？」というYossyさんの記事が大変参考になりましたので、その理由等が解説されているので、ぜひご一読ください。なお、現時点（2024.4.21）で私が利用している媒体は①Zennと②noteの2つになり、個人ブログは現時点では開設していません。（ゆくゆくは開設したいと考えております。）
いつ技術記事を書く？
いよいよ本記事のメインパートです。前提、技術記事を書く最適なタイミングは人それぞれであり、業務に関する守秘義務は当然守ります。なお、私が実践している技術記事を作成するタイミングは以下の3点になります。
業務中
帰宅後
土日
なお、朝もおすすめですが、私は実務やCoding、実務関連の学習をしているため、朝にはガッツリと技術記事は記載していません。しかし、作業する際にはZennは常に開いています。その理由や具体的な進め方について解説していきます。
① 業務中
こちらが最大のポイントです。（もちろん可能であればの話なのですが、可能な限り試していただきたい内容になります。）こちらでの主な目的は、業務中に遭遇する技術的な問題に対処しながら、エラーメッセージや参考にした情報などの記録をメモする感覚で技術記事の下書きに残します。具体的にメモするべき内容は、遭遇した問題の詳細、発生したエラー、行った調査、参照した記事のURLです。これらの情報は、後で詳細な技術記事を書く際の手助けになります。もし可能であれば、この方法を試してみてください。あくまで、ログをメモすることが業務中の目的なので、記事の文章を作成したり、文構造を考えたりすることはこの段階では行いません。さらに大前提として業務中は当然業務を前に進める時間なので、そのあたりの目的は履き違えないように意識しましょう。
② 帰宅後
技術記事のタイトル設定：
記事のゴールを明確にするためにざっくりとしたタイトルを先に決めます。これが記事全体の指針となるためです。
具体的には「技術記事 書き方 継続コツ」など検索をかけるように何について書くか決めたら、時間をあまりかけずに次にステップに進みましょう。
見出しの構築：
記事の大枠を形作るために見出しを設定します。例えば、「はじめに」、「エラー内容」、「調べたこと」、「解決方法」、「まとめ」といった構成が一般的です。
文構造をあらかじめ構築することで、話が脱線することを防ぎやすくします。技術記事を記載していると分からないことが頻出して「アレもコレの満腹状態になり」途中で燃え尽きてしまうのを防ぐためでもあります。
ログ情報の整理：
業務中に収集したログ情報を見出しに沿って配置します。エラー内容から解決方法、そして調査した背景まで、ひとつのストーリーを描くように論理的な流れに沿って配置すると、読み手にも理解しやすい記事になります。
内容の充実：
各セクションに必要な情報、例えば参考記事のリンクやスクリーンショットなどを追加します。これにより、具体性が増し、説得力のある記事に仕上がります。
ただし、これはある程度執筆に慣れてきたらの段階で良いと思います。まずは、書いてリリースするところを意識しましょう。
情報の削減：
最後に、余分な情報の削除と誤字脱字チェック、プレビューを確認して問題なければリリースします。
③ 土日
土日は平日と比べてまとまった時間が取れるため、技術記事の執筆に最適な日です。可能であれば、新たな技術にキャッチアップして、その内容を技術記事に記載して発信することを意識していますが、それと同時に今まで執筆した内容の校正や再編集、追記を必要があれば行っています。今後は、SNSなども併用し更なる拡散力をつけていきたいです。
参考記事
短く、頻繁な執筆でリリースのハードルを下げる
長い記事だけが価値があるわけではありません。たとえ100字程度の短い記事でも、エラー解決法や技術的なヒントを提供すれば、多くの読者の役に立ちます。また、完璧を求めることは大切ですが、すべての読者に100％完璧な内容を提供することは現実的ではありません。実際、40〜60％の完成度でリリースすることも一つの手段です。記事の質を高める努力は価値がありますが、過度にこだわって公開が遅れることは避けましょう。
技術記事の執筆は、短距離走ではなくマラソンに似ています。自分のペースでコツコツと前に書き続けることが重要です。リリースのハードルを下げ、定期的に情報を発信することで、より多くの読者に価値を提供し続けることができます。
"一喜するが一憂はしない"
技術記事の公開では、すべての記事が必ずしも好評を得るわけではありません。一部の記事が多くの「いいね」を獲得する一方で、期待したほどの反応が得られないこともあります。しかし、読者からの反応に下を向かず、次へのステップへ進むことが重要です。
初期はなかなか「いいね」がつかないかもしれませんが、継続して誰かのためになる内容を提供し続けることが大切です。インターネットの世界で、自分の記事が読者に届き、時には大きな反響があれば、それはさらに大きな喜びとなるでしょう。穏やかな心持ちで記事を書き続けましょう。
ネタ探し
技術記事のネタは日常の業務中に見つけることができます。エラー解決の過程、新しい技術の学習、業務改善のための試みなどが記事になり得ます。通勤時間などの隙間時間を利用してアイデアを練るのも良いでしょう。また、以下の堤さんの動画で主に4点、ネタの見つけ方について説明されており大変参考になったので、再びリンクを添付させていただきます。
執筆後の行動
（こちらは現在の自分に最も不足している習慣で恐縮なのですが）記事を公開したら、それをSNSで共有することを意識しましょう。Xなどで告知することで、より多くの読者との接触が可能になります。また、読者からのフィードバックは次の記事の改善につながります。
1番効果があったこと（要点まとめ）
本記事の要点は、業務の妨げにならない範囲で、業務中に遭遇する技術的な問題に対処しながら、解決策や参考となった情報をリアルタイムでメモすることです。この習慣は、技術記事の執筆を業務の一部として組み込むことで、効率的に情報を記録し、後で記事として形式化するための基盤となります。業務中に得た洞察や解決策を即座にメモすることにより、技術的な課題への迅速な対応と同時に、有用なコンテンツの創出が可能となります。
今回もご精読いただきありがとうございました！
よろしければ「いいね」を押していただけると大変励みになります💪
また、以下は私のZennです。合わせてクリックしていただいて閲覧だけでもしていただけると嬉しいです！（もちろんフォロー大歓迎です🎉）