月末の報告会で「技術記事を8本公開し、合計2万PVでした」と説明する。数字は増えたのに、採用担当は候補者の理解が深まったか分からず、営業は商談で使われたかを答えられない。制作本数と閲覧数だけでは、技術広報が事業に何を変えたかは見えない。
技術広報のKPIは、記事本数を捨てて採用数や受注額だけを見ることではない。本数、対象読者への到達、読者の行動、採用・商談・信頼への寄与、社内へ戻った学習を五層に分け、隣り合う層の因果を記録する。早く分かる補助指標と遅れて分かる成果指標を組み合わせるのが基本である。
技術広報のKPIは、記事本数から成果までを一段ずつつなぐ
KPIを決める前に、活動目的を一文にする。「技術力を示す」では測れない。「バックエンド採用の候補者が、扱う難題と支援体制を理解して応募を判断できる」「導入企業の技術責任者が、制約を理解して検証へ進める」まで具体化する。目的が違えば、同じ記事でも成功の定義が変わる。
五層の第一は産出である。公開本数、予定どおりの公開率、一本にかかった日数など、チームが直接制御できる。第二は対象読者への到達で、狙った検索語、指名流入、該当職種の読了、イベント参加者を見る。第三は読者の行動で、関連文書の閲覧、問い合わせ、応募時の言及、サンプル実行などを置く。
第四は事業成果への寄与である。採用なら仕事内容への理解や選考の認識差、営業なら技術検証の前進や商談で解けた論点、信頼なら第三者からの引用や継続的な相談を見る。第五は組織の学習で、読者の質問が製品、文書、採用説明、営業資料を何件変えたかを残す。最上段だけを年に一度見るのでは遅く、最下段だけを毎週増やしても目的から離れる。
技術広報の始め方で整理したように、先に決めるのは媒体ではなく、誰のどの判断を助けるかである。KPIはその設計を観測可能にしたものだ。読者と判断が曖昧なままでは、PVが増えても「誰に何が届いたか」を説明できない。
公開数とPVは必要だが、それだけでは成功を判定できない
公開数は制作体制の健康を測る。ゼロが続けば検証も始まらない。しかし本数を主目標にすると、短く作れるテーマ、既知の話題、確認の少ない内容へ偏りやすい。難しい設計判断を一本で丁寧に示すより、似た記事を五本出す方が評価されるからだ。PVも到達の広さは示すが、採用候補者と競合の閲覧を区別せず、読後の理解を直接は示さない。
GitLabのDeveloper Advocacyは、開発者との接点数と肯定的な反応をKPIとして公開する一方、それだけではチームの多様な仕事を捉えきれないと明記する。[S1] 同社のコンテンツ効果の資料も、ブログや動画の閲覧、キャンペーンへの影響、収益との接続を段階的に扱う。[S2] 一つの数字で活動全体を表せないという前提に立っている。
よくある反論は「採用数や受注額を追えばよい」だ。しかし最終成果は、求人条件、報酬、営業力、価格、製品品質、市況にも左右される。記事を読んだ人が採用されても、記事だけの成果とは言えない。逆に受注がまだなくても、比較に必要な制約を理解して検証へ進んだなら、技術広報は役割を果たしている。最終成果は共同成果として追い、途中の接点を残す必要がある。
指標が操作される危険もある。閲覧数を目標にすれば広い話題へ、問い合わせ数を目標にすれば質を問わない導線へ寄る。だから数量には条件を付ける。「対象職種からの応募時言及」「技術要件が確認できた商談」「修正につながった固有の質問」のように、望む変化を定義する。数字の増減と、実際の発言や判断理由を一緒に読む。
採用・商談・信頼は、記事との接点を残して確かめる
採用では、応募フォームに「知った記事」を増やすだけでは足りない。面談担当が、候補者が言及した技術テーマ、入社後の仕事に対する理解、誤解していた点を選択式と短いメモで残す。母数が小さい段階は率を競わず、同じ誤解が減ったかを見る。採用決定まで時間がかかるため、読了やイベント参加は先行指標、応募・選考・入社後の整合は遅行指標になる。
商談では、記事URLをCRMへ貼るだけでなく、いつ、誰の、どの論点を解くために共有したかを残す。共有後に技術検証へ進んだか、同じ質問が減ったか、制約の理解不足で後戻りしたかを見る。受注額へ機械的に全額を割り当てず、「要件確認を一段進めた」「不適合を早く判定した」といった寄与を記録する。不適合を早く見つけることも、双方の時間を守る成果である。
信頼は好意度という一語に閉じない。技術者からの再訪、資料や登壇での引用、具体的な相談、公開後の訂正への反応を追う。GitLabのイベント報告は、参加者数だけでなく、顧客からの学び、製品へのフィードバック、市場の示唆、リードの質まで記録対象にする。[S3] 接点で得た内容が社内の判断へ戻る設計は、オンライン記事にも応用できる。
この記録をつくるには、広報だけで完結しない。企業の中で編集者が担う接続の役割のように、技術者が事実と制約、採用・営業が読者の反応、編集者が問いと証拠のつながりを持ち寄る。個人を監視するのではなく、記事単位で接点と変化を最小限記録する。
月次レビューでは、数字より先に因果の切れ目を見る
運用開始時は、目的ごとに主指標を一つ、先行指標を二つまでに絞る。例として採用理解なら、主指標を「候補者が仕事内容を正しく説明できた面談の割合」、先行指標を「対象職種による記事言及」と「関連する採用ページへの遷移」にする。公開数は制作の制約条件として別に監視する。すべてを一枚の点数に合算しない。
月次レビューは、産出から学習までを左から読み上げる会議ではない。「届いたのに行動がない」「行動はあるのに成果へ進まない」「成果は出たが学習が戻らない」という切れ目を一つ選ぶ。届かないなら配信先や検索意図、動かないなら内容と導線、成果へ進まないなら製品や選考の条件を確かめる。記事の責任にできない問題も見える。
指標の基準値は最初から外部平均で決めない。媒体、読者、採用人数、商談期間が違えば比較できないためだ。まず四半期ほど同じ定義で記録し、自社の通常値と変化を知る。ただし観測期間中に職種、価格、計測方法を変えた場合は注記する。小さい母数では一件で率が大きく動くので、件数と具体例を併記する。
GitLabのDeveloper Relationsは、コミュニティ参加、貢献、プログラムの収益寄与など複数の指標を公開し、新しい測定方法について学習中であることも示す。[S4] 指標は完成品ではなく、活動仮説とともに更新される。過去との比較を守るため、定義変更日と理由は残す。
最初の90日は、少ない指標で測定経路をつくる
最初の30日は、目的と主読者を一つに絞り、既存記事にも共通の識別方法を付ける。検索、イベント、応募、商談など、読者が記事へ触れる場所を洗い出す。取得できない個人情報を無理に集めず、集計値と担当者の短い記録で足りる範囲を決める。計測のために読者の負担やプライバシーを損なってはならない。
次の30日は、五層のうち切れている箇所を一つ検証する。対象読者へ届かないなら配信を変え、届いても動かないなら読後の判断と導線を直す。最後の30日は、質問や誤解が社内の何を変えたかを確認する。一本の文書修正でも、同じ問い合わせの減少でもよい。変化がなければ、反応の戻し先に責任者がいるかを見直す。
技術広報のKPIで答えるべき問いは、「何本作ったか」だけではない。狙った読者へ届いたか。その人の判断や行動が変わったか。採用、商談、信頼へどのように寄与したか。得た学びが組織へ戻ったか。この四つを記事との接点でつなげれば、本数とPVは捨てる数字ではなく、成果へ至る最初の計器として正しい位置に戻る。
Sources / 参考資料
