長く読まれるブログを書く

SocialDog でエンジニアチームのブログ編集長を担当している上田です。

私たちは最近ブログ発信に力を入れているのですが、『ブログをどう書けばいいのかわからない』という声がちらほらありました。

そこで今回は私の経験則^[1]をベースに、ブログの 書き方のプロセス や 長く読まれるために心がけていること をご紹介します。

✍️この記事で書くこと

主に次の2つのことを書きます。

執筆のプロセス

記事を書く上で 迷いを減らすためのプロセス について書きます。

寿命の長い記事の書き方

私がブログ記事を書いてきたなかで、 数年にわたって Google の検索順位で 10 位以内 をキープする記事がいくつかありました。^[2]

また前職でも、 会社ブログ全体の流入数の3割が私の1つの記事だった 経験があります。

ただ、毎回すべての記事が一定読まれるようになったわけではなく、継続的に読まれる記事にはいくつかの共通点があることに気づきました。

この共通点について紹介します。

🙅この記事で書か ない こと

• SEO のためのテクニック
• インプレッションを増やす方法

上記は短期的には有用だと思いますが、長期的には 「記事の質」が数字や順位の結果になる と感じているため、敢えて触れません。

• ポエムの描き方

ポエムは思いの発露を思うままに書きましょう。

• 継続的にアウトプットする方法

私が知りたいです。

迷いを減らす執筆のプロセス

ソフトウェア開発において、いきなりコードを書くでしょうか。

否、通常は次のような流れでソフトウェアが作られると思います。^[3]

1. 要件定義
2. 設計
3. コーディング

これには、次のような理由があるからでしょう。

• 設計がよくても、要件を間違えていたら、価値あるソフトウェアにはならない
• コードが良くても、設計が悪かったら、持続するソフトウェアにならない

これを記事執筆に当てはめてみます。

• 構成（設計）がよくても、要件を間違えていたら、伝えたいことが伝わらない
• 文章（コード）がよくても、構成が悪かったら、読みづらく持続的に読んでもらえない

『記事を書く』ことはつい『書く』ことにフォーカスしてしまいますが、それよりも『何を伝えたいのか』を明確にし（= 要件定義）、構成やプロットを作成（= 設計）してから書くことが大事です。

要件定義：何を伝えたいのかを決める

書くことは伝えることです。伝えたいこと は何でしょうか。

これが明確でなければ、ゴールがわからないまま書くことにつながり、ゴールのない執筆は苦痛につながる恐れがあります。

なんとか書けたとしても、記事の内容が脱線しがちであったり、読み手が混乱しやすい記事になってしまいます。

設計：構成・プロットを決める

伝えたいことが決まったら、大まかな記事の流れを整理します。

技術記事の場合、小説や漫画ではないので、起承転結の流れではなく 次のような流れを意識して整理すると読みやすくなると感じます。^[4]

1. 導入
   • 省略可能です。簡単に記事を書く動機などに触れます
2. 要約
   • この記事がどんなことを書いているのかに触れます
3. 本文
   • 伝えたいことを存分に伝えます
4. 結論・まとめ
   • 『要するにこういうことを伝えたかったんだよ』とまとめます
5. あとがき
   • 省略可能です。スペシャルサンクス・参考文献・共有しておきたい関連情報などを載せます

ずっと読んでもらえる記事を書く

• ユーザーを離脱させない
• ブックマークしてもらえる

ために心がけていることを紹介します。

伝えたいことだけを書く

伝えたいこと『だけ』というのは極端かもしれませんが、伝えたいこと以外は書かないくらいの気持ちで書きます。

あなたが一番伝えたいことを伝えるために書くのです。

他の情報によって、その存在感が薄くなったら勿体ありません。

リンク・アノテーションを活用する

『伝えたいことだけを書く』 ために、記事の趣旨とは外れる補足や参考情報は、リンクやアノテーションを活用します。

リンク

文中で登場する専門用語や形式知などを含む文などは、信頼できるソース（情報源）^[5] でリンクします。

適当なものが見つからない場合、Wikipedia のリンクにすることもあります。それでいいのかという声もありそうですが、脚注に信頼できそうなソースが含まれているのであれば、信頼のチェーン^[6] で問題ないという考え方です。

