Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
はてなサマーインターンシップ2025 ライティング 講義資料
Search
Hatena
October 14, 2025
Technology
0
26
はてなサマーインターンシップ2025 ライティング 講義資料
https://hatena.co.jp/recruit/intern/2025
Hatena
October 14, 2025
Tweet
Share
More Decks by Hatena
See All by Hatena
はてなサマーインターンシップ2025 Web API 講義資料
hatena
0
180
はてなサマーインターンシップ2025 フロントエンド 講義資料
hatena
0
59
はてなサマーインターンシップ2025 コンテナ + Kubernetesハンズオン 講義資料
hatena
0
33
はてなサマーインターンシップ2025 クラウドと運用 講義資料
hatena
0
22
はてなサマーインターンシップ2025 RDBMSの基礎 講義資料
hatena
0
26
はてなサマーインターンシップ2025 セキュリティ 講義資料
hatena
0
35
はてなサマーインターンシップ2025 AIエージェント活用 講義資料
hatena
0
45
はてなサマーインターンシップ2025 プロダクトマネジメント 講義資料
hatena
0
56
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
570
Other Decks in Technology
See All in Technology
Raycast AI APIを使ってちょっと便利なAI拡張機能を作ってみた
kawamataryo
0
240
プロファイルとAIエージェントによる効率的なデバッグ / Effective debugging with profiler and AI assistant
ymotongpoo
1
790
JAWS UG AI/ML #32 Amazon BedrockモデルのライフサイクルとEOL対応/How Amazon Bedrock Model Lifecycle Works
quiver
1
730
AIとの協業で実現!レガシーコードをKotlinらしく生まれ変わらせる実践ガイド
zozotech
PRO
2
300
OTEPsで知るOpenTelemetryの未来 / Observability Conference Tokyo 2025
arthur1
0
420
短期間でRAGシステムを実現 お客様と歩んだ生成AI内製化への道のり
taka0709
1
170
AIの個性を理解し、指揮する
shoota
3
620
パフォーマンスチューニングのために普段からできること/Performance Tuning: Daily Practices
fujiwara3
2
200
ストレージエンジニアの仕事と、近年の計算機について / 第58回 情報科学若手の会
pfn
PRO
4
960
NOT A HOTEL SOFTWARE DECK (2025/11/06)
notahotel
0
1.8k
実践マルチモーダル検索!
shibuiwilliam
3
540
今から間に合う re:Invent 準備グッズと現地の地図、その他ラスベガスを周る際の Tips/reinvent-preparation-guide
emiki
1
240
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Mobile First: as difficult as doing things right
swwweet
225
10k
Music & Morning Musume
bryan
46
6.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
Faster Mobile Websites
deanohume
310
31k
Speed Design
sergeychernyshev
32
1.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
Transcript
ライティング講義 はてなインターンシップ2025 8月22日 11時〜12時
コンテンツマーケティング / オウンドメディア 現在の所属:コンテンツ本部 第2グループ 編集チーム コンテンツ本部第2グループ = 企業のオウンドメディアを中心にコンテンツマーケティングに協力 コンテンツマーケティング
とは「対象となるオーディエンス向けのコンテンツをオンラインで作成、 公開、および配布することに焦点を当てたマーケティングの⼀形態」ウィキペディア メディア(媒体)の設計‧運⽤およびコンテンツ制作(編集チーム)
企業のテックブログ運営をお手伝い
この講義でお伝えすること 「エンジニアによるエンジニアのためのライティング技術」を伝えるのではなく 職業として「記事を作って公開している」ひと の視点をお伝えします。 みなさんは、インターンが終了後何らかのレポートを書くことになるはず そのとき、実用できて役に立つかもしれないし、 視点が違いすぎて役に立たないかもしれない でも、そういう視点を伝えます
これから話すこと ソフトウェアエンジニアのアウトプットを編集していて感じたことなど • なぜソフトウェアエンジニアはアウトプットするのか?アウトプットが大切なのか? ◦ 技術ブログの役割 ◦ エンジニアごとにさまざまな技術ブログの書き方・考え方がある • ブログを書くときに意識したほうがよさそうな「読者」のこと
◦ 書いた記事を広くいろいろな人に届けたいと考えたときにできること ◦ 振り返るべき量と質の話
なぜソフトウェアエンジニアはアウトプットするのか?アウト プットが大切なのか?
エンジニアは技術情報をアウトプットする ソフトウェアエンジニア、特に Web系のエンジニアは自分の余暇の時間を使ってまで技術状況を共有し合っている ほかの業界では見かけないことなのでは? 皆さんもすでにブログや SNS、カンファレンス登壇などを通じてアウトプットをしているかも そうでなくても、どこかのエンジニアが書いたブログ(個人ブログ、企業ブログ含む)や技術書、 QiitaやZenn、Stack Overflowで のやりとりや発表資料などを見かけたり参考にしたことがあるはず
なぜアウトプットするのか?
なぜアウトプットするのか? →コミュニティが情報共有を求めている
コミュニティが技術情報を共有するベース プロダクトごとのユーザ会、言語ごとのコミュニティやカンファレンス ソフトウェア技術は使われ続け、改善され続けなければ古びて使われなくなってしまう 自分たちが開発している技術・便利に使っている技術が古びてしまわないようにしたい 新しい機能、新しい使い方、ベストプラクティス、より便利になるもとを共有する →情報共有がソフトウェアのエコシステムを維持し、良質なものにする
なぜテックブログ(企業)は書かれるのか? 所属企業 → 会社のプレゼンスの向上 → エンジニア採用
なぜテックブログ(個人)は書かれるのか? エンジニア自身→ アウトプットは最大の学び・プレゼンスの向上 Findyエンジニアラボ https://findy-code.io/engineer-lab/
shibayuさん 柴﨑優季さん 元はてなエンジニア 現・クラスタ― 新しい領域への挑戦を続けて成長するために必要だったソフトウェアエンジニアとしての「軸」とは アウトプットにもいろいろな方法がありますが、僕はひたすら技術ブログを書いています。 自分で言語化できな いことは、本を読んだりして分かったつもりでいても、実はぜんぜん理解できていない んですよね。だからとに かくブログで言語化してきました。
自分の得意な形でアウトプットし続けること。それがエンジニアとしての成長につながるはずです。 書いたブログが、その後の障害対応や改善に役立ったことがありました。
Soudaiさん YAPC::Hiroshima 2024のゲストスピーカー・曽根壮大さんが語る YAPCの思い出とその魅力 小さな勉強会でしゃべると、それについて知っている人が教えてくれる。「次までに調べてきます」と言って、ネク ストアクションを積んで、次の登壇までにそれをやる、というふうに「勉強会駆動で勉強する」ことが多かった ブログに書いたことについても教えてくれたり、その内容について発表するとまた教えてくれる人が現れたり して、アウトプット駆動が Twitterや勉強会を通じて先に起きていた。 ※
SoudaiさんのFindyの記事も近いことを書いてるけど YAPCのブログの方がよかったので もっと成長したいソフトウェアエンジニアへ、出会いと経験で自分を変える「キャリアの螺旋」の歩み方 - Findy Engineer Lab
yusukebeさん 和田裕介さん 現・クラウドフレア Hono開発者 Cloudflareで動くフレームワークを和田裕介さんがオープンソースで開発する理由 僕はその代わり「こういうものを作ったら他の人は喜ぶだろうな」ということを発見したり、それを発信するのが 得意なんです。ブログの記事にしたり、セミナーで発表したり。 そういうふうにプログラミングが得意でなかった としても、技術を追求し続けることはできるんです。 エンジニアが技術ブログを書くことは多いですが、バズる記事はそう多くないですよね。広く読まれる記事にした
いのなら、他で読めない内容になるまで突き詰めないと意味がありません 。「ちょっと試しにやってみました」と いうチュートリアル的な記事にもそれはそれで価値はありますが、 プレゼンスの向上を目的に発信するならそこ で終わらないようにするといいですね。
情報発信のモチベーションは三者三様 3人とも自分のためにブログを書いているけど、モチベーションがそれぞれ異なる Shibayuさん …… 勉強したことをまとめて次に生かす・想定読者も自分 Soudaiさん …… もっとインプットを得るため・アウトプット駆動勉強法 Yusukebeさん ……
読者を喜ばせたい・からのプレゼンス向上
モチベーションが違う=読者の種類も違う 想定読者をどこに置くかで、記事の書き方が変わってくる 想定読者の種類 • 自分自身 • 社内のエンジニア • あるコミュニティに属するエンジニア •
不特定多数日本中のエンジニア →想定読者が変わればブログや記事の目的も変化する
ブログを書くときに 意識したほうがよさそうな「読者」のこと
テストファースト! 記事を書く前に読者を想定する どういった読者に向けて書くのか? その読者たちはこの記事を読んだらどういった反応をするだろうか?どんな 読後感を持つ? 読後感をあらかじめテストケースのように考える →読者に期待する反応を想定しておく
SEOは記事を届ける手段 SEO(Search Engine Optimization)とは? 検索エンジン最適化。検索エンジンのオーガニックな検索結果において、特定のウェブサイトが上位に表示され るよう、ウェブサイトの構成や記述などを調整すること。(ウィキペディアより) 記事のタイトルや構成、内容などを、読者が分かりやすく、読みやすく調整するといった最適化を工夫すること で、記事が検索画面の上位に表示され、より多くの読者の目に触れやすくなる →上位表示されることで、記事が届きやすくなる 【★注意★】
検索画面上位に表示されることが目的にならないように!
SEOは読者目線を考える手段 この記事を読んで嬉しいのは、どんなことに困っているエンジニアか? ↓ どういう検索キーワードで調べものをしているエンジニアが読むと嬉しいのか? ↓ そのエンジニアに届くように「彼や彼女が知りたいキーワードを目立たせる」 ↓ これが本来の意味での SEO(検索エンジン最適化)
「読者が知りたいこととは?」のヒントは検索画面にあり 「はてな インターン」でググってみよう ↓ その検索画面にはどんなサイトやページが上位に表示されていますか? ↓ そのサイトやページにはどんな情報が記載されています? ↓ その情報を欲しがるのはどんな人ですか? ↓ その人は他にどんな情報を知れたら嬉しいですか?
↓ 皆さんは、その情報を知っていますか?その情報を記事にできますか?
そして振り返る そして公開した記事への反応を見て、自分の見立てを確認する • 記事への反応は想定したものになっていただろうか? • 読んでもらいたかった読者には届いていただろうか?
振り返りのポイント 前のページの項目は、それぞれ次のように言い換えることもできる • 定量的評価(PV数、ブックマーク数) • 定性的評価(コメント、XなどSNSでの反応、傾向) はてなブログの簡易アクセス解析や Googleアナリティクスで数字を確認しよう できればサーチコンソールで流入も見よう!
自分の記事はどんな性質を持っている? =読者の反応を見てみよう テック系の記事には3つの読者視点がある • 「なるほど」 • 「わかる」 • 「そうじゃない」
なるほど 評価を保留した態度である。良いとも悪いともいわなくて、ただそのテキストを受け入れましたという状況なのだ が、実はテック系のテキストにおいては、この領域がたいへん重要になる。 なぜなら「なるほど」としか言えないということは、自分の中にまだ評価軸がないことであり、読者が知らない知識 が書いてあるということであって、なおかつそれについて何かしらの自分のリアクションがしたいのだけどまだ学 習の途中であったり、業務で必要だから知っておかなければならなかったり、 とにかく「重要そうなことが書いて ある」ということだけ共有できている状況 を、ここでは「なるほど」というワードで象徴させています。 いわゆる無言ブクマや「あとで読む」ブクマが多い記事は、この「なるほど」感が高いとみてよい。技術系の媒体
ではたいへん重要。 =新しい知見の提供
わかる これは一般的な話で、つまり「わかりみ」がどれだけあるか、ということ。 読者自身がよく知っていたり、体験していたり、あるいは聞きかじっていたりといろいろな程度差はあれど、読ん で共感できる、納得感があるということ。やはりどんな記事でも、わかりみから入っていくことになるので、リード にはとくにわかりみがほしいところ。 コメント欄は往々にして「自分の場合はこうだった」という共感の例示や、シンプルに「わかる」的なワードが並 ぶ。コメントは多めになる。 =共感を得る
そうじゃない 記事が間違っている。 というだけではない。間違いではないのだけれど時代遅れだとか、もっとベストプラクティスがあるとか、そういっ た違和感の表明。 一見すると炎上しているようであっても、エッジな話題であるので単に議論百出していたり、そもそも議論が起き がちな話題であればそういった背景も考慮したほうがよい。 時代遅れを指摘されることは避けたいが、炎上であっても異論反論のコメントの中から学びが得られることもあ る。 =議論を巻き起こす
ふりかえりたいポイント(主に質的なまとめ) 想定読者に読まれているか? 期待したように読まれているか?(読後感) 知見を与えたかったのに議論が巻き起こってないか 共感を得たかったのにただ知見として読まれてないか 反論がほしかったのに「わかる」ばかりになってないか この記事に届いてほしい人が探しているキーワードで検索されているか?
ふりかえったら次のサイクルを回す! テーマ設定:同じ話題をまた書くか? 深堀りするのか? 少し角度を変えるのか? 想定読者:期待した読者に、期待した人数だけ読まれているか? 想定している読まれ方・読後感:何を期待して記事を公開するのか? 探されているキーワード:検索流入は取れたのか? 取りたいワードは何か?
ご清聴ありがとうございました! ブログを書くまでが はてなインターン!