パイプライン管理の手法と実践|フェーズ・確度・ネクストアクションを体系的に管理する
四半期末になって「今期の売上着地が読めない」「あと何件詰めれば目標に届くのか分からない」と、月末の駆け込みで受注確度を積み上げている営業マネージャーは少なくありません。あるいは、案件が特定のフェーズで止まっているのに、その原因を数値で説明できず、担当者の勘に頼って対応している状況もよくあります。こうした状態から抜け出すための土台がパイプライン管理です。
この記事では、パイプライン管理とは何かを押さえたうえで、フェーズ・受注確度・ネクストアクションという3つの要素をどう設計・運用すれば、売上予測の精度向上とボトルネックの早期発見につながるのかを、実践手順・失敗の回避策・ExcelとSFAの使い分けまで含めて整理します。
パイプライン管理とは
パイプライン管理とは、進行中の案件をフェーズごとに分けて進捗と量(件数・金額)を可視化し、売上予測とボトルネックの発見に使うマネジメント手法です。リード獲得から受注までの一連の流れを1本の配管(パイプライン)に見立て、どのフェーズにどれだけの案件が滞っているか、どこで案件が抜け落ちているかを俯瞰します。単なる進捗一覧をつくることが目的ではなく、案件の流れを数値で捉えて「次に売上がどう着地するか」を予測できる営業組織をつくることが本質です。
パイプラインとファネルの違い
パイプラインとファネルは近い場面で使われますが、見ているものが異なります。ファネルは、リードから受注に至るまで件数が段階的に絞り込まれていく様子を漏斗の形で捉える考え方で、各段階の通過率(移行率)に注目します。一方のパイプラインは、いま進行中の個々の案件が営業プロセスのどこにあるかという、案件の進行過程そのものに注目します。
ファネルが全体の歩留まりを俯瞰する見方だとすれば、パイプラインは1件1件の案件を追いながら組織全体の売上見込みを組み立てる見方です。両者は排他的ではなく、ファネルの各段階の通過率をパイプライン上のフェーズ移行率として使うことで、予測とボトルネック発見の両方を同じデータで扱えます。
パイプライン管理が経営課題になる理由
パイプライン管理が単なる営業の進捗管理を超えて経営課題になるのは、売上予測の精度と直結するからです。フェーズと確度に基づく予測がなければ、売上着地は担当者やマネージャーの感覚に依存し、期末になるまで読めません。属人化した勘の予測から脱却し、データに基づいて先手を打てるかどうかは、リソース配分や採用計画にも影響します。
売上・利益の最大化は、営業生産性の最大化と言い換えられます。営業生産性は「(商談数 × 受注率 × 単価)÷ 工数」で表せます(出所:Mazrica の営業生産性フレーム)。パイプライン管理は、この式のうち商談数の積み上がり方と受注率(フェーズ間の移行率)を可視化する仕組みであり、どのフェーズで案件が滞留・脱落しているかを特定することで受注率の改善に直接効きます。可視化した数値を改善行動につなげられる点が、経営が投資する価値のあるテーマになっている理由です。
パイプライン管理で得られること
パイプライン管理で得られる価値は、精度の高い売上予測、ボトルネックの早期発見、営業担当の育成につながる案件マネジメントの3点に集約されます。特に大きいのは、感覚のヨミから加重予測への転換です。同じパイプラインを見ても、マネージャーはリソース配分や先手の判断に、担当者は自分の案件の優先順位づけに使えるように、立場によって得られる価値が変わります。ここでは立場別にどう役立つかまで掘り下げます。
売上着地の予測精度が上がる
各フェーズの案件金額に、そのフェーズの受注確度を掛け合わせて合算することで、期末の売上着地を加重予測できます。「商談中の案件がいくつあるか」ではなく「確度で重み付けした期待金額がいくら積み上がっているか」で見るため、感覚のヨミよりぶれが小さくなります。
さらに、予測金額と目標との差分(不足額)が早い段階で見えるため、期末になってから慌てるのではなく、月初や期初の段階で「あと何件・いくら分の案件を前に進める必要があるか」を逆算できます。予測が数字で立つと、営業会議の議論も「達成できそうか」ではなく「不足分をどう埋めるか」に変わります。
ボトルネックを早期に発見できる
どのフェーズに案件が滞留し、どのフェーズで脱落が多いかが数値で見えると、営業プロセスの詰まっている箇所を特定できます。たとえば、初回商談から提案フェーズへの移行率が極端に低ければ、ヒアリングや課題設定の質に問題がある可能性が高いと当たりをつけられます。特定フェーズでの滞留日数が長ければ、そこに承認プロセスや意思決定者への接触の壁がある、といった仮説が立ちます。
勘に頼った改善は、声の大きい失敗事例に引きずられがちです。パイプラインの数値を起点にすれば、組織全体で最も効果の大きい詰まりから優先的に手を打てます。ボトルネックの具体的な見つけ方は、商談フェーズの進捗管理とボトルネックの発見方法で詳しく扱っています。
立場で変わる利点
同じパイプラインでも、マネージャーと担当者では活用の仕方が異なります。マネージャーにとっては、チーム全体の案件分布から「どの担当者のどのフェーズに支援を集中すべきか」というリソース配分の判断材料になり、滞留や脱落の兆候を早めに掴んで先手を打つための道具になります。
担当者にとっては、自分が抱える案件のうち、どれを優先的に動かせば期末の目標に効くかを判断する道具になります。フェーズと期限、次にやるべきことが整理されていれば、対応漏れや放置による失注を防げます。この2つの視点、つまり個別案件を前に進める視点と、どの案件に組織のリソースを寄せるかという全体最適の視点を、1つのパイプライン上で両立できることが利点です。
フェーズ・受注確度・ネクストアクションで管理する
パイプラインを実務で機能させるには、フェーズ(どこまで進んだか)、受注確度(どれだけ受注に近いか)、ネクストアクション(次に何をするか)の3要素で管理することをおすすめします。フェーズと確度だけでは案件の現状は分かっても行動に落ちません。次の一手を必ずセットで持たせることで、可視化がそのまま改善行動に直結します。3要素それぞれの設計を掘り下げる詳細記事は個別に用意しているため、ここでは全体像と要点を押さえます。
フェーズ設計とボトルネックの発見
フェーズは、自社の受注に至る実際の流れをもとに設計します。ここで重要なのは、フェーズ間の移行条件を客観的に定義することです。移行条件が曖昧だと、担当者ごとに「提案中」の意味がずれ、パイプライン上の数値が信用できなくなります。フェーズ移行の条件を統一しておくことで、各フェーズの滞留や移行率が正しく測れるようになり、ボトルネックの発見につながります。
フェーズ設計と移行条件からボトルネックを見つける具体的な進め方は、商談フェーズの進捗管理とボトルネックの発見方法をご覧ください。
受注確度をどう定義するか
受注確度は、担当者の主観的な自信ではなく、フェーズや客観的な行動に紐づけて定義することが精度向上の鍵です。「たぶん受注できそう」という感覚を数値に置き換えるのではなく、「決裁者と接触済みなら○%」「見積提出済みで前向きな反応があれば○%」のように、確度を裏付ける事実と対応づけて設計します。こうすることで、担当者による確度のばらつきが減り、加重した売上予測が現実の着地に近づきます。
確度のスコアリング設計と予測精度の高め方については、受注確度のスコアリングと予測精度の高め方で詳しく解説しています。
ネクストアクションと定例会議での運用
フェーズと確度を数字で監視するだけでは、案件は前に進みません。1件ごとに「次に何を・いつまでにやるか」というネクストアクションを持たせ、それをパイプライン会議で確認・更新する運用が定着の分かれ目になります。パイプライン会議は、進捗を報告し合う場ではなく、滞留している案件に対して次の一手を決め、支援の必要な案件にリソースを寄せる意思決定の場として設計します。
会議の進め方や案件を全員で見える状態にする運用は、パイプライン会議と案件の見える化で詳しく扱っています。
パイプライン管理を実践する手順
パイプライン管理は、営業プロセスの細分化、フェーズごとのゴールと移行条件の定義、追跡するKPIの設定、可視化と分析、継続改善という流れで進めると定着しやすくなります。ポイントは、最初から完璧なフェーズを作り込もうとせず、実際の受注の流れに沿ってシンプルに始め、運用しながら精度を上げることです。各ステップには、細分化しすぎない、移行条件を客観化するといった判断基準があり、ここを外すと形骸化します。
営業プロセスを細分化し、フェーズを定義する
まず、自社が案件を受注するまでに実際にたどる流れを書き出し、それをフェーズに分けます。ここで多くの組織がつまずくのは、フェーズを細かく分けすぎることです。フェーズが多すぎると入力の手間が増え、担当者が更新しなくなり、結局パイプラインが実態を反映しなくなります。まずは3〜5段階程度で、自社の営業の節目に対応するフェーズから始めるのが現実的です。
フェーズ移行条件を明確にする
次に、各フェーズから次のフェーズへ移る条件を、誰が見ても同じ判断になる客観的な基準で定義します。「提案書を提出済み」「決裁者と面談を実施済み」のように、事実として確認できる状態を条件にします。この移行条件が曖昧なままだと、同じ案件でも担当者によって置くフェーズが変わり、パイプライン全体のデータの信頼性が崩れます。フェーズ設計そのものより、この移行条件の統一に時間をかける価値があります。
追跡するKPIを決める
パイプラインを改善につなげるには、監視するKPIを決めておきます。代表的な指標は、フェーズ別の案件数と金額、各フェーズの移行率(CVR)、そして時間軸の指標です。時間軸では、案件が発生してから受注までにかかった期間を示す「案件発生日からのリードタイム」と、特定のフェーズにとどまっている日数を示す「フェーズ滞留日数」を分けて追います。この2つは別の概念で、リードタイムは案件全体のスピード、フェーズ滞留日数は特定の詰まりを表します。滞留日数が基準を超えた案件を早期に拾えれば、放置による失注を防げます。
可視化・分析し、継続的に改善する
設計したフェーズとKPIをもとにパイプラインを可視化し、定例のサイクルで分析・改善を回します。移行率の低いフェーズや滞留の長いフェーズを見つけ、なぜそこで詰まるのかの仮説を立て、フェーズ定義やアプローチを見直します。パイプライン管理は一度設計して終わりではなく、営業プロセスやフェーズ定義自体を運用しながら磨き続ける前提で、更新の責任者と見直しの頻度を決めておくと形骸化を防げます。
よくある失敗と回避策
パイプライン管理でつまずくパターンは、入力が目的化して形骸化する、フェーズ定義が曖昧でデータが信用されない、失注分析が浅く次に活かせない、という3つに大きく分かれます。いずれもツールの問題ではなく運用設計の問題で、設計段階で手を打てば回避できます。ここでは、見落とされがちな注意点も含めて、それぞれの回避策を掘り下げます。
入力が目的化し形骸化する
パイプライン管理が続かない最大の原因は、担当者にとって入力が「マネージャーに報告するための作業」になり、自分の役に立たないと感じられることです。入力させることを目的にすると、更新は後回しになり、データは実態とずれていきます。回避策は、入力そのものを軽くしたうえで、入力した情報が担当者自身の案件優先順位づけや次アクションの整理に返ってくる設計にすることです。
SFA(営業支援システム)のなかには、活動履歴の要約や入力補助といった入力負荷を下げる機能を備えたものがあり、こうしたアシスト機能を活用すると更新が続きやすくなります。ツール選定の観点は後半のセクションで扱います。
フェーズ定義が曖昧でデータが信用されない
フェーズの移行条件が担当者ごとに異なると、パイプライン上の数値は「誰かの主観の集合」になり、予測にもボトルネック分析にも使えなくなります。回避策は、実践手順でも触れたとおり、移行条件を客観的な事実で定義し、チーム全員で共通認識をつくることです。定義を決めるだけでなく、実際の案件をいくつか使って「この案件は今どのフェーズか」を全員で答え合わせすると、認識のずれを早期に埋められます。
失注分析が浅く次の一手が見つからない
失注したときに「価格が合わなかった」「タイミングが悪かった」で終わらせると、パイプラインに失注のデータは溜まっても、次の改善につながりません。失注理由を記録し、競合・価格・タイミング・要件不一致などの型に分類して蓄積することで、どのフェーズのどんな案件が落ちやすいかが見えてきます。
失注の記録と類型化から次の一手を導く進め方は、失注分析とパイプライン改善の進め方で詳しく解説しています。
ExcelとSFAの違いとツールの選び方
パイプライン管理は、案件数が少なく立ち上げ期の段階ならExcelでも始められます。ただし、案件数の増加、リアルタイムでの情報共有、集計や分析の自動化が必要になると、手作業による管理は限界を迎え、SFA(営業支援システム)が適するようになります。判断のポイントは「Excelが使えるかどうか」ではなく、「手作業でどこまで追えるか、その限界がいつ来るか」です。ここでは両者の現実的な範囲と、ツール選定で確認すべき観点を整理します。
Excelで管理する場合の現実的な範囲
Excelは追加コストなく始められ、少人数のチームがフェーズと案件を一覧で管理する程度であれば十分に機能します。表計算やグラフの自由度も高く、自社のフェーズ定義を柔軟に反映できます。
案件数とメンバーが増えてくると、複数人が同時に最新状態を共有すること、更新のたびに集計を自動反映すること、誰がいつ何を変更したかの履歴を残すことが手作業では重くなります。関数や外部連携を使えば拡張の余地はありますが、その仕組みの維持自体が属人化しやすい点には注意が必要です。Excelが機能しなくなるというより、運用の手間が生む成果を上回る地点が来る、という捉え方が実態に近いです。
SFAで管理する場合にできること
SFA/CRMは、パイプライン管理を前提に案件のフェーズ・確度・活動履歴を一元管理し、集計や分析を自動化します(SFAは営業支援システム、CRMは顧客との関係を長期に築くための仕組みで、実務では両者を統合して扱う形が一般的です)。
たとえば Mazrica Sales のようなSFA/CRMでは、案件をフェーズごとにカンバン表示する案件ボードで進捗をひと目で把握でき、各案件カードを直近のアクション状況で色分けして滞留を可視化します(青が1週間以内にアクションあり、黄が1か月以内、赤が1か月以上アクションなし)。滞留した赤い案件を拾えば、放置による失注を防ぎやすくなります。集計面では、売上予測・売上推移・売上実績・ファネル分析・アクション予測・アクション分析・アクション推移・フェーズ進捗という8種の標準レポートが設定不要で使え、フェーズ別の分布や進捗を自動で確認できます。
加えて、蓄積した案件データをもとにAIが受注確度・契約日・受注金額を予測したり、対応すべきリスク案件を提示したりする機能を備えたツールもあります(Mazrica Sales のAIインサイトはこうした予測・リスク提示を行う機能で、Growth以上のプランで利用できます。これらはAIが蓄積データから推定・提示するもので、実際の受注を保証するものではありません)。
ツール選定で確認する観点
ツールを選ぶときは、入力負荷、案件の見える化、既存ツール連携の3つを、原則この順で確認します。まず入力負荷です。どれだけ高機能でも、現場が入力を続けられなければパイプラインは形骸化するため、入力補助や自動連携で更新の手間が下がるかを最優先で見ます。次に案件の見える化で、フェーズ・確度・滞留がひと目で分かる表示や、必要な集計が自動で出るかを確認します。最後に、名刺管理・会計・チャットなど既存で使っているツールと連携し、二重入力を避けられるかを見ます。この順で優先すると、導入後に定着しやすくなります。
まとめ
パイプライン管理は、案件をフェーズで区切って可視化するだけでなく、フェーズ・受注確度・ネクストアクションの3要素で管理し、可視化を次の一手へ接続してはじめて売上予測とボトルネック発見に効きます。案件数が少なく手作業で追える段階なら、まずExcelでフェーズ管理から着手して問題ありません。案件数やメンバーが増え、属人化や集計負荷が課題になってきたら、フェーズ・確度・ネクストアクションを一元管理し集計を自動化できるSFA/CRMへの移行を検討する、という順が現実的です。
最初の一歩は小さくて構いません。自社が受注に至るまでの流れを3〜5段階のフェーズに書き出し、各フェーズの移行条件を「提案書を提出済み」のように1行で客観的に定義してみることから始めてみてください。この移行条件が揃うだけで、パイプラインの数値は一気に信頼できるものに近づきます。
よくある質問
Q パイプライン管理とファネル管理は何が違いますか
ファネル管理は、リードから受注まで件数が段階的に絞り込まれる「歩留まり(通過率)」に注目する考え方です。パイプライン管理は、進行中の個々の案件が営業プロセスのどこにあるかという「案件の進行過程」に注目します。ファネルの各段階の通過率を、パイプライン上のフェーズ移行率として使うと、両者を同じデータで扱えます。
Q フェーズはいくつに分けるのが適切ですか
決まった正解はありませんが、まずは自社の営業の節目に対応する3〜5段階から始めるのが現実的です。フェーズを細かく分けすぎると入力の手間が増えて更新されなくなり、パイプラインが実態を反映しなくなります。運用しながら、分析に必要な粒度に合わせて増減させるのが定着のコツです。
Q 受注確度のパーセンテージはどう決めればよいですか
担当者の主観的な自信ではなく、フェーズや客観的な行動に紐づけて決めると精度が上がります。「決裁者と接触済み」「見積提出済みで前向きな反応がある」といった確認できる事実と確度を対応させると、担当者によるばらつきが減り、加重した売上予測が現実の着地に近づきます。
Q パイプライン会議はどのくらいの頻度で行うべきですか
案件の動くスピードによりますが、週次で開き、滞留している案件と次の一手を確認する運用が多く見られます。会議を進捗報告の場にせず、詰まっている案件への対応を決め、支援が必要な案件にリソースを寄せる意思決定の場として設計することが、頻度以上に重要です。
Q SFAとCRMはどちらを先に導入すべきですか
判断軸は、入力負荷・案件の見える化・既存ツール連携の3つで、原則この順で優先します。日々の入力を続けられ、案件の進捗が見える状態をまず作りたいなら、営業プロセスを前に進める仕組みであるSFAから着手するケースが多くなります。ただし実務では両機能を統合して扱う形が一般的で、統合型なら顧客との関係構築と案件管理を同じデータ上で両立できます。
Q 少人数の営業チームでもパイプライン管理は必要ですか
少人数でも、フェーズと移行条件を決めて案件を並べるだけで、対応漏れの防止と売上見込みの把握に役立ちます。人数が少ないうちはExcelでも十分に始められ、案件数やメンバーが増えて手作業の集計・共有が重くなってきた段階でツール移行を検討する、という進め方が現実的です。







