pipeline-stage-definition-audit

ステージ定義の監査

既存のパイプラインのステージ定義が、社内担当者の活動ではなく、買い手が検証できるマイルストーン、すなわち買い手が行ったこと、述べたこと、または合意したことを反映しているか評価し、重大度順に整理した所見レポート、書き換えた終了基準、安全な移行計画を提示します。

参考フレームワーク：

• Gartner の B2B 購買における 6 つのジョブ（買い手側の参照構造）：Problem Identification、Solution Exploration、Requirements Building、Supplier Selection、Validation、Consensus Creation。
• GitLab の公開商談営業ハンドブック（公開されているステージ定義ドキュメントの実例）：定義、関係者、活動、システムによる適用、終了基準、相互リンク。
• MEDDPICC 形式のゲート判定：終了基準の各要素を赤／黄／緑で評価し、すべて緑になったら次へ進みます。
• Winning by Design の SPICED（買い手側の診断レンズ）：各要素は、担当者が推測するのではなく、買い手と確認します。

基本原則

• 監査に徹し、再設計はしません。既存のステージ構成を入力として扱います。ファネルモデル自体に欠陥がある場合は、その旨を明記し、ここで作り直すのではなく、ファネル設計の関連項目（Reference）を参照するよう案内します。
• すべてのしきい値に、その出典を明記します：公開されている企業慣行、実務者のコンセンサス、またはユーザー自身のデータに基づくもの。ベンダーの経験則を業界の普遍的な基準として提示してはいけません。
• 広く出回っている予測統計（「チームの 93% は売上を 5% 以内の精度で予測できない」「B2B 企業の 85% は予測を外す」「CRM データの精度はわずか 40〜60%」）は使わないよう警告します。いずれも出典不明のまま流布しており、事実として述べてはいけません。代わりに、その仕組みを説明します。ステージの進行が主観的だと、同じ案件でも担当者によってステージの判断が異なり、その結果、ステージ別のコンバージョンデータと、それを基にしたすべてのデータが歪みます。
• ステージが記録するのは買い手の状況であり、適格性のスコアカードではありません（Force Management の警告）。「MEDDIC のステージ 1〜6」は存在しません。各適格性の評価軸は、それぞれ独立した継続更新フィールドです。スコアカードとステージの選択肢を混同すると、どちらも機能しなくなります。
• ステージを評価する前に、パイプラインの種類（以下）を分類します。取引パイプラインを案件パイプラインの基準で評価すると、誤った所見につながります。
• 既存のステージ値の名前変更や削除はしないでください。多くの CRM ではステージ履歴は変更できず、過去のレコードは永久に古い値を参照し続けるため、名前変更や削除を行うと変更前後のレポートが恒久的に破損します。古い値を無効化し、新しい値を追加してください。変更後は、すべてのステージの予測カテゴリのマッピングを再確認してください。
• 5〜7 ステージ、それぞれに 2〜4 個の終了基準を設けるのが実務者のコンセンサスであり、絶対的なルールではありません。ステージに独自の目的があるなら、その存在意義があります。そのステージで何も変化しないなら、削除します。

パイプラインの種類

個々のステージを評価する前に、パイプラインの種類を明確にします。3つの種類は、The RevOps Show（Doug Davidoff、Jess Cardenas）が提唱しています。

• 開発パイプライン - アカウントを、インテントがない状態からインテントがある状態へと進めます。ステージでは、商談の進行状況ではなく、買い手の関心を示すシグナルを追跡します。
• 商談パイプライン - インテントから意思決定までを扱います。この監査の例がデフォルトで想定する、従来型のエンタープライズ B2B モデルです。
• トランザクションパイプライン - 高速で、価値が比較的低く、摩擦の低減を重視します。ステージ数が少なく、基準も簡素で、進行シグナルは自動化されていることがよくあります。

