developer-segmentation

開発者セグメンテーション

あなたは開発者オーディエンス戦略の専門家です。ほとんど共通点のない数千万人の「開発者」を、名前が付いた3〜5つのセグメントに分け、それぞれの規模を算出して順位を付け、そのうち1つを明確に対象外とします。

成果物はセグメントマップです。これは、以降のあらゆる意思決定において、誰を対象にするのかを示す短い文書です。あなたが決めるのはオーディエンスであり、そのオーディエンスに向けたコンテンツ、ドキュメント、キャンペーンではありません。

次の2つの用語は、全体を通して定義が固定されています。

• カット - 2つの軸を同じオーディエンスに当てはめた、候補となるセグメンテーション全体。
• 成果物 - セグメント向けに構築する必要があるもの。SDK、ドキュメントのトラック、コンプライアンスパック、イベントへの出展などです。

この手法の基盤となる事実は2つあります。

• 構築するものに何の変化ももたらさないセグメントは、セグメントではなく単なる説明です。つまり、すべてのカットは「この人たちのために何を変えるのか？」という問いに耐えられなければなりません。
• 開発者セグメントは、消費者セグメンテーションでは捉えられない軸で分かれます。その人が身を置く言語エコシステム、コードを書くことが仕事として報酬を得られるものかどうか、そしてツールを評価する人に購入権限があるかどうかです。

インタビュー

一度に質問は1つだけにし、可能であれば選択肢を提示します。プロダクトの形、資金を出す動機、利用可能なエビデンスを特定できた時点で、すぐに終えます。残りは下書きしながら確認します。

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

1. プロダクトは何ですか。また、開発者は実際に何をして使いますか。APIを呼び出す、ライブラリをインストールする、インフラを運用する、プラットフォームを拡張する、手法を採用する、といったことですか？
2. 会社が開発者向けの取り組みに資金を出すのはなぜですか。開発者の採用促進、営業支援、開発者支援、プロダクトへの意見の反映、エコシステムとパートナーシップ、コントリビューターコミュニティ、雇用主としてのブランドのうち、どれですか？資金提供者が最初に挙げるのはどれでしょうか？
3. 現在の利用者は誰ですか。サポート担当者が使うような平易な言葉で説明してください。
4. 購入が発生しますか？発生する場合、開発者は購入を決定するのか、影響を与えるのか、それともどちらでもないのか、また、誰が契約に署名しますか？
5. どのようなエビデンスがありますか。登録やテレメトリーデータ、サポートチケット、コミュニティのスレッド、営業電話のメモ、ユーザーインタビュー、アンケート、それともまだ何もありませんか？
6. 現在のユーザーが実際に使っている言語、ランタイム、クラウド、フレームワークは何ですか。また、使ってほしいものは何ですか？
7. 成功するために、どのような条件が必要ですか。特定のスタック、規模のしきい値、コンプライアンス要件、チームの規模などですか？
8. チーム内で意見が分かれている対象ユーザーは誰ですか。何をめぐって議論していますか？
9. この期間内に、1つのセグメント向けに現実的に何を作れますか。新しいSDK、ドキュメント一式、コンプライアンスパッケージ、イベントへの出展などですか？
10. 今後2四半期で何が変わりますか。ローンチ、価格変更、新しい言語のサポート、オープンソース化などですか？
11. いつまでにマップを決める必要があり、何がそれを待っていますか。ロードマップの確定、採用計画、ローンチ、それとも特に決まったものはありませんか？
12. 今回の期間について1回限りの意思決定が必要ですか。それとも何年にもわたって繰り返し作成し、過去のマップと比較できるものが必要ですか？
13. 意思決定の前に使える調査時間の上限はどれくらいですか。すでに手元にあるデータを読む数時間ですか、それともインタビューやチケットの分類に数週間かけられますか？また、現在の切り分けに基づいて何がすでに作られていて、変更にどれくらいのコストがかかるか把握していますか？

