developer-journey-map

開発者ジャーニーマップ

開発者リレーションズ戦略担当者として、開発者があるテクノロジーの存在をまったく知らない状態から、それに依存するようになるまで、そして時にはそのテクノロジーを代弁するようになるまでの道のりをマッピングします。マップと離脱箇所の診断を作成してください。各ステージの改善は行わないでください。

出力は開発者ジャーニーマップです。各ステージにつき1行の表と、次に取り組むべき1つのステージを特定する簡潔な診断を作成します。これは意思決定のための資料であり、ポスターではありません。各行では、必ず次の項目に答えてください。

• 開発者がこのステージを離れたことを示す、観測可能なイベントは何か
• その率に責任を持つのは誰か
• その率を追跡する単一の数値は何か

開発者層に関する2つの事実が、この作業全体を左右します。

• ジャーニーの大半は観測できません。開発者はアカウントを作成するずっと前に、ドキュメントを読み、リポジトリにざっと目を通し、コンテナを実行し、同僚に質問します。そのため、初期ステージは測定されるのではなく、推定されます。
• 多くのステージはDevRel以外が担当します。ドキュメント、プロダクト、サポート、エンジニアリング、コミュニティなどです。すべての行に担当者が1人ずついるだけのマップでは、誰も合意していないマップになってしまいます。

引用できるもの、できないもの

この分野では用語は定まりましたが、数値は定まりませんでした。Revellは2016年に6ステージモデルを発表し、将来のガイドでステージごとの測定方法を示すと約束して締めくくりましたが、そのガイドが発表されることはありませんでした。

広く出回っている数値は、ステージの定義が一致しない単一企業の逸話にすぎません。そのため、開発者向けプロダクトにおける「認知から本番環境までの標準的な率」は、誰も引用できるものではありません。したがって、マップに記載する各率はプロダクト独自のデータに基づき、正直に比較できるのは同じマップの前バージョンとの比較だけです。

このスキルに含まれる数値は、次の2種類です。ユーザーに説明するときは、両者を明確に区別してください。

• 出典あり。 出典を付けて引用します。例：「Revellの2016年モデル」「Plausibleが2021年8月に測定した数値」。
• このスキル独自のデフォルト値。 5～7ステージの範囲、インタビューの件数、シグナルカバレッジの60％というゲート、1つの離脱箇所のルール、90日後の再評価などです。それぞれ「作業上のデフォルト値です。データが異なる結論を示す場合は変更してください」と明記します。

references/published-findings.mdには、出典のある主張とその出典、このスキルが独自に設定したベースライン、そして引用を避けるべき数値の全項目が記載されています。数値を引用する前に読んでください。

呼び出し例

ユーザーの発言	実行内容
"自社の API 製品における開発者の利用プロセスをマッピングしてください"	ステップ1〜7をすべて実施します。まずインタビューを行います。最終状態とセグメントがわからなければ、ステージモデルを選べないためです。
"開発者は試しても、本番環境に到達しません。どこで離脱しているのでしょうか？"	ステップ2を先に行い、全ステップを実施します。答えを出すには根拠を確認する必要があり、マップがあればそれを可能にできます。
"開発者エクスペリエンスの各ステップは、誰が担当していますか？"	担当者の列を主な成果物として、全ステップを実施します。2つのステージを誰も担当していないことが判明する見込みです。
"前四半期の利用プロセスマップを更新してください"	ステップ1は省略します。以前のステージモデルに問題がなければ維持し、ステップ2に進んで、シグナルを以前の値と比較します。
"この5つのステージのうち、どれを最初に改善すべきですか？"	既存のステージリストを使って、ステップ2と6のみ実施します。モデルを再構成しないでください。

次の2種類の依頼は断り、適切なスキルに案内してください。

• "クイックスタートを書き直して、コンバージョン率を上げてください" - 1つのステージの改善に、7ステージの成果物は必要ありません。このファイルの末尾に記載されているクイックスタート用スキルに案内してください。
• "開発者向けメトリクスのフレームワークを構築してください"、"どのセグメントをターゲットにすべきですか？" - マップの対象範囲より上流または下流の内容であり、マップには含まれません。そこに記載されているメトリクスおよびセグメンテーション用スキルにも案内してください。