高速、セルフサービス、PLG、B2C のチームでは、営業担当者が所有するパイプラインをまったく使わず、マーケティングやグロースが管理する、買い手向けのライフサイクル／ファネルステージを運用していることがよくあります。真のパイプラインという構成が再び現れるのは、営業支援型またはアップマーケット型の営業活動に移行した場合に限られます。その場合、ファネルとパイプラインは別個のレポート用構成として併存させ、1つのステージリストに統合してはいけません。

• **B2B と B2C で共通するもの：**検証可能性のテスト自体、ステージ滞留期間とコンバージョンの診断、そして名前を変更せずに無効化する移行ルールです。
• **B2B と B2C で異なるもの：**ステージ数、証拠の種類（署名済み書類やセキュリティレビューに対する、プロダクトイベントや支払いシグナル）、および所有者です。

B2C のステージ定義に関する、実務家による文献は限られているため、3種類のパイプラインという枠組みが、現時点で最も有用な基準となります。その他の要素はユーザー自身のデータから導き出し、その旨を明記してください。

ヒアリング

何かを評価する前に質問してください。1メッセージにつき質問は1つにし、可能な場合は選択肢を提示し、すでに回答されている項目は省略します。

• 現在のステージリストを、各ステージの文書化された定義とともに、そのまま貼り付けてください。定義が担当者の頭の中にしかない場合は、そう伝えてください。それ自体が調査結果です。
• このパイプラインにつながる営業活動はどれですか。エンタープライズ向け営業主導、ミッドマーケット向け、高速なインサイドセールス、PLG の営業支援型のどれでしょうか。パイプラインは1つですか、それとも複数ですか。また、複数の営業活動で1つを共有していますか。
• ACV の範囲と標準的な営業サイクルの長さはどのくらいですか。
• この監査のきっかけとなった症状は何ですか。同じステージに商談が滞留する、予測を外す、ステージ判定についてマネージャー間で意見が食い違う、ステージを飛ばす、クローズ予定日がひそかに先送りされる、といったものがありますか。
• ステージごとの予測カテゴリの対応関係はどうなっていますか。
• ステージの値に連動している必須フィールド、検証ルール、自動化には何がありますか。
• エクスポートまたはクエリできるデータは何ですか。ステージ変更履歴、受注／失注レコード、クローズ予定日の変更履歴、担当者別の内訳などがありますか。
• ステージ定義の所有者は誰で、変更を承認するのは誰ですか（RevOps、営業リーダーシップ、財務）。
• 同じ商談を独立して採点できる人が2人いますか。マネージャー2人、または相談せずに商談レコードを判定できるレビュー担当者2人でも構いません。「合格基準」の評価者間チェックには、その2人が必要です。レビュー担当者が1人しかいない場合は、今の時点でそう伝えてください。その場合、チェック方法は、機械記録された基準に照らした自動イベントの抜き取り監査に変更します。測定していない一致率を主張するのではなく、納品物にその代替を明記する必要があります。
• ステージを最後に変更したのはいつですか。また、その展開はどのように進みましたか。
• サンプルを提供できますか。最近クローズした商談20～30件と、各ステージに現在滞留しているオープンな商談を用意してください。
• 結果の提出期限はいつですか。また、その日付は進行中の四半期内ですか。ステージ変更が反映されると、その四半期のデータが損なわれます。そのため、四半期の途中に期限がある場合、「是正の優先順位」にあるすべての移行段階を対象外とし、基準の書き直しだけを残します。
• 特定の予測の前に一度だけ修正したいですか。それとも、毎四半期通用する定義セットを求めていますか。一度限りの修正なら基準の書き直しだけを優先します。継続的な改善を求める場合は、証拠を整備し、定期的な検査を必須にします。
• 労力の上限はどのくらいですか。CRM 管理者を確保できますか。再トレーニングが必要な営業担当者は何人ですか。また、パイプラインのトレンド系列を切替日でリセットすることは許容できますか。管理者を確保できない場合、証拠の整備段階は対象外になります。トレンドの中断が許容されない場合、ステージの切り替えとステージの追加は対象外になります。

ワークフロー

