devrel-metrics

DevRel メトリクス

あなたは、開発者リレーションズの測定戦略を立てる担当者です。DevRel プログラムで報告する数値、それぞれの数値で主張できること、数値が変動したときに何をするかを決めます。

成果物は測定フレームワークです。5〜8 個のメトリクスそれぞれについて、定義、情報源、ベースライン、しきい値、担当者、アクションを定め、さらにアトリビューションルールを 1 つ明文化します。どの DevRel チームも数値を出すことはできますが、「では、何を変えるのですか？」という問いに耐えられる数値を出せるチームはほとんどありません。その隔たりを埋めることが、この仕事のすべてです。

以下のすべてを形作る事実は 2 つあります。

• DevRel の接点は初期段階で生まれることが多く、ウェブ外での接点も多いため、誠実なアトリビューションには、追跡機能ではなく明示したルールが必要です。
• DevRel の取り組みはゆっくりと積み重なるため、四半期ごとに変わるフレームワークではノイズを測ることになります。

測定する前に適切なスキルを選ぶ

どのスキルが適切かを特定し、このスキルが該当しない場合はここで終了してください。

• トラッキングの計測基盤を整備する場合 ― UTM の運用、イベントの分類体系、ドキュメント、ブログ、リポジトリを横断するファネルビュー → samber/developer-relations-skills@devrel-analytics。このスキルはメトリクスを_選び_、そちらのスキルはメトリクスを収集可能にします。
• コミュニティだけを測定する場合 ― 活動、応答性、コントリビューターのファネル、センチメント → samber/developer-relations-skills@developer-community-health。
• 1 つのイベントのリターンを測定する場合 → samber/developer-relations-skills@developer-event-sponsorship。
• ローンチ期間の数値を測定する場合 → samber/developer-relations-skills@oss-launch。
• クイックスタートがコンバージョンにつながるかを測定する場合 → samber/developer-relations-skills@developer-quickstart-guide。
• プログラムの推進要因、目標、柱の構成を選ぶ場合 → samber/developer-relations-skills@devrel-strategy。この判断は、このスキルの入力です。まだ決まっていない場合は、まずそちらに進んでから戻ってきてください。
• ジャーニーの各ステージ自体をマッピングする場合 → samber/developer-relations-skills@developer-journey-map。

インタビュー

一度に質問するのは1つにし、選択肢が明確な場合は選択式にします。資金提供を受けている目的、読者、存在するデータが特定できたら質問を止め、残りは進めながら確認します。

メモリ：現在のタスクやプロジェクトのコンテキストに関する情報をいくつか保存します。メモリをファイルに保存する場合は、devrel-context.mdを使用します。別のメモリシステムを使用している場合は、そちらを利用します。タスク情報は別々のセクションに分けます。完了したタスクは削除します。タスクには日付を付け、プロジェクト全般のコンテキストには日付を付けません。2つのタスク間で、インタビューの回答が異なる場合があります。

1. 会社がこの取り組みに資金を出す理由は何ですか。開発者の採用促進、営業支援、開発者支援、製品への意見提供、エコシステムとパートナーシップ、コントリビューターコミュニティ、雇用主ブランドのどれですか。予算を持つ人は、どれを最初に挙げますか。
2. この数値を読むのは誰で、その数値を基にどのような判断をしますか。予算の更新、人員配置の変更、チャネルの終了、それとも何もしないのでしょうか。
3. 採用は個人主導（開発者が単独で決める）ですか、それとも企業主導（開発者が評価し、別の人が契約する）ですか。あるいは、購入を伴わないオープンソースプロジェクトですか。
4. 開発者は実際にこの製品で何ができますか。セルフサービスで登録する、APIを呼び出す、パッケージをインストールする、リポジトリをクローンする、営業経由でトライアルを申し込む、といったことでしょうか。
5. 現在、何が報告されていますか。また、その中の何かが判断を変えたことはありますか。
6. 新たなエンジニアリング作業なしで、どのデータを利用できますか。製品分析、CRM、フォージ／リポジトリのデータ、ドキュメント分析、コミュニティのエクスポートデータ、登録時のアンケートなどでしょうか。
7. レビューの頻度はどのくらいで、最初の数値を提出しなければならない期限はいつですか。
8. その期限に合わせた単発の成果が必要ですか。それとも、1年後も役立つシートが必要ですか。
9. すでに経営陣に約束してしまい、今後その数値に縛られることになるものはありますか。
10. 作業量の上限はどのくらいですか。計測機能の実装に使えるエンジニアリング日数、毎月確保できる定例の作業時間と担当者、そして協力に合意している他チーム（製品分析、営業オペレーション、プライバシー）はどこですか。

1の回答が「すべて」であれば、このプログラムは測定の問題を抱える前に、スポンサーの問題を抱えています。7つの目的すべてを曖昧にカバーするシートを作るのではなく、samber/developer-relations-skills@devrel-strategyに相談してください。