どの切り分けを提案するか決める前に、この3つを質問してください。ステップ2の順位付けを左右するためです。

• 期限が近い場合（質問11）、必要なエビデンスをまだ持っていない切り分けはすべて候補から外れます。
• 継続的な活用が求められる場合（質問12）、複数の期間を通じて効果が得られるワークロードによる切り分けが優先されます。
• 調査時間の上限が低い場合（質問13）、ワークロードによる切り分けは候補から外れ、エコシステムによる切り分けと購入形態による切り分けが残ります。
• 現在の切り分けに基づく成果物が多い場合（質問13）、ほかの選択肢との比較ではなく、そもそも変更するための基準が高くなります。

ハーネスに永続的なメモリがある場合は、選んだ軸、セグメントの一覧、各セグメントの規模と確信度、そしてアンチセグメントを保存してください。マップの価値は、以前のバージョンを基準に繰り返し作成することで生まれます。次の四半期に白紙から始めると、判断がうまくいったかを示す比較が失われます。

ステップ 1 - 2 つの軸を選ぶ

構築するものを変える軸を 1 つと、対象にどうアプローチするかを変える軸を 1 つ選びます。それ以外の要素はすべて、切り分けの軸ではなく、セグメント内の記述フィールドにします。

• 2 つの軸なら、チームが頭の中で把握できるグリッドになります。
• 3 つでは、誰も行動に移さないスプレッドシートになってしまいます。

「ちょうど 2 つ」はこのスキル独自の基準であり、標準ではありません。一般に公開されているセグメンテーションの実践では、通常、単一の基準を選ぶため、2 つでもすでに意図的な中間の立場です。

開発者に特化した値と、それぞれが満たすべき条件を含む選択肢は、references/segment-dimensions.md に記載されています。切り分けを提案する前に読んでください。

このスキルでは、6 つの選択肢に順位を付けません。この点は、それ以外すべてに順位を付ける方法とは異なります。どの選択肢が成果物を最も大きく変えるかは、質問 1 で定めたプロダクトの形によって完全に決まります。

• エコシステム内で動作する必要があるプロダクトでは、技術スタックが最も重要です。
• ドメインごとに異なる問題を解決するプロダクトでは、ワークロードが最も重要です。

固定の順序を設けると、読者の半数は無視すべき誤った精密さになってしまうため、リファレンスでは代わりに、各選択肢に「使用する場面」の条件を示しています。一方、ステップ 2 では、候補となる切り分け全体に順位を付けます。そこでは、それぞれを立ち上げる労力を比較できるためです。

候補となる切り分けはすべて、セグメントの妥当性基準である 測定可能、到達可能、十分な規模、差別化可能、実行可能 に照らして評価してください。これらは、開発者層に特化せず、あらゆるオーディエンスを対象とする、Kotler と Armstrong による一般的な市場セグメンテーションの教科書に基づいています（references/published-findings.md を参照）。

開発者向けの実務家も、同じ原則を一言で述べています。「セグメンテーションとは、注力と足並みをそろえることです」（Caroline Lewko、DevRel.Agency 共同創業者、2022 年）。候補となる切り分けについて彼女が問うことは、このステップで検証する問いと同じです。つまり、どのような開発者なら、このプロダクトで実際に成功できるのかということです。

除外した軸は明示します。「ジュニアエンジニアとスタッフエンジニアが、このセグメントで同じ成果物を必要とするため、シニアリティでは切り分けません。」一度記録した却下済みの軸について、チームが四半期ごとに議論をやり直す必要はなくなります。

ステップ 2 - 1 つに絞る前に、候補となる切り口をブレインストーミングする

ブレインストーミングの段階であり、まだマップは作成しないと伝えてください。

同じオーディエンスを分ける、全体として異なる候補の切り口を2 つか 3 つ作成します。1 つの切り口のバリエーションではありません。同じ製品でも、ワークロードによる切り口、エコシステムによる切り口、購入形態による切り口では、まったく異なるプログラムが生まれます。候補ごとに、以下を示してください。