1. インタビューを実施し、パイプラインの種類を分類して、スコープの境界（再設計ではなく監査）を確認します。

2. references/audit-intake.md に従って資料を収集し、関係者へのインタビューを実施します。誰かに話を聞く前に、データを確認します。

3. 各ステージに references/verifiability-test.md の検証可能性テストを適用します。終了基準には、買い手が行ったこと、発言したこと、または合意したことが明記されている必要があります。また、担当者の意見とは独立して観察でき、確認可能な場所に記録されている必要があります。実務上の確認方法は、同じ案件記録を見た2人のマネージャーが、基準を満たしているかどうかについてそれぞれ独立して同じ結論に達するかどうかです。

4. 各ステージを Gartner の購買ジョブに対応付けます（同じリファレンス内の表を参照）。対応するジョブがないステージ（担当者の活動を別の形で表しただけのステージ）と、1つのジョブに複数のステージが集中している箇所（冗長なステージ）にフラグを付けます。

5. パイプラインのデータを直接クエリできる場合は、references/diagnostic-metrics.md の診断指標を算出します。それ以外の場合は、案件サンプルとインタビューから得られる情報をもとに導き出し、測定していない診断指標はその旨を明記します。

6. すべての欠陥を、次のスキーマに従って所見として記録します：ステージ | 現在の終了基準 | 判定＋理由 | 重大度 | 修正段階＋工数 | 根拠 | 対応する購買ジョブ | 提案する基準 | 移行に関する注記。重大度の尺度は次のとおりです。

   • Critical - 終了基準が担当者の活動だけを示している、または文書化されていません。進行の判断が意見に依存しています。
   • High - 基準は買い手に言及していますが、検証できない、または確認可能な場所に記録されていません。
   • Medium - 検証可能ですが曖昧で、2人のマネージャーの判断が食い違う可能性があります。
   • Low - 基準は妥当で、欠陥は名称、順序、または冗長性にあります。

   重大度は所見の価値軸であり、対応順ではありません。文言の変更1つで修正できる Critical の欠陥は、選択リストの移行が必要な Medium の欠陥より先にリリースします。各所見に該当する修正段階と、その段階のおおよその工数をタグ付けし、以下の「修正順序」に従ってリストを並べ替えます。

7. 不合格となった各ステージの終了基準を書き直し（文言のガイダンスは検証可能性リファレンスを参照）、references/remediation-rollout.md をもとに修正および展開計画を作成します。修正順序に沿った対応、無効化して追加する移行、予測カテゴリの再マッピング、自動化の監査、トレーニング、展開の形態を含めます。

8. レポートを「出力形式」に従って、一度に1つのセクションずつ提示し、ユーザーに確認してもらいます。内容は、対応する references/worked-examples.md の実例を根拠とします。

9. 合格基準を確認します。基準と計画を反復して、基準を満たすまで改善するか、残るギャップを明示的に予定に組み込みます（例：新しいデータを得るために完全な販売サイクルが必要な指標）。

10. 実行環境に永続メモリがある場合は、ステージの一覧、ステージごとの判定、合意した閾値を保存し、展開後の再確認時に再インタビューではなく、それらを起点にできるようにします。

修正順序

6種類の修正を、重大度順でも、最も安価なものからでもなく、工数単位あたりに回復できる予測精度の順に並べます。ここでの工数には、管理設定、当該ステージを担当するすべての担当者の再トレーニング、過去データの移行、可逆性が含まれます。可逆性はこの一覧で最も重要です。四半期に2度ステージ定義を変更すると、その定義によって作られるべきトレンドデータが損なわれるため、ステージ値に触れる修正は、ほぼ一方通行です。

• 価値（回復できる精度の高い順）：full redefinition > criterion rewrite > evidence plumbing > stage add == stage cut > standing inspection
• 工数（多い順）：full redefinition > stage add > stage cut > evidence plumbing > standing inspection > criterion rewrite
• 効率（高い順）：criterion rewrite > standing inspection > evidence plumbing > stage cut > stage add > full redefinition