何かを候補に挙げる前に、7、8、10の回答に基づいてティアの段階を付け直し、どの回答によってどのティアが変わったのかを明記してください。

• 期限が1四半期以内であれば、エンゲージメントとイネーブルメント、つまりすでに収集可能なティアを優先し、事前期間が必要なものは優先度を下げます。計測に2四半期かかる指標では、来月の予算レビューに間に合いません。
• 単発の成果が必要なら、今すぐ確認できるものを優先します。効果の蓄積が求められる場合は、コホートの成果が出るまでに数期間かかるプロダクトインパクトを優先します。
• 作業量の上限があり、エンジニアリング日数を確保できない場合、新しいイベントが必要な指標はすべて除外し、samber/developer-relations-skills@devrel-analyticsへの依頼に切り替えます。
• 営業オペレーションの協力が得られない場合は、影響を受けたパイプラインを完全に除外します。除外したことを明記し、シートの最下部に保留項目として置かないでください。

ワークフロー

1. まず振り分けを行い、資金を提供する側、読み手、データアクセスが明確になるまでヒアリングします。
2. 資金を提供する側の目的とプログラムの目標を、それぞれ1文で言い換えます。以下のすべては、この2つを基盤とします。
3. 指標の軸をブレインストーミングします。詳しくは下記を参照してください。まだシートは作成しません。
4. 効率性の順に並べたティアの段階に照らして候補を絞り込みます。各目標につき主要指標を1つ、合計5～8個とし、プロダクトまたはビジネスへのインパクトを少なくとも1つ含めます。
5. 各候補を、チームが実際に保有するデータと照らして現実性を確認します。チームが計測できないものは削除し、見落としの項目に削除対象として明記します。そのうえで、ないものとして扱ったり、最下位に置いたりせず、そのギャップを samber/developer-relations-skills@devrel-analytics に引き継ぎます。
6. 目標に取り掛かる前に、アトリビューションのルールを定めます。これによって、指標の半数が何を示せるかが決まります。
7. ベースラインを取得します。各指標について、過去の期間を少なくとも3つ用意します。履歴データがない場合は、指標を「ベースライン設定中」とし、次回のレビューでしきい値を設定します。
8. 最初の2サイクルでは、目標値を単一の値ではなく、方向性と範囲で設定します。
9. すべてのしきい値に、担当者と具体的なアクションを設定します。アクションが設定されていない指標は、残すのではなく削除します。
10. 頻度を設定し、フレームワーク文書を作成して、セクションごとに提示しながら内容を確認します。

指標を選ぶ前に、軸をブレインストーミングする

ブレインストーミング中であることを明確に伝えます。軸を1つだけ提示するのではなく、軸全体を2つまたは3つ提示し、詳細に進む前に担当者に選んでもらいます。軸によってその下に置かれるすべての指標が決まるため、誤った軸を後から変更するには大きな手間がかかります。

多くのプログラムに適した軸は、次の3つです。

• 目的に基づく軸。 戦略で資金を投じたAAARRRPの目標ごとに、主要指標を1つ設定します。計画書に目標がすでに記載されている場合に最適です。一方で、異なる編成のチームにとっては分かりやすさが損なわれます。
• ジャーニー段階別の軸。 開発者が現在離脱している各段階に指標を1つ設定します。「どこで離脱するのか分からない」という課題がある場合に最適です。一方で、指標から予算項目への直接的なつながりは失われます。
• 機能別の軸（認知／活用支援／エンゲージメント）。 チームの編成に合わせて、機能ごとに指標を1つ設定します。各担当者がそれぞれ自分の指標を持つ必要がある場合に最適です。一方で、チーム間の因果関係は分かりにくくなります。

それぞれについて、以下を提示します。

• 何が明確になるか
• 何が見えなくなるか
• 誰にとって分かりやすいか
• どのような条件では選択を誤るか

1つを推奨し、その理由を説明します。参照する情報源とそのつながりについては、./references/metric-catalog.md を参照してください。

軸を効率性の順に並べてはいけません。ここでそれを行うのは、精密さを装うことになります。資金提供者が理解できない軸には、どれだけ費用をかけても価値がありません。つまり、どの順序付けも「資金提供者がすでに理解している軸」に行き着きます。選んだ軸の下にあるティアを、その中で順位付けしてください。

2つの軸を重ねてはいけません。AAARRRPの目標とジャーニー段階の両方を含むフレームワークは、同じ作業を二重に数え、シートを倍増させます。

ティアの階層

この5つのティアは、名前のある業界モデルを再現するのではなく、現場で実際に測定されている内容をまとめたものです。リストの下に進むほど測定コストが高くなり、予算レビューで数値が持つ価値も高まります。この階層を業界標準として経営幹部に提示してはいけません。

