はてなインターンシップ2024 ブログライティング講義資料

https://hatena.co.jp/recruit/intern/2024 /

Transcript

1. ライティング講義 はてなインターンシップ2024
2. 自己紹介 毛利勝久（コンテンツ本部第3グループ所属の編集者） • 企業のオウンドメディアを中心に コンテンツマーケティング に協力するチーム • メディア（媒体）の設計‧運⽤およびコンテンツ制作を仕事としています • 主にテック領域（技術記事、テック企業の記事広告、エンジニアのキャリア）を担当 • 前職から含めると編集者歴は30年になります @mohri / id:mohri
3. （前職ではいわゆる技術書の編集者経験もあります） コンテンツ本部 第3グループ 編集チーム（現職） 1994年から2008年まで翔泳社で紙の書籍を編集していた
4. この講義のモチベーション 職業として「記事を作って公開している」ひと の視点をお伝えします みなさんは、インターンが終了後 何らかのレポートを書くことになるはず 実用できて役に立つかもしれないし 視点が違いすぎて役に立たないかもしれない でも、そういう視点をお伝えします https://blog.hatenablog.com/entry/2013/09/25/103722
5. これから話すこと ソフトウェアエンジニアのアウトプットを編集していて感じたことなど • ソフトウェアエンジニアはどんなアウトプットをするのか？ • なぜソフトウェアエンジニアにはアウトプットが大切なのか？ • 技術ブログの役割 • エンジニアごとにさまざまな技術ブログの書き方・考え方がある • 書いた記事を広くいろいろな人に届けたいと考えたときにできること • オウンドメディア編集者としての視点 ＋おまけ • 記事を書くときに気をつけたい目次と構成のこと
6. エンジニアは技術情報をアウトプットする ソフトウェアエンジニア、特に Web系のエンジニアは自分の余暇の時間を使ってまで技術状況を共有し合っている ほかの業界では見かけないことなのでは？ 「単純に自分が仕事で得た知見を公開するのは楽しいし、人が公開している情報が自分の仕事の役に立つのはありが たい。どちらにしても嬉しいからこそ、大量の情報が勉強会や、ブログや、同人誌といった非商用の形で流通している。 休日に、自分の仕事で役立つ情報を売ったり買ったりして、みんな楽しんでいる。」 情報を必要としている者が自ら情報を発信する文化について - in between days
7. エンジニアはどんな方法でアウトプットするか？ ⇑［コスト大・影響力大］ 本を出版する・雑誌に記事を書く（技術系同人誌） カンファレンスに登壇する・セミナーを企画する（コミュニティへの参加） （技術系オウンドメディアに記事を書く） ブログに記事を書く［個人ブログ・ 企業ブログ・QiitaやZenn］ ⇓［コスト小・影響力それぞれ］
8. なぜテックブログは書かれるのか？ • エンジニア自身→ アウトプットは最大の学び・プレゼンスの向上 など • 所属企業 → 会社のプレゼンスの向上 → エンジニア採用 • コミュニティが情報共有を求めている
9. コミュニティ＝技術情報を共有するベース プロダクトごとのユーザ会や、言語ごとのコミュニティやカンファレンスで情報は共有される 理由としてはこういったモチベーションがあるのではないか …… • ソフトウェア技術は使われ続け、改善され続けなければ古びて使われなくなってしまう • 自分たちが開発している技術・便利に使っている技術が古びてしまわないようにしたい • 新しい機能、新しい使い方、ベストプラクティス、より便利になることを共有する （そもそも開発する対象が複雑だから、方法論くらい共有されてないとやってられない？）
10. なぜテックブログは書かれるのか？（再掲） • エンジニア自身→ アウトプットは最大の学び・プレゼンスの向上 • 所属企業 → 会社のプレゼンスの向上 → エンジニア採用 • コミュニティが情報共有を求めている ここからは書き手＝読み手にフォーカスして話していきます
11. エンジニアはなぜブログを書くのか？ エンジニア自身が「なぜブログを書くか？」を書いてある記事をいくつか見てみましょう • 自分自身でもあとで参照する言語化のため • アウトプット駆動で勉強して、情報のインプットとアウトプットのサイクルを回す • 他の人に読んでもらって喜んでもらう（情報を伝えるため） ※ご注意：以降のページでは、あくまで分かりやすく「ブログを書くこと」について触れている箇所を引用していますが、本来それ ぞれの意図するところは引用元の記事をあわせてお読みいただけるようお願いします。
12. 言語化しておいて後で参照できるように 柴崎優季さん 新しい領域への挑戦を続けて成長するために必要だったソフトウェアエンジニアとしての「軸」とは 「 アウトプットにもいろいろな方法がありますが、僕はひたすら技術ブログを書いています。 自分で言語化できな いことは、本を読んだりして分かったつもりでいても、実はぜんぜん理解できていない んですよね。だからとに かくブログで言語化してきました。 自分の得意な形でアウトプットし続けること。それがエンジニアとしての成長につながるはずです。 書いたブログが、その後の障害対応や改善に役立ったことがありました。」
13. アウトプット駆動のため 曽根壮大さん YAPC::Hiroshima 2024のゲストスピーカー・曽根壮大さんが語る YAPCの思い出とその魅力 「 小さな勉強会でしゃべると、それについて知っている人が教えてくれる。「次までに調べてきます」と言って、ネク ストアクションを積んで、次の登壇までにそれをやる、というふうに「勉強会駆動で勉強する」ことが多かったです ね。 ブログに書いたことについても教えてくれたり 、その内容について発表するとまた教えてくれる人が現れたりし て、アウトプット駆動がTwitterや勉強会を通じて先に起きていた。」
14. 他の人に伝える（喜ばせる）ため 和田裕介さん Cloudflareで動くフレームワークを和田裕介さんがオープンソースで開発する理由 「僕はその代わり「こういうものを作ったら他の人は喜ぶだろうな 」ということを発見したり、それを発信するのが 得意なんです。ブログの記事にしたり、セミナーで発表したり。そういうふうにプログラミングが得意でなかったと しても、技術を追求し続けることはできるんです。」 「エンジニアが技術ブログを書くことは多いですが、バズる記事はそう多くないですよね。広く読まれる記事にした いのなら、他で読めない内容になるまで突き詰めないと意味がありません 。「ちょっと試しにやってみました」と いうチュートリアル的な記事にもそれはそれで価値はありますが、 プレゼンスの向上を目的に発信するならそこ で終わらないようにするといいですね。」
15. 情報発信のモチベーションは三者三様 例に挙げた3人とも素晴らしいブログを書いているけど、モチベーションがちょっと異なりそう • 勉強したことをまとめて次に生かす・主な想定読者は自分 • もっとインプットを得るため・アウトプット駆動勉強法 • 読者を喜ばせたい・あわせてプレゼンスの向上も
16. モチベーションに応じて読者を選ぶ 想定読者をどこに置くかで、記事の書き方も変わってくる 想定読者の種類 • 自分自身 • 社内のエンジニア • あるコミュニティに属するエンジニア • 不特定多数日本中のエンジニア 想定読者が変わればブログの目的も変化する
17. テストファースト！ 公開した記事を読んでくれる人が「読者」である だけど、読者になる人は記事を公開した後にだけ存在するわけではない 記事を書く前に読者を想定しよう！ • どういった読者に向けて書くのか？ • その読者たちはこの記事を読んだらどういった反応をするだろうか？ 読後感をあらかじめテストケースのように考える
18. そして振り返る そして公開した記事への反応を見て、自分の見立てを確認する • 記事への反応は想定したものになっていただろうか？ • 読んでもらいたかった読者には届いていただろうか？
19. 振り返りのポイント 前のページの項目は、それぞれ次のように言い換えることもできる • 定量的評価（PV数、はてなブックマーク数 などの数字） • 定性的評価（コメント、ツイートの傾向 など） はてなブログの簡易アクセス解析や Googleアナリティクスで数字を確認しよう できればサーチコンソールで流入も見よう！
20. ツールは「はてなビジネスブログ」に参考記事 オウンドメディアの分析 - はてなビジネスブログ
21. SNSとSEO：流入元の 2つの観点 SNSとは、はてなブックマークや X（Twitter）など • 記事公開時に筆者の周囲から読者が広がる • この拡散が短期的にはとても重要 • 記事によってプラットフォームが異なることもあって興味深い でも長期的には検索されると嬉しい • 長期的にその技術が気になっている人に読まれる • 定番記事になると、ブログのファンも増える
22. 検索キーワードを読者目線で考える テックブログの記事を調べている読者の立場に立ってみると 1. この記事を読んで嬉しいのは、どんなことに困っているエンジニアか？ 2. どういう検索キーワードで調べものをしている エンジニアが読むと嬉しいのか？ 3. そのエンジニアに届くように「そのキーワード」をタイトルや本文で使っておきたい できる範囲でいいので、どういうことを知りたい人に読んでもらいたいか？ を考えたい
23. 記事の質＝読者の反応を見てみよう テック系の記事には3つの読者視点がある • 「なるほど」新しい知見の提供 • 「わかる」共感を得る • 「そうじゃない」議論を巻き起こす
24. なるほど 評価を保留した態度である。良いとも悪いともいわなくて、ただそのテキストを受け入れましたという状況なのだ が、実はテック系のテキストにおいては、この領域がたいへん重要になる。 なぜなら「なるほど」としか言えないということは、自分の中にまだ評価軸がないことであり、読者が知らない知識 が書いてあるということである。なおかつ、何かしらの自分のリアクションがしたいのだけどまだ学習の途中で あったり、業務で必要だから知っておかなければならなかったり、 とにかく「重要なことが書いてありそう」という ことが共有できている状況 のこと。 いわゆる無言ブクマや「あとで読む」ブクマが多い記事は、この「なるほど」感が高いとみてよい。無言ブックマー クが多いからといってスパムだとは限らない。
25. わかる これは一般的な話で、つまり「わかりみ」がどれだけあるか、ということ。 読者自身がよく知っていたり、体験していたり、あるいは聞きかじっていたりといろいろな程度差はあれど、読ん で共感できる、納得感があるということ。やはりどんな記事でも、わかりみから入っていくことになるので、記事に は何かしらのわかりみがほしいところ。 コメント欄は往々にして「自分の場合はこうだった」という共感の例示や、シンプルに「わかる」的なワードが並 び、コメント率は高めになる。
26. そうじゃない 記事が間違っている…… ということでもない。間違いではないけれど時代遅れだとか、別のベストプラクティスがあるとか、そういった違和 感も含む。 一見すると炎上しているようではあるが、エッジな話題だから議論百出していることもあり、そもそも議論が起き がちな話題だったりということもあるので、炎上かどうかは背景も考慮したい。 なお、たとえ本当に炎上していても、異論反論コメントから学びが得られることもよくある。
27. 「なるほど」「わかる」「そうじゃない」のバランス 実際は、記事中に「わかる」と「なるほど」と「そうじゃない」が、まだらになって混在する • タイトルに「そうじゃない」感が出ると本文が読まれないままコメントされたり • 前半に「わかる」話を集めて、後半で「そうじゃない」を小出しにする • どうしても「そうじゃない」感が出てしまう場合、もっと突っ込みやすい穴を意図して用意すると「何か言い たくてもやもやしている」人がみんなそちらに流れるかも？ 長文の記事になれば、そういった読後感のバランスを取ることも必要になるかも ……
28. まとめ：ふりかえりポイント（主に質的なもの） 想定読者に読まれているか？ 期待したように読まれているか？（読後感） 知見を与えたかったのに議論が巻き起こってないか 共感を得たかったのにただ知見として読まれてないか 反論がほしかったのに「わかる」ばかりになってないか この記事に届いてほしい人が探しているキーワードで検索されているか？
29. ふりかえったら次のサイクルを回す！ 次のことを考えながら、また記事を書いてみよう！ • テーマ設定：同じ話題をまた書くか？ 深堀りするのか？ 少し角度を変えるのか？ • 想定読者：期待した読者に、期待した人数だけ読まれているか？ ◦ そもそもその記事をほしい人ってどのくらいのコミュニティに刺さるのか？ • 想定している読まれ方・読後感：何を期待して記事を公開するのか？ • 探されているキーワード：検索流入は取れたのか？ 取りたいワードは何か？
30. TL;DR このスライドは長すぎるので、次のページから 表紙＋3ページでまとめます。
31. テックブログをバズらせる たぶんたった 1つの方法 インターン生のためのテックブログ入門
32. キャリア30年の編集者が教える「バズるブログ」とは？
33. 「バズるまで何度も書く」
34. バズるまで［読者を考えて 改善を重ねて］何度も書く
35. ご清聴ありがとうございました！ ブログを書くまでが はてなインターン！
36. おまけ：記事を書くときに考えたい見出しと構成 かなり多くのエンジニアブログ・技術記事を編集してきた 文章の上手下手は一朝一夕ではなかなか難しい・コツもシンプルにまとめづらい むしろ「構成」のほうが考えるヒントがあるのではないか
37. 長い文章を書くときにアウトラインが便利 とりあえず雑に構成をつくる • はじめに（序論） • やったこと（本論） • まとめ（結論）
38. アウトラインはだいたいこうなる 構成を細かく分割していく • はじめに（序論） ◦ 自己紹介 ◦ 動機・モチベーション • やったこと（本論） ◦ 最初の実装 ◦ 改善した実装 • まとめ（結論） ◦ 分かったこと ◦ 感想
39. 当然だけど本論が長くなる もっと細かく • やったこと（本論） ◦ 最初の実装 ▪ なぜその実装がよいと思ったか？ ▪ 工夫したこと ▪ 何がよくなかったか？ ◦ 改善した実装 ▪ 改善のアイデア ▪ 工夫したこと ▪ なぜうまくいったのか？
40. 4層になるとさすがにわかりずらいが …… もっともっと細かくなる • やったこと（本論） ◦ 最初の実装 ▪ なぜその実装が選択したか ▪ 工夫したこと • 技術の選択 ▪ 何がよくなかったか？ ◦ 改善した実装 ▪ 改善のアイデア • 別の技術を選択 ▪ 工夫したこと • 最初の工夫 • 次の工夫 • さらなる工夫 ▪ なぜうまくいったのか？
41. こんなになることもある 工夫にも手間がかかったものとそうでないものがある • やったこと（本論） ◦ 最初の実装 ▪ なぜその実装が選択したか ▪ 工夫したこと • 技術の選択 ▪ 何がよくなかったか？ ◦ 改善した実装 ▪ 改善のアイデア • 別の技術を選択 ▪ 工夫したこと • 最初の工夫 • 次の工夫 ◦ 工夫を成功させるアイデア ◦ アイデアの実装 ◦ 実装をやり直した ◦ またまたやり直した • さらなる工夫 ▪ なぜうまくいったのか？
42. まとめるとこんなアウトライン 論文ならまだしも、Webの技術記事がこうなってたらけっこう厳しい • はじめに（序論） ◦ 自己紹介 ◦ 動機・モチベーション • やったこと（本論） ◦ 最初の実装 ▪ なぜその実装が選択したか ▪ 工夫したこと • 技術の選択 ▪ 何がよくなかったか？ ◦ 改善した実装 ▪ 改善のアイデア • 別の技術を選択 ▪ 工夫したこと • 最初の工夫 • 次の工夫 ◦ 工夫を成功させるアイデア ◦ アイデアの実装 ◦ 実装をやり直した ◦ またまたやり直した • さらなる工夫 ▪ なぜうまくいったのか？ • まとめ（結論） ◦ 分かったこと ◦ 感想
43. 思い切っていったんフラットにしてみる 論文ならまだしも、 Webの技術記事がこうなってたらけっこう厳しい • はじめに（序論） • 自己紹介 • 動機・モチベーション • やったこと（本論） • 最初の実装 • なぜその実装が選択したか • 工夫したこと • 技術の選択 • 何がよくなかったか？ • 改善した実装 • 改善のアイデア • 別の技術を選択 • 工夫したこと • 最初の工夫 • 次の工夫 • 工夫を成功させるアイデア • アイデアの実装 • 実装をやり直した • またまたやり直した • さらなる工夫 • なぜうまくいったのか？ • まとめ（結論） • 分かったこと • 感想
44. 項目をまとめられたりしないか？ 1行や2行だけの項目はないか？ 同じことを書いている項目はないか？ • はじめに（序論） ← この見出し必要？ • 自己紹介 ← 2行くらいで終わってない？ • 動機・モチベーション • やったこと（本論） ← この見出し必要？ • 最初の実装 ← この見出し必要？ • なぜその実装が選択したか • 工夫したこと • 技術の選択 • 何がよくなかったか？ ← よくなかったことと改善のアイデアが表裏一体だったりしない？ • 改善した実装 ← この見出し必要？ • 改善のアイデア • 別の技術を選択 • 工夫したこと • 最初の工夫 • 次の工夫 • 工夫を成功させるアイデア • アイデアの実装 • 実装をやり直した • またまたやり直した • さらなる工夫 • なぜうまくいったのか？ ← 次の「分かったこと」と同じことを書いてない？ • まとめ（結論） ← この見出し必要？ • 分かったこと • 感想 ← 2行くらいで終わってない？
45. それでこうまとめられるかも？ 1行や2行だけの項目はないか？ 同じことを書いている項目はないか？ • （見出しなし）リードとして自己紹介 • 動機・モチベーション • 最初の実装方法として何を選択したか？ ◦ その方向を実現するために選択した技術 • うまくいかなかったので改善することになった ◦ 改善のアイデアとしては別の技術を選択することに ◦ 最初の工夫 • 次の工夫 ◦ 工夫を成功させるアイデア ◦ アイデアの実装 ◦ 実装をやり直した ◦ またまたやり直した • さらなる工夫により成功！ • ここから分かったこと・なぜうまくいったのか？ ◦ 感想
46. 書きやすい構造が、読みやすいとは限らない Web記事の構造について職業編集者が考えていること • インデントが深くなりすぎてないか？ • 項目ごとの分量は揃っているか？ • Web記事はフラットに上から下へと読み進める • 見出しが登場するタイミングが読むリズムを作る • 子要素だけで成り立っている親要素はそもそも親が不要かも • 見出しは2段階くらいにまとめるのが実用的 • 目次だけを見て、何が書いてあるのかわかるように
47. 参考リンク 僕が考える テックブログを書く意義 と 書き方のすゝめ 初めての「技術ブログ」書き方のご紹介 - SORACOM公式ブログ 技術ブログを書くモチベが上がるサイトまとめ テックブログ執筆に役立つ心構え - paiza times どうしてもやってしまいがちな「固有名詞間違いあるある」