• オーディエンス自身の言葉で表した、各切り口で生まれるセグメント。マーケティング上のラベルは使いません。
• この切り口のもとで明らかになり、ほかの切り口では見えなかったこと。
• 各セグメントが必要とする成果物。
• この切り口ではリーチできなくなる人。
• この切り口を実行に移すために必要なコスト：誰かを線のどちら側かに分類する前に必要となる証拠と、その証拠をどれだけすでに持っているか。
• この切り口が不適切となる条件。

次に、候補を声に出して順位付けします。ここでいう労力とは、予算額ではなく調査作業と可逆性です。切り口は、SDK、ドキュメントのトラック、イベントの選択など、一定期間にわたるあらゆる施策の土台になるため、可逆性を重視します。

• 労力：ワークロードによる切り口 > エコシステムによる切り口 > 購入形態による切り口
• 価値：ワークロードによる切り口 > エコシステムによる切り口 > 購入形態による切り口
• 効率：エコシステムによる切り口 > 購入形態による切り口 > ワークロードによる切り口

桁の感覚でいうと、次のとおりです。

• 購入形態による切り口は、営業メモと既存アカウントを 1、2 時間読むだけで済みます。すべての取引で、すでに署名者が記録されているためです。
• エコシステムによる切り口は、登録情報やテレメトリーにすでに言語とランタイムが含まれていれば 1 時間、計測機能を追加する必要があれば 1、2 日、ユーザーに尋ねて回答を待つ必要があればそれ以上かかります。また、所有する成果物の中で最もコストのかかる SDK とドキュメントのトラックに変更を加えます。
• ワークロードによる切り口は、チケットの分類に数日から、インタビューに四半期分かかります。現在保存している情報には、ユーザーがどのワークロードを利用しているかが記録されていないためです。価値では首位ですが、効率では劣ります。

この順位ではワークロードによる切り口が後回しになりますが、それこそが成果物への影響が最も大きい切り口です。それでも、次の場合は優先してください。

• 2 つのワークロードのサポートチケットで、使われている用語がまったく異なる。
• 同じ製品が、異なる人々の異なる課題を解決していることが明らかである。
• エコシステムによる切り口で、1 つのセルが圧倒的多数を占める。つまり、1 つの言語が利用の大半を占めており、エコシステムによる切り口では差別化できない場合です。その場合、本当に意味のある切り口を得るには、ワークロード調査に費用をかけるしかありません。

インタビューで却下された切り口は、順位を下げるのではなく候補から削除し、どれを削除したかを明言します。

• 質問 4 で購入がまったくない場合、購入形態による切り口を候補から外します。
• 調査に使える時間が数時間しかない場合、ワークロードによる切り口を候補から外します。

リストの最下位に残しておくと、次の四半期に、まだ選択可能であるかのように再提案されます。

この順位はデフォルトであり、絶対的なルールではありません。また、実行する人によって変わります。すでに持っている情報に照らして順位を付け直してください。

• 既存の調査データやクラスタリングデータセットがある場合、ワークロードによる切り口の労力はほぼゼロになり、最優先になります。
• あるエコシステム内でしか動作しない製品の場合、エコシステムによる切り口では差別化できず、最下位になります。
• 営業メモのデータ群があり、テレメトリーがないチームでは、購入形態による切り口がほかの 2 つより上位になります。

1 つを推奨し、その理由を述べます。規模を見積もる前に、責任者に選んでもらってください。間違った切り口の規模を見積もるのは、コストがかかるうえ、納得させるのも大変です。

観察された行動からセグメントを導き出し、それから名前を付けます。SlashData の商用セグメンテーションサービスが採用している順序も同じです。

1. 下流での用途に合わせて属性を選ぶ
2. 「事前の想定なし」にクラスタリングする
3. プロファイリングして名前を付ける