ここでの「イネーブルメント」は、測定ティアの名称です。このコレクションで使われている、互いに関連のない3つの意味のうちの1つであり、samber/developer-relations-skills@devrel-strategyのピラーミックスにおけるイネーブルメントの柱と、samber/developer-relations-skills@devrel-team-structureで使われているMary Thengvallの認知 → イネーブルメント → エンゲージメントのマッピングにおけるイネーブルメントの段階とは別の意味です。この3つを同じものと見なしてはいけません。

ティア	問い	例	正直な限界
リーチ	誰かが目にしたか	インプレッション、閲覧数、参加者、フォロワー	数量のみ。最も水増ししやすいティアであり、プログラムの目標にしてはいけません
エンゲージメント	誰かが何かをしたか	質問数、リポジトリのクローン数、ドキュメント検索数、適格な会話、ニュースレターへの返信	意図を伴う関心ですが、プロダクトとの接点はまだありません
イネーブルメント	成功できたか	サインアップ → 初回成功率、初回成功までの所要時間の中央値、各ステップでの離脱、100人の新規ユーザーあたりのチケット数	DevRelが最も直接的に担い、最も直接的に改善できるティア
プロダクトへの影響	行動が変わったか	接点のあったコホートのアクティベーションと30／60／90日後の継続率、2つ目のプロジェクトに取り組んだ割合、施策後の機能採用	名前を特定したコホートと施策前の期間が必要です。そうでなければ偶然にすぎません
ビジネスへの影響	収益またはリスクが動いたか	影響を受けたパイプライン、アクティブメンバーがいるアカウントでの拡大、サポート問い合わせの削減、採用につながった人材、出荷されたインテグレーション	貢献は常に共有です。毎回そのことを伝えてください

最初に構築するティア

この階層を下に進むにつれて価値と労力は常にともに高まるため、階層を見るだけでは「まず何を計測すべきか」という問いには答えられません。比率を計算してください。すると順序は単調ではなくなり、最適なティアは両端のどちらでもありません。

• 労力 - 計測の仕組みづくり、チーム間の調整、継続的な保守です。ここでの収集コストは労力そのものなので、両方を1行で表します：business impact > product impact > enablement > engagement > reach
• 価値 - 資金提供者に対してその数値でどこまで主張できるかです：business impact > product impact > enablement > engagement > reach
• コンプライアンスコスト - 発生するレビューと、仕組みを取り除く際のコストです：business impact > product impact > enablement > engagement == reach
• 効率 - 労力あたりの価値です：enablement > engagement > product impact > business impact > reach

ティアごとの比率の桁数：

• リーチ。 ダッシュボードはすでに開いていますが、分母がどれだけ小さくても分子がゼロならゼロのままです。そのため、最も安価なティアは最上位ではなく最下位に位置します。
• エンゲージメント。 主に、Forgeとドキュメント検索ログですでに記録されているデータ（時間）を読み取ります。また、その指標の1つは、それ自体が修正を示しています。
• イネーブルメント。 計測対象の成功イベントが1つ必要です。初回はエンジニアリングに約1日かかり、その大半はイベントのテストに費やされますが、その後の負担はほぼゼロです。そして、このチームが最も直接的に改善できる数値、つまり指標階層で最高の比率が得られます。
• プロダクトインパクト。 コホートタグと、期間開始前に存在していなければならない事前期間が必要なため、調整に四半期かかり、その後さらに待つ必要があります。
• ビジネスインパクト。 CRMフィールド、セールスオペレーションの協力、会計年度を通じて適用されるルールが必要で、そのうえで回答が得られるのは2～4四半期後です。

engagement > product impact は同点ではなく、優劣が分かれることを示しています。

• エンゲージメントが勝るのは、データがすでに収集されているからにすぎません。そのため、プロダクト分析がすでに計測されている場合は、この順序を逆にしてください。
• 唯一の == が成り立つのは、エンゲージメントとリーチがどちらもチームがすでに保有している公開データや集計データを参照するためです。どちらも個人とアカウントの間に新たな関連付けを追加しないため、新たなレビューは発生しません。

デフォルトの段階。 主要指標はイネーブルメントに置きます。数値を読む人が予算を更新するかどうかを決める場合、またはプログラムが営業費目やマーケティング費目から資金提供を受ける場合は、ビジネスインパクトを比率より上位にしてください。

この引き上げは、以下の「プロダクトインパクトまたはビジネスインパクトの指標を少なくとも1つ含める」というルールで担保されます。価値も労力も大きい指標は、毎回比率に負けます。そのため、効率だけで測定するプログラムではリーチとエンゲージメントをいつまでも報告し続け、予算を獲得できません。また、予算レビューを乗り越えられるのはビジネスインパクトだけです。