成果物は常に、ステップ7に示す7つの見出しを含む単一の Markdown ドキュメントです。

• 表を1つ
• バイヤーレーンを1つ
• 名前を付けたモーメントを3つ
• 離脱ポイントを1つ
• 引き継ぎを1つ
• ギャップの一覧を1つ

インタビュー

一度に質問するのは1つだけにし、可能な場合は選択肢を提示します。対象セグメント、望ましい最終状態、利用可能な証拠を特定できたら、そこで止めます。残りはドラフト作成中に確認します。

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

1. 製品は何ですか。また、開発者はそれを使って具体的に何をしますか。API を呼び出す、ライブラリをインストールする、インフラストラクチャをデプロイする、プラットフォームを拡張する、リポジトリに貢献する、のどれですか。
2. このマップの対象となるオーディエンスセグメントはどれですか。セグメントごとにマップを1つ作成します。趣味で使う人の道筋と、エンタープライズのプラットフォームチームの道筋は、異なる列ではなく、異なるジャーニーです。
3. この期間で重視する最終状態は何ですか。実運用での利用、有料化、貢献のマージ、公開での推奨、組織全体での標準化のどれですか。
4. 購入において、開発者は購入者、影響を与える人、それともどちらでもありませんか。誰が契約を承認し、どの段階で関与しますか。
5. 製品はセルフサービス型、営業支援型、無料のオープンソース、それともその組み合わせですか。
6. すでにどのような証拠がありますか。分析データ、登録時の流入元に関する質問、サポートチケット、コミュニティのスレッド、ユーザーインタビュー、過去の摩擦記録などはありますか。
7. 現在、ジャーニーのどの部分を実際に観測でき、どこから可視性が始まりますか。
8. 開発者が触れる各接点の担当者は誰ですか。ウェブサイト、ドキュメント、クイックスタート、SDK、ダッシュボード、サポート、コミュニティ、リポジトリについて教えてください。
9. 開発者がどこで離脱するかについて、すでにどのような仮説がありますか。また、そう考える根拠は何ですか。
10. これは初めて作るマップですか、それとも既存のマップの更新ですか。更新の場合、前回から何が変わりましたか。
11. マップの決定期限はいつですか。また、何がそれを待っていますか。計画サイクル、計測の依頼、組織再編、特に決まったものはない、のどれですか。
12. 現状の離脱箇所を一度だけ診断したいですか。それとも、四半期ごとに再実行して差分を比較するマップが必要ですか。
13. 労力の上限はどの程度ですか。すでに保有しているデータの確認までですか。それとも、インタビュー対象者を募集し、別のチームに新たな計測を依頼することも含みますか。また、現在のステージ名に何が依存していますか。ダッシュボード、目標、別チームのファネルなどはありますか。

この3つの回答でステップ1の優先順位が決まるため、モデルを選ぶ前に質問してください。

• 期限が近い場合、すでに保有しているデータではステージの境界を確認できないモデルは候補から外します。
• 継続的な活用が求められる場合、出典のない既定のモデルよりも、公表されたモデルを優先します。再実行時やチーム間で比較できる語彙を保てるのは、公表されたモデルだけだからです。
• 労力の上限が低い場合、マップはすでに計測されている境界までにとどめ、それ以外はマップ作成を妨げないよう「ギャップ」セクションに記載します。

ハーネスに永続メモリがある場合は、選択したセグメント、ステージモデル、離脱イベント、現在のシグナル値をそこに保存します。このマップの価値は、前回のバージョンと比較しながら再実行できることにあります。来四半期に白紙の状態から始めるのでは、それはできません。

ステップ1 - ステージモデルを選ぶ。独自に作らない

ブレインストーミングの段階であることを伝え、まだ行を作成しないでください。

次の順番で2段階に分けて進めます。まず候補から外し、その後、残ったものに優先順位を付けます。

• 削除する。 インタビュー質問3で定めた最終状態によってモデルの末尾が決まるため、最終段階がその最終状態ではないモデルはすべて候補から完全に外します。どのモデルを外したか、またその理由を、マップの「スコープ」セクションに記録してください。標準化、収益、実運用での利用、貢献、支持はそれぞれ異なる最終段階であり、末尾が3種類あるマップには優先順位がありません。更新時は、以前のモデルに実際の問題がない限り、それ以外をすべて削除します。より適した語彙よりも、自分たちの過去との比較可能性を優先します。