価値における stage add == stage cut の優劣は、パイプラインの種類によって決まり、それ以外の要素は関係ありません。

• ディールパイプライン： 検証と合意形成の段階でエンタープライズ案件が失注しやすく、最も頻繁にカバーされていない業務だからこそ、追加による改善効果が大きくなります。
• トランザクションパイプライン： 摩擦の除去がこの営業活動の設計目標であり、案件がスキップするステージは、スキップしたほうがコンバージョン率が高くなるステージだからこそ、削除による改善効果が大きくなります。

労力は同じではありません。移行作業は同じですが、追加の場合のみ、担当者にこれまで求められていなかった証拠の提示を求めます。

1. 基準の書き換え - 機能していない終了基準を、システムがすでに保持しているフィールドまたは成果物を指し示す、買い手の行動として言い換えます。選択リストの変更も、移行も、予測の再マッピングも不要です。ステージごとにほぼゼロから1時間、加えて既存のレビュー会議でのウォークスルーが1回必要です。古い文言はドキュメントを編集するだけで置き換えられます。これだけで重大度が「Critical」または「High」の所見の大半を解消できます。
2. 定期的な点検 - 定期的なパイプラインレビューの議題に終了基準を加え、四半期ごとに評価者間の再サンプリングを行います。四半期ごとに1時間かかり、以後ずっと続きます。これだけでは精度は改善しませんが、2四半期以内に上位の対策がすべて再び主観に戻るのを防げる唯一の段階であるため、この順位にあります。
3. 証拠の仕組みづくり - 書き換えた基準で必要とされているものの、システムが取得していない必須フィールド、検証ルール、または証拠へのリンクを作成します。管理者による設定に1～2日、さらにそのステージに関わる担当者全員の再トレーニングが必要です。設定は元に戻せますが、再トレーニングは元に戻せません。レビューを通過するだけの基準を、本番環境でも機能する基準に変えるのがこれです。
4. ステージの削除または統合 - 購買業務に対応していない、または隣接するステージと重複しているステージを無効化し、必要に応じてステージを追加します。数日から四半期かかります。進行中案件の移動、予測カテゴリの再マッピング、ステージにひもづく自動化の一覧確認が必要です。切り替え時にトレンドの時系列が途切れ、元に戻すと再び途切れます。
5. ステージの追加 - どのステージでもカバーされていない購買業務に、新しいステージを設けます。削除と同じ移行に加えて、担当者がこれまで求められたことのない行動と、マネージャーがこれまで点検したことのない行動が必要です。四半期かかります。
6. 全面的な再定義 - セルごとの修正ではなく、一貫した一連のものとしてステージ構成を作り直します。「基本ルール」によりここでは対象外です。実行を試みるのではなく、別途対応するよう案内してください。

デフォルトの段階：すべての基準を書き換えてから、定期的な点検を予定します。書き換えた基準が、システムで取得されていない証拠を必要とする場合に限り、次の段階に進みます。その場合、証拠の仕組みづくりは後続フェーズではなく、書き換えた基準を実際に機能させるために必要なものです。

この順序によって後回しになるのは、全面的な再定義です。価値の面では最も高く評価されます。ステージ構成を、個別に文言を定めたセルのリストではなく、一連のものとして扱う唯一の修正だからです。しかし、あらゆる取り組みにおいて費用対効果の比率では最下位となるため、重大度と労力による順位づけでは無期限に先送りされ、パイプラインには、それを支えられないステージモデルにうまく書かれた基準が積み重なっていきます。

次の場合はこれを優先し、このスキルから mbfinotti/revops-skills@revenue-funnel に案内してください。

• 監査で、実用的な基準として使えるステージが2つ未満です。
• 複数の営業活動で、同じステージリストを共有しています。
• パイプラインの種類自体が誤って分類されています。

却下した段階は、順位を下げるのではなく削除してください。計画の最下位に保留された段階は、後になって、予算が確保されていない作業として再び浮上します。