この順序はデフォルトであり、絶対的なルールではありません。状況や実行する人によって変わります。このチームについてすでにわかっていることを踏まえて、優先順位を付け直してください。

• 既存のプロダクト分析環境や、整備されたセルフサービスのテレメトリーがあれば、イネーブルメントとプロダクトインパクトの労力が軽減され、どちらも上位になります。
• 営業チームがパイプラインデータを共有しない場合、ビジネスインパクトの優先順位を下げるのではなく、削除します。

チームが計測できないものは削除し、フレームワークの死角のセクションに、削除したことと、それを実現するために必要なことを明記してください。除外した指標をシートの最下部に置いておくと、次の四半期にスコープとして再浮上します。

シートを使いやすく保つためのルール：

• 目標ごとに主要指標を1つにします。補助指標はいくつあってもかまいませんが、主要指標が複数あるのは誰も解決しない同点です。
• プロダクトインパクトまたはビジネスインパクトの指標を少なくとも1つ含めます。エンゲージメントで止まるフレームワークでは、資金提供者の問いに答えられません。
• 指標は合計8つまでにします。定期的に更新される5つの指標シートは、3か月目には形骸化する20の指標シートに勝ります。DevRel以外のダッシュボード設計の実務でも、標準的な慣例として5～7個の主要KPIという同じ範囲に収束します。これは調査結果ではなく、慣例です。
• リーチ指標にはすべて、同じ行のストーリーにおける下流の対応指標が必要です。そうでなければ公開しません。

各ティアの候補指標と、定義、データソース、注意点（オープンソース版とB2B版を含む）：./references/metric-catalog.md。

アトリビューションの現実

期間が始まる前にルールを書き留めてください。四半期終了後に考案したルールは、後付けのストーリーです。

4つの手法があり、それぞれ偏りの方向がわかっています。意識的に選び、同じ手法を一貫して使ってください。

方法	バイアス	用途
自己申告によるアトリビューション（「どこで当社を知りましたか」）	印象に残る接点を過大に数え、ドキュメントや検索を過小に数える	常設の測定手段。廊下での会話、ポッドキャスト、口コミによる接点を把握できる唯一の方法です
タグ付きリンクとラストタッチ分析	タグ付け可能な場所からクリックされなかったものを過小に数え、「ダイレクト」を水増しする	成果物の比較に使用し、プログラム全体の数値には使用しません
文書化された接点ルールに基づく影響パイプライン	定義上、過大に数える。クレジットは共有されます	B2B向けです。CRMで接点を記録でき、「影響を与えた」という表現が決して抜け落ちない場合に限ります
事前・事後のリフト測定、または1つの地域やセグメントでのホールドアウト	因果関係の把握に最も近いものの、通常DevRelの規模では検出力が不足します	事前期間を記録した、範囲を限定した1回の施策に使用します

使える時間が1つか2つの方法を導入する分しかない場合、どれを最初に導入するか：

• 労力 - 導入と継続的な維持にかかる負担：influenced pipeline > pre/post lift > tagged links > self-reported
• 価値 - プログラムが主張できる内容：influenced pipeline > pre/post lift > self-reported > tagged links
• コンプライアンスコスト - 発生するレビュー：influenced pipeline > tagged links > pre/post lift == self-reported
• 効率：self-reported > pre/post lift > tagged links > influenced pipeline

自己申告が大差で勝ります：

• 登録時の質問が1つだけで、継続的なコストはほぼゼロです。また、廊下での会話、ポッドキャスト、同僚からの推薦をすべて把握できる唯一の方法です。
• 事前・事後のリフト測定で追加される作業は、施策を始める前に事前期間を記録することです。実施当日の負担はほぼゼロですが、後からでは不可能です。その見返りとして、利用できる唯一の因果関係に関する主張が得られます。
• タグ付きリンクには命名規則とキャンペーンごとの運用徹底が必要で、成果物の比較にしか使えない可能性があります。

==は実際に同等です：

• 事前・事後のリフト測定も自己申告も、集計データまたは自発的に寄せられた回答を読み取るため、どちらも新たなプライバシーレビューを発生させません。
• 影響パイプラインがコンプライアンスのコストで最上位になるのは、特定の人物による公開コミュニティでの活動をCRMレコードに結び付けるためです。この個人を特定する対応表は、一度作成すると元に戻すのが困難です。

この順序で犠牲になるのは影響パイプラインです：

• 効率では最下位ですが、予算責任者が目を通す唯一の方法です。
• 予算が営業またはマーケティングの予算枠から出ている場合は、比率より上位にします。これは、後述する収益に関する問いと同じ判断です。
• チームがデータを取得できない方法（CRMに接点を記録するフィールドがない、質問を追加できる登録フォームがないなど）は、リストの最下位に置くのではなく、フレームワークから外して、盲点のセクションにその理由を明記します。

すべてのレポートで、次の3点をはっきり伝えます：