• 順位を付ける。 残ったモデルに順位を付け、順位を声に出して伝えます。ここでいう労力とは、段階の境界を数えられるようにするために集めなければならない証拠に加え、調整と可逆性を指します。すべての後続列とダッシュボードは段階の一覧を基に構築されるため、段階を切り直すと、すでに割り当てた証拠が無効になります。

• 労力：Revell の6段階 > AAARRRP > OSS コントリビューターファネル > API の5段階アーク > 出典のないデフォルト

• 効率：API の5段階アーク > OSS コントリビューターファネル > AAARRRP > Revell の6段階 > 出典のないデフォルト

意図的に「価値」の順位は設けていません。モデルの価値は、資金提供対象の最終状態に最終段階がどれだけ合致するかだけで決まるため、同じモデルでも、あるチームにとっては最適な選択肢になり、別のチームにとっては価値がありません。ここで固定の価値順位を設けるのは見せかけの精密さであり、上記の削除手順ですでにその判断を行っています。

桁違いの目安：

• API の5段階アークの境界、つまり初回の呼び出し、統合、実運用は、通常すでにプロダクトのテレメトリに記録されています。確認にかかる時間は、1時間から1日です。
• OSS コントリビューターファネルには数日かかります。初回の PR、レビューの遅延、再訪はリポジトリに記録されていますが、離脱した人への聞き取りには時間がかかります。
• AAARRRP には1週間から1四半期かかります。主に調査ではなく調整に時間を要します。段階を、他チームが所有する全社的なファネルとすり合わせる必要があるためです。
• Revell の6段階には1四半期かかります。標準化の境界を特定するには、アカウントの集約と、ほとんどの組織がまだ実施していない買い手側へのインタビューが必要だからです。

最も安価な選択肢がどこに位置するかに注目してください。出典のないデフォルトは、ほぼコストがかからないにもかかわらず、効率では最下位です。業界の語彙や他チームのファネルとの比較可能性が得られないためです。安価であることと効率がよいことは、同じ順位にはなりません。

効率の順位では、標準化の段階を明示的に設けている唯一のモデル、Revell の6段階が後回しになります。それでも、資金提供対象の問いが「チームが採用するのに、なぜ組織全体では標準化されないのか」である場合や、組織全体のデフォルトになることが契約更新の条件である場合は、これを上位にしてください。その場合、必要となるアカウントの集約こそが目的であり、コストではありません。

どちらの順位も法則ではなく、デフォルトとして扱ってください。各チームがすでに計測している内容によって変わります。それを踏まえて順位を付け直します。

• すでに全社的な AARRR ファネルがあるなら、AAARRRP の調整コストはほぼなくなり、最上位になります。
• 営業向けにアカウントの集約がすでに行われているなら、Revell のコストの大半がなくなります。
• 登録前のテレメトリがないプロダクトでは、API アークの初期境界がちょうど観測できない部分にあたるため、順位を下げます。

references/stage-models.md から、効率の高い順に 2つまたは3つの候補となる段階モデルを提示してください。それぞれについて、何が見えるようになり、何が見えなくなり、境界の観測にどれだけのコストがかかるかを説明します。1つを推奨し、その理由を述べてください。行を一つでも記入する前に、ユーザーに選んでもらいます。

残りを決める指針：

• 5～7段階を優先します。これはこのスキルのデフォルトの範囲であり、標準ではありません。段階が少なすぎると、段階内の離脱箇所が見えなくなり、多すぎると、離脱イベントを定義できない段階が生まれます。
• 段階を分割するのは、異なる担当者が所有する異なる離脱イベントが2つある場合に限ります。たとえば、「評価」は、ドキュメントを読むこととローカルトライアルを実行することを別々のチームが担当している場合、明確に分割できます。
• 公開済みのモデルを使う場合は、モデルの公開済み段階名を維持してください。そうすることで、マップを業界の語彙や、その段階に目標を結び付けるプログラム戦略と比較可能な状態に保てます。

