(cache)発信は最後でいい。知り合いゼロの職場で技術広報が信頼を築く順番

顔と名前が一致するエンジニアは、せいぜい一人か二人。直接の知り合いがひとりもいない職場で技術広報をすることになったらどうするか、をぼんやり考えてみました。参考になるものがあったら取り入れてみてください。

技術広報を18年やっていると、業界にそれなりの知り合いや、多少の知名度みたいなものはできます。ただ、これは声を大にして言いたいんですが、有名なのと新しい職場でちゃんと仕事ができることはまったく別の話です。結果を出し続けるために地に足をつけて地道にやるしかありません。

では順番に行ってみましょう。

チームやポジションへの期待値はどこにあるか

まずはっきりさせたいのが、上司と経営が求める期待値です。要は「技術広報というチームやポジションは、何をもって評価されるのか」。これを最初に聞きにいきます。

もちろん、面接の段階である程度は確認しているはずです。ただ、流れの早い業界だと、面接から入社までの数カ月で状況がガラッと変わることも珍しくありません。入ってからあらためて、聞き直しておきましょう。

聞くことはふたつ。

「この会社は、いまなぜ技術広報をやるんですか？」

「半年後、技術広報として何ができていたら合格ですか？」

ここを曖昧にしたまま働き始めるとどうなるか。頑張った感や労働時間の長さを見られるか、明確になっていない目標数値に振り回されるか、です。どちらにしても、1年後に「成果が見えにくい活動」と判断されて、部門そのものが見直される、なんてことも起こり得ます。

技術広報として打てる手は、たくさんあります。ブログ、イベントスポンサー、イベント開催、登壇支援、SNSなど。ただ、どれが有効でどの順番でやるべきかは、期待値次第でまるっきり変わります。採用のためなのか、技術ブランディングのためなのか、エンジニアの定着のためなのか。目指す方向が違えば、取るべきアクションも変わる。まずは期待値を聞いて、そのうえで打ち手を組み立てます。

逆に、ここで経営側が具体性を持っていないとしたら、それはそれで大事な情報です。技術広報の必要性を理解していない環境では、頑張りが評価につながりにくい。それを早めに知れるだけでも、大きいと思います。

評価軸そのものの立て方については、以前技術広報チームのマネージャーに贈る、経営層に説明できる評価軸にまとめたので、技術広報に関連する部門のマネジメントをされている方はあわせてどうぞ。

最初の1ヶ月は仲間を知る時間

期待値がはっきりしたら、まずは最大の仲間である社内の人達のことを知りましょう。最初の1ヶ月は、発信することにこだわりません。出来るかぎり、エンジニアや開発関係者など社内のコミュニケーションに時間を使います。

よく「新しい職場ではまず3ヶ月観察しろ」と言われますよね。でも、わたしはそこにはこだわりません。最初の1ヶ月を全力で観察しながら、手を付けられるところにはどんどん手を付けていく。観察と着手は、並行できます。焦らなくていいのは「外への発信」だけ。

そもそも専任の技術広報を置くということは、技術的なブランディングや採用への効果を見込んで、その活動に理解がある会社だということ。だとすれば、Xやブログといったアカウントも、すでに動いていることが多いはずです。だからといって、いきなり手を出す必要はありません。まずは様子を見て、どんな体制で運用されているかを確認する程度にとどめる。この1ヶ月は、発信するための土台をつくる期間だと捉えましょう。

誰に何が刺さるかわからないまま発信しても、それは「告知」にはなっても「コミュニケーション」にはなりません。外部に対して届ける価値がある情報かどうかを見極めるには、まず社内の人達を知って自分たちが使える武器を確認することが大事です。

どうやって社内の人達とコミュニケーションをとるか

いくつか方法があります。積極的に1on1をする、チームのランチに混ぜてもらう、Slackのtimes的なチャンネルに片っ端から入る。

おすすめはとにかく1on1を沢山すること。組織の規模にもよりますが、目安は20人から30人くらい。それくらいやらないと組織の傾向は見えてきません。入社してすぐはボーナスタイムなのでだいたいの組織で1on1の申し込みは歓迎されるでしょう。時間は30分でスパッとやります。

