ゼロから始める技術広報、まずはこれを読んでくれ！
TL;DR
この記事は、Money Forward 関西拠点 Advent Calendar 2021 🎄19日目の投稿です。18日目は 井上 慎也さんで でした。
本日はマネーフォワードで技術広報をしている luccafort が技術広報を始めるにあたり、どのような書籍やブログ、スライドを読んで学習したのか、そのときどう考えていたのかなどをご紹介します。
「参考になった！」と思っていただければ ❤️とシェアをお願いします。
ぜひ紹介した書籍やスライド、ブログの感想をSNSやブログにアウトプットしてもらえると嬉しいです！
よいものがより広く知られるとこのnoteを書いた意義と価値が生まれるのでぜひ積極的に感想などを書いてしてもらえればと思います。
対象読者
エンジニア採用したい！そのためにはブログだ！と思ってるひと
ブログ書いてもらいたいけど誰も書いてくれないどうすれば…と頭を抱えているひと
なんかよくわからんが技術広報とやらをやることになった、何する人なのこれ？というひと
なにもわからんがとにかく情報発信しないとなんかまずい！と思ってるひと
ゴール
ブログ何書けばいいの？から書けそう！と思ってもらえること
誰かにブログを書いてもらうためにどうすればいいか？がわかること
技術広報についてなにもわからないからなんとなく説明できるようになれること
章構成とその理由について
このエントリは大きく2つの構成で成り立っています。
1つ目は技術発信をするときに非常に参考になった記事や書籍の紹介、2つ目は技術広報を始めるにあたりどういうことなにを学んだか紹介という構成です。このエントリの主な対象者は1つ目を期待しているのではないかと思っています。
ただ、技術広報を初めてから情報発信についての相談が増えたので、「技術広報とはなんなのか？」「なぜ情報発信することが大事なのか？」というWhyの部分、技術広報に対する誤解が少なくないので自身が情報整理する上で非常に参考になった考え方のエッセンスと参考資料の紹介をすることで後に続く人の参考となるログを残しておこうと考えたため、このような構成になっています。
情報発信を0→1にする
エンジニア採用における技術広報の重要ポイント
技術広報を始めるにあたってアンチパターンをまず学んだ大事なスライド。
14ページに情報発信することの大事なエッセンスが詰め込まれてるのでまず読んでほしい。
特に「いいことしか書かない→ 🙅♀️ 悪いことを書いたっていい→ 🙆♂️ 」が至言なので絶対にみてほしい。
例えば、「操作をミスしてDBを吹き飛ばしてしまった」「マイクロサービス化したけどドメイン分割に失敗した」などの失敗談があったときに、これらを書いてしまうと会社のブランドを毀損してしまうのでは？と考えると思います。
これらの失敗談は実は大変強烈なコンテンツです。もちろん、表現に気をつける必要はありますが、エンジニア（主語がデカい）は成功例よりも失敗例とその対策や試行錯誤の経緯により注目する傾向があります。
こういった失敗談を外部発信するのをNGににしてしまうと「いいことしか書かない」という状況が生まれてしまい、息苦しい空気感ができてしまいます。こういった匂いを読者は敏感に感じ取ります。
本来採用や魅力づけのために頑張ってブログを書いてもらっているのに逆効果になってしまうのはとてもつらいです。
また、エンジニア組織の文化としても非常に重要なポイントで、小さく早くチャレンジすることでフィードバックサイクルを高速で回すことがプロダクトであれば、価値提供の質の向上につながりますし、エンジニアとしても学びを得る機会が増えることにつながります。
ブログを書く技術 / Blog is My Life
「ブログが書けません。(時間 | ネタ) がないんです」と言われたらまずこれを「読んでほしい」とご紹介しているスライドです。
かなり強いワードが出てくる（個人的にブログ原理主義と呼んでいます、ここまでいい切れるようになりたい）んですが本質はそこではなく「なぜブログを書くのか？」「なぜブログが書けないか？」「どうすればできるようになるか」という問いかけから出来るようになるまでのプロセスが濃縮され、とても参考になっています。
エンジニアが日常的におこなっている開発と同じく、習慣化することで出来るようになっていくと教えてくれる素晴らしいスライドです。
このスライドの素晴らしい点は「自分が書けない」ときだけに役立つのではなく、誰かにブログを書いてほしいときにも大活躍します。
特に16ページ目の「こんなネタはどう？」のページに書かれている内容をお伝えすると「これなら書けそうです！」といってもらえることが多く大変重宝しています。
採用強化のためにブログやイベント登壇をお願いするエンジニアリングマネージャーや広報担当者、会社の情報発信に課題感を持っているエンジニアなど書き手だけに留まらずさまざまな立場のひとにとって有用なスライドです。
イベント登壇されたときに書かれたブログがこちら。
情報ではなく経験をアウトプットすること
ブログが書けない、書かれない理由の1つに「質の低いブログを書いても意味がない」「二番煎じのブログは書きたくない」があります。
こういった相談を受けたときにレビューを行なうとだいたい「ブログがやったこと、わかったことの情報になってしまっている」になっている傾向が非常に高いです。
内容そのものはめちゃくちゃいいことが書かれているのに非常にもったいないなーどうすればいいんだろう？と悩んでいたのですが、そのときには次のブログを紹介して「こういう観点を注入してみるとどうですか？」とお伝えするようになってからブログの質がグッとよくなりました。
Classi株式会社で働くエンジニア、lacolaco氏によるブログより情報ではなく経験をアウトプットすることを紹介。
このブログの効果は質を高めるだけではなく「なんとなく書けそうだ！」と思ってくれるという効果もあります。
後述するファンベースに書かれているのですが、情報には共感ポイントがなく、「ふむふむそうなのか、それで？」となってしまいがちです。
ところがこのブログで言及されている経験や感情、考えていることを差し込むと「このひとは○○という現象のXXの課題を解決するために△△を試した」というコンテキストが共有され、一気に書き手の背景や前提を揃えることができます。
またこの情報で書き手への解像度があがることで、自分との比較が容易になり、読者のネクストアクションを促しやすい副次的効果が見込めます。
技術広報の解像度を高める
「技術をアウトプットするところに技術は集まる」ソウゾウ エキスパートチームの役割
なぜエンジニアに時間を割いてブログを書いてもらうのか？を考えたときにいいたいことの全てが濃縮されている！と思った記事です。
なぜカンファレンスにスポンサードや登壇するのか、なぜ開発ではなく登壇や発表に力を入れるのか？ブログを含む情報発信がしないとどうなるのか？を説明する際に情報補強としてよく使っています。
特にタイトルの 「技術をアウトプットするところに技術は集まる」 が個人的に大変気に入っていて、これは逆にいうならば「技術をアウトプットしないと加速度的に手元から離れていってしまう」と言い換えることができます。
これは、情報を発信しないと現状維持すら難しくなっていく（採用の難易度があがったり、認知度を高めるときのコストが上がったりする）とも言えます。
ここで多少無理してもやろう！となりがちですがこれは完全にアンチパターン&燃え尽き症候群になるので、自分たちがどれくらい継続可能なペースであるか？を考えて「これぐらいなら余裕だろう」と思った数値目標を設定することをオススメしています。
だいたいその目標で開始すると「頑張ればできそう」と思っていたくらいの大変さになっていたりします。
ですが、ここまで来ると仲間が1人2人増え始めるのでグッと楽になります。継続的な発信ができるかどうかの分水嶺なので頑張ってください！
DevRel エンジニアフレンドリーになるための3C
技術広報を初めてまず疑問に思ったことの1つに「技術広報ってエンジニアリングなの？広報なの？昨今話題にあがるDevRelとは何が違うのか？」ということがありました。
技術広報に関する情報はほとんど存在しなかったので、まずDevRelを知ることから始めようといくつかの書籍を購入して読んでみました。
その中の1冊が「DevRel エンジニアフレンドリーになるための3C」です。
DevRelを理解することで、技術広報との違いやDevRelが担うもの、その概念と共通するものしないものを理解する取っ掛かりになりました。
特に、本著の中のテーマの1つである「共創」が技術広報という「誰かにお願いをして情報発信をしてもらう、そのために何をすればよいか？」という観点でとても参考になりました。
本著はDevRelという切り口ではありますが、DevRelが持つ持ち物の1つに情報発信が含まれており、うまく言語化できない技術広報のモヤモヤを解消するきっかけになりました。
また技術広報とDevRelは違うと認識ができることで、技術広報のスコープとスコープ外を明確に意識することができ、タスクや目標の優先順位を決める際に指標を手に入れることができました。
ファンベース ──支持され、愛され、長く売れ続けるために (ちくま新書)
大変有名な書籍なのであえて紹介するまでもない気がするがファンベースは技術広報になるかたにはまず最初に読んでもらいたい一冊です。
いってしまえば情報発信というのは手段で、なにか成し遂げたい目的や目標があり、そのために用いられることがおそらく一般的だと思います。
その目的や目標を定めるとき、なぜそれを選択したのか？どうしてそれを行なうのか？といった背景を実に丁寧に1冊の書籍にまとめてくれています。
ファンベース ──支持され、愛され、長く売れ続けるために (ちくま新書)
情報発信を重要視する多くの理由は「採用強化」と「認知度向上」です。
エンジニアを採用するためにはまず「知ってもらう」ことが重要であり、その認知度を高めるために出来ることの1つとして情報発信を通した認知度と魅力づけを行っていると思います。
本著では「どういったことを伝えればいいのか？」の背景と理論が非常にコンパクトにまとめられています。
情報発信以外にも自社のブランディングやマーケティング、魅力づけなど応用範囲が非常に高い知識なので興味があって未読のかたにはぜひオススメです。
特に本著に刺激を受けた一文として以下のようなものがあるので紹介します。
こういうちょっとしたことが愛着につながっていく。ポイントは、モノの背景に「人」がいることをどうやって感じさせるかだ。
技術広報も根幹の部分は同じで、ただの情報ではなく開発のストーリーや開発者の課題や背景を届けることが大事だと考えています。
うまく伝えることは難しいですが、意識してそういった魅力を引き出すよう働きかけることで会社の魅力付けの強化や興味、関心を持ってもらうエントリーポイントになると考えています。
実際にそこからカジュアル面談や採用につながったケースもちらほら出ているので、採用が全てではないけど大事な要素の1つだと考えています。
そのためにもテックブログやテックイベント、カンファレンスなどで発表登壇が継続的かつ持続的におこなえることの重要性を痛感しています。
EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ
マネーフォワードでは社内でも活発に勉強会や輪読会が業務時間を使っておこなわれています。
その中の1つにPO輪読会というものがあり、対象読書本として紹介されていたこちらのEMPOWEREDを紹介します。
EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ
この本はいわゆるプロダクトマネジメント、あるいはプロダクトリーダーシップに関する書籍です。
かなり抽象的な内容も含んでいるため、完全に理解したとはいい難いのが本音です。
一見、技術広報とは遠い存在のように思われるかもしれません、ぼく自身もそのように思っていました。
ところがあるときプロダクトオーナーと直近おこなっていた技術広報の取り組みや苦労話の雑談をしていたときに「それってプロダクトオーナーやプロダクトマネージャーと同じ苦悩ですね」と言われ、参考になるかもとこの書籍を教えてもらいました。
また近日この本の読書会が社内で開催されるということだったので参加して、他のプロダクトオーナーとも議論し、より洗練された気づきを得るきっかけになればいいと思って読み始めました。
この本はテーマがテーマなので、とても抽象的な内容なのですが、いくつかの点で技術広報として学ぶべきことを教えられました。
その中の1つを以下にご紹介します。
本質的に問題解決者にならなければいけない。デザイナーとエンジニアは、多くの制約を抱えた問題の解決に長けている。それが文字通り、毎日の仕事だ。同様に、プロダクトマネジャーも問題解決者にならなければいけない。
これは技術広報も同じで抽象的かつ組織課題を解決する必要が多く、なぜエンジニアやデザイナーが技術広報をやるのか？を説明することができるようになりました。
本著内でより詳細にその理由が語られているのですが、ここでは割愛します。ぜひ手にとって読みいただければと思います。
ともあれ、抽象的かつ的を射た内容が書かれているため、技術広報にも応用可能な知識だと感じられました。
対象がプロダクト課題か組織課題か？の違いこそあれ、抽象的な課題の本質をみつけ、本当に解決すべき課題か仮説検証をおこない、課題の改善解消を進める…そのためには仲間を巻き込んだり、自律やスケールが必要になるなどプロセスの部分は全く同じだということに気づきました。
まとめ
当初はさらっと書籍やブログなどの紹介をする日和ったものを書く予定でしたがレビュアーから「ざっと読んだ印象だと単発でぽんぽん紹介されてる感じだったのでちょっと勿体無い」とコメントをもらって手直しをしたらいつもどおりの長文になってしまいました。口直しとはなんだったのか…。
2021年はおそらく過去一番、意識的に目的を持ってビジネス書を読んだのではないかと思います。
技術広報というエンジニアのスキルセットと全く違う職責、職務になったので必要な知識やベースをインプットする必要があったので当たり前ですが、前提となる知識や背景、考えないといけないものなど多くのものが異なっていたので苦労しました。
特に「こういうことを伝えないといけないんだ」「当たり前だと思っていたこういう情報が伝わってなかったのか」を実感し、それらを整備したり準備したりで奔走する1年（実際には9ヶ月）でした。
こういったインプットと経験が増えてくると「抽象的な課題から問題を抽出して仮説検証していく」というプロセスの部分はエンジニアとなんら変わりないということに気づくことができました。
ぼくは技術広報を始めるにあたり、どういった情報をインプットすればいいのかで右往左往しました。
この記事が過去の自分のように何から始めればいいのかわからない、どれを参考にすればいいかわからないというひとの参考になれば幸いです。
最近はリーダーシップ的な書籍や会議のファシリテーションをする機会が増えたのでこのあたりの書籍を読んだり、組織を変えていくことが一定求められるので組織をどうマネジメントするかや組織論、各種戦略について書かれた書籍やブログを読んでいます。
正直、とても苦手な分野ではあるのですが必要であることと、自分以外のひとの成果を最大化するためには重要なことなのでいろいろ学びと実践、そして失敗を経験しています。
こちらは機会があれば別でご紹介させていただこうと思います。
京都・大阪拠点では全方位、全職種を絶賛募集中です。少しでも興味を持っていただけたら↓からエントリーをお願いします、「まずはカジュアル面談から…」もOKです！ぜひご応募ください。
明日は京都開発拠点のエンジニア東海林さんの「自分の住む街、一乗寺をただただ自慢したい」です、レビューで読んだのですが、一乗寺への想いが溢れていてめちゃくちゃ面白かったです。
スラスラと読める内容だったのでぜひご覧ください！