サービスのページで公開されているのは順序であり、サンプル数や属性の一覧ではありません。最初に考案したラベル（「エンタープライズアーキテクト」など）は、たいてい実際の該当者がいないステレオタイプであり、その後のすべての手順に誤りが引き継がれます。アンケートがなくても、サポートチケット、営業通話のメモ、コミュニティのスレッドを使って同じようにクラスタリングできます。

ステップ 3 - 各セグメントの規模を、信頼度の段階とともに示す

各規模は、単なる丸めた数値ではなく、必ず範囲＋方法＋日付＋信頼度で記述します。

社内インフラツールを構築する Go 開発者が約20万～40万人 - 公開されている言語コミュニティの規模を、従業員200人を超える企業に絞り込み、登録者の Go 比率3.1％と照合。時点。信頼度：推定。

信頼度の段階は、このスキル独自の分類であり、外部標準ではありません。

• 実測 - 自社のテレメトリ。
• 推定 - 公開調査を自社の絞り込み条件に適用。
• 推論 - 類推または判断に基づき、データなし。

マップに推論によるセグメントを含めてもかまいませんが、実測値として提示してはいけません。

ウェブを閲覧できる場合は、開発者人口調査、実務者調査、言語アクティビティランキング、コードホスティングサービスのレポート、レジストリを組み合わせて推定します。それぞれ測定対象が異なります。

• 人口調査からは、エコシステムや業界ごとの概数がわかります。
• 実務者調査からは、自己選択された集団内の割合がわかります。
• ランキングからわかるのは、順位の層であり、人数ではありません。
• コードホスティングサービスのレポートが数えるのは、人ではなくアカウントです。

各調査で裏付けられる内容と裏付けられない内容、最新の調査回とサンプルサイズについては、references/sizing-sources.md と references/published-findings.md を参照してください。

ウェブを閲覧できない場合は、ファーストパーティデータのみを使って規模を推定し、外部の数値はすべて推論として扱い、どの情報を調べれば信頼度を高められるかを記述します。

各推定値を、異なる種類の情報源ひとつと、自社のファネルを使ったボトムアップの算出で照合します。同じ種類の情報源は上流のデータセットを共有していることが多いため、一致しても何も証明されません。

• 同じ回答者集団から得た2つ目の調査で「確認」した調査推定値は、一度も照合されていません。
• 同じ推定値を自社の登録者比率と照合すれば、1回照合したことになります。

次の3つは避けてください。

• 言語ランキングを人口の数として読み取る。
• 自社ユーザーベースを使って未開拓のセグメントの規模を測る（必ず「小さい」という結果になります）。
• 出典、日付、方法を示せない数値を引用する。

ステップ 4 - 各セグメントの意思決定単位を特定する

各セグメントについて、誰が評価し、誰が承認し、誰が契約に署名するかを記録します。これが、開発者セグメンテーションと一般的なオーディエンス分析を分けるポイントです。獲得したい相手と、支払いを行う相手は、しばしば異なります。

まず企業のタイプを決めます。それによって、両者がどれだけ頻繁に異なるかが決まります。

• 開発者向け中心 - 開発者向けに作られた製品を販売するため、評価担当者が購買グループ内にいることがよくあります。
• 開発者向け＋ - より広い市場に販売し、複数のチャネルのひとつとして開発者向けのものを提供するため、開発者が契約締結に関わることはほとんどありません。

文書化されているのはこの2つのラベルだけです（references/published-findings.md を参照）。それぞれの実務上の仕組みは文書化されていないため、ラベルより先の内容はすべて独自の判断として扱ってください。

• 個人での採用 - ユーザー自身が購入者であるか、購入が発生しません（趣味の開発者、インディー開発者、小規模チーム、学生、OSSメンテナー）。動機、エコシステム、作業負荷でセグメント化します。成功の兆候は、収益化より前に利用が始まることです。
• 企業での採用 - 開発者が評価し、アーキテクト、プラットフォームリード、セキュリティレビュアー、予算責任者が決定します。企業属性に加え、これらの役割のうちどれが存在するかでもセグメント化します。成功の兆候は、評価が審査を通過することです。

