エンジニア発信を応援する技術
2年半、エンジニアと共にその発信を支援してきた。
その中で特に大切だったのは以下2つ。
発信する気持ちを応援する
実際に届けるHowを支援する
正直「支援した」というと、なんだかおこがましい。むしろ元々持っている素敵なものを外に届けるための「応援」と呼びたい。
普段考えていることを書いていく。
発信するエンジニアの大半は「不安」
発信するエンジニアは自身のキャリアのためだったり、会社の広報のためだったり、採用のためだったり色んなミッションの中で発信に向き合っている。
よほど発信に慣れたエンジニアでない限り、発信には不安感を持っていることが多い。
自分の仕事が受け入れられるのか
どのように反応されるのか
おかしなことは言っていないか
そのような漠然とした不安感の中で、筆を進めていく。いくら仕事とは言え、その「不安感」は簡単にはぬぐえない。
横で「応援」する
その不安を横でサポートする立場として「大丈夫ですよ」と常に応援していく。
私は既にコードを書いていないから、実際の技術的な細部は分からない。でも、それが「なぜ素敵なのか」は元エンジニアなのもあって、ある程度みれば把握できる。
内容に関する不安感は他エンジニアのレビューをもらい払拭していく。炎上しそうな表現がないか、適切でない表現がないかは私が見ていく。
最後に残る「自信の無さ」は「普段頑張って仕事をして、ここまで磨いたものなら大丈夫ですよ」と背中を押す。
ありがたいことに、登壇に関してはかなり増えた。私だけの力では当然ないが、継続的にやってきた手応えは感じている。
しかし、単に"応援する"ではそうならなかったのも事実である。そこには「実際に届けるHowを支援する」スキルも確かに必要である。
その発信は「誰」の「何」を変えるのか
ではどうやって支えていくのか。
発信する時は必ず「誰」の「何」を変えるのかを共に決めていく。平たく言えばペルソナ定義と学びの定義をする。
発信をするときにやりがちなのは「話したいことを話す」ことである。
え？話したいこと話しちゃだめなの？
と思いがちだが、それ自体は良い。一方で、時間を取って聞いてもらう分、お互いがWin-Winな状態を作りたい。
ペルソナ定義
その発信を見るであろう「誰」を決める。
技術的なレベル
業界年数
どんな課題にあたっているか
可能な限りリアルに定義する。最も良いのは「身近な〇〇さんのために」と具体的な人を決めてしまうことだ。これを決めると「何を話し、何を切るべきか」が自然と分かるようになる。
学びの定義
「誰」が決まったあとは「何」を決める。その内容に触れた後、受け手は何を学ぶのかを先に決める。
〇〇の設定方法が分かる
〇〇移管のPjリード方法がわかる
〇〇のコンセプト全容が掴める
など最初は大雑把な簡単なものでよい。慣れてきたらしっかり作っていく。
例えば「サーバサイドが得意な新卒3年目」がペルソナなら
新卒3年目が経験のない「DBを含むシステム移管Pj」のリードを取る。その時にどんな落とし穴があるか、どうやって無停止で終わらせたのかを学べる
とはっきりと受け手のメリットを決める。するとパキッとしたメリットを主軸にコンテンツを作ることができる。
話したいことを話しても良い。でもWin-Winになる設計を先に終わらせておくと良い。
ネタの良さを見つける
もしコンテンツを作り始める前にサポートに入れるなら、ネタの概要を掴み共にそのネタの「良さ」を見つけていく。
「誰」に「何」を届けるのかを共に定義する
その仕事の中で本人にどんな成長があったのか
そのBefore /Afterの差分を取る
変化には必ず「前後」がある。その間にある変容や気づきは多くの学びに溢れている。
技術的な発見、マインドセットの変化、対象とする領域の広がり、制約条件の捉え方。
本人にとっては、自分が通過してしまったことだから変化ごと「当たり前」になっていることが多い。そこを丁寧にほどいていくと自ずと良さは見つけられていく。
ブログ発信は「書く前」に話す
エンジニアと共にブログを発信する時、必ず2つのパターンを経る。
1つはエンジニアが書いた記事のレビュー、もう1つは書き始める前からのサポートである。
書かかれたものは技術的レビューとレピュテーションリスク、前提のヌケモレをレビューすれば良い。
書く前であれば、共に話を聞いて「良さ」を見つけ、筋書きと書き味を決めていく。すると本人もスーッと記事を書き上げられることが多くなる。
登壇は「狙い」をサポートする
カンファレンス登壇には2パターンがある。
CfP: プロポーザル提出と採択
スポンサード
プロポーザル
プロポーザルは「そのカンファレンスのコンセプトや技術・コミュニティとしての価値観」に近いほど良い。その過程は選考そのものだからWin-Winの設計がとても大切になる。可能ならプロポーザル提出前の時点から共に考えていく。すると登壇資料作りも難航しない。
スポンサード
スポンサード登壇はお金を払って居るので、正直何を話してもいいのだが、以下2点に気をつけると良いことに気がついた。
どんな印象を持ってほしいのか
どんな学びを得てほしいのか
つまりプロポーザル+ブランディングとより難度の高い設計が必要になる。せっかくお金を出すし、力を貸してくれる社内エンジニアがいるのだから、良い登壇を作りたい。常にいろんなカンファレンスを下見したり前例をみたり、チューニングのやりようは色々ある。ここは日々の努力。
まとめ
エンジニアの発信を応援する方法について書いてきた。
発信する気持ちを応援する
実際に届けるHowを支援する
どちらも重要だ。気持ちだけでは足りないし、技術だけではHowの押し売りになってしまう。両方ができて初めて「共に創る」ができる。
言うは易し、行うは難し。ぜひ。やってみてください。
