DevRelの概念設計
Published in
May 22, 2024
DevRel（Developer Relations）関連業務を進める中でプロセスを思案したので記録
構造化（プロセス）
KPIマネジメントベースで考えてみる。
- Goal / KGI（成し遂げたいこと） : ソフトウェアでは良いプロダクトを作ることが目的になることが多い
- Input（入力） : 何を資源としてここに投入するか
- Fact（成し遂げたこと） : Goalに向かって組織が出した成果
- Output（発信）: Factをブランディングに変えていく作業
といった項目になる。
成果設計
それが、どこの成果に繋がってくるかは抱えている課題や狙いたいことにもよるが主に3つ。
- 発信を通して、組織にいるメンバーのブランディング、スキルアップ（アウトプット駆動）
- 採用。ブランディングを通してGoal（mission / vision）に共感した潜在層が入社する
- 1,2を通して強い組織になり、良いプロダクトが作れるようになる。競合優位性が勝る
これらは、1.から順に計測（因果関係）が難しくなっていく（遠くなっていく）が確かに効果はあると思われる。
- についても定量化が難しい部分もあるが満足度といった定性的な観点で良いと思う
DevRel活動の設計
こうした構造及び成果設計においてDevRel領域ができることは主に2つ。
- Factの表出化 : 成し遂げたことの中から、アウトプットができる素材を抽出し、提案する。もしくは新しい取り組みをDevRelチームでキャッチアップして提供してあげることでFactを作り出すことをサポートする
- 場の適応・セッティング : 発信の種別ごとに最適な場を選択・適応させる（登壇なのか、文章なのか、音声なのか）（外部メディアなのか、内部のメディア・イベントなのか）
特にエンジニア・デザイナー・PMからの能動的なアプローチを待っているだけでは厳しいので、こちらから発信内容の抽出・提案を仕組み化してフレーミングしてあげることは必要だと思う
効果設計
活動の予算を取っていく中で、定量的な成果をどこに置くかの議論になる。
とはいえ、成果設計にもあった直接的な採用数は成果として遠かったり定量的に示せないので、KPIではなくKDI（”Do”）を初手として取っても良いかもしれない。 実際の行動を数値化する上でまずは実行回数でもよい。
例えば発信内容の抽出からの提案の回数の内、実際に発信に繋がった数値（KDI）を目的として、結果としての遅行指標（応募数等）に響いているかを見るなどでも良いかもしれない