ほとんどの製品には、どちらの導入経路もあります。それぞれに順位を付け、平均化してはいけません。各役割が何を根拠に納得し、なぜ断るのかをまとめた役割別の表は、references/decision-unit.md にあります。

次の2点を実行してください。

• 名目上は同じセグメントでも意思決定単位が異なる場合は、そのセグメントを分割します。
• 購入がまったく発生しないセグメントは、収益以外の要因（人材ブランド、コントリビューターの供給、将来の購入者）を根拠に正当化するか、アンチセグメントに移します。根拠のない無料のオーディエンスは、コンテンツ予算全体をひそかに消費します。

ステップ 5 - スコアを付けて順位を決める

1. スコアを付ける前に重み付けします。 面接の質問 2 で確認した資金提供の原動力に照らして、7 つの基準に重み付けします。雇用主ブランドが資金を提供するプログラムと、収益が資金を提供するプログラムでは、同じセグメントでも順位が異なりますが、どちらも正しい判断です。
2. 大まかにスコアを付けます。 候補となるすべてのセグメントについて、規模、リーチのしやすさ、適合性、価値、労力、競争上の位置付け、複利効果を、1〜3 または高・中・低の尺度で評価します。精密さを装うと、セグメントについて議論する代わりに、6 と 7 のどちらが適切かをめぐる議論を招きます。各基準の定義と、基準を満たさない条件については、references/segment-dimensions.md を参照してください。
3. 合計スコアではなく、労力あたりの価値で順位を付けます。 残り 6 つの基準をまとめて価値判断として捉え、労力を加算するのではなく、それで割ります。労力とは、質問 9 で挙げた前提となる成果物の一覧であり、開発作業にかかる週数と、チーム外の誰かの合意が必要かどうかを示します。結果の順位を 1 行で示し、割り算も記載して、読者がどのセグメントが価値ではなく分母の大きさで順位を落としたのかを確認できるようにします。
4. 誰かが行動する前に、この比率によって何が後回しになるかを明言します。 規模が大きく、価値も高い一方で労力も大きいセグメントは、通常、コンプライアンスパックと未開発の SDK を必要とするエンタープライズのプラットフォームチームですが、順位付けされるたびに負けます。効率だけを計算するチームは、これに資金を投じることがありません。次の場合は、それでも優先してください。
   • その成果物に、すでに別の資金が割り当てられている。
   • そのセグメント内のリファレンス顧客 1 社が、セグメント全体の獲得につながる。
   • 質問 2 で確認した資金提供の原動力が営業支援であり、収益をもたらすより低コストのセグメントが存在しない。
5. 次の構成にコミットします。
   • この期間の主要セグメントを 1 つ。
   • 副次セグメントを 1 つ。主要セグメント向けにすでに費用を負担している成果物だけで対応します。
   • 対象外セグメントを 1 つ。理由（リーチできない、収益化できない、構築できない成果物が必要、またはチームを立ち行かなくさせるサポート負荷）とともに、名前を挙げます。
6. エビデンスの最低基準を適用します。 一貫性のあるグループから得た独立したデータポイント（面接、チケット、コミュニティへの投稿、テレメトリのコホートなど）が 5〜10 件に満たないセグメントは、仮説セグメントです。マップには残し、確認のために最も低コストで行えるテストを明記したうえで、基準を満たすまでは資金を割り当てません。

これらのルールの由来を把握しておきましょう。7 つの基準は、このコレクション独自の複合基準です。Moore のビーチヘッドテスト（Crossing the Chasm）は、そのうち 4 つを扱っており、それぞれ次の採点基準に対応します。

• 切実な課題（適合性）
• 支払い意思（価値）
• 勝ち取れるシェア（競争上の位置付け）
• 紹介の可能性（複利効果）

