はじめに
はじめまして。開発者のためのセキュリティサービスを提供したい、Flatt Security 執行役員の豊田恵二郎 @toyojuniです。
Flatt Securityは、Webエンジニア向けのセキュアコーディング学習プラットフォーム「KENRO」や「Shisho Cloud」のような開発者向けセキュリティプロダクトの開発・提供も行っていますが、2022年現在、売上の主軸となっているのは「セキュリティ診断」(以下、診断)というサービスです。セキュリティ診断とは、世の中で広く開発・提供されているtoCスマホアプリやBtoB SaaSのようなWebサービスにハッキングされるような脆弱性がないか、専門のセキュリティエンジニアが調査するサービスです。
このようなセキュリティサービスは主にセキュリティ担当者・情報システム部の方を対象に提供されることが多いですが、私たちはプロダクト開発の現場でコードを書いているような開発者の方を主な対象としています。
さて、2022年当初、私たちは診断のマーケティングに困っていました。 今回主題ではないので詳細は割愛しますが、いくつかの検証を繰り返しながら(最終的には半ば直感にも従いながら)、技術ブログでの情報発信をマーケティングの主軸に据えることにしました。
その効果については後ほど詳述しますが、結論から言うと、技術ブログでの情報発信によってターゲットの認知・理解・共感を得ることができたのではないかと思っています。診断依頼が増え過ぎてしまってブログ執筆が順調に進まないという嬉しい悲鳴の時期もありました(正直なところ、今も似たような状態ですが)。
具体的な数字としては、blog.flatt.tech (技術ブログを配置しているドメインです)において以下のような総PV数の差が出ました。
| 記事数(参考) | 総PV数 | |
|---|---|---|
| 2021年 | 10 | 46,578 |
| 2022年(~12/17) | 38 | 248,833 |
私たちは、診断サービスのメインターゲットを開発者1の方々に据えたので、技術ブログという施策をマーケティングにおいて選定しましたが、この記事を読んでいる皆様が所属する会社では、主にエンジニア採用の文脈で技術ブログという施策を実行することも多いのではないでしょうか。
本記事で紹介するのはこの技術ブログ運営の上流工程、すなわち「企画」において私たちが考え、実践していることです。そして、これはマーケティング/採用等の目的を問わずに活用できる考え方だと認識しています。
あくまでFlatt Security個別の事例ではありますが、継続的に世の中を豊かにする情報発信をしていきたい(その副次効果として組織的な目標を達成したい)方に読んでいただければ幸いです。
本記事の流れ
技術ブログ運営に携わる方が最初に立ち向かう必要があり、そして最も高い壁であるのが「ネタ出し」だと思います。本記事ではこの「ネタ出し」への向き合い方をまず紹介し、その手法を「企画2」全体へと拡張していきます。
また、本記事は「組織的な記事発信において、読者との最適なコミュニケーションを探る方法」の解説を目的としているため、個人が備忘録的に、自らへの投資として執筆する記事は対象にしていません。当然ですが、そのタイプの記事は方法論や目的にとらわれず、各々のスタンスで書かれることが大事かなと思います。
最初にして最大の難関「ネタ出し」
まずは、「技術ブログのネタが出ない」という状態の原因を2つに分解してみましょう。大抵は以下の2つで説明できるのではないでしょうか。
- ネタ出しのコミュニケーション・体制作りを構築していない
- 本来ネタになるはずのものを見逃している / 諦めている
個人的に、前者は仕組みと気合で解決できるもの、後者は攻略難易度が高いものだと思っています。まずは前者の議論を片付け、その後で後者をじっくり見てみましょう。
「1. ネタ出しのコミュニケーション・体制作りを構築していない」の解決
こちらは以下のような方法を駆使すれば解決できるのではないでしょうか。Flatt Securityでは以下の施策は全て運用しています。
- 定期的に技術者が集まってブレストを行う
- はてなブックマークの「テクノロジー」カテゴリの記事をRSSでSlackに配信する
- 技術的なネタを一定以上理解できる責任者を置く
- これは弊社ではビジネス職である自分です。すなわち技術者である必要はないです(が、Web開発に関する最低限の素養は必要だと思います)。
- Reacji Channeler を活用して、社内の些細な会話で生じたネタを見逃さないようにする
- 弊社では
:blog_idea:がついた投稿が#blog_ideaチャンネルにストックされるようになっています。
- 弊社では
#z_** のような分報チャンネルの話題も見逃しません。
- 「カジュアル社内ブログ」を運用し、ネタをストックする
- 技術的に気になったことや学んだことを、社内向けの文章として雑な文体で構わないのでWikiツール内に記録していこうという文化です。とにかく気負わないで書こうぜ！というポリシーは「チラシの裏宣言」というドキュメントに明文化されています。
他の企業様でも、こういった具体的なノウハウを蓄積されているのではないかと思います。実践している良い施策があれば、是非記事のシェアの時などに教えてください🙋♀️
「2. 本来ネタになるはずのものを見逃している / 諦めている」の深掘り
技術ブログに限らずコンテンツというものは「ネタ」と「切り口」によって方向性が決定すると思います。すなわち全く同じネタが存在した時にも、それのどのような面に着目するか、どのような読者をターゲットにするかで記事の方向性は大きく変わってくるということです。
しかし、これは持論ですが、技術ブログが執筆される際には「技術に真摯に向き合おう」という思いが先行して「目の前の事実を愚直に記述しよう」という意識が芽生え、「切り口」に関して考える機会が少なくなりがちだと感じています。「切り口」を考えないと、(少なくともあるターゲットに対しては)発信する価値がある、世界をよりよくすることができる情報も「新規性がない」等の理由で切り捨てられてしまうかもしれません。
これが「2. 本来ネタになるはずのものを見逃している / 諦めている」という状態です。
前節で紹介したような仕組みによって、ネタ不足の課題は一定解決されるでしょう。しかし、(少なくとも企画に携わる)メンバー全員で「ネタ」と「切り口」に関する共通認識を持たないと、こちらの課題が残ったままになると思います。
当然ですが、「切り口」を大事にしようというのは読者を騙そうという話ではありません。むしろ「もっと読者の課題意識に向かい合おう」という話だと考えています。
「切り口を考える」とは？
やや抽象的な話になってしまいましたので、「切り口を考える」とは具体的にどういうことか、Flatt Securityの事例で紹介します。
※以下で登場するXSS(クロスサイトスクリプティング)とは、Webアプリケーションにおけるとても有名な脆弱性で、アカウント(セッション)の乗っ取りやその他様々なリスクにつながるものです。
☔️ 切り口を考えていない例
〜ある日のFlatt Security〜
toyojuni「XSSに関するブログを書きましょう！」
エンジニア「XSSなんて有名すぎて今更書く事ないですよ」
toyojuni「そっか...そうですよね...」
〜Fin〜
🌞 切り口を考えられている例
〜ある日のFlatt Security〜
toyojuni「XSSって既にだいぶ有名ですけど、原理説明がメインのコンテンツで、JavaScriptの発火を alert() で再現するだけで終わってる記事がほとんどですよね。実際どういうJavaScriptが動作して、どんな被害が生まれるかはあまり語られていないのでブログネタとしていいと思うんですよ」
エンジニア「XSSって有名な割にまだまだ頻繁に検出される脆弱性ですし、その切り口で発信すればよりリスク・対策の必要性が世の中に伝わる気がしますね！書きましょう！」
〜後日〜
エンジニア「公開3日で5,400PV...めちゃくちゃバズりましたね...」
※ちなみに、実際は上記の切り口は自分ではなく執筆したエンジニア自身が提案してくれました。ありがたいことです...
切り口のまとめ
改めて結論ですが、仮にとても有名な概念 = ネタをブログで取り上げるにしても、よくよく考えてみるとまだ世の中では着目されていない側面 = 切り口が存在するかもしれません。 「既に世の中には十分に知られていて、ブログで発信する価値はないんじゃないか」と思えるネタであっても、すぐには諦めずに、世の中に与えられる価値・インパクトを再考してみても良いのではないでしょうか。
一方で、世の中にはまだ十分に知られていないネタであっても、切り口を考えることによって、読者や世の中に向き合ったより良い記事になるのではないかと思います。
切り口を考えるために必要な要素
ここまで、ネタと切り口をセットで考えることによって得られる利点について確認しました。では、具体的にどのような考え方をして、どのようなポイントを押さえれば切り口を適切に考えられるのでしょうか。1年弱発信を行う中で、少しずつ自信を持ててきた考え方について説明したいと思います。
とはいえ、こういった議論は偉大な先人が切り開いてくれているものです。車輪の再発明はせずに、以下の記事で紹介されている概念を導入させていただきます。
この古賀史健さんの記事では以下の3つの概念が紹介されています(なお、自分はこちらの記事ではなく同じ古賀さんの著書『取材・執筆・推敲 書く人の教科書』でこれらの概念に触れました)。
- 情報の希少性
- 課題の鏡面性
- 構造の頑強性
それぞれざっくり自分の言葉で解説してみます(オリジナルの説明は上記の記事よりどうぞ)。
情報の希少性
これは、記事で紹介する内容が「世の中にまだ十分に流通していない希少なものか」という視点です。当然ですが「AppleはiPhoneというイノベーションによって躍進を遂げた」なんて誰もが知っている事実を解説したところで、人々が求める情報にはならないでしょう。
課題の鏡面性
これは、記事で紹介する内容が「読者が自分ごと化して読むことができるか」という視点です。こちらも当然ですが、自らの生活や業務・知的好奇心に何の関わりもないような情報に興味が向くことはないでしょう。
(構造の頑強性)
こちらは自分の解釈では(本当にざっくり言うと)「文章がロジカルにわかりやすく書かれているか」だと思っており、どちらかというと構成・執筆工程の話と認識しています。 なので、「企画」にフォーカスしている今回の記事では省略します3。
「情報の希少性」「課題の鏡面性」を意識して切り口を考える
結論として、コンテンツの企画においては「情報の希少性」「課題の鏡面性」をバランスよく追求できるような切り口を考えることが大事だと考えています。いくら情報が希少でも鏡面性がないと当然ダメです。例えば、僕が今日カフェで飲んでいるコーヒーの味は、店員さん以外知り得ないとっても希少な情報ですが、課題の鏡面性がなさすぎて、とてもコンテンツとして成り立つものではないでしょう。
さて、ここで先述のXSSの例を振り返ってみます。
XSSはWebアプリケーションのかなり有名な(かつ絶滅していない)脆弱性なので、課題の鏡面性は元々あったものと思われます。セキュリティに明るくない方でも、Webエンジニアであれば「XSSの名前は知っている。攻撃者がJSを実行できてしまう。対策しないといけない」ぐらいの認識は持っている方が多いのではないでしょうか。
ですが、XSSという脆弱性を愚直に解説するコンテンツは、インターネット上の記事から書籍まで世の中に溢れています。すなわち、切り口を考えていない段階では情報の希少性がなかったということです。
そこで、情報の希少性を生むために既存の記事をリサーチし、「JavaScriptが実行されるまでの原理」というありふれた切り口ではなく「具体的にどのようなJavaScriptでどのような被害が生まれるか」という切り口を考え発信した結果、記事は大きな反響を生んだのだと思います。
企画は難しいからこそ、ガチガチの運用はしない
ここまで紹介したような考え方をFlatt Securityではどのように運用しているか、具体的に紹介します。
Flatt Securityでは、以下の画像(本記事の企画ドキュメントです)のように、記事の企画の段階で「情報の希少性」「課題の鏡面性」の2点をチェックする項目として入れています。どのように希少性があるか、どのように鏡面性があるかを必要に応じてエビデンスを示しつつ簡潔に記述することをルール化しています。
「情報の希少性」はいわゆる「既存記事」をGoogle検索 / はてなブックマーク等でリサーチします。「課題の鏡面性」に関してはかなり定性的ですが、弊社の場合は「この脆弱性はよく見つかる」「この技術スタックは広く使われている」あたりが複数人で認識が一致すればOKにしてます。
「大事大事言ってたわりにアッサリしたチェックだな」と思ったでしょうか。実際その通りだと思います。
いくら企画が大事でもこの工程をガチガチに固めすぎると運用自体が回らなくなるので、個人的には推奨しません。元も子もないですが、いくら時間をかけて検討したところで記事公開後の反響は予見できない部分が多いので、とにかく記事を書いてPDCAを回して、市場と編集部の間の「情報の希少性」「課題の鏡面性」に関する認識のギャップを埋めていくのが最も大事なことではないかと思います。
「記事公開後の反響は予見できない」と書きましたが、これはすなわち「情報の希少性」「課題の鏡面性」に関して適切に判断する難易度が非常に高いということです。本記事の最後のコンテンツとして、読者の皆様の組織でもこの非常に難しい指標を見極めていくにあたってヒントになりそうな事項を紹介していきます。
どのように難しいのか？
2つに共通する難しさ
「情報の希少性」と「課題の鏡面性」に共通する難しいポイントは、この2つが多くの場面でトレードオフの関係にあるということです。
希少な情報は、それだけネタに関して認知している人が少ないということですから、自分ごと化している人だって少ないはずです。逆も然りで、多くの人が課題に感じていることは既に先人がソリューションを提示していることでしょう。
「情報の希少性」をジャッジする難しさ
先述のように「情報の希少性」はいわゆる「既存記事」をGoogle検索 / はてなブックマーク等でリサーチしてチェックします。
ところが、自分がここまで紹介した内容を真剣に受け止めすぎてしまうと、検索してみたら似たような記事が出てきた時に「ああ、この記事は『情報の希少性』がない。オシマイだ。」と感じてしまうかもしれません。
でも、よく考えてみてください。例えば有名そうな既存記事があったとして果たして想定読者の1%以上がそれを読んだことがあるでしょうか(仮に読んだことがあるとして、十分に内容を覚えているのでしょうか)？
もちろん、既存記事を参考にして全く / ほとんど同じ内容のものを(個人の備忘録ならいざ知らず)組織として発信するのは倫理観が問われることですし、そうでなくともレピュテーションリスクになるので避けるべきだと思いますが、切り口や説明方法を工夫する(e.g. 図解する / 実際のコードをたくさん載せる)などでまだ世の中にない価値を生む余地はあるのではないでしょうか4。
情報の希少性に関するチェックがアッサリしているのはこれが理由です。既存記事のリサーチはシンプルにいい記事を書くために大事ですが、その結果に囚われすぎると思考が行き詰まってしまいます。
極論、「このトピックはまだ知らない人が多い、世の中にとって価値があるはず！」と思ったら書き、発信すればいいと考えてます。
「課題の鏡面性」をジャッジする難しさ
「課題の鏡面性」に関する難しさは、一言で言うと「課題が存在する」ことと「人々が課題を認識している」ことは別ということです。
人間は概して、自分の課題とその最適なソリューションが何であるかは認識・言語化できていないものです。なので、「これは多くの人々の課題を解決するアイデアだ」と考えて何かプロダクトやブログ記事を作成したとしても、人々がそもそもそのような課題があると自認していない場合、手にすら取ってもらえないことが多いのです。
プロダクトであれば、マーケティングやセールス・社会の変化によって、このギャップを埋めていくことができると思いますがが、ブログ記事でそんなことができるでしょうか？せいぜい、タイトルを工夫する程度でしょう。
ここで、Flatt Securityの事例を一つ紹介します。
「認可制御の不備」は弊社がとても頻繁に検出する脆弱性です。そこで、これは鏡面性のある課題だ、と思い記事を作成しました。もちろん、既存記事も少ないものでした。
結果として、伸びなかったというわけではなかったのですが、認可制御はとても強烈な課題だと認識していた自分にとって期待したほどではありませんでした。はてなブックマーク数で言うと先程のXSSの記事の1/5以下でした。この原因は何だったのでしょうか。
ここからはあくまで仮説ですが、よく考えてみると簡単な話です。もし世の中の開発者が「認可制御の不備」を課題として認識していたら十分に対策がなされ、そもそもあまり脆弱性として検出されないはずなのです。これがすなわち「『課題が存在する』ことと『人々が課題を認識している』ことは別」ということであり、非常に事前のジャッジが難しいなと感じたポイントでした。
結果として世の中に必要な情報を公開できているので、「記事を出すべきじゃなかった」という話では全くないのですが、より多くの人に情報を流通する努力をすべきであるのも確かです5。
難しさを受け入れる
このような難しさがあるゆえ、基本的には本記事前半で示したようなフレームワークにガチガチに則ることよりも、PDCAを繰り返して市場と編集部の間の「情報の希少性」「課題の鏡面性」に関する認識のギャップを埋めていくことが大事だと考えています。
個人的には、この2つの指標は「これらを踏まえれば絶対に伸びる記事が企画できる！」というものではなく、「これらを意識して改善を回していくことで企画が洗練されていく」ものだと思っています。
まとめ
本記事の内容をまとめます。
- 技術記事で「ネタ出し」が障壁になりがちな理由の一つに、「本来良いコンテンツになりうるものを見逃している」という課題があるのではないか
- ネタと切り口をセットで考えることで、その課題が解決できるはず
- 切り口を考えるには「情報の希少性」「課題の鏡面性」という2要素が指標として有効
- しかし、この2要素は銀の弾丸ではなく、あくまで改善を回して企画を洗練させていくためのガイドラインのようなもの
技術記事が何かしらのKPIのために書かれることは本質的ではないですが、皆さんが所属する組織においても必ず提供するサービス・プロダクトごとにによって成し遂げたいビジョン・ミッションがあり、そのためには採用が必要で、世の中に対して真摯な方法でその採用KPIを達成するために様々な努力をされていると思います。その助けに少しでもなれば幸いです。
ここまで紹介したような考え方で運営しているFlatt Securtiyの技術ブログはこちら。Webアプリケーション、AWS、Firebaseなどカテゴリ分けもしっかりしてあるので是非気になるお役立ち記事を見つけてみてください。
新着記事はTwitterの公式アカウントでお知らせしています。
また、事業拡大に伴い、Flatt Securityではセキュリティエンジニアを大募集中です！ブログでの発信に限らず、業務のあらゆる面で顧客の価値に向き合おうとする刺激的な環境です。是非直接お話したいと思いますので、 興味がある方はぜひ採用ページよりカジュアル面談希望の旨ご連絡ください。
「本記事を読んだ」とお伝えいただければ、わたくし豊田がカジュアル面談にてお話しさせていただきますので、ご連絡お待ちしております！
それでは、ここまでお読みいただきありがとうございました。
- いわゆるソフトウェアエンジニア以外でも、SREの方やプロダクトセキュリティの責任者などのプロダクト開発に近しい立場の方もターゲットと考えているのですが、この場ではわかりやすさのために丸めさせてください。↩
- 「企画」を対象にしているので、その後工程である執筆や運用に関するノウハウは本記事では対象としません。別の機会があればこちらも紹介したいなと思っています。↩
- こちらに関しても蓄積されたノウハウ的なものはないでもないので、また機会があれば書きたいと思います。しかし、技術ブログだから殊更どうこうという要素は少ない気がしており、それこそロジカルでわかりやすい文章を書くテクニックの情報は世の中に氾濫していそうで「情報の希少性」が下がってしまうかもしれません。↩
- 極端な話、XSSの例で言うと、愚直にXSSの発生原理を説明する記事は「希少性がない」と否定しましたが、本気で世の中をセキュアにしたい気持ちがあるなら世界からXSSを撲滅できるまで何回でも発信することには意義があるわけです。(実際はそんな書き方をしても読者に求められるコンテンツにならないので記事が流通せず、結局撲滅はできないわけですが。)↩
- このブログの成果として、読者の方から「このような内容の開発者向け研修をやってほしい」という依頼まで来たので、PV数では測れない価値ももちろんありました。しかし、それだけいいコンテンツだったなら、やはり流通して欲しかったと口惜しい気持ちになります。↩