1on1で何を話すかというと、まずはお互いの自己紹介から。相手がどんな仕事をしていて、どんなチームにいて、そのチームのミッションは何か。じっくり聞きます。

ひととおり聞いたら、今度はこちらの番です。技術広報とは何をする人なのか。チームとしてどこを目指したいのか。ここは、経営や上司から聞いた期待値をそのまま抜粋して話せばいい。そのうえで「あなたの立場から、技術広報に期待することはありますか？」と聞きます。

相手が開発組織の人なら、普段どんなメディアを見て、どんなイベントに興味を持つのかも聞いておく。会社は基本的に「いまいる人に近いタイプ」を採用したいと考えるので、ここは採用のヒントに直結します。

これを何人ともやっていると、課題感や「こうしたい」という要望が、なんとなく見えてきます。複数の人から同じ意見が出たら、「なるほど、そこに課題感や興味が集まっているのだな」となります。

そしてこれは当たり前でとても重要ですが、全てしっかりとメモを取っておきましょう。AIのメモでもよいですが、いつでも見返せるように管理しておいてください。

調整力を高めるために組織の解像度が武器になる

1on1で話す相手はエンジニアだけとは限りません。PdMやEM、経営陣とも話せるなら話しましょう。広報やマーケティングとも出来れば実施します。意外と見落としがちなのが総務で、イベントやオフィスまわりで連携が必要になる場面はけっこうあります。早めに顔をつないでおくと、あとがずいぶん楽になります。

以前、実行力と突破力の話を書きましたが、実務でそれ以上に効いてくるのは調整力です。何かを実現しようとすると、たいてい誰かや何かの都合とバッティングします。そこで必要になるのが調整力です。

では、何を根拠に調整を進めるのか。判断基準になるのが社内の沢山の人と話した内容です。色々な立場の人の話を聞いておくと、会社組織そのものの解像度が上がります。物事を多角的に捉えられるようになり、どこを立ててどこを通せばよいのか、全体最適の方針はどっちにありそうか、その勘所がわかるようになります。

技術広報の武器は、技術・エンジニアへの解像度と、会社組織への解像度。知り合いゼロの職場では、そのどちらもゼロからのスタートです。だからこそ、この1ヶ月に時間をかけ今後の糧とするのです。

社外発信の前にまず社内の情報共有

隣のチームが何をやっているか知らないのに、外の人に「うちの開発組織はこうです」と語れますか？わたしにはちょっと無理です。だから社外発信の前に、社内の情報の流れを良くすることから始めます。

社内には発信できるネタが必ず眠っています。エンジニアの取り組み、開発プロセスの工夫、しくじりからの学び。ただ、それが共有される場がないと、ネタは各チームの中で埋もれていきます。「普通のことをやってるだけだから書くネタがない」と言われたら、業務内容をヒアリングして独自性を見出して「これは面白いから書く価値がありますよ」と伝えてみましょう。要はコミュニケーションをすればいいんです。

社内LT会でも、分報の盛り上げでも、週次の「今週のグッドニュース」でも、形はなんでもいい。まず社内で「あのチーム、そんなことやってたんだ」が起きる状態を作る。情報の非対称性を作らないようオープンにしていても、取りに行かないとなかなか情報を得ることはできません。内部に向けて伝えることからはじめてみましょう。

社外発信は、この延長にあります。社内で面白がられたネタは、外に出しても面白い。社内で誰も反応しないネタは、外に出しても刺さらない。社内の情報共有は、発信ネタの品質チェック機構でもあるんです。

ちなみに、会社の認知度を上げるために、技術広報担当者のキャラクターを前面に出すという手もあります。ただ、それは会社の状況に左右されるし、担当者が抜けたら続きません。本質的に技術に関して話していない人はすぐに見抜かれ、情報を届けたい人からはスルーされてしまいます。こうした理由で持続可能ではないので避けておくのが無難です。