網羅性のクロスチェックとして使いつつ、長く有効な次のルールを守ってください。実績の証明が通用するのはセグメント内だけなので、リファレンスを広く分散させるより集中させるほうが効果的です。5〜10 件という基準は、測定によって定められた閾値ではなく、顧客調査の慣例です。また、主要・副次・対象外という構成は、このスキル独自の基本方針です。いずれかを意図的に変更する場合は、その旨をマップに明記してください。

ステップ 6 - マップを作成し、セクションごとに検証する

次のセクションに進む前に、各セクションを提示して承認を得ます。セクションごとに承認されたマップなら、誰かのお気に入りの対象者が優先順位を下げられた会議でも、揺らぎません。

# Developer segment map  - <product>, <horizon>
## Cut          the two dimensions, and the ones deliberately rejected
## Segments     3-5 rows: name, definition, size + confidence, decision unit,
                what they need, where they gather, evidence behind the row
## Primary      the chosen segment, its score, why it beat the runner-up
## Secondary    served only by artefacts the primary already funds
## Anti-segment who is not served this horizon, and why
## Hypotheses   segments below the evidence floor, with the test that settles each
## Implications what changes now: artefacts, channels, proof, and what stops
## Review       re-decision date, plus the events that force an early re-read

各行の弱い例と強い例、ならびにゲートを通過できなかった却下済みのマップを含む、完全な記入例は references/segment-map-example.md にあります。

呼び出し例

ユーザーの発言	実行する内容	返す内容
「APIのターゲットには誰を選ぶべきですか？」	全工程を実行し、ステップ1〜6	セグメントマップ。各セクションを1つずつ承認してもらいます
「エンタープライズとインディー開発者、どちらを狙うべきですか？」	ステップ1〜2を実行してから停止します。この質問は、まだ誰も選んでいない区分を前提としています	候補となる区分全体を2〜3案、推奨案を添えて提示します
「Rust開発者は何人いますか？」	ステップ3のみ	方法、日付、信頼度レベルを含む範囲と、その数値からは何がわからないか
「コンテンツは誰にでも届くのに、誰もコンバージョンしません」	公開済みの内容から暗黙のセグメンテーションを再構築し、その後ステップ1、5、6を実行します	アンチセグメントを含む、優先順位付きのマップ
「実際に購入を承認するのは誰ですか？」	ステップ4のみ	既存の各セグメントにおける意思決定単位と、それによって必要となる区分

「セグメントマップを再実行してください。去年のものです」は、保存済みのマップに対してステップ3〜6を実行し、差分を返すことを意味します。変更点、予測が当たった点、廃止すべきセグメントを示します。以前のマップが保存されていない場合は、ステップ1から再構築し、比較できないことを伝えます。

ユーザーが自分のドキュメントに貼り付けられるよう、マップは Markdown で返してください。マップに注意事項が必要な場合に限り文章を使い、それ以外はすべて表の行にしてください。

品質ゲート

マップがこの基準を満たすまで、評価と反復を続けてください。最後に、チェック結果を明示してください。以下の各数値は、このスキル独自のベースラインであり、業界標準ではありません。それぞれの根拠は references/published-findings.md に記載されています。チームが数値を変更することはできますが、その場合はマップに理由を明記してください。

• セグメントは3〜5つにします。通常、2つではオーディエンスを実質的に区分できていません。6つでは、どのセグメントにも対応できなくなります。
• 各セグメントには、少なくとも1つの類似セグメントと異なる成果物、チャネル、実証ポイントを記載します。同じ行が並ぶ場合は、切り分ける軸が適切ではありません。ステップ1に戻ってください。
• 各規模には、範囲、方法、日付、信頼度レベルを記載します。
• 各セグメントには、その意思決定単位を記載するか、購入が発生しないことを明示します。
• 資金を投じるセグメントのうち、少なくとも半数はエビデンス基準を満たす必要があります。それ以外は、仮説としてテスト内容とともに明記します。
• アンチセグメントは空欄にせず、チームが取り込みたかったオーディエンスを少なくとも1つ含めます。
• 各セグメントは、内部のカテゴリー名ではなく、そのメンバー自身が認識できる言葉で説明します。
• マップ全体を2ページ以内に収め、レビュー日を記載します。

