こんにちは、緑川です。
今回は技術広報を行う上で、個人的に早めにやっておけばよかったことを反省を踏まえて、簡単に書き留めておきます。
今回は広報というより、"エンジニアと目線を合わせるために"という点で記しています。自社の技術を知るためには、GHEを見るとか、エンジニアにインタビューをするとか、そういう日々の情報収集が一番大事だと思いますが、加えて下記をやっておくと目線が合って発信ネタの幅が広がると思います。
1.一回くらいプルリクを出してみる
技術広報に限らずだと思いますが、業務量が多いと本業以外のことになかなか手を出せないですよね。技術広報にとって「コードを書く」というのは本業ではないので、元エンジニアの技術広報の人でないと「自社で一回もコードを書いたことがない」という人もいるのではないでしょうか(自分がそうだったのですが)？
私自身は開発環境を整えていたのですが、特にコードを書くわけでもないので宝の持ち腐れでした。それでも技術広報の仕事はできてしまうのが、このキャリアにおいてステップアップの壁のような気が若干していますが、実際にプルリクを出すところまでやるといろんなことが体験できるので、その壁がやや低くなると思います。体験できることとしては、ドキュメントの豊富さやインフラの整備によりスムーズにツールの導入が完了したり、セキュリティの堅固さにも関わらずDBへの接続のしやすさだったり、エンジニアに聞くことの心理的安全性の高さだったり、たくさんあるかと思います。他にも、実際のプロダクトのコードをローカルに落としていじって遊んでみたり、DBから色々なデータを調べてみたりすることで、自社の技術のことがより理解できますし、発信するネタにもなるかと思います。
もしハードルが高かったり、わからないことがあったりすれば、気軽にプロに聞けますし、エラーは大抵誰かしらが経験済みでSlackに対処法が残ってたりするので、初めて行うとしても最高の環境下にあると思います。本業ではないので失敗もあるかと思いますが、その後の学習効果が高まりますので（生成効果）、コードを書いてプルリクを出したことがない人は一回はやっておくのがおすすめです。
2.スクラムを理解する
このご時世、多くの企業で開発にスクラムが導入されていると思います。
これも上記と同じで別にスクラムのことを知っていなくても技術広報の仕事はできますし、社内で何かスクラムのイベントを行なっていても「エンジニアの人たちが何か打ち合わせをしているなー」という認識で問題が起こらなかったりします。
とは言え、開発の流れを理解しないことには、エンジニア一人一人の役割が正しく認識できなかったり、今どういう状況なのか、どこが重要なイベントなのかが理解できなかったりするので、エンジニアの働き方だったり開発の仕方だったりはきちんと理解しておくべきなんですよね。エンジニアと共通言語を持つというのは何もプログラム言語やアーキテクチャだけの話というわけではないのです。
何より「うちのスクラムはこうやっていますよ！」というのも技術広報の一部なので、本当にスクラムは早めに理解しておくべきだったと思います。ちなみに今は認定スクラムマスターです。
3.幅探索優先
『両利きの経営』という書籍（言葉）の影響で、 最近は探索と深化という言葉が広まっていると思いますが、それに似たようなもので、知識も縦か横に探索することができるかと思います。縦と横、エンジニアの場合はどちらを選択するかで結構キャリアが大きく変わるかと思いますが、技術広報の場合は自他を比較をすることで広報すべき自の良さが把握できるので、知識は横を優先に広げていくべきなのかと思います（わかりやすい言葉にすると幅探索優先）
今年は「割と一つの技術にこだわり過ぎてしまっていたなー」という反省が個人的にあるのですが、技術広報は企業全体の技術力を広報する立場から組織横断型人材になることが求められると思いますので、知識の習得の仕方や働き方など深さ優先探索ではなく、早めに幅探索優先を意識して動いていくべきだったなと思います。
おまけ.なんでも数値を残しておく
KPIは不要派なのですが、それでも勉強会に参加した人数やカンファレンスでのブース来場人数なんかは、予算やノベルティ制作に関わってくるので、正確な数値を早めに毎回残しておくべきだったとは思います。ノベルティの数とか懇親会の規模とか、毎回記憶を無くしてしまうのですが、正確な数値を残しておけばよかったな、と思います。
カンファレンスのブースで↓をおいている企業を見たことがないですけど、どうやってブースへの来場者をカウントしているんでしょうかね（ノベルティを減らした数とか）？
今度機会があったら持って行こうかと思います。