はじめに
読み手（エンジニア）にとって「価値のあるテックブログ」とはなんでしょうか。
- いいねがいっぱいついている記事？
- SNSでバズっている記事？
- 界隈での著名人が書いている記事？
一見間違ってはないだろうし、それはそれで価値があると思います。（たまに炎上してたりするけど）なのですが、私は明確に『価値のあるテックブログとは、記事を読み終えた読者の行動を変えられるものである』と定義しています。
多くの人にたくさん記事書いてほしいなぁという想いを込めて、本記事では「テックブログにおける価値」についての私なりの解釈と、価値をちゃんと届けるための小手先ではないテクをちょっとだけ文字に起こそうと思います。
想定読者
- 「テックブログ何書いたらいいか分からないよぉ」と思っている人
- 「自分がテックブログ書くなんてハードル高いなぁ」と思っている人
- 「5分くらいなら読む時間あるよぉ」と思っている人
もくじ
価値あるテックブログとは
冒頭で、テックブログの価値は記事を読んだ読者に行動を促せるものであると定義しました。言い換えれば、記事を読まなかった世界線と記事を読んだ世界線で差分を生み出せるかどうか で価値が決まると言えます。
例えば、エンジニアやってたら以下のような経験て無限にあると思うんです。
- 開発中にずっとエラーで詰まっていたけど、ある記事を読むことで解消できた！
- チームの困りごとについて、ある記事を参考にチームで実践してみたらよくなった！
- 何気なく見た記事に書いてあった内容を真似てみたら開発効率が上がった！
これって記事が生み出した「ポジティブな行動の変化」ですし、テックブログのパワーですよね。なので、エンジニアをよりよい方向へ１歩前進させる力こそテックブログの価値だ！ と言っていいと思っています。
「いいね」は見かけの価値
では、「いいねの数」というのを「それだけ多くの人に影響を与えた証跡」だとすれば、いいね数は記事の価値と言ってもよいのでは？
回答としては、「その可能性は高そう」になります。「いいね」が多い記事は、「なんかいいね」かもしれないし「とりあえずいいね」かもしれないからです。多くの読者に共感されたり興味を持たれたりしたことを示しているわけですが、それ以上のことは見えてきません。だから「価値がある可能性が高そう」なんです。
ここで何が言いたいかというと、いいね数では記事の価値を判断できないという当然の話です。鬼バズしててSNSのタイムラインで何回も見かけるような記事でも、私には全く関係のない内容で価値がないに等しいものもある一方で、1つもいいねがついてないけど泣いて感謝してコメント送っちゃうものもある。結局は そのときの読み手自身にしかその記事に価値があるかないかは判断できない んです。なので「いいね」でテックブログとしての価値は見えてこない。
そもそもテックブログの「成功」とは
ちょっと視点を変えて、テックブログの「成功」を考えてみます。
テックブログの成功を考えることは、文章を書く目的を考えることとほぼ同義です。普段の業務をちょっと思い出してみてください。
- 先輩に質問を投げることで、先輩にどうしてほしい？
- プルリクエストの概要欄に説明を記載することで、レビュワーにどうしてほしい？
- 要件定義書を書くことで、ステークホルダーにどうしてほしい？
基本的に、文章を書くことの目的は読み手に何かしらの行動をしてもらうこと に他なりません。
この点を考えると、おのずとテックブログの成功とは何かが見えてきます。つまり、テックブログの成功とは記事を読んだ人の行動が変わること で、さらに言うなら、たった1人でも記事を読んだBefore-Afterで行動が変化すればそれは成功 と言えます、むしろこの時点で大成功です。 「この記事を読む〇〇さん」という明確な相手がいないからこそ、インターネットに公開する記事はその影響力がたった1人でもものすごいことだと思います。（冷静に考えて、自分の書いた記事が顔も知らない誰かの人生に影響を与えてるかもしれないってヤバくないですか~！）
公開していいのは読まれる覚悟のある記事だけだ
とは言え、この記事を読んでいる人の中には「別に誰かに読んでほしくて書いてないし...。」という方もいるかと思います。
私の基本的なスタンスとしては見出しの通りです。なぜなら、記事として第三者に見える形で公開している以上、その価値は問われて当然だからです。（※ 気合い入れて執筆しろ！と言いたいわけじゃないです）
私も記事をちょくちょく投稿しているので、アウトプットすることが最も自身の理解度を向上させることはすごくすごく分かります。なのですが、誰かに見られることを想定していない内容や、第三者の文章そのまんまや生成AIに書かせた文章のコピペなど、「誰も読まなくていい」を盾に軽率に記事を公開してしまうことは少し責任を欠いた行動であり、ダサいです。
見かけの価値より成功を
さて、先ほどテックブログの価値は「いいね」では測れない、読んでみないと分からない、と述べました。じゃあ書いたテックブログが読者の行動を促せたかどうかは測れるのか？当然、測れません。つまり、前提として記事の価値は測れないと思っています。（異論反論認めます）
だからこそ、興味を持って見にきてくれた読者に実質的な価値を届けることを目指してみませんか？ を提案したいです。定義することと計測できることは必ずしもセットである必要はないので、計測が難しくても読者の行動変化にピン止めして執筆することには意味があります。
どうやって読者の行動を促すのか
「テックブログの書き手にとっての成功は、読み手に行動の変化を促せたこと！」
「その時点でその読み手には価値があったって事で、そのテックブログには価値がある！」
『それは分かったから、読み手の行動を促す確度を上げる方法を教えてや！！』
てなわけで、こっからはちょっとだけテクい話です。個人的に決して小手先ではないと思っている執筆時の考え方について、テックブログを形にしていくプロセスに沿ってお伝えします。（あくまで1つの書き方でしかないのでぜひ自分に合うスタイルを探してみてください）
読み終えた読者はどうなりそう？
「読者の行動を変化させたら成功」とは言うけれど、それって読者がどういう状態になったらいいの？
これは記事の種類ごとにイメージすると考えやすいと思います。
| 記事の系統 | 読み手へ促すことができる変化（例） |
|---|---|
| 最新情報系 | サービスの新たな機能とユースケースを知ることで、課題解決の幅を広げる |
| トラブルシューティング系 | 原因が解消できたことで次のステップへ進むことができる |
| チュートリアル系 | ツールの概要を理解できたことで、実務でスムーズに活用できるようになる |
| まとめ系 | 目的に適した情報を短時間でインプットできたことで手持ちの選択肢が増える |
| キャリア・転職系 | 書き手の経験を追体験することで、行動の幅が広がる |
| 事例紹介系 | 具体的なユースケースを読み手のプロジェクトにそのまま活かすことができる |
| エンタメ系 | 記事をつまみにおいしいお酒が飲める |
まだまだふわっとしていますし、分類も全然MECEではないのですが、だいたいイメージはつくのではないかと思います。勘違いしちゃいけないのは、即時反映の行動変化を促すことだけが価値ではないという点です。 即時でアハ体験を生むようなものもあれば、あとからジワジワ効いてくるものもあるからです。大事なのは、読み手が記事を読んだ後にどういう状態になっていてほしいかを自分なりにイメージできることです。
記事全体でたった1つの問いに回答する意識を持つこと
ここが記事の根幹を成す最も重要なポイントです。
「読み手が記事を読んだ後にどういう状態に変化していてほしいか」というのは、「読み手は今どんな情報を欲しているか」を考えることであり、言い換えれば、『読み手が今、最も解決したい問いは何か』と言えます。
この読み手の問いにクリティカルに答えること、つまり、「この記事は〇〇という問いに対して、△△という回答をするものである」という記事の主張を 簡潔 かつ 具体的 に意識すること がめっちゃくちゃ大切です。なぜならこの前提があることで、記事全体を通して一貫した主張ができるようになるからです。たまに話が迷子になっている記事や主張がぶれている記事なんかを見かけることがありますが、そこには主張が複数あることも少なくないです。
『このテックブログはこういう問いを解決するものです、それ以外は知りません』くらいの意識を持っておくことで、記事はギュッとまとまります。たった1つの主張を論理的に説明するだけですからね。
想定読者は「過去の自分」でだいたいOK
特に説明する系の記事全般において、「誰に伝えるか」で説明の仕方が変わるので、多くの書き手はペルソナを思い描きながら書くと思います。ですが、考えるのもしゃらくせぇ場合は過去の自分に向けて書くとよいです。これには明確な理由があります。
理由の1つは、記事のネタに困らないからです。 業務の中で、あるいはプライベートな時間で日々試行錯誤して学んでいるとしたら、具体的な経験はたくさん積み上がっているかと思います。その中で小さな「うまくいかなかったこと」は無限にあるはずなので、それをどう解消したのか？のエピソードは1つのネタになりえます。
理由のもう1つは、自分のアハ体験は自分の言葉で語りやすく、オリジナリティを出しやすいからです。 『あ~なるほど完全に理解した』『これってこういうことか~！』の経験、つまり「分かっていなかった過去の自分と理解した今の自分の差分がどこにあったのか」はスラスラ話せるのではないでしょうか。なので、過去の自分に対して『この話はここが分かるとすごく理解しやすくなるよ（君はここが分かってなかったせいで詰まってたんだよ）』を文章にするだけで記事が1本書けます。
理由の最後は、エンジニア（過去の自分）1人にぶっ刺さるテックブログは、他のエンジニアにもぶっ刺さる可能性が高いからです。 テックブログという性質上、読者がエンジニアに限られていることで、同じような悩みや困りごと、経験などを読者が容易にイメージできる可能性が高いです。加えて、自分が体験した経験は駆け出し初心者たちも高確率で体験することになるので、価値を継続的に生む可能性も高いです。
書き始めはまず見出しだけでロジックを立てる
記事全体でたった1つの問いに回答する意識を持つこと で想定読者の解決したい問いを考えたので、ここではそれに回答するためのロジックを組み立てます。
「その問いへの回答としては、こうです」を記事のメインの主張に据えて、それを支えるロジックを見出しに落としてみること をオススメします。見出しごとに何を伝えたいか（ゴール）を明確にしておくことで、迷子になりにくくなるからです。おもしろい文章などもロジックがあってこそだと思うので、まずは足場を固めましょう。（最終的に見出しをどう書くかはあとから考えたらいいと思います）
長めの文章を書く際に特におすすめですが、短めの文章ではそこまで考える必要はないです
とは言え、具体例を示した方が分かりやすいと思うので、例として私の過去記事を３つ雑に引用します。
サンプルその１：起承転結みたいな構成
# 記事で解決したい問い
エンジニアは一生勉強らしいけど、どう勉強してこかな...
# 問いへの回答（記事で主張したいこと）
たぶん知ったかぶりしてけばええんやで
# 回答の妥当性を支える根拠（見出しの主張）
- 起 ：エンジニアは勉強ってよく言うよね
- 転 ：知ったかぶりって実は悪い意味じゃない
- 承 ：知ったかぶりとエンジニアは相性がよさげ
- 結 ：とりあえず知ったかぶりできるを目標にしたらいいんじゃないか
- 提案：具体的にどうやって知ったかぶりするか、オススメ方法はこれ
- 締め：バランスよくインプットアウトプットしよう
サンプルその２：根拠をとりあえず並べる構成
# 記事で解決したい問い
プルリクつくってもなかなかレビューされないんだけどなんで？
# 問いへの回答（記事で主張したいこと）
コミット履歴に気を遣ってないから、かもよ
# 回答の妥当性を支える根拠（見出しの主張）
- 導入 ：コミット履歴キレイだといいことあるよ、目指すべきコミット履歴はこれから説明するよ
- 理由１：コミットの単位は開発者の意思決定の単位だから
- 理由２：意思決定の根拠はコミットメッセージ見ないと分からないから
- 理由３：意思決定プロセスが妥当であるかコミットメッセージ見ないと分からないから
- 理由４：コメットメッセージと変更差分がイコールになっているべきだから
- 理由５：コミット履歴が少ない方がレビュワーの負担が少ないから
- まとめ：コミットに気を遣うことでレビューされるスピード上がるかもよ
サンプルその３：シンプルなトラシュー構成
# 記事で解決したい問い
GitHub の REST API確認するときか返ってくるUNIX時刻をJSTにしたい
# 問いへの回答（記事で主張したいこと）
エンドポイント叩くときにこのコマンドにしなはれ
# 回答の妥当性を支える根拠（見出しの主張）
- 課題 ：UNIX時刻分からない
- 解決策：これでJSTで分かる
- 証跡 ：実際こんな感じの結果になります
無駄を省いて納得感を生む AREA法 × PREP法
見出しを置いて記事全体のイメージが出来上がったら、次に見出しの主張を支える内容を書いていきます。
特に、ボリュームのあるテックブログを書きたいとき、強烈に力を発揮してくれるのが以下の2つのフレームワークです。パラグラフライティングというやつで、どっちも似たようなもんです。
AREA法：
- Assertion（主張）：主張や意見を明確に述べる
- Reason（理由）：主張を支える理由を挙げる
- Evidence（根拠）：主張と理由を支える具体的な証拠やデータを提示する
- Assertion（主張）：主張や意見を明確に述べる（言い換えて述べる） / 別の視点を提示する
PREP法：
- Point（要点）：要点や結論を明確に述べる
- Reason（理由）：要点を支える理由を説明する
- Example（例）：例を挙げて、要点と理由を裏付けする
- Point（要点）：再度要点を強調する / 別の視点を提示する
これらを使って1つの段落を構成するように書くと無駄なく主張がまとまります。また、このフレームワークに沿って下書きを書いているとつながっているようでつながっていない甘いロジックにも気が付くことができます。ただ、あくまで枠組みを提供しているだけできっちり守る必要はないので、論理がちゃんとしてたらなんでもよいとおもいます。
とは言え、具体例を示した方が分かりやすいと思うので、例として私の過去記事を1つ雑に引用します。（2回目）
# なぜ単体テストが書けないのか
- 見出しの主張：レガシーコードで単体テスト書けないのは対処法を知らないから！
- A : 書けないのは対処法を知らないからだ
- R1: なぜなら、テスト対象を絞らなきゃいけない原因があるからだ
- R2: なぜなら、依存関係を排除しなきゃいけない原因があるからだ
- E : 例えば、実際こういう経験ある人いるんじゃないでしょうか
- A : 逆に、対処法を知ってればなんてことなく書ききることができる
# 依存関係を排除できればテストは書ける
- 見出しの主張：この記事で説明したいスコープは依存関係の排除についてだ！
- A1 : テストが書けない原因で2つあったけど、本記事で依存関係の排除を扱う
- R&E: なぜなら、テスト対象はIDEの機能で絞れるからだ
- A1 : なのでそっちはIDEでメソッド抽出して対処してください
- A2 : 依存関係の排除は苦しんでいる人が多いイメージだ
- R&E: なぜなら、いっぱいmockito使ってる人がいるからだ
- A2 : そんな人こそ依存関係排除のことを思い出してほしい
# 依存関係を排除するためのカギになる考え方
- 見出しの主張：「接合部」という概念を知ってればOK！
- A : 依存関係を断ち切るためのポイントは接合部という考え方だ
- A': つまり、接合部によって依存関係を断ち切ることができる
- E : 例えば、こういう場合に接合部という考え方は有効だ
- A : こうすることで、依存関係を排除することができるのだ
全部 AREA / PREP で書くと逆に冗長になるかもなので、適度に使うべきです
下書き時点での頭の整理には非常に有効ですのでそっちは超オススメ
めちゃくちゃ大切な誤字脱字チェック
「誤字脱字くらい...」なんてことは全くなくて、けっこう悪影響あるのでできる限り気を付けるべきです。見つけた瞬間、集中が途切れませんか？内容がスラスラと頭に入ってきてる途中で「誤字だ...」が急に脳みそを支配するじゃないですか、とってももったいないです。
いちばん最後にタイトルをつける
最後にタイトルをつけます。
私自身、タイトルをつけるのがけっこう下手なのでテクい話はできませんし知らないのですが、自身の記事の主張と読み手の期待値を乖離させない意識は大事だと考えています。期待値を下回ってきたときに、釣られた自分が悪いなぁと思いつつちょっとだけ残念な気持ちになるからです。例えば「開発生産性」や「エンジニア」などのビッグワードは多くの人に引っ掛かると思いますが、曖昧なワードだからこそ期待値も様々で、扱いが難しいですよね。
ですので、ここまでで考えた「想定読者の解決したい問い」「問いに対する自分なりの回答（主張）」なんかをうまいこと混ぜ込めるとよいんだろうなぁとぼんやり思っています。
まとめ
- そもそも文章を書くことの目的は読み手に何かしらの行動をしてもらうこと
- テックブログも読者の行動変化にピン止めするとよい記事になりそう
- 記事のメインの主張を、想定読者の問いへの回答に設定するとブレない
- 過去の自分に対して記事を書くことで、いろいろ捗る
- メインの主張を支えるロジックを見出しに、見出しの詳細はAREA法やPREP法で語る
おわりに
ここまで読んでいただいた読者の皆様、ありがとうございました。
学生時代に「いいスピーチとは何か」を勉強してたので、その経験をもとに最も大事だと思っているポイントを言語化してみました。
『たった1人でも自分で書いたテックブログによって行動が変われば成功だよ、駆け出しエンジニアでもハードル高くないよ』が伝わって、記事書く人が増えるといいなぁと思ってます！！