なお、 SEO のために外部リンクを貼らない といったプラクティスをたまに見かけますが、むしろ積極的にリンクにします。

信頼できる情報源が多くリンクされた記事 は、質の高い情報へのインデックス集になります。つまり、読者がブックマークする上での付加価値になります。

メリハリをつける

技術記事は長くなりがちです。単調な長文が続くと読むのに疲れてしまいます。

次のような工夫でメリハリがつき、読みやすい記事になります。

セクションを分ける

伝えたいことの内容別に、こまめに セクションを分けます。セクションの責務を意識し、1 つのセクションで 1 つのことを書きます。^[7]

スタイルを活用する

スタイリングをこまめにやります。^[8]

太字・斜体だけを追って読むと、文の内容が自動で頭に入ってくるような書き方を意識します。

適切なセクションを分けと併用することで、『読む』というより 『見る』 に近い感覚で読めれば、読むときの疲労感が減ります。

もちろんやりすぎると、逆に単調になるのでご注意ください。

その他 Tips

おまけに近いですが、細かな Tips を紹介します。

プロ意識をもつ

記事を書く以上 『自分はプロ』 という意識で書きます。虚勢でもいいのでこの意識をもつと、表現の迷いが少なくなります。

ユニークな題材にする

ユニークな情報とは他に代えられない情報ということです。つまりそれだけで存在する意義になります。

みんな違ってみんないい。

タイトル、それは 0.5 秒の勝負

今まで書いてきたのはあくまで記事の内容の話です。が、そもそも記事を読んでもらえるかという最初の勝負があります。

タイムラインやレコメンドという数多の流し読みする情報の中に、一粒のあなたの記事が流れてきます。そのタイトルを見ただけで『読んでみよう』と思ってもらえるか、という勝負です。

あなたが書いた記事のその内容を、例えばまだあなたが知らないと仮定したとき、そのタイトルで読んでみようと思えるでしょうか？

そう思える納得のタイトルで、書き上げた記事を世に送り出しましょう。

書き方にこだわりすぎない

今まで書いてきたことをすべてをひっくり返しますが、正解はありません。

自分にとってそのとき書きたいことを書きたいように書く。

書き方にこだわって書けない より、生み出すことに価値があります。

本記事の内容は、書き方に迷ったり悩んだりしたときに斜め読み していただくくらいだと嬉しいです。

まとめ

• 要件定義・設計はブログを書くうえでも大事
• 伝えたいことだけに絞ってメリハリをつけて書くと読みやすくなる

---

SocialDog は技術発信に力を入れています 💪

最近はスクラム開発のスプリントゴールにブログ記事の執筆タスクをいれる取り組みをしています。

開発チーム全体で発信していく上で、それぞれのメンバーにとても助けられており、よいチームに恵まれたと日々感じています。

モダンな開発をしながら技術発信もしたい方は、ぜひカジュアル面談しましょう！

https://portal.socialdog.jp/recruit

脚注

1. あくまで経験則であり、絶対的ノウハウではないことにご注意ください

2. 例：「vim java」「cgit」「pipenv venv」「git linus」「git スカッシュマージ」

3. かなり簡略化しています

4. 気づいた方もいるかもしれませんが、論文の書き方に似ています。『エンジニア』という言葉が学術的な知識を前提とすることも踏まえると、技術記事の読みやすさが論文のような形式に収斂（しゅうれん）されるのは自然なことかもしれません

5. ほとんどの場合、公式ドキュメントや RFC などの 一次情報そのもの や 一次情報に近い情報 です。

6. chain of trust。これこそリンクにしたかったのですが、適当なソースが見つかりませんでした。筆者がこの考え方を学んだのは Linus Torvalds 氏が git のコミットに sign-off を含めることを提案したときのメールです。

7. 単一責任の原則に通じると捉えるとわかりやすいかなと思い、あえて「責務」という言葉を使いました

8. 2024-08-02 追記：技術ブログは Zenn を含め Markdown という制約の中で書くことが多く、「制約の中で少しでも読みやすくする」という工夫の一環として、筆者は太字・斜体はカジュアルに使っています。他の目的で意識的に太字・斜体を使っている方もいると思うので、あくまで筆者のやり方であり絶対ではないという点を改めて強調しておきます。