ステップ 2 - どの行も埋める前に証拠を集める

意見をまとめたマップに記されるのは、チームの考えであって、開発者の道のりではありません。まず証拠を集め、手間の少ない情報源から確認し、各調査結果に該当するステージを付けます。

1. 自分で道のりをたどり、摩擦ログを記録します（Google の DevRel の実践。プロトコルは以下のリファレンスを参照）：現実的なシナリオを 1 つ選び、何を検索し、クリックし、貼り付け、どう感じたかを逐次記録し、緑／黄／赤のマークを付けます。誰も報告しない離脱を見つけられるのは、この方法だけです。
2. 開発者がすでに書いたものを掘り起こします。サポートチケット、イシュー、コミュニティでの質問、検索結果がなかったドキュメント検索などです。ステージ別に分類します。最大のクラスターは摩擦の候補であり、まだ結論ではありません。
3. ジャーニーを完了した開発者 5～8 人にインタビューし、さらに、募集は難しいものの価値の高い、途中で断念した開発者 3 人にもインタビューします。どちらの人数もこのスキルのデフォルトです。5～8 人という人数は一般的なユーザビリティ調査パネルの規模に合致するもので、ジャーニーマッピングの標準ではありません。
4. 新たな計測を依頼する前に、すでに存在するファネルデータを確認します。

シグナルを約束する前に、各場所から実際にどの情報を取得できるか確認してください。開発者マップの数値に最も大きな影響を与えるのは、次の 3 つの補正です。

• アナリティクスのブロック。 Plausible は、2021 年 8 月に Hacker News と Reddit からのトラフィックがある 1 つのサイトで、自社のプロキシ経由スクリプトを使って計測したところ、技術系オーディエンスの 58％がサードパーティのアナリティクススクリプトをブロックしていたと報告しています（Linux では 82.3％、Firefox では 88.3％）。関心を持つベンダーによる単一サイトでの計測ですが、公開されている情報としてはこれが唯一です。そのため、開発者向けサイトの絶対トラフィック数はページごとに異なる係数で誤っています。同一の情報源内での比率だけが有効です。
• 保持期間。 リポジトリのトラフィック API は 14 日間、npm のダウンロード数は 18 か月、PyPI の時系列データは 180 日間保持されます（GitHub REST Metrics/Traffic と pypistats のドキュメント）。これらを使うシグナルは、定義した当日からスナップショットを保存してください。期限切れのデータは後から補完できません。
• リファラーの欠落。 アグリゲーター、チャットクライアント、プライバシー重視のブラウザー、AI アシスタントはリファラーを取り除きます。AI アシスタント経由のトラフィックの約 70％にリファラーがないというのは、調査結果ではなくニュースレターでの推定値です（Demand Curve #331）。「ダイレクト」の割合が大きいのは通常の状態であり、計測の不具合ではありません。

references/evidence-and-signals.md には、各ステージで確認する項目、シグナル候補、各場所を通常どのチームが担当するか、摩擦ログと離脱者インタビューのプロトコル、および場所ごとの計測の実情が詳しく記載されています。

ステップ 3 - 各ステージに 1 行ずつ記入する

各行には 8 つの項目があります。太字の 3 項目が、一般的なジャーニーマップとの違いです。これらのいずれかが欠けている行は未完成です。

項目	記入する内容
ステージ	選択したモデルに記載されている名称
開発者の目的	ベンダーのファネル用語ではなく、本人の言葉で、達成しようとしていること
開始トリガー	ステージの開始を示す、観測可能なイベント
終了イベント	次の段階に進んだことを証明する、単一の観測可能なイベント — 初回の API 呼び出し成功、本番環境への初回デプロイ、初回の PR マージ、初めての登壇
タッチポイント	関係する接点：ドキュメントページ、リポジトリ、CLI の出力、ダッシュボード、コミュニティのスレッド、サポートチケット
担当者	このステージの終了率に責任を持つ個人またはチーム
摩擦の証拠	出典を明記した観察結果。仮説は不可。証拠がない場合は「証拠なし」と記入します
シグナル	データソースと現在の値を含む指標を 1 つ、または not instrumented

一般的なジャーニーマップに含まれる次の 2 つの列は設けないでください。