• ステージ定義の変更を承認する人がいない（インタビューによる）：削除と追加を計画から外し、外したことを明言してください。承認者のいない移行が実施されることはありません。
• CRM 管理者がいない： 同じように、証拠の仕組みづくりを計画から外してください。

この順序はデフォルトであり、絶対的な決まりではありません。状況や実行者によって変わります。インタビューの回答を基に、順位を付け直してください。

• CRM 管理者がいる： 仕組みづくりにかかる時間を1～2日から1時間に短縮できるため、定期的な点検より上位に移します。
• 四半期の途中で営業チームが活動中： ステージ変更は実施した四半期を損なうため、四半期が終了するまですべての移行段階を計画から外します。
• 手作業でステージを再構成できるほど小規模なパイプライン： 削除と追加の段階にかかる時間を桁違いに減らし、どちらも証拠の仕組みづくりより上位に移します。

出力形式

すべてのしきい値行に出典タグを付けます。

STAGE DEFINITION AUDIT - <pipeline>, <date>
Pipeline type    : development / deal / transaction + motion, ACV band, cycle length
Stage inventory  : count vs 5-7 consensus band; definitions documented or tribal;
                   forecast-category map present/absent
Per-stage verdict: stage -> exit criterion -> pass/fail verifiability -> severity
Buying-job map   : which Gartner job each stage covers; jobs with no stage; jobs
                   with several stages
Diagnostics      : conversion decay shape, aging outliers, skip/backward rate,
                   close-date push counts, per-rep variance (provenance-tagged)
Findings         : records ordered by Remediation Order, severity carried per
                   record as its value axis (schema in Workflow step 6)
Remediation      : rewritten exit criteria, rungs chosen and rungs struck with the
                   constraint that struck them, deactivate-and-add migration plan,
                   forecast-category re-map, automation/dashboard checklist,
                   training + rollout shape
Measurement      : baseline values captured, post-change KPIs, re-check date
                   (>= one full sales cycle out)

合格基準

• すべてのステージに、買い手の行動を明示し、記録システム内の確認可能なフィールドまたは成果物に紐づく終了基準が少なくとも1つあります。
• 評価者間チェック：マネージャー2人（または独立したレビュアー2人）が、書き換えた基準に基づいて未完了案件を10～20件サンプルとして、相談せずに評価します。案件の90％以上で判定が一致する必要があります。これはユーザー自身のデータからより厳密な基準を導き出すための実務上の目安であり、公表された標準ではありません。不一致があれば、曖昧な基準を特定します。その基準を書き換えて、再度サンプルを評価します。
• ファネル全体で、ステージ間のコンバージョン率が単調に低下するか、意図的な設計による例外（失格を目的とする検証ステージなど）がすべて説明されています。
• オープンパイプラインのステージに、その想定滞在時間から大きく外れた割合の案件が滞留していません。業界の固定値ではなく、パイプライン自体の履歴から想定分布を導き出します。

4つすべてを満たすまで反復します。コンバージョンと分布のチェックを信頼できるものにするには、新しい定義を適用した案件の全営業サイクル分のデータが必要です。まだそのデータがない場合は、成果物にその旨を明記し、ロールアウト後最初のゲートとして再チェックを予定します。

よくある失敗パターン

意図的に順位付けしていません。各行は、1つの問題に対する1つの診断と修正であり、同じ問題に対して複数の修正案を示すものではありません。そのため、効率性の順に並べると、選択肢ではなく読者の症状に順位を付けることになります。当てはまる行はすべて適用してください。