• 「ダイレクト」の割合が大きくても正常であり、不具合ではありません。アグリゲーター、チャットクライアント、プライバシー保護ブラウザー、AI アシスタントはリファラーを削除します。AI アシスタントからのトラフィックのおよそ70％はリファラーなしで到着し、「ダイレクト」に分類されます（Demand Curve ニュースレター #331。これは1つのニュースレターによる数値なので、参考値として扱ってください）。
• エンタープライズの営業サイクルでは、パイプラインに関する回答が出るまでに2～4四半期かかります。その間を支える先行指標を明記してください。
• 2つのチームが同じ収益を創出したものとして主張してはなりません。「影響を与えた」収益は定義上、共有されます。

収益に関する問いを明確に決めてください。 以下のどちらの立場にも妥当性があり、フレームワークではどちらかを選ぶ必要があります。判断を左右するのは、誰が予算を持っているかです。

• DevRel に営業指標を持たせません。 Mary Thengvall の見解（2019 年 12 月）では、DevRel は決して営業指標を持つべきではありません。ノルマを課すと、「本来は誠実な関係であるべきものが、お金を中心とした関係に変わってしまう」ためです。収益以外の指標となるのが DevRel Qualified Lead であり、活用できるチームに振り分けられるつながりを指します。
• 影響を受けたパイプラインを、明示的に共有します。 営業部門またはマーケティング部門の予算から資金を得ているチームは、自ら提案するかどうかにかかわらず、収益に関連する数値で評価されます。そのため、不誠実な指標を割り当てられるより、誠実な指標を提案するほうが適切です。

手法の詳細と適用例を含むルール：./references/attribution-methods.md。

虚栄指標を避けるためのガードレール

候補となる指標はすべて、次の 3 つのテストにかけます。いずれかに不合格となった指標は、基準を緩めるのではなく、除外します。

1. 単調性テスト。 数値が増える一方ではありませんか？スターの総数、累積フォロワー数、累計ダウンロード数、メンバー総数は、プログラムが機能しなくなっても減らないため、情報をもたらしません。一定期間の増減または割合に置き換えるか、指標から外します。特にスターは操作しやすく、プロジェクトの種類によって比較できません。Ashley Hathaway（developerrelations.com、2017 年）の言葉を借りれば、「オープンソース指標におけるモノポリーのお金」です。
2. 「それで？」テスト。 来月 20％変化したら、誰かの行動は変わりますか？具体的な行動を挙げられなければ、その指標を外します。
3. 担当範囲テスト。 このチームの取り組みによって、1 回のレビュー期間内に数値が動く可能性はありますか？ほとんどのプログラムでは会社の ARR は不合格ですが、チームが関与したコホートのアクティベーションは通常合格します。

次に、残った指標を守ります。

• インセンティブを与える指標には、必ず対抗指標を組み合わせます。 Goodhart の法則を Marilyn Strathern が 1997 年に一般化した「測定値が目標になると、それは良い測定値ではなくなる」という考え方は、投稿数の目標によって内容の薄い投稿が増えること、課題クローズ数の目標によって時期尚早なクローズが起きること、メッセージ量の目標によって中身のない会話が増えること、登録数の目標によって使い捨てアカウントが増えることに表れます。対策として、量と質を組み合わせます。
  • 投稿数と、投稿あたりの自然流入数
  • クローズした課題数と、再オープン率
  • 登録数と、30 日後の継続率
• 少数サンプルの下限を尊重します。 期間中のイベント数が約 30 件を下回る場合は（DevRel で測定された基準値ではなく、借用した大まかな目安です）、割合ではなく、日付を含む実数の一覧を報告します。カンファレンスでの講演、エンタープライズとの対話、外部からのプルリクエストは、いずれももともと件数が少なく、少数サンプルの割合は大きく変動するため、誤った判断を招く可能性があります。
• 他社の絶対値を基準にしてはいけません。 プログラム自身の過去と比較します。オーディエンスの規模、エコシステム、製品の成熟度によって、通常の状態は変わります。
• 一時的な急増と傾向を区別します。 ローンチ、カンファレンス、インシデントはあらゆる数値を急増させます。ローンチ月を平穏な月と比較することは、この分野で最もよくある誤った傾向の捉え方です。
• 広く流通している基準値は仮説として扱います。 24 時間以内の応答、月間アクティブ率 20％、7 日後の継続率 40％といった閾値は、測定されたベンチマークではなく、経験則です。使う場合はその旨を明記し、3 期間が経過したら、プログラム自身の直近の中央値に置き換えます。

B2B、個人による導入、オープンソースの比較

階層の考え方は3つすべてに当てはまります。変わるのは単位と読み取る指標です。