• 開発者の規模を考えると、感情スコアは捏造になりやすく、責任の所在を明らかにする列を圧迫します。
• 同じ作業中に作成した改善機会のリストは、どのステージで離脱が起きているかがわかる前に、マップをバックログに変えてしまいます。

測定値ではなく推定値を使った数値があるステージには、すべて印を付けてください。ステップ 2 のブロッキングによる離脱やリファラーの離脱を考えると、初期ステージはほぼ必ず推定値になります。正直に inferred とラベル付けすれば、マップから導く結論の信頼性を守れます。もっともらしい偽の数値は、その信頼性を損ないます。

ステップ 4 - 購入者レーンを追加するか、存在しないと明記する

• B2B で、開発者が購入者ではない場合。 経済的な購入者向けに、短い第 2 のレーンを追加します。内容はセキュリティレビュー、法務とライセンス、調達、予算承認で、購入の確約または標準化の段階で合流します。このレーンには独自の離脱イベント（セキュリティ質問票の審査通過、契約締結）と独自の担当者がいます。通常、その担当者は DevRel の外にいます。開発者のレーンは並行して続きます。承認者を動かせない推進者がいると、開発者のレーンでは示せない段階で停滞します。

• このレーンを読む前に、利用状況をアカウント単位に集約します。 開発者のレーンでは人数を数えますが、購入者のレーンでは組織数を数えます。まず、メールドメイン、ワークスペース、またはライセンスごとにサインアップをグループ化します。そうしなければ、同じ企業からの 40 件のサインアップが、40 件のリードに見えてしまいます。

• 購入意欲が高まる順に、3 つのシグナル群を読み取ります。

  • 利用の深さ - 本番環境での利用、継続的な利用量、CI への組み込み。
  • 利用の広がり - 同じアカウント内の 2 人目、3 人目の開発者。
  • 境界への接触 - SSO または RBAC のページを開く、コンプライアンスに関する質問をする、シート上限に達する、セキュリティ質問票を求める。

  境界への接触は最もまれで、最も強力なシグナルであり、このレーンで最も明確な離脱イベントです。まず、これを計測できるようにします。

• 個人による採用、または B2C 型のセルフサービス。 2 つのレーンは一つにまとまります。開発者自身が判断して支払うか、まったく支払いが発生しません。購入者のレーンを空欄のままにするのではなく、マップ上にその旨を明記します。そうすれば、後から読む人は、忘れられたのではなく、決定済みだとわかります。

• 購入につながらないオープンソース。 購入者のレーンはありませんが、ユーザー自身の会社内で採用承認の段階（ライセンスの互換性、依存関係に関するポリシー）があることは少なくありません。これをレーンとしてではなく、採用段階での摩擦としてモデル化します。

それ以外のマップの要素は、どちらのモデルでも同じです。段階のモデル化、証拠の収集、離脱イベント、離脱箇所の診断は、ビジネスモデルによって変わりません。

ステップ 5 - 3 つの重要な瞬間に名前を付ける

これらを各行から取り出し、個別に記載します。マップは主にこれらを読み解くためのものです。

• 最初の成功 - 開発者が製品から実際の成果を得る瞬間です。具体的に定義し、現在、そこに至るまでにどれくらい時間がかかるかを記します。
• 正念場 - 開発者が導入を決めるか、見送るかの分岐点です。実際のプロジェクトへの導入、推薦、プルリクエストの作成といった決断を指します。
• 離脱ポイント - 証拠から、多くの人が実際に利用をやめているとわかる地点です。チームが想定している地点よりも前で、目立たない地点であることがよくあります。

ステップ 6 - 離脱の原因を診断する

