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