• 企業主導の導入（B2B）。 人数とあわせてアカウント数を数えます。少なくとも1人のアクティブな開発者がいるアカウント、セキュリティ審査またはアーキテクチャ審査を通過した評価、コミュニティの参加があるアカウントでの拡大が対象です。件数が少ないため、割合ではなく、実際のリストやアカウントを特定した対話を重視します。パイプラインの結果が判明するのは2～4四半期後になるため、フレームワークでは遅行指標ごとに明示的な先行指標が必要です。
• 個人による導入。 件数が多いため、ファネルを読み取れます。登録 → 初回の成功、コホートの継続率、2つ目のプロジェクトに取り組む割合、セグメント化できるだけの回答数がある場合の登録時の自己申告による貢献元などです。イネーブルメント層の指標が最も役立つのはここであり、ドキュメントやクイックスタートの改善も最も早く効果が表れます。
• 購入を伴わないオープンソース。 製品はリポジトリとエコシステムです。独自の指標を作るのではなく、CHAOSS Starter Project Health の指標セットを基準にします。初回応答までの時間、変更リクエストのクローズ率、コントリビューター不在率、リリース頻度が含まれます。CHAOSSは4つすべてを定義していますが、いずれにも目標値は設定していません。しきい値は独自に導き出す必要があります。また、数値を他のプロジェクトが公開しているものと比較できるよう、定義はそのまま採用する価値があります。ダウンロード数や依存プロジェクト数はスター数より有用です。ドキュメントを読んだ見知らぬ人が起票したイシューは、100個のスターより価値があります。
• 3つすべてに共通するもの。 アトリビューションのルール、ベースラインから導き出したしきい値、指標ごとのアクション、単調増加する指標を主要指標にしないことです。

出典あり、独自設定、または俗説

シート内の各しきい値に、その由来を数値と同じセル内でタグ付けしてください：sourced、baseline（独自設定）、または hypothesis（検証中の俗説）。ある「ベンチマーク」が作り話だと幹部が知れば、ページ上のほかの数値も、根拠のあるものまで含めてすべて信用されなくなります。

• 出典あり。 発行元と日付を特定できる文献にさかのぼれるものです。DevRel の数値でこれに該当するものはごくわずかで、何を良しとするかまで示しているものはほとんどありません。最も近い例でも、基準値は設定していません。CHAOSS の Starter Project Health モデルは、4つのリポジトリ指標を定義していますが、いずれにも数値目標を公表していません。CHAOSS の標準として広まっている初回応答までの2営業日という数値は、同ページのケーススタディ内で引用されている VMware の社内ガイドラインです。VMware のものと明記するか、省いてください。
• 独自設定。 このプログラムの直近のベースラインから導き出すものです。シート内のほぼすべてのしきい値は、ここから設定するべきです。そう明示することは強みになります。この種の目標だけが、このオーディエンス、製品の成熟度、チームの規模を考慮できるからです。
• 俗説。 測定結果による裏付けのない、広まっている丸い数字です。24時間以内の応答、月間アクティブ率20％、7日後の継続率40％、「セルフサービスでのアクティベーション率20～40％」などがあります。それぞれを、ベースラインに照らして検証する仮説として扱ってください。目標として設定してはならず、繰り返し述べるときは、必ず俗説だと明記してください。

出典のある事実の多くは、むしろ測定できる範囲に制約を加えます。ほぼすべてのシートの内容を変える、特に重要な3つを紹介します。

• クライアント側のアナリティクスでは、開発者数が大幅に少なくカウントされます。Plausible の測定によると、テクノロジー関連のオーディエンスの58％が Google Analytics をブロックしていました。Linux では82.3％、Firefox では88.3％でした（2021年8月、Hacker News と Reddit からのトラフィックが多い単一サイトで、Plausible 独自のプロキシ経由スクリプトと比較して測定）。サードパーティ製スクリプトによるセッションの絶対数は、ページごとに異なる割合で不正確です。そのため、リーチとエンゲージメントの指標は、同一ソース内の比率として算出し、異なるソース間で比較する絶対値としては扱わないでください。
• レジストリのダウンロード数は、レジストリ自身のドキュメントにもあるとおり、人数ではなくリクエスト数です。npm は HTTP 200 の tarball レスポンスをすべて数えます。CI やミラーも含まれ、おおむね1日50件未満は、そのほとんどが自動化によるものとして扱われます。PyPI は既知のミラーをデフォルトで除外します。複数のレジストリの数値を合算して、ユーザー数と呼んではいけません。
• データソースの有効期間は、それぞれ異なります。GitHub のリポジトリトラフィックエンドポイントが保持するのは14日分で、書き込み権限のあるリポジトリに限られます（REST ドキュメントを参照）。パッケージレジストリの時系列データは数か月分で、数年分ではありません。チャットサービスが保持するデータは、プランの許容範囲によって異なります。今日定義した指標を前四半期分は算出できない場合があります。シートに追加した日からスナップショットの保存を開始してください。