• 両方の離脱イベントがカウントされている場合に限り、ステージ間の転換率を算出します。それ以外は inferred と記載します。
• 取り組むステージを1つ選びます。転換率が低く、かつ変更できる担当者がいるステージのうち、最も早い段階のものです。早い段階を優先するのは、上流での離脱によって下流のあらゆる改善効果が薄まるためです。担当者がいることを優先するのは、担当者のいない提案は願望にすぎないためです。候補は、改善にかかる労力あたりの回復できる開発者数で順位付けします。ドキュメントの修正とオンボーディングの再設計では、かかる週数は同じではありません。そのうえで初めて、「最も早い段階で、担当者がいるもの」をタイブレークに適用します。
• この順位付けによって何が後回しになるかも伝えます。標準化、支持者の育成、貢献など、効果は大きいものの改善に多大な労力がかかる後半のステージは、早期の低コストな改善に勝てることがありません。そのため、チームがこのマップを四半期ごとに作り直しても、何年もそのステージに手を付けない可能性があります。最も早い離脱ステージに担当者がいない場合、その改善がすでに進行中の場合、またはインタビューで示されたゴールがまさにその後半のステージである場合は、優先順位を上げます。
• ある期間のイベント数が約30件を下回る場合、率ではなく日付付きの生データ一覧を公開します。これは統計上の慣例であり、DevRel に関する知見ではありません。後半のジャーニーステージでは、この基準に達しないことが頻繁にあります。
• 比較対象は、このマップの過去のバージョンだけにします。他社が公開しているファネルは、対象となるオーディエンス、プロダクトの成熟度、各ステージの定義が異なります。
• ほとんどの行で担当者が DevRel になっている場合は、それを組織に関する知見として報告します。これは、各接点に責任者がいないことを意味しており、離脱よりも大きな問題です。

ステージを選んでから初めて、BJ Fogg の行動モデルを使って、そこで離脱が起きる理由を説明します（B = MAP：動機、能力、プロンプトがそろうと行動が起きます）。B=MAP は1つのステージを説明するものであり、ステージ同士の優先順位付けには使えません。

ステージを選ぶ前にこのモデルを使うと、そもそもボトルネックではなかったステージについて、説得力のある動機付けのストーリーを書いてしまいます。離脱が起きているステージとは、行動が起きていないステージです。このモデルでは原因を3つに分け、それぞれ異なる担当者に行き着きます。

• 能力が低すぎる - 手順が長すぎる、明示されていない前提条件が必要である、または慣れない手順を求めている場合です。ドキュメント、開発者体験、またはプロダクトによって改善します。開発者を対象とする場合は、これがまず考えられる答えです。また、Fogg 自身の方向性を示す助言も当てはまります。「動機付けは当てにならない。幸い、能力はそうではない」という言葉のとおり、動機付けを高めるよりも能力を高めます。
• 動機が低すぎる - このステージでは、労力をかけるだけの価値がある理由が示されていません。ポジショニングとプロダクトマーケティングによって改善します。開発者向けステージで動機付けを優先して改善する場合、チームが手順を減らすよりもコピーを書くことを選んだということがよくあります。
• プロンプトがない - 続ける能力も意思もあったのに、続けるよう促すものがありませんでした。アプリ内ガイダンス、ライフサイクルコンテンツ、またはコミュニティによって改善します。

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

# Developer journey map - <segment>, <date>

## Scope segment, end state, stage model used and why

## Journey the stage table (one row per stage, eight fields)

## Buyer lane the buyer's stages, or an explicit "none - self-serve"

## Moments first success, moment of truth, abandonment point

## Leak the chosen stage, its evidence, why it beat the others

## Handoff who owns the fix, the signal to watch, the re-read date

## Gaps stages marked inferred, and what would make them measurable

一度に1つのセクションを提示し、次を書く前に合意を得ます。誤ったステージモデルを最初の見出しで見つければ、修正は1段落で済みます。離脱の診断まで進んでから見つけると、文書全体を書き直すことになります。

同じ行について、弱い例と強い例を示したマップの作成例は、references/journey-map-example.md にあります。

品質ゲート

マップをこの基準に照らして確認し、合格するまで改善を繰り返してから、チェック結果を明示してください。これらはこのスキル独自の基準であり、業界標準ではありません。数値の根拠をユーザーに尋ねられたら、その旨を伝え、状況に応じてユーザーが基準を変更できるようにしてください。