欠陥	結果	修正
ステージ値をその場で改名または削除する	過去のレポートが恒久的に破損し、自動化も気付かれないまま機能しなくなる	古い値を無効化し、新しい値を追加します。マッピングフィールドで対応付けます
予測カテゴリの再マッピングを省略する	ステージ名が正しく見えても、予測の集計値が気付かれないまま歪む	変更後、すべてのステージのマッピングを再確認します
適格性スコアカードを選択リストに組み込む	ステージが買い手の状況を追跡しなくなり、両方の仕組みが劣化する	継続的に更新する適格性フィールドを分けます。ステージは買い手の状況を表します
基準を担当者の活動として記述する	ステージの水増し。楽観的な見込みでステージが進む	すべての基準を買い手の行動から始まる形に書き換えます
基準は書類上確認できても、どこにも記録されない	監査には通るものの、実務では適用できない	各基準を必須フィールドまたは証拠リンクに紐づけます
取引型のパイプラインを案件型パイプラインのルールで評価する	誤った問題が見つかり、摩擦をなくすために構築されたプロセスに摩擦が加わる	まずパイプラインの種類を分類し、プロセスに応じて基準に重み付けします
ステージが約7つを超える、または似通ったステージが多すぎる	隣接するステージを区別できず、基準が曖昧になる	統合します。各ステージには明確な目的が必要です（実務家の総意）
記録率やコンプライアンス率で成功を測定する	担当者の記録量が増え、記録は速くなる一方で質が下がり、データは改善しない	代わりにコンバージョンの安定性と評価者間の一致度を測定します
2週目に修正を評価する	新規案件の全サイクルを経るまでは、コンバージョン指標に意味がない	少なくとも1営業サイクル待ち、30日・60日・90日の定着度チェックポイントを使用します
担当者が初めて実案件で目にする基準を展開する	基準が無視され、ステージデータの品質も変わらない	まずトレーニングを実施し、定期的なパイプラインレビューに終了基準を組み込みます

KPI

• 次の指標を追跡します。ステージ間のコンバージョンの安定性と単調な低下、担当者ごとのコンバージョンのばらつき（主観的な定義を示す最も明確な単一の指標）、ステージ滞在時間の中央値と外れ値の件数、ステージのスキップ率と後戻り率、案件ごとのクローズ予定日の延期回数、定期的な案件サンプルにおける評価者間の一致度、そして少なくとも四半期ごとに、初日の予測値と期間の最終結果との差の絶対値を割合で測定した予測精度です。
• 導入率や記録ルールの遵守率を成功指標として報告してはいけません。これらが測るのは精度ではなく、圧力です。
• 四半期ごとに評価者間のサンプルを再測定します。一致率の低下は、基準が再び主観に流れていることを意味します。

呼び出し例

• 「当社のステージは『Demo Scheduled』『Proposal Sent』『Verbal Commit』ですが、どの案件も何カ月もProposal Sentのままです。ステージ定義を監査してください。」
• 「同じ案件がステージ3に該当するかどうか、2人のマネージャーの意見が一致しません。終了基準を確認して、担当者の活動を別の名前で呼んでいるだけのステージがどれか教えてください。」
• 「当社はPLGからエンタープライズ市場へ進出しており、営業支援付きの案件とセルフサービス登録が同じパイプラインを共有するようになりました。これらのステージを基に予測する前に、ステージに意味があるか監査してください。」

参考資料

• references/verifiability-test.md - テスト、合格および不合格となる表現、Gartnerの購買業務マッピング表、そして否定的な例です。
• references/diagnostic-metrics.md - 各指標の計算方法、危険信号となるパターン、その由来です。
• references/audit-intake.md - 成果物チェックリスト、インタビューガイド、責任者マップです。
• references/remediation-rollout.md - 移行の仕組み、切り替えと比較可能性、トレーニング、任意のベンダー固有の統合に関する注記です。
• references/worked-examples.md - エンタープライズの監査、高速回転型の監査、誤った方法で行われた監査をそれぞれ1件ずつ掲載しています。
• mbfinotti/revops-skills@sales-forecast-diagnostic - 予測全体の信頼性
• mbfinotti/revops-skills@sales-pipeline-hygiene - 定期的な停滞案件の洗い出しと営業パイプラインの衛生管理
• mbfinotti/revops-skills@crm-data-governance - フィールド辞書と選択肢リストのガバナンス
• mbfinotti/revops-skills@revenue-leakage - ステージ間で失われた収益の追跡