しきい値を設定する

• まずベースラインを設定します。しきい値を設定する前に、過去3期間分のデータを用意してください。履歴がない場合は、その指標に「ベースラインを構築中」と記して公開し、次回のレビューでしきい値を設定します。
• 最初の2サイクルでは、目標を方向と範囲で設定します（「初回成功率を22％から28～33％の範囲へ」など）。ベースラインが安定してから、単一の目標値に切り替えてください。
• 固定値よりも、ベースラインに応じて変動するしきい値を優先してください。たとえば、値が直近の期間の範囲を外れた場合にフラグを立てます。具体的には、30日間の移動平均から標準偏差2つ分離れた場合などです。固定値は時間とともに古くなり、3か月目には誰も読まないアラートを生みます。
• コホートは日単位ではなく、月単位で作成してください。DevRel の規模では、日単位のコホートは1桁の人数となり、そこから作成した継続率曲線は、実際に何が起きたかにかかわらず、どれも横ばいに見えます。

このルールにある具体的な数値、すなわち3期間、標準偏差2つ分、30日間のウィンドウ、上記の少数サンプルの下限などは、隣接するダッシュボードや調査の慣行から借用した目安であり、DevRel の状況で測定された値ではありません。これらを使う場合は、由来を尋ねられたときに慣行上の目安だと明記してください。

書き留め、実行し、不要なものを削る

• すべての指標に、定義、情報源、ベースライン、しきい値、担当者、アクションの6項目を設定してください。例外はありません。
• 各指標がシートに入る前に、その前提条件を明記してください。その数値がそもそも存在するために、すでに何が成立していなければならないかを示します（計測された成功イベント、ブログの編集権限、トラフィックを測定したいリポジトリへの書き込み権限など）。これを満たさないものは指標ではなく、計測機能の実装依頼です。
• 説明が必要な指標には、個別のページを作成してください。Developer Relations Foundation の Metrics Index が公開している形式にします。定義、影響が大きい理由、前提条件、計算式、計算例、分析、ガードレール、障害、自動化を含めます。採用するのは形式だけです。このリポジトリは引き続き公開されており、アーカイブされていませんが、公開以来、ブログ記事の公開率に関する計算例付きの指標ページが1つ公開されたのみで、参照できるカタログはまだありません。
• 運用のためには毎月、意思決定のためには四半期ごとに読み返し、フレームワーク自体は毎年見直してリセットしてください。DevRel の規模では、月次より頻繁な確認で見えるものはノイズです。
• 廃止ルール。 連続する2回のレビューサイクルで意思決定に影響を与えなかった指標は削除してください。このルールを文書に明記し、削除を議論ではなく定期的な手続きにします。

呼び出し例

• 「毎月、スター数、ブログの閲覧数、イベント数を報告していますが、VP から、それぞれ何のためなのかと聞かれました。指標フレームワークを作ってください。」
• 「6週間後に DevRel の予算を守るための説明をします。スライドには何を載せればよく、正直に何を主張できますか？」
• 「チームにパイプライン目標が割り当てられようとしています。筋の通った代案はありますか？また、どう文書化すればよいですか？」
• 「私たちは販売するものがないオープンソースプロジェクトです。スター数の代わりに何を測定すればよいですか？」
• 「現在のダッシュボードを確認してください。この30個の指標のうち、残すべきものはどれですか？」

どの例からも同じ成果物が得られます。以下のフレームワーク文書を、各セクションの内容を担当者が承認しながら順に作成します。ダッシュボードでも、トラッキングコードでも、網羅的な指標一覧でもありません。

出力

6つのセクション、すなわち推進要因と目標、指標シート、アトリビューションルール、レポート、既知の盲点、レビューで構成される測定フレームワーク文書を作成してください。草案を作成する前に、テンプレート全体、計算例、弱い例と強い例の比較を読み込んでください：./references/measurement-plan-template.md。

一度に1つのセクションを提示し、次のセクションを書く前に合意を得てください。最初の見出しで誤った推進要因に気づけば段落の修正で済みますが、最後に気づけば文書全体の作り直しになります。

合格基準

このチェックで100％のスコアを獲得したら、フレームワークは完成です。達成するまで反復し、チェック結果を明示してください。

• 指標は5～8個にし、それを超えないこと。
• すべての指標に6項目すべてを含めること：定義、情報源、ベースライン（または明示的な「ベースライン設定中」のマーク）、しきい値、担当者、アクション。
• プロダクト影響またはビジネス影響のティアに、少なくとも1つの指標を含めること。
• 主指標に単調増加する指標を使わないこと。
• すべての指標が「それで何が変わるか」と担当者のテストを満たすこと。
• アトリビューションルールを明記し、手法とルックバック期間を示すこと。また、功績を分け合う場合は「影響した」という表現を使うこと。
• インセンティブの対象となるすべての量的指標に、カウンター指標を設定すること。
• すべてのしきい値に sourced、baseline、hypothesis のいずれかのラベルを付け、hypothesis のしきい値を目標として示さないこと。
• 盲点のセクションを空にしないこと。

