連絡先と関係者は同じではありません。
名刺交換をして、定期的に連絡が取れている相手が、意思決定にまったく関与していないことがあります。逆に、一度も会っていない人物が承認を左右することもあります。
そして、探すべきは「キーパーソン1人」ではありません。複数部門が関わる案件では、役割の違う複数の人物が、それぞれ別の条件を握っています。整理すべきは次の5項目です。
| 項目 | 問い |
|---|---|
| 役割 | この案件で何を担っているか |
| 関心事 | 何を基準に判断するか |
| 影響力 | 進める力と止める力のどちらを、どの程度持つか |
| 現在の状態 | その人（部門）で何が終わり、何が未解決か |
| 未解決の要件 | 前進するために、この人に対して何が必要か |
本記事では、この5項目の使い方と、影響力を誤読しやすい3つのパターンを整理します。
連絡先と関係者の違い
営業が持っている情報は、多くの場合「接触した人のリスト」です。関係者マップは「案件を動かす条件を握っている人の構造」です。この2つは重なりますが、一致しません。
| 連絡先リスト | 関係者マップ | |
|---|---|---|
| 載る基準 | 接触したかどうか | 案件の条件に関与するかどうか |
| 未接触の人物 | 載らない | 載る（役割不明として） |
| 情報の中身 | 氏名、部署、連絡先 | 役割、関心事、影響力、状態、未解決要件 |
| 更新の契機 | 名刺交換 | 局面の変化 |
決定的な違いは、未接触の人物が載るかどうかです。
接触した人だけを並べたリストは、常に「網羅できている」ように見えます。承認に必要な部門の担当者が一度も出てこないという事実は、接触した人のリストからは見えません。
関係者マッピングの5項目
① 役割 ― この案件で何を担っているか
役職ではなく、この案件における機能で分類します。同じ部長職でも、案件によって役割は変わります。
| 役割 | 担っていること |
|---|---|
| 推進者 | 社内で案件を進める人。起案・調整・他部門への説明を行う |
| 実務評価者 | 実際に使う、または技術的に検証する人 |
| 承認者 | 特定の条件について可否を判断する立場（技術承認、予算承認など） |
| 影響者 | 決裁権はないが、意見が判断に反映される人 |
1人が複数の役割を持つこともあります。重要なのは、役割が不明な人物を「不明」と記録することです。空欄にすると、その人は存在しないものとして扱われます。
なお、組織としての意思決定単位（DMU）をどう構造化するかは、++意思決定単位の捉え方++ で扱います。本記事は個々の人物の整理に焦点を置きます。
② 関心事 ― 何を基準に判断するか
同じ提案でも、判断基準は立場によって異なります。
- 使用部門：業務が回るか、教育負荷はどうか
- 情報システム：既存環境と整合するか、運用負荷が増えないか
- 情報セキュリティ：社内基準を満たすか
- 購買：価格の妥当性、契約条件、保守体制
- 経理・経営：支出時期、投資の優先度
記録する際は、推測ではなく発言として出たものを優先します。「セキュリティを気にしているはず」と「セキュリティ基準への適合確認が必要と述べた」では、情報としての価値がまったく違います。
③ 影響力 ― 賛否とは別に評価する
ここが最も誤読されやすい項目です。影響力は、賛成しているかどうかとは無関係に評価します。
| 影響力の種類 | 意味 | 例 |
|---|---|---|
| 進める力 | 案件を前進させられる | 起案できる、予算を確保できる、他部門を動かせる |
| 止める力 | 案件を止められる | 技術要件で不可と判断できる、基準不適合と結論できる |
| 限定的 | 意見は反映されるが、単独では動かない | 使用部門の一担当者 |
日本の組織では、進める力は持たないが止める力は持つ部門が案件を左右することがよくあります。情報セキュリティ部門や法務部門が典型です。これらの部門は積極的に推進する立場にないため、賛成者としては現れません。しかし要件を満たさないと判断すれば、そこで案件は止まります。
「賛成してくれている人が多いから順調」という読み方が危険なのは、この非対称性のためです。
④ 現在の状態 ― 何が終わり、何が未解決か
人物ごとに、次の3つを持ちます。
- 直近の接点はいつ、どのような内容だったか
- その人（部門）として完了した判断は何か
- 未解決のまま残っている確認事項は何か
未接触の人物については「未接触」と明記します。部門単位での進捗運用の方法は ++複数部門が関わる商談の進め方++ で扱っています。
⑤ 未解決の要件 ― この人に対して何が必要か
最後に、その人が判断を下すために足りていないものを書きます。
- 判断材料が足りない（比較軸、運用負荷の見積、他社事例）
- 前提が終わっていない（他部門の確認待ち）
- そもそも接触できていない（紹介が必要）
この欄が埋まると、関係者マップはそのまま行動の候補一覧になります。行動の選び方は ++商談の次のアクションを決める5つの問い++ を参照してください。
関係者マップの例
※ 以下は考え方を示すための仮想例です。実在の顧客事例ではありません。
案件：中堅小売業への業務ソフトウェア導入（提案から3か月）
| 人物・部門 | 役割 | 関心事 | 影響力 | 状態 | 未解決の要件 |
|---|---|---|---|---|---|
| 営業企画部 課長 | 推進者 | 現場の業務改善、導入効果の説明 | 進める力（起案者） | 継続的に接触、支持側 | 社内説明用の費用対効果資料 |
| 店舗運営部 担当者2名 | 実務評価者 | 操作負荷、教育コスト | 限定的 | 試用済み、おおむね肯定的 | なし |
| 情報システム部 担当者 | 承認者（技術） | 既存基幹システムとの連携 | 止める力 | 連携仕様を確認中 | 仕様回答、検証期間の合意 |
| 情報システム部 部長 | 承認者（技術） | 運用体制、保守負荷 | 止める力 | 未接触 | 担当者経由で意向を確認 |
| 経営企画 | 影響者 | 全社の投資優先度 | 不明 | 未接触 | 関与の有無が未確認 |
| 役員（決裁者） | 承認者（予算） | 投資規模、時期 | 進める力・止める力 | 未特定 | 誰が決裁するかの確認 |
このマップから読み取れることは明確です。
- 支持している人は複数いるが、いずれも止める力を持つ立場ではない
- 止める力を持つ情報システム部については、担当者とは接触しているが部長とは接触していない
- 予算の決裁者が3か月経っても特定できていない
推進者との関係は良好で、実務評価も肯定的です。それでもこの案件は、承認の経路が見えていない状態です。
影響力を誤読する3つのパターン
① 役職を影響力と同一視する
役職が高い人物が、その案件に関心を持っているとは限りません。逆に、役職は高くない技術担当者が、要件の可否を実質的に決めていることがあります。影響力はその案件のどの条件を握っているかで判断します。
② 熱意を影響力と同一視する
最も熱心に対応してくれる相手が、最も影響力を持つ相手とは限りません。熱意は貴重な資産ですが、それは推進者としての価値であり、承認権限の代わりにはなりません。推進者を大事にしつつ、承認の経路を別途確認する必要があります。
③ 発言量を影響力と同一視する
会議で最も発言する人が意思決定者とは限りません。日本の会議では、決裁権を持つ人物ほど発言を控える場合があります。誰が発言したかより、誰の発言の後に議論が収束したかを記録すると精度が上がります。
見えていない関係者をどう見つけるか
関係者マップの価値は、載っている人ではなく、載っていない人に気づけることにあります。実務上の手がかりは次の通りです。
「社内で確認します」の宛先を聞く この発言は、確認先の存在を示しています。「どちらの部門にご確認いただくことになりますか」と聞くだけで、未知の部門が1つ見つかります。
代弁されている意見を追う 「情報システムが難色を示している」という伝聞は、その部門に判断者がいることを意味します。伝聞のまま扱わず、出所を特定します。
社内申請の経路を確認する 稟議・決裁の経路を尋ねることは、多くの場合失礼にあたりません。「起案から決裁まで、どのような流れになりますか」という質問は、推進者にとっても自分の作業を整理する助けになります。
過去の類似導入を聞く 「前回同様のシステムを導入されたときは、どちらの部門が関わられましたか」という質問は、組織の構造を推測ではなく事実として得る方法です。
接点の記録から欠けている部門を探す これが最も確実です。関与するはずの部門を先に並べておき、顧客接点の記録に一度も登場しない部門を洗い出します。記録の残し方は ++商談履歴の残し方++ を参照してください。
マップは図ではなく、更新されるもの
関係者マップを一度作って終わりにすると、数週間で実態から乖離します。更新すべき契機は次のような場面です。
- 新しい人物が会話に登場したとき
- 役割が判明したとき、または変わったとき
- ある部門の判断が完了したとき
- 局面が変わったとき（評価 → 技術確認 → 条件交渉 → 承認）
局面が変われば、重要な人物も入れ替わります。技術確認の段階で使用部門との関係を深めても、前進には直結しません。マップは案件の現在地とセットで読むものです。
関係者の情報を、商談の文脈とともに保持する ― VINEQRA の考え方
VINEQRA は、複数の関係者が関わる長期案件を担当する営業担当者個人のために設計された iOS 向けの AI CRM です。設計上の前提は、関係者の情報は連絡先の属性ではなく、商談の文脈の一部であるという点にあります。
商談の文脈は次の構造で捉えます。
顧客接点 ＋ 関係者 ＋ 意思決定ポイント ＋ 阻害要因 → 次に取るべき行動（Next Best Action）
（VINEQRA Opportunity Context Model）
関係者マッピングに関係するのは、記録された顧客接点と関係者情報を結びつけて保持し、接点の記録が存在しない関係者や、未解決のまま残っている要件を手がかりとして提示できる点です。
対応する AI 分析は、Apple Foundation Models を通じて端末内のシステム言語モデルで実行できます。
そして、前提となる原則があります。
VINEQRA は提案します。判断するのは営業担当者です。
影響力の評価は、その場にいた担当者の観察に基づく判断です。記録に残っていない空気や力関係を知っているのは担当者本人です。
よくある質問
Q. 関係者は何人まで整理すべきですか？ 人数の上限はありません。基準は「案件の条件に関与するか」です。関与する可能性があるなら、未接触でも並べます。実務上は5〜10名程度になることが多く、それを超える場合は部門単位でまとめる方が管理しやすくなります。
Q. 影響力はどう評価すればいいですか？推測になりませんか？ 推測になります。だからこそ、推測であることを記録に残します。「止める力を持つと思われる（根拠：前回の会議で技術要件について結論を述べた）」という形で根拠とセットにしておけば、後から検証も修正もできます。
Q. 相手企業の組織図は入手すべきですか？ 入手できるなら有用ですが、必須ではありません。組織図は指揮命令系統を示すもので、その案件の意思決定経路とは一致しません。実際の経路は、接点の記録から組み立てる方が正確です。
Q. 推進者に他部門のことを聞くと、警戒されませんか？ 目的の伝え方によります。「どなたが決裁されますか」と権限を尋ねる形より、「どの部門にどのような資料をお出しすればスムーズですか」と相手の作業を減らす形の方が受け入れられやすい傾向があります。
Q. キーパーソンが1人に絞れない場合は？ 絞る必要はありません。複数部門が関わる案件では、条件ごとに握っている人が違うのが通常です。1人に絞ろうとすると、その人が握っていない条件が見えなくなります。
「誰が案件を動かすか」を、構造として持つ
案件が決まらない理由が関係構築の不足に見えるとき、実際には承認の経路が見えていないだけであることがあります。関係者を5項目で整理すると、接触の量ではなく構造の欠落として問題が見えるようになります。
VINEQRA は、関係者の役割と関心事を顧客接点の記録とともに保持し、接点のない関係者や未解決の要件を手がかりとして提示します。
案件の背後にいる人を整理する。 → VINEQRAをApp Storeでダウンロード