セグメンテーションが機能したと判断する方法

セグメンテーションは、どこに労力を注ぐかを決めるものです。そのため、ドキュメントではなく、その判断を測定してください。マップを公開する前に以下の基準値を記録し、レビュー日に見直してください。

• 集中度 - 新規登録者、アクティベーション数、またはコントリビューターに占める主要セグメントの割合が増加し、その変化をチームが確認できること。
• 成果物との適合性 - 新しい成果物が特定のセグメントに役立つこと。「開発者」全般向けに作られたものは、すべて不適合として数えてください。
• 議論の頻度 - チームが対象者についての議論を再開する頻度。マップが機能すれば、一定期間は議論に決着がつきます。
• 予測精度 - レビュー時に、規模を見積もったセグメントが実際にマップの予測どおりに行動したかを確認し、結論ではなく見積もり方法を修正してください。

次のいずれかが発生した場合は、早めに見直してください。

• 価格設定またはパッケージの変更；
• 新しい言語またはランタイムの対象；
• 資金提供の推進要因の変更；
• 競合が主要セグメントにおけるデフォルトの地位を獲得したとき；
• 主要セグメントが目標を達成したとき。

よくある失敗

• 「対象者は開発者です。」 これは集団であって、セグメントではありません。その結果、互いに共通点のない人々の平均を対象に、あらゆる成果物を作ることになります。
• 経験年数だけでセグメントを分ける。 同じスタックを使う初級と上級の開発者は、通常、同じものを必要とします。経験年数が重要なのは、権限や学習ニーズに結びつく場合だけです。
• 誰も行動に移さないディメンション。 2つのセグメントに同じ成果物を提供するなら、それらは人口統計上の注記が異なるだけの1つのセグメントです。
• 文章による人物描写や平均値としてのペルソナ。 一日の過ごし方を描く段落は読みやすくても、何も決めません。また、セグメント間で平均化されたペルソナは誰のことも表しません。規模、意思決定単位、成果物、根拠を記載した行が判断に役立ちます。
• 自社のファネルだけに基づく規模の見積もり。 自社のデータが示すのは、すでにファネルを通過した人々です。まだ対応できていないセグメントは、常に小さく見えます。
• 対象外セグメントがない。 除外対象を明記しなければ、すべての対象者が理論上は対象範囲に残り、四半期以内に労力が再び分散します。
• 有効期限のないマップ。 エコシステムは変化します。レビュー日がないセグメントマップは、いつの間にか昨年の計画になってしまいます。

参考資料

• references/segment-dimensions.md - 開発者に特化した値を含む6つのディメンション群、各ディメンションが満たすべきテスト、7つの評価基準。
• references/sizing-sources.md - 各公開データソースが測定するもの、根拠として使えないもの、推定の形式、仮説上のセグメントを低コストで検証する方法。
• references/decision-unit.md - ユーザー／推進者／承認者／購入者の役割、それぞれを納得させる要素、個人と企業で導入の形が変わるとセグメントの定義がどう変わるか。
• references/segment-map-example.md - セグメントマップの完全な作成例、各セクションの弱い例と強い例、却下されたマップ。
• references/published-findings.md - 出典を伴うすべての主張とその出典および限界、このスキル自体の基準値。
• samber/developer-relations-skills@developer-journey-map
• samber/developer-relations-skills@devrel-strategy
• samber/developer-relations-skills@developer-first-gtm
• samber/developer-relations-skills@devrel-metrics
• samber/developer-relations-skills@devrel-content-calendar
• samber/developer-relations-skills@developer-event-sponsorship