2025年10月29日·1 分
創業者向け：正直で使えるB2Bセールスパイプライン設計
B2B創業者向けのセールスパイプライン設計：明確に予測し、CRM肥大化を避けつつ案件を前に進めるための最小フィールド、ステージ、活動追跡。
B2B創業者向けのセールスパイプライン設計：明確に予測し、CRM肥大化を避けつつ案件を前に進めるための最小フィールド、ステージ、活動追跡。
最初は案件が少なく、ほとんどの文脈があなたの頭にあるのでパイプラインは明快に見えます。ところがリストが増え、フォローアップを逃し始めると、パイプラインは現実よりも都合のいい話を語り始めます。これが「パイプラインの嘘」です：意図的ではなく、システムに真実を強制する仕組みがないために起きます。
同じパターンで現れます：
よくある反応はCRMを過剰に作り込むことです：フィールドが増え、カスタムステージが増え、ノートが長くなる。皮肉なことに、それは通常予測を悪化させます。更新が重く感じられると、人は更新しなくなり、パイプラインは静かに腐ります。
最小限の有効なセールスパイプラインスキーマは逆のことをします。決定を下すのに十分な構造だけを提供し、すべてを捕らえようとはしません。自分を騙さないための少数の事実を記録します。
もし一つだけルールを使うなら、これにしてください：オープンな案件には必ず（1）明確な次のアクション、（2）そのアクションの日付、（3）ミーティングや法務手続き、予算レビューのような実際の買い手のタイムラインに結びついたクローズ日、の3つが必要です。これらのどれかが欠けているなら、その案件はアクティブではありません。
ステージにも意味があるべきです。案件は「気分が良いから」進むのではなく、具体的な出来事が起きたときだけ前に進めます。目的は美しいダッシュボードではなく、事業運営に使える正直なビューです。
パイプラインスキーマは、全員が同じ方法で扱うときだけ機能します。フィールドを追加したりステージを議論する前に、1つのパイプライン項目が何を表すかを決めてください。
B2Bのクリーンなデフォルトは：1つの案件は1つの購買決定を表す、です。同じ会社が2回買う可能性がある（2つのチーム、2つのプロダクト、2つの予算）なら、それは2つの案件であり、1つの混乱した記録ではありません。
オブジェクトはシンプルに保ちましょう。リード（連絡可能な個人）、アカウント（会社）、案件（あなたがクローズしようとしている具体的な購入）の3つで十分です。もし一人でやっているなら、正式なリードやアカウントを飛ばしても構いません。各案件に会社名と主要連絡先が明記されていれば良いのです。
誰かがあなた以外にパイプラインに触るなら、いくつかの運用ルールを書き出してください：
例：あなたはNorthwindのAlexとファイナンスチーム向けのパイロットについて話しました。それは1つの案件です。1か月後にプロダクトが別契約を望むなら、別の案件を作ってください。1つの記録で2つの決定を無理に扱わないでください。
パイプラインは、各案件が毎週チェックする少数のフィールドを持っていると有用に保てます。「念のため」のフィールドを追加すると装飾になってしまいます。
重複を防ぐ案件名フォーマットから始めましょう。簡単なパターンが機能します：会社 - 製品/範囲 - 四半期/月。例：「Acme - Team plan - Mar 2026」。これで「Acme - Demo」と「Acme - Follow-up」が同じ案件かどうかが明らかになります。
各案件には明確な識別情報も必要です：
役割は次に何をするかを変えます。チャンピオンには支援が必要ですし、意思決定者にはビジネスケースが必要です。
説明責任のフィールドを追加します：
その後、実際に使う金額とタイミングだけを加えます：
迷うフィールドがあるなら、入れないでおきましょう。後で追加できますが、習慣ができてからフィールドを削るのはずっと難しいです。
多くの「大きな」パイプラインは実は大きくありません。見栄えはいいが成約への道筋がない案件で満たされています。
まず明確さを強制する1つのフィールドから始めてください：ユースケース（範囲）。買い手が何を達成しようとしているかを平易な言葉で書き、何が「完了」なのかを示します。2文で結果を説明できなければ、その案件はまだ理解が足りない可能性が高いです。
次に、意思決定プロセスを1か所にまとめます。これは連絡先の羅列ではなく、誰がサインし得るか、誰がブロックできるか、どんなステップが必要か（セキュリティレビュー、法務、調達）という物語です。サイナーがわからないなら、その案件は早期として扱ってください。
粗いでも良いので価格適合のシグナルを入れてください。レンジ（"< $5k", "$5-25k", ">$25k"）や Likely / Unclear / Unlikely といった分類で十分です。目的は、価格的にあなたに合わない案件を先に進めるのを止めることです。
最後に、レッドフラグ欄を1行に抑えましょう。段落が必要ならノートに書きます。
多くのB2B創業者に有効なコンパクトなセット：
例：「契約更新前にCRMの整理を希望、サイナーはVP Sales、セキュリティレビュー必要、予算は概ね $10-20k、競合は現状維持、レッドフラグ：チャンピオンがプロジェクトを所有していない。」この1件で自分を騙しにくくなります。
パイプラインが望みのリストになるのは、活動が見えなくなるときです。解決策はフィールドを増やすことではなく、各案件に次に何が起きるか答えさせる活動シグナルを数個加えることです。
もしパイプラインスキーマに1つだけ層を追加するなら、次の活動フィールドにしてください：
実用的なルール：案件に次ステップか期限がなければ、それは本当の案件ではありません。保留するかクローズしてください。これはどんなスコアリングモデルよりも予測精度に寄与します。
「失注理由」は短くして使いやすくします：価格、予算なし、意思決定なし、競合に負けた、タイミング、フィットしない、など。
例：火曜日にオプスリードとデモがありました。通話直後に最終活動日＝火曜日、最終接触チャネル＝ミーティング、次ステップ＝「ケーススタディ2件を送付してサイナーを確認」、次ステップ期限＝木曜日、と設定します。木曜日に返信がなければ、その案件は誰も「進捗した」と主張する余地なくレッドになります。
良いステージモデルは1つの仕事をします：各案件がどこにいるかを事実で伝え、たくさんの細かいステップを管理する必要をなくすこと。ステージごとに何が真実であるべきか言えないなら、そのステージは感覚に陥ります。
以下の6ステージは多くのB2B創業者に有効です：
New（新規）：名前があり、連絡する理由がある。最初の接触が行われたか予定されている。
Qualified（適格）：基本的な適合が確認されている。問題は実在し、顧客がICPに合い、購入の道筋がありそうである。
Discovery done（ディスカバリー完了）：実際の会話があり、ユースケース、成功基準、関与者を理解している。
Proposal sent（提案送付）：価格と範囲を顧客に渡した。次ステップが予約されるか明示的に要求されている。
Negotiation/Legal（交渉／法務）：調達、セキュリティ、予算承認、契約修正が進んでいる。
Closed won / Closed lost（成約／失注）：結果が記録され、理由がキャプチャされている。
何も現実で起きていなければステージは進めないでください（ミーティング完了、提案送付、法務開始など）。
ステージ名はステージ定義ではありません。「Qualified」や「Negotiation」とラベルを付けるだけだと、何が完了か合意できず、その列に案件が停滞します。
ステージルールは真／偽チェックのように書いてください。ステージ内の案件が同じ事実を共有していれば、パイプラインは信頼できるものになります。
エントリ基準は案件がステージに入る前に満たすべき事実を示し、退出基準は次に進む前に何が変わるべきかを示します。両方とも短く測定可能にしてください。
例：
「良い」「強い」「興味あり」のような語が出ないように基準を書けないなら、そのステージはあいまいすぎます。
各ステージに最大滞在日を設定し、早期警告に使ってください（罰則ではありません）。例：Discovery は最大14日、Proposal は最大21日。リミットに達したらリセットをトリガー：次ステップを入れる、戻す、またはクローズするなど。
基準が満たされないときのデフォルトアクションを決めておきます：
これにより「ゾンビ案件」が予測を水増しするのを防げます。
スキーマは小さなプロダクトのように扱えば数時間で作れます：まずルール、その後ルールを支える最低限だけを作ります。
ツールの中ではなく白紙から始めてください。ステージとエントリ／退出基準をプレーンな英語（またはチームの共通言語）で書き出します。1文で説明できないステージは恐らく2つに分けるか不要です。
シンプルな構築フロー：
セットアップ中に現実的なテストを1つ行ってください：今動かしている案件を取り、ステージごとに動かしてみる。もし推測ばかりしているなら、基準があいまいすぎます。
早めに強制すべきルール：次活動日が空なら、その案件はアクティブステージに留まれません。
多くのCRM肥大化は善意から始まります：正確にしたいのでフィールドやステージ、ノートを増やす。しかし結果は逆です。人は更新を止め、パイプラインは年を取る場所になります。
2つのステージが同じように感じられるなら、両方とも同じように使われます。「Discovery」「Deep discovery」「Discovery follow-up」はしばしば「話しただけ」を意味します。ステージは実際に何かが変わるときだけ変わるべきです。
簡単なテスト：ステージに入るために何が真でなければならないかを1文で言えないなら、そのステージは余分です。
クローズ日は理由に結びついているときだけ有用です。それを予算承認日、調達会議、署名締切など次の決定点の日と見なしてください。そのイベントが動いたら日付を動かします。
長いノートは必要な1つのことを隠します：最後に何が起きたかと次に何が起きるか。ノートは短くし、活動は最終活動日＋次ステップ（担当と期限付き）で追跡してください。
定義がなければ「適格」は「感じがよかった」に変わります。3〜4のチェック（問題、買い手、タイムライン、予算の何らか）が満たされている必要があります。1つでも欠けているなら、まだ適格ではありません。
案件が増え続けるパイプラインは墓場になります。案件が非アクティブかフィットしないなら速やかに失注にして、学びのために1つの明確な理由を記録してください。
毎週同じ時間（30分で十分）を決めて、将来の自分とのミーティングのように扱ってください。パイプライン衛生はフィールドを増やすことではなく、各案件に現実的な道筋がまだあるか確認することです。
シンプルなレビューの流れ：
具体例：案件が「Proposal sent」になっているが、それをレビューするミーティングが予約されていないなら、それは提案ステージではありません。戻して次ステップを設定し、買い手が再び関与するまでカウントを止めます。
あなたはB2Bの分析ツールを50人規模のeコマース会社に売っています。初回通話直後に案件を作り、次週に使うものだけを記入します。シンプルなスキーマは書類作りではなく明確さを強制するので効果的です。
通話直後のレコードは次のようになります：
案件はDiscoveryに入ります。カレンダー招待が受諾されたときだけ前に進めます（誰かが「興味ありそう」と言っただけではない）。デモ後、評価段階に進むトリガーは具体的な要求（例：「Shopifyと倉庫データに接続できますか？」）と合意された技術チェックです。
停滞例：価格提示後にCFOが沈黙した。ログには2回のフォローアップ、返信なし、次ステップ日が過ぎている。ルールは簡単です：合意された次ステップがなければ、その案件はProposalに留まれません。
誠実な判断をします：必要なら評価に戻す（新しいスポンサーや情報が必要な場合）、あるいは設定した期限までに意思決定者が関与しなければ失注にする。この例では戻してステークホルダーを更新（Opsがファイナンスマネージャーを巻き込む）、新しい次ステップ日を設定し、CFOが意思決定ミーティングを確認したときだけProposalに戻します。
スキーマが機能するのは人が信頼できるようになったときです。一番速い道は最小限で始めて30日間運用することです。そうすると実際に使うものが見えてきます。
最初の1か月は厳格に：フィールドが決定を変えないなら削除する。ある決定が繰り返し出てきてパイプラインから答えられないなら、そのギャップを埋めるために正確に1つだけフィールドを追加します。
新しいフィールドを追加する前のシンプルなテスト：「これが空白なら、私たちは ___ するかどうか決められないか？」
もし汎用的なCRMに無理やり合わせるのではなく、軽量でカスタムなCRMを作りたいなら、Koder.ai（koder.ai）のようなツールは、ステージ、必須フィールド、バリデーションルールを書いた後に役立ちます。一度スキーマが明確なら、シンプルなアプリを生成して反復するのはずっと簡単です。
パイプラインが「嘘をつく」とは、進捗が買い手の実際の行動で裏付けられていない状態を指します。もっとも多い原因は、次のアクションが不明確、最終アクティビティ日が古い、買い手が同意していないのにクローズ日だけ先送りにされる、などです。
開いている案件には必ず3つの欄を必須にしてください：具体的な次のアクション、そのアクションの期限、そしてミーティングやレビュー、署名など買い手のイベントに紐づいたクローズ日。どれかが空欄なら、その案件は非アクティブとして扱います。
基本は「1案件＝1購買決定」です。同じ企業が異なるチームや予算で別々に買う可能性があるなら、別案件を作成してください。1つの記録に複数のタイムラインや利害関係者を混ぜると混乱します。
重複を防ぐ命名規則、会社、主要連絡先、所有者、期待金額、目標クローズ日、明確なソースから始めてください。さらに、なぜ成約するのかを説明するための簡単な絞り込み情報（ユースケース、意思決定プロセス、価格適合）を加えます。
1文のユースケースと成功基準は、買い手が何を達成したいかを理解させます。結果を明確に説明できないなら、その案件は予測に値するほど成熟していないことが多いです。
意思決定プロセスは、誰がサインするか、誰が差し止められるか、セキュリティや法務、調達などどんなステップが必要かを短い物語で書きます。まだサイナーがわからないなら、その案件は早期段階として扱い、次のアクションでその人物を見つけることに集中します。
細かい予算数字を増やす代わりに、大まかなレンジや Likely/Unclear/Unlikely のような簡単な指標を使ってください。目的は完璧な計算ではなく、予算的に合わない案件を先に進めないことです。
週ごとに重要なのは、最終アクティビティ日、次のステップ、次ステップの期限、そして案件終了時の理由（クローズ理由）を追うことです。ノートは残してよいですが、これらの活動フィールドが案件の流れを止めないために重要です。
ステージを変えるのは、ディスカバリー通話が完了した、提案が実際に送られた、法務が関与した、など「実際に何が起きたか」のときだけにしてください。感覚で動くとステージ定義が曖昧になり、予測がずれていきます。
各ステージに最大滞在日数を設定し、リミットに達したらリセットをトリガーします。通常のアクションは、実際の次ステップを予約する、事実に合う前のステージに戻す、または明確なフォローアップ規則に従ってクローズ（No decision）にすることです。