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
13
はてなサマーインターンシップ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
8
はてなサマーインターンシップ2025 フロントエンド 講義資料
hatena
0
17
はてなサマーインターンシップ2025 コンテナ + Kubernetesハンズオン 講義資料
hatena
0
7
はてなサマーインターンシップ2025 クラウドと運用 講義資料
hatena
0
6
はてなサマーインターンシップ2025 RDBMSの基礎 講義資料
hatena
0
6
はてなサマーインターンシップ2025 セキュリティ 講義資料
hatena
0
5
はてなサマーインターンシップ2025 AIエージェント活用 講義資料
hatena
0
12
はてなサマーインターンシップ2025 プロダクトマネジメント 講義資料
hatena
0
23
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
560
Other Decks in Technology
See All in Technology
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
140
Vibe Coding Year in Review. From Karpathy to Real-World Agents by Niels Rolland, CEO Paatch
vcoisne
0
120
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
4
310
防災デジタル分野での官民共創の取り組み (2)DIT/CCとD-CERTについて
ditccsugii
0
210
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
4
460
社内報はAIにやらせよう / Let AI handle the company newsletter
saka2jp
8
1.4k
カンファレンスに託児サポートがあるということ / Having Childcare Support at Conferences
nobu09
1
530
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
290
AWS 잘하는 개발자 되기 - AWS 시작하기: 클라우드 개념부터 IAM까지
kimjaewook
0
130
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化/ #DevRelKaigi
nishiuma
2
160
リセラー企業のテクサポ担当が考える、生成 AI 時代のトラブルシュート 2025
kazzpapa3
1
150
「れきちず」のこれまでとこれから - 誰にでもわかりやすい歴史地図を目指して / FOSS4G 2025 Japan
hjmkth
1
280
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
37
3.4k
The Cost Of JavaScript in 2023
addyosmani
54
9k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Navigating Team Friction
lara
190
15k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
30
2.7k
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つの読者視点がある • 「なるほど」 • 「わかる」 • 「そうじゃない」
なるほど 評価を保留した態度である。良いとも悪いともいわなくて、ただそのテキストを受け入れましたという状況なのだ が、実はテック系のテキストにおいては、この領域がたいへん重要になる。 なぜなら「なるほど」としか言えないということは、自分の中にまだ評価軸がないことであり、読者が知らない知識 が書いてあるということであって、なおかつそれについて何かしらの自分のリアクションがしたいのだけどまだ学 習の途中であったり、業務で必要だから知っておかなければならなかったり、 とにかく「重要そうなことが書いて ある」ということだけ共有できている状況 を、ここでは「なるほど」というワードで象徴させています。 いわゆる無言ブクマや「あとで読む」ブクマが多い記事は、この「なるほど」感が高いとみてよい。技術系の媒体
ではたいへん重要。 =新しい知見の提供
わかる これは一般的な話で、つまり「わかりみ」がどれだけあるか、ということ。 読者自身がよく知っていたり、体験していたり、あるいは聞きかじっていたりといろいろな程度差はあれど、読ん で共感できる、納得感があるということ。やはりどんな記事でも、わかりみから入っていくことになるので、リード にはとくにわかりみがほしいところ。 コメント欄は往々にして「自分の場合はこうだった」という共感の例示や、シンプルに「わかる」的なワードが並 ぶ。コメントは多めになる。 =共感を得る
そうじゃない 記事が間違っている。 というだけではない。間違いではないのだけれど時代遅れだとか、もっとベストプラクティスがあるとか、そういっ た違和感の表明。 一見すると炎上しているようであっても、エッジな話題であるので単に議論百出していたり、そもそも議論が起き がちな話題であればそういった背景も考慮したほうがよい。 時代遅れを指摘されることは避けたいが、炎上であっても異論反論のコメントの中から学びが得られることもあ る。 =議論を巻き起こす
ふりかえりたいポイント(主に質的なまとめ) 想定読者に読まれているか? 期待したように読まれているか?(読後感) 知見を与えたかったのに議論が巻き起こってないか 共感を得たかったのにただ知見として読まれてないか 反論がほしかったのに「わかる」ばかりになってないか この記事に届いてほしい人が探しているキーワードで検索されているか?
ふりかえったら次のサイクルを回す! テーマ設定:同じ話題をまた書くか? 深堀りするのか? 少し角度を変えるのか? 想定読者:期待した読者に、期待した人数だけ読まれているか? 想定している読まれ方・読後感:何を期待して記事を公開するのか? 探されているキーワード:検索流入は取れたのか? 取りたいワードは何か?
ご清聴ありがとうございました! ブログを書くまでが はてなインターン!