そのブログはなんのために書くのか？

会社でやっているテックブログ、多いですよね。ではそのブログはなんのために書くのでしょうか。仕事として手を動かす以上、理由や目標や計画が必要です。

ここでPVをKPIにした瞬間、テックブログは苦行になります。PVを追うと、書きやすいバズ狙いのネタに寄っていき、現場の実態から離れ、エンジニアが「これ、うちのブログっぽくないよね」と冷めていく。数字は伸びても、書く側も読む側も、どこか満たされない。

技術的な発信だけをするのもよいですが、わたしがまず確認するのが「採用ツールとして過不足ないか」という視点です。採用候補者はカジュアル面談や面接の前に、必ずテックブログを読んでくれます。そのときに「どんな技術スタックで、どんな人たちが、どんな課題に向き合っているのか」が伝わる記事が揃っているか。そしてそれが職種やJDごとに揃っているか。揃っていないなら、何から書き始めるか自動的に決まります。

PVは、あとから見る数字です。目的ではありません。数字を置くとしたらユニーク執筆者を見て、関わってくれる人を増やすほうがよいでしょう。

ボトムアップは待っていても始まらない

「エンジニアが自発的にブログを書いてくれる文化を作りたい」

よく聞く話ですし、気持ちもわかります。ただ、これがなかなかうまくいかないんですよね。

「会社のブログでこういうことを実現したいんです」とエンジニアたちに丁寧に伝えて、あとは待つ。それで記事があがってくればいいのですが、たいていは月に数本書いてもらえるのがやっとです。目標にはぜんぜん届きません。じゃあリマインドすればいいかというと、どこの部署も忙しい。リマインドが途切れた瞬間、更新は簡単に止まります。想いを伝えるだけでは、現場は動いてはくれません。

エンジニアには開発という本業があり「書きたい気持ち」はあっても、締切のないタスクは開発の優先度に負けがちです。現場に必要なのは、想いではなく「書く理由」と「締切」と、ある程度の強制力です。

これは経験年数でどうにかなる話ではなく、どんな環境でも起きる構造の問題です。だから、知り合いゼロの職場ならなおさら待っていないほうがよい。ではどうするかというと、マネージャー陣にブログ執筆者をアサインしてもらえるよう交渉します。

「ブログを業務として書いてほしい。チームごとにアサイン依頼をするので工数をください。執筆者が決まってからの進行管理はこちらでやりますので」と。こっちも仕事なら、向こうも仕事。業務としてアサインされていれば、書く側も「業務時間に堂々と書ける」ので、書く大変さはあってもお互いにとって気が楽なんですよね。

文化は、あとからついてきます。アサインで書いた記事が読まれて、反応があって、「書くといいことがある」と体感した人が増えて、はじめて自発的に書く人が出てくる。順番が逆なんです。

仕事は待っていても来ない

そもそも技術広報を専任ポジションとしている会社自体、まだまだ多くありません。兼任、他業務との掛け持ち、あるいは存在すらしない。そんな会社のほうが圧倒的に多いです。そして、このポジションは決まったフローに沿って仕事が降ってくるものではありません。定型業務をこなしていれば回る、という職種ではないんです。「次なにしたらいいんですか、タスクくるまで待ってます」そういう姿勢ではどこにも辿り着けません。

自分で課題を見つける。自分で解決する。人を巻き込む。プロジェクトにする。やり遂げる。成果を出す。そして、また次の課題を見つける。このサイクルが技術広報という仕事のエンジンです。待っていてはダメなんです。

サイクルを一周まわすたびに、関わる範囲が広がっていきます。開発組織のことも、採用のことも、プロダクトのことも、顧客のことも。知らなかった領域に自分から手を伸ばして行かざるを得なくなる。

範囲が広がれば、できることの幅が広がる。幅が広がれば、練度が上がる。練度が上がって、はじめてプロフェッショナルと呼べる状態になる。

言われたことをやるのは、当たり前。それだけでは、プロの仕事とは言えません。プロは、期待値を超えていくものです。