件数の条件を満たさないフレームワークに必要なのは規律ではありません。目標が多すぎるのです。

よくある失敗パターン

• 活動ログをレポートとして扱う。 「講演12回、投稿40件、イベント6回」は労力を数えているのであって、成果を示しているのではありません。予算レビューに一度かけただけで通用しなくなります。
• すべてを一つの数値で表そうとする。 ドキュメント、コンテンツ、コミュニティ、イベントにまたがるプログラムを網羅できる単一の指標はありません。開発者コミュニティは「すべてを一つの数値で表せるものではありません」（Hathaway、2017）。目標ごとに主要指標を一つ設定した、少数の指標を使いましょう。
• 決める前に計測を仕込む。 計測可能なものすべての追跡機能を作ると、誰も読まないダッシュボードができあがります。指標を選んでから、その不足分を samber/developer-relations-skills@devrel-analytics に任せましょう。
• リーチをインパクトと言い換える。 インプレッションを「開発者リーチ」と改称しても何も変わりません。指標の段階を決めるのは、その数値が何を観測しているかであって、何と呼ばれているかではありません。
• 最終接点の売上を約束する。 DevRel が最後のクリックを担うことはめったにありません。自ら創出した売上を約束すると、次のレビューで返済期限を迎える負債を抱えることになります。
• 他社のダッシュボードをコピーする。 その指標には、その会社の推進要因、段階、計測方法が反映されています。自分たちのものから導き出しましょう。
• 他社から借りたベンチマーク。 カンファレンスの講演やブログ記事の概数を業界標準として引用することです。一度検証されると、シートのほかの数値まで疑われるようになります。仮説として明記し、代わりに自社の過去のベースラインと照らし合わせて調整しましょう。
• 計測がブロックされるデータソースから絶対数のトラフィックを出す。 開発者オーディエンスの大半が実行しないサードパーティの分析スクリプトを使って、「ドキュメントのセッション数」を主要数値として報告することです。同じデータソースで計測した二つのステップ間の比率を報告しましょう。
• ローンチ月をトレンドとして示す。 ローンチやカンファレンスによる急増をトレンドラインとして提示すると、翌月に信頼を失います。
• オーナーのいないダッシュボード。 オーナーがいない指標は、3か月目までに更新されなくなります。解決策は自動化を増やすことではなく、指標を減らすことです。
• プログラムではなくチームを測る。 一人ひとりに指標の目標を割り当てると、同僚同士が競争するようになり、作業が計測対象のものへと偏ります。
• 把握できない領域について黙る。 明示されていない不足に幹部が気づくと、シート全体への信頼が損なわれます。不足を公開することで、ほかの内容にも信頼性が生まれます。

メモリー

ハーネスに永続メモリーがある場合は、資金提供の判断要因、ベースラインとしきい値を含む指標シート、オーナーが検証した帰属ルールを保存してください。そうすれば次の四半期は、ベースラインを再導出するのではなく、記録されたベースラインから始められます。また、しきい値の変更を、黙って編集するのではなく、明示的な判断として可視化できます。

参考資料

• ./references/metric-catalog.md - ティアごとの候補指標とその定義、出典、留意点、および名称付きのスパインとその公開元。
• ./references/attribution-methods.md - 4 つの手法の詳細、影響を受けたパイプラインのルール例、自己申告によるアトリビューションの質問セット。
• ./references/measurement-plan-template.md - フレームワークのテンプレート、完成した記入例、および各セクションの弱い例と強い例の比較。
• CHAOSS は、Starter Project Health の指標定義を chaoss.community で公開しています。
• Developer Relations Foundation は、指標ごとのページスキーマと貢献方法を github.com/DevRel-Foundation/metrics-index で公開しています。
• samber/developer-relations-skills@devrel-team-structure - 指標フレームワークが適合しなければならない組織構造とレポートライン。
• samber/developer-relations-skills@developer-first-gtm - このフレームワークで残りの指標を階層化する前に、選んだ導入施策が機能していることを証明する数値を厳選します。
• samber/developer-relations-skills@developer-segmentation - セグメント別の指標シートの基準となるセグメントの切り分け。
• samber/developer-relations-skills@developer-education-strategy - 認定プログラムまたはアカデミープログラムで報告するコホート、修了率、ラボ合格の指標。
• samber/developer-relations-skills@devrel-budget-allocation - プログラムが予算を増やす前に、測定結果を読み取れるかどうかのゲートで確認する支出。
• samber/developer-relations-skills@devrel-competitor-analysis - プログラムを外部に向けて比較します。このスキルはプログラムを内部で計測します。