はじめに
フューチャーAdvent Calendar 2020 の1日目です。
12月1日は私の誕生日です、ハッピーバースデー自分、これからも頑張ろう自分。
誕生日、そして年末らしくエモめな内容でいきます。
今年もアドベントカレンダーの季節が始まりました、楽しみにしています、そして忙しさに負けず締め切りを守っていきたいですね。
そんな思いを込めて、記事を書きたくなるような記事を目指して書いてみます。
さて、ここはQiitaですが、フューチャーアドベントカレンダーに参加している以上、私がフューチャー社員であることを隠す意味は無いでしょう、遠慮なく自分語りをします。
私はフューチャーには今年の6月に入社しました。
フューチャーには技術ブログがあり、そちらで文章を書きたい意欲が満たされるのでQiitaに書く機会は結構減ってしまいました、あとzennの台頭が以下略。
フューチャーの技術ブログには入社初月から月に1~2記事を掲載しています、結構頑張りました。
書いた内容を一覧にまとめてみました。
春の入門祭り🌸 #10 denoに触れてみよう
春の入門祭り🌸 #11 Kaggle入門
AWS認定 Machine learning specialty 合格記
GoPlus自由研究
go-swaggerでhello world
TiKVに触れる
「Go on DockerスタイルでのバックエンドAPI構築」というテーマでGo Conference’20 in Autumn SENDAIに登壇しました
2020年秋にVue.jsのアプリケーションを作るなら、押さえておきたい5つのポイント
読書の秋に読みたい、オライリー謎書籍10選
前職でも技術ブログに相当するものはあったのですが、社内でも認知度は低く、更新頻度は数カ月に1度だったり、所謂モチベの維持に失敗した状態です。
さっき見たら最新記事が4月のものでした...
会社のオウンドメディアがQiita以上の存在意義、ブランド価値を発揮できる状態に持っていくのは、会社のブランド力とブログ運営の努力が必要です。
フューチャー技術ブログは他の会社から参考になったと言っていただける事例を実際に聞くことがあり、この会社に入ってよかったと思うところです。
一方フューチャーでも技術ブログを更新させるモチベを保つのはシステムではなく、ひとえに編集長の頑張りのおかげだと感じる部分があり、尊敬の念を感じずにはいられません。
少々話が逸れましたが、この記事はブログ記事の話をするブログ記事です、表題の通り技術ブログを書く際に心がけたことを書いていきます。
本題の前に、何故ブログ記事を書くのか
人は何故Qiitaや、その他技術ブログに記事を書くでしょうか。
- 自分が困った部分を備忘録としてまとめる
- 文章としてアウトプットすることで知識の定着、体系化が期待できる
- 知見をオープンな場に残すことで説明に利用できる
- まとめたものが誰かの役に立つ
- 単純に文章を書くのが好き
- 会社のブランディングへの貢献
- セルフブランディングの一環
- 強くなりたい
- 偉くなりたい
色々建設的な理由と、出世欲や承認欲求みたいな人間の業とが各々の配分で存在すると思っています。
また産まれもった気質によるところもあるでしょう。
いずれにせよ、やったら自分にも他人にも良い事がありますし、どうせやるなら大きな反響があった方が嬉しいですよね。
ちなみにフューチャーには書いた記事がはてなブックマークのホットエントリーに乗ると讃えて貰える文化があります。
大人になっても褒められたいのが人の業、バズる記事を量産できるブログマスターを目指していきましょう。
良い記事を書くために心がけたこと
1. まだ世にないものを書く
ブログ記事を新しく書くからには、今までに無い記事である事が望ましいです。
具体的な事例はすぐに思いつかないですが、記事を書くための記事としてググった結果を切り貼りする程度の薄めな記事が公開されてしまう事が時折あります。
究極的には「いかがでしたか？」で終わるシリーズのアレとか（一応会社の看板を背負うので割愛
個人的な趣味ですが、同じ情報がそのトピックについてgoogle検索の1～2ページ目を読めば手に入るようなレベルの記事は書かないように心がけています。
まだ世にないもの、つまり、記事を公開するまでググっても出てこない情報です。
最新の情報で日本語での知見が無いもの、公式ドキュメントの不足を補うものや、マイナーなユースケースで知見が少ないものなど、同じ仕事を始めることになった人が救われるような記事を書くことを心がけています。
2. 自分が心から読みたい記事を書く
これは趣味の話を書けという意味ではなく、自分が仕事をしていて実際に困ったことをアウトプットしていこうという意味です。
情報の不足によって数時間溶けるような事があったら積極的にブログネタにしていきましょう。
誰かの役に立つのはもちろんですが、いつの日か同じことを別の案件でやる日が来たときに、記事に残したものが実際に役に立つことがあります。
3. 長文を書く筋力をつける
はてぶのランキングに乗るような記事、及び会社の看板を背負っても恥ずかしくないような記事は充分な文章量があります。
たとえば私の書いたdeno入門記事とさくらのナレッジのdeno入門記事を見比べてみましょう。
圧倒的敗北、流石はさくらインターネットです、否、力不足ですいませんでした。
単純な文字数だけでも私の記事は約3000文字であるのに対し、さくらのナレッジの記事は約18000文字、圧倒的な情報量の差があります。
私の記事のほうが1週間ほど先に公開されましたが、はてなブックマーク的には見向きもされなかった私の記事に対してさくらのナレッジの記事は350以上のブックマークがついています。
会社の知名度の問題ではない事は明らかでしょう（むしろそうでないと結局ネームバリューバトルなので辛い）
これは単純に記事の質が違うとウケが違う、という話＋αとして、はてぶの使い方が、あとで読むためのブックマークというユースケースを想定している事にも起因するのではと考えています。
後で見返したいだけの価値のある内容であること、ぱっと見で読み終えるには重い文章量である、一旦ブックマークしたくなるような内容であること。
「はてぶウケ」という意味では上記の2点は特に影響が大きいと思われます。
また、企業の看板を背負っても恥ずかしくない、仕事としても充分な品質のテクニカルライティングに相当する技術を身に着けるという意味でも、
難なく、呼吸をするように長文を書くスキルは身についた方が良いでしょう。
わかりやすい事例がフューチャーのCNCF連載です。
Policy as Code を実現する Open Policy Agent に憧れて。ポリシーコードでAPI仕様をLintする
Buildpacksのビルダーをスクラッチから作ってみる
の2記事は文字数が10000文字を超える力作であり、またはてぶ数が2桁を超えています。
Linkerdで始めるサービスメッシュは惜しくも9400文字といった分量なので、ジャスト10000文字が閾値という単純な話ではないと思いますが、一つの考え方として、文章量の観点で自分の記事の質を振り返ってみると良いかもしれません。
4. ウケそうなタイトルにする
私が今年書いた記事の中で一番のはてぶ数を誇る記事は、2020年秋にVue.jsのアプリケーションを作るなら、押さえておきたい5つのポイントです、胡散臭いタイトルですね。
この記事は元々「2020年秋にVue.jsのアプリケーションを作るなら」でタイトルを終わらせるつもりでしたが、何したらウケるのかなと色々実験している一環でキャッチーな文言を入れてみました。
正直大事なポイントも本当は3つくらいなんですが、3つだと物足りないので細かい部分を足して5つにしました。
なんとも下世話な工夫ですが、功を奏してはてなブックマークのトレンド入りすることができました。
世の中的にあったら嬉しい記事だと思って書いたのは本当なので、またVueはウケが良いとか、企業の名を使って技術選定の正解を提示するという行いはそれだけの価値がある、など別の要因がある可能性は大いにありますが、一番目に付くタイトルでの一工夫を心がけたのがこの記事です。
タイムマシンがあったらつまらない記事タイトルにしてどのくらいウケなくなるかを調査したい。
一方同じテイストのタイトルにした読書の秋に読みたい、オライリー謎書籍10選はスベりました。
個人的にはこういう良い大人が全力で変な事をしているの大好きなのでみんなに読んでほしかった。
ともかく、共感を呼びそうなタイトルや、転職エントリーとか炎上案件とか、本番環境の事故とか、良くも悪くも人の興味を引く内容であることがタイトルから読み取れることは反響の規模に少なからず影響を及ぼすのではないでしょうか。
世間の動きは読めないですが、炎上しない程度に工夫していきましょう。
自分も詳しくないですが技術系記事だろうがニュースだろうが、PV数を稼ぐノウハウはある程度共通しているのかもしれません。
この記事も、当初の仮タイトルは「半年間の技術ブログ振り返り」のような自分語りであることを示すものでしたが、「はてぶのランキングに乗るくらい良い技術記事を書くには」と敢えて一般化したタイトルにしました。
フューチャー技術ブログ分析
思ってること、言いたいことはだいたい言い終わったのですが、直感で思ってるだけです。
もう少しファクトベースな事をこの機会に書いてみましょう。
フューチャー技術ブログはてぶ数ランキングを勝手に開催します。
1位 これさえあればシステム構成図がだいたい描けるアイコンセットを公開します！
はてぶ数: 1362
文字数: 824
1位から特殊事例というか、今まで書いてきた内容とは別系統のジャンルですが、本当に使いたいと思って貰えるものを公開すると、それだけで圧倒的な件数ブックマークされます。
2位 本当に使ってよかったOpenAPI (Swagger) ツール
はてぶ数: 541
文字数: 13287
2位は想定通り、質、量ともに素晴らしい、OpenAPIを導入したい人たちの役に立つ良記事ですね、一安心です。
3位 GoでWebアプリ開発時にあるあるだったレビューコメント
はてぶ数: 431
文字数: 19839
2万文字近い力作、コードレビューのつらみという共感を呼ぶトピックなのも相まって納得の順位ではないでしょうか。
4位 チームで機能設計するためのPlantUML標準化
はてぶ数: 424
文字数: 5799
文字数的には決して凄いものではないのですが(とはいえ充分な量ですが)、1位と同じく実際に使ってみたくなる内容であることが4位という結果に寄与しています。
5位 一周回って、人間が読み書きする設定ファイルはJSONが良いと思った
はてぶ数: 397
文字数: 5281
お役立ちアイテムの紹介でも長文でもないパターンでは初のランクイン。
タイトルが読みたくなってくる、議論を呼びそうな内容であること、その人ならではの深い知見が端的ながらも記されている点が良かったのかなと思います。
6位 Goを学ぶときにつまずきやすいポイントFAQ
はてぶ数: 389
文字数: 33480
30000文字を超える超大作、質と言い量と言い精神と時の部屋で過ごしてるんじゃないかと思いたくなります。
7位 JavaプログラマーのためのGo言語入門
はてぶ数: 341
文字数: 20085
翻訳記事という新パターンとも解釈できますが、質の高い入門記事を書けばGoだろうとJavaだろうとみんな読んでくれるという説が出てきました。
8位 TypeScript教育用コンテンツ公開のお知らせ
はてぶ数: 333
文字数: 2177
私もお世話になっている仕事ですぐに使えるTypeScriptの紹介記事です。
1位、4位と同様本当に良いものをお知らせするタイプですね。
9位 TypeScriptでReactをやるときは、小さいアプリでもReduxを最初から使ってもいいかもねというお話
はてぶ数: 306
文字数: 12490
安定の1万文字越えハイクオリティコンテンツです。
10位 システム開発で得たRedis利用ノウハウ
はてぶ数: 281
文字数: 8830
初投稿でこの実績、強い
1万文字切りましたが、内容の質、タイトルのわかりやすさなど、全体的にハイクオリティである事で補っているように見えます。
以上トップ10位でした、目指したい領域です。
注意: バズる事を最大の目的にするのはダメ、絶対
ここまで書きましたが、バズることは目的にしてはダメです。
理由は2つほどあります。
- ノウハウはあっても基本的に周囲の評価は制御できない、精神を病む元になる
- バズる事だけを目標とした炎上狙いなど間違った方向に尖り始める
本人にとっても周囲にとっても良くないので、あくまでも結果としてニュートラルに受け止めて、健康的にやっていきたいですね。
技術ブログ分析2
11月27日に、本家技術ブログの方でも分析記事が公開されました、
数字で振り返るフューチャー技術ブログ（2020）
限りなく上位互換に近い冷や汗ものの内容です、ちょっと焦りましたが公開時点でこの記事ほぼ書き終わっていたので...南無参!!
さて、本家の記事は編集長パワーでPV数が集計されています。
ランキングもPV数ベースのものが集計されています。
ここで着目したいのが、はてぶ数ではランキング圏外にも関わらず、PV数ではランキング上位に存在する記事が存在する点です。
Reduxを分かりやすく解説してみた 文字数: 3395
Vue.jsのslotの機能を初心者にわかるように解説してみた 文字数: 5293
【合格記】GCP Professional Cloud Architect認定資格を振り返る 文字数: 2838
などです、傾向としては初心者向けだったり、ググられる需要があるものでしょうか...?
上二つはフロントエンド記事集中投稿の一環なので他の記事に引っ張らっれた可能性、フロントエンド知識の需要なども可能性としては考えられそうです。
いずれにしても、何が言いたいかというと、はてぶの数に一喜一憂するもダメではないですが、良い記事を書けばちゃんと見てもらえます。
バズる事を最大の目的にするのはダメ、絶対の補足です。
ちなみに今年のPV数ランキングという意味では私の記事も9位にランクインし、個人投稿数では4位でした。
最後にドヤっておきます。
まとめ
- 本当に人の役に立つ記事を書く、役に立つものがあればそれを紹介するだけでも良い。
- 技術記事なら10000文字超えるくらいの力作を書く。
- タイトルでウケを狙う
上記3点を抑えればきっと良い反響が得られることでしょう。
良質なアウトプットができることを目指して、これからも精進していきたいと思います。