複数部門が関わる案件では、進捗は一本の線では進みません。
使用部門の評価は完了しているのに、情報システム部門の要件確認は未着手。購買部門とは一度も接点がなく、予算の決裁者は名前すら分からない。この4つが同時に成立している状態は珍しくありません。それでも社内のパイプライン上は「提案中」の1行です。
この状態を管理するために必要なのは、進捗を意思決定単位（部門）ごとに持つことです。具体的には、関係する各部門について次の3つを常に言える状態にします。
- その部門が何を気にしているか
- その部門で何が終わり、何が未解決か
- 次にその部門で満たされる必要がある条件は何か
本記事では、部門単位で進捗を管理する方法と、窓口を一本化したまま進めたときに起きる見落としを整理します。
窓口一本化はなぜ破綻するのか
多くの案件は、1人の担当者との関係から始まります。その担当者が協力的であれば、やり取りは窓口に集約されます。これは礼儀として自然であり、相手の社内調整を尊重する進め方でもあります。
問題は、この形が続いたときに起きることです。
- 情報が要約されて届く。 他部門の懸念は、窓口の理解を経た形で伝わります。「情報システムが難色を示している」という一言の背後にある具体的な要件は、そこで失われます。
- 反論に立ち会えない。 社内で議論が起きた場所に自社がいないため、誤解が生じても訂正できません。
- 進捗が窓口の熱意と同じに見える。 窓口が前向きであることと、承認プロセスが進んでいることは別の事実です。
- 窓口が異動すると案件が消える。 関係が1人に依存している状態では、引き継ぎ先に文脈が残りません。
窓口を飛ばすべき、という話ではありません。窓口を通しながら、他部門の状態を把握する必要があるということです。多くの場合、その経路を作れるのも窓口（推進者）自身です。
意思決定単位ごとに状態を持つ
複数部門が関わる案件では、部門をそれぞれ独立した判断主体として扱います。
※ 以下は考え方を示すための仮想例です。実在の顧客事例ではありません。
案件：中規模病院への医療機器導入（想定サイクル6〜9か月）
| 意思決定単位 | 主な関心事 | 現在の状態 | 未解決の条件 |
|---|---|---|---|
| 臨床／使用部門 | 業務適合、運用負荷、臨床的な有用性 | 実機評価まで完了 | なし（支持側） |
| 情報システム部門 | 院内ネットワーク接続、既存システムとの整合 | 要件確認中 | 接続要件の回答、検証期間の見込み |
| 情報セキュリティ | 院内基準への適合 | 未接触 | 担当者が未特定 |
| 購買部門 | 価格、契約条件、保守体制 | 見積提出済み、他社2社と比較中 | 保守条件の説明 |
| 経理／財務 | 予算枠、支出時期 | 未接触 | 次年度予算での扱いが未確認 |
| 経営層 | 導入の優先度、戦略適合 | 未接触 | 決裁者が未特定 |
同じ案件の中に、完了・進行中・未接触・特定不能という4種類の状態が同時に存在しています。
ここで重要なのは、臨床部門の評価完了が案件全体の進捗を意味しないという点です。使用部門の支持は必要条件ですが、十分条件ではありません。この案件が実際に前進するかどうかは、いま未接触の3部門で何が起きるかに依存しています。
なお、どの部門の誰が実質的な影響力を持つかを見極める手順は、本記事の範囲を超えます。++関係者マッピングの考え方++ で扱います。
部門ごとのステータスを4段階で持つ
運用上は、細かい進捗率より粗い4段階の方が機能します。判断が速く、更新が続くためです。
| 段階 | 定義 | この段階でやること |
|---|---|---|
| ① 未接触 | 関与する可能性があるが、接点がない | 推進者経由で担当者を特定する |
| ② 接触済み・要件未確認 | 担当者は分かったが、判断基準が不明 | 何を確認する部門なのか、何が必要かを聞く |
| ③ 要件確認中 | 判断基準が分かり、対応が進行中 | 必要な情報を提供し、所要期間を合意する |
| ④ 条件充足 | その部門としての判断が完了 | 完了した事実と時期を記録する |
この4段階を使うと、案件の状態が一文で言えるようになります。
「臨床は④、情報システムは③、セキュリティと経理と経営は①。ボトルネックはセキュリティ担当者の未特定」
対して、ステージ表示だけで管理している場合、同じ案件の説明は「提案中、感触は良好」で止まります。説明の粒度が、そのまま次の行動の粒度になります。
「未接触」を空欄にしない
運用上の要点は、関与する可能性がある部門を、接触前から一覧に並べておくことです。
接触した部門だけを記録すると、一覧は常に「順調」に見えます。関与するはずの部門が最初から並んでいて、そこが①のまま何週間も動いていないと分かる状態にしておくことが、見落としを防ぎます。
部門ごとに、渡す情報を変える
複数部門が関わる案件で効率が落ちる典型は、同じ資料を全員に送ることです。
各部門が判断に使う材料は異なります。
| 部門 | 求めている情報 | 送っても判断に使われない情報 |
|---|---|---|
| 使用部門 | 業務フローへの適合、操作負荷、教育の必要性 | 契約条件、システム構成図 |
| 情報システム | 接続要件、構成、既存環境との整合 | 臨床的な有用性の説明 |
| 情報セキュリティ | 基準への適合可否、確認項目 | 価格、導入効果 |
| 購買 | 価格根拠、保守条件、納期 | 技術仕様の詳細 |
| 経理・経営 | 費用規模、支出時期、優先度の根拠 | 製品機能の一覧 |
汎用の提案書一式を全部門に配ると、各部門は自分に関係する部分を探す作業から始めることになります。これは相手の負担を増やし、確認の所要期間を延ばします。
同時に、推進者が社内で説明するときに使える形になっているかも確認します。多くの案件で、他部門への説明を実際に行うのは営業ではなく推進者です。推進者がそのまま転送・引用できる形の資料は、承認プロセスの摩擦を減らします。
ステージ「提案中」の内訳を言えるか
複数部門が関わる案件の管理が難しいのは、進捗の見え方が実態から乖離しやすいためです。
| 見え方 | 実際の内訳 |
|---|---|
| 提案中・感触良好 | 使用部門④／他5部門は①か② |
| 検討中 | 情報システムの要件確認待ち（所要期間の合意なし） |
| 最終確認中 | 推進者が社内申請を準備中、決裁者は未特定 |
内訳が言えない場合、それは案件が進んでいないのではなく、状態が見えていない状態です。この2つは対処が異なります。前者は行動の問題、後者は情報収集の問題です。
停滞の原因をどう切り分けるかは ++商談が進まない理由の見つけ方++ で扱っています。
接点を広げるときの実務
未接触の部門に接点を作るとき、多くの案件では推進者の協力が必要になります。実務上、次の形が受け入れられやすい傾向があります。
- 目的を限定して依頼する。 「情報システムのご担当者を紹介してください」ではなく「接続要件の確認項目をお送りしたいので、どなたにお送りすればよいか教えてください」。相手の負担が具体的に小さくなります。
- 推進者の立場を守る。 紹介された部門とのやり取りを推進者に共有する運用にしておくと、推進者が社内で情報を把握していない状態を避けられます。
- 先回りして負担を減らす。 確認項目リスト、技術資料、比較表など、相手部門が作るはずの作業を代わりに用意します。
- 記録は商談単位でまとめる。 部門ごとに別のメモを持つと全体像が失われます。1つの商談に、複数部門の接点が時系列で並んでいる状態を保ちます。記録の方法は ++商談履歴の残し方++ を参照してください。
よくある失敗
① 支持者の数を進捗と考える 賛成している人が増えても、承認プロセスは進みません。支持は必要ですが、条件の充足とは別に数えます。
② 反対されていない部門を「問題なし」と扱う 未接触の部門は、賛成でも反対でもありません。判断していない状態です。空欄を「問題なし」と読むと、承認直前に要件が出てきます。
③ 部門ごとの進捗を、人の名前で管理する 担当者は異動します。部門と役割で管理し、担当者名はその属性として持つ形にしておくと、人事異動で案件の文脈が消えません。
複数部門の状態を、1つの商談として見る ― VINEQRA の考え方
VINEQRA は、複数の関係者が関わる長期案件を担当する営業担当者個人のために設計された iOS 向けの AI CRM です。設計上の前提は、商談の進捗は1つのステージではなく、複数の判断主体の状態の集合であるという点にあります。
商談の文脈は次の構造で捉えます。
顧客接点 ＋ 関係者 ＋ 意思決定ポイント ＋ 阻害要因 → 次に取るべき行動（Next Best Action）
（VINEQRA Opportunity Context Model）
複数部門の管理に関係するのは、記録された顧客接点を関係者・部門と結びつけて保持し、接点の記録が存在しない部門や、未解決のまま残っている条件を手がかりとして提示できる点です。
[Product Screenshot: Stakeholder Role Information] （関係者ごとの役割・所属部門・関心事が記録されている状態）
対応する AI 分析は、Apple Foundation Models を通じて端末内のシステム言語モデルで実行できます。
そして、前提となる原則があります。
VINEQRA は提案します。判断するのは営業担当者です。
提示されるのは候補であり、その部門が実際にどう動くかを予測するものではありません。
よくある質問
Q. 関係部門は、どこまで洗い出せばいいですか？ 承認または実行に関与する可能性がある部門をすべて並べます。過剰に並べても害はありません。①未接触のまま残った部門が、そのまま確認すべき項目になります。
Q. 窓口担当者に「他部門に直接連絡してよいか」と聞くべきですか？ 聞き方次第です。紹介を求める形（誰に何を送ればよいか）は受け入れられやすく、直接交渉の許可を求める形は警戒を招きやすい傾向があります。目的を限定して依頼するのが実務的です。
Q. 相手企業の組織構造が分からない場合は？ 推測で図を作る前に、記録に登場した人物と部門から確認します。分からない部分は「不明」として残し、次の接点で確認する項目にします。空欄のまま進めるより、不明と明示する方が安全です。
Q. 部門が多すぎて管理しきれない場合、どこから手をつけますか？ 現在の前進を止めている部門からです。すべての部門を同じ頻度で追う必要はありません。①未接触のうち、次の条件充足に必要な部門を優先します。
Q. 意思決定単位ごとの管理は、社内の CRM でもできますか？ 部門や役割を記録できる CRM は多くあります。差が出るのは、記録された内容から「接点のない部門」「未解決のまま残っている条件」を継続的に把握できるかどうかです。多くの場合、不足しているのは入力欄ではなく運用です。
進捗を、部門単位で説明できる状態に
複数部門が関わる案件で必要なのは、関係者全員と等しく接触することではありません。どの部門で何が終わり、何が未解決なのかを常に言える状態を保つことです。
VINEQRA は、複数部門の関係者と顧客接点を1つの商談として保持し、未解決のまま残っている条件を手がかりとして提示します。
関係部門ごとの状態を、1つの商談で把握する。 → VINEQRAをApp Storeでダウンロード