• 各ステージの出口イベントは必ず1つとし、心の状態ではなく、観察可能なイベントとして表現します。
• 各ステージに担当者を1人記載し、担当者の少なくとも1人はDevRelチームの外部から選びます。
• ステージの少なくとも60％に実際の現在値があるシグナルを付けます。残りは not instrumented と記載し、「ギャップ」セクションに含めます。
• 摩擦に関する主張にはすべて出典を示します。どの行も、根拠と仮説を混在させてはいけません。
• 特定するリークは必ず1つとし、担当者と再確認日を明記します。
• 推定したステージには、登場するすべての箇所で推定であることを明記します。
• 読みやすいサイズで1ページに収めます。収まらない場合は、ステージの一覧が長すぎるか、セルに説明文を詰め込みすぎています。

シグナルの基準を満たさなくても、マップの公開を妨げるものではありません。ギャップを明記して公開しましょう。穴があっても正直なマップのほうが、数値を捏造して完成させたマップより優れており、ギャップを計測の要望として提示できます。

よくある失敗

• 会社が望むファネルをマッピングする。 営業パイプラインから取ったステージ名は、開発者の行動ではなく、社内プロセスを表しています。各ステージ名について、「開発者が自分の行動として認識できるか」を確認してください。
• すべての開発者に1つのマップを使う。 趣味で開発する人、プラットフォームエンジニア、エンタープライズアーキテクトが直面する摩擦は、ほとんど共通しません。セグメントを選ぶか、何も作らないでください。
• イベントではないものを出口イベントにする。 「価値提案を理解する」は観察、集計、担当者の割り当てができません。「クイックスタートを最後まで実行する」なら可能です。
• マップ全体をアナリティクスで埋める。 アナリティクスで計測できるのはサインアップ後からで、そこですでに利用者の行程は中盤です。それ以前のすべての段階には、定性的な根拠を使うか、正直に inferred と記載する必要があります。
• 反応がないことを満足の表れと決めつける。 セットアップに失敗した開発者は、問題を報告せず、そのまま離脱することがよくあります。あるステージに関する苦情がないことは、そのステージがうまく機能している証拠にはなりません。
• リークを3つ特定する。 優先事項が3つあるのは、優先事項がないのと同じです。順位を付け、担当者が割り当てられている最も早い段階のものを修正してください。
• B2Bでバイヤーのレーンを省く。 その結果、マップには健全な開発者の行程と停滞したパイプラインが並びますが、そのどちらも説明できなくなります。
• マップを不変のものとして扱う。 ローンチ、価格変更、ドキュメントの書き直し、新しいSDKによって接点が変わったら、マップを再確認してください。2四半期以上更新されていないマップは、もはや存在しない製品について説明しています。
• 他社のコンバージョン率を流用する。 広く出回っている数値は、ステージの定義が互いに一致しない、単一企業の逸話にすぎません。これを引用すると、マップに根拠のない自信を持たせ、唯一意味のある比較、つまり自社の前回のバージョンとの比較を見えにくくします。
• 初期ステージに絶対的なトラフィック数を記載する。 ステップ2のブロック率により、セッション数はいずれもページごとに変動する割合にすぎません。同じソース内で比率を扱い、ステージには推定であることを明記してください。

参考資料

• references/stage-models.md - 公開されているステージモデル、その情報源、およびモデルの選び方です。
• references/evidence-and-signals.md - エビデンスの情報源、ステージごとの候補シグナルと一般的な担当者、購入者レーンのシグナル群、各サーフェスにおける計測の実情、摩擦ログと終了時インタビュープロトコルについて説明しています。
• references/published-findings.md - 出典のある主張、このスキル独自のベースラインとなる数値、および使用を避けるべき数値について説明しています。
• references/journey-map-example.md - 弱い行と強い行を含む、完成版のマップ例です。
• samber/developer-relations-skills@developer-segmentation - マップの対象とするセグメントを選びます。
• samber/developer-relations-skills@devrel-metrics - ステージごとのシグナルを、測定フレームワーク全体にまとめます。
• samber/developer-relations-skills@devrel-analytics - ステージごとのシグナルを計測します。
• samber/developer-relations-skills@devrel-strategy - プログラムの目標を、このマップで作成するジャーニーに結び付けます。
• samber/developer-relations-skills@developer-quickstart-guide - 初回の成功に向けて、ステージ単位で改善します。
• samber/developer-relations-skills@developer-docs-structure-audit - 評価と導入における摩擦を、ステージ単位で改善します。