大企業や企業グループの案件では、連絡先・関係者・部門・意思決定単位は、それぞれ別のものです。混同したまま案件を管理すると、名刺は十分に集まっているのに決裁の流れがまったく見えない、という状態になります。
まず定義を整理します。
| 概念 | 定義 | 例 |
|---|---|---|
| 連絡先 | 接触した個人 | 名刺交換した現場担当者 |
| 関係者 | 案件の条件に関与する個人 | 技術要件の可否を判断する担当者 |
| 部門 | 組織図上の単位 | 情報システム部 |
| 意思決定単位（DMU） | ある条件について判断を下す主体 | 情報システム部の要件審査（部門内の一機能） |
| 購買に関与する部門の集合 | 1つの案件で判断に関わる単位の全体 | 使用部門＋情報システム＋購買＋経営 |
| 決定ノード | ある単位が満たす必要のある条件 | 「セキュリティ基準への適合が確認済み」 |
重要なのは、意思決定単位は部門と一致しないという点です。1つの部門に複数の単位が存在することも、複数部門が1つの単位として動くことも、組織図に現れない単位（グループ本部、外部監査、親会社）が存在することもあります。
本記事では、担当している案件を意思決定単位の集合として表現する方法を整理します。
フラットな人名リストでは何が足りないのか
多くの案件情報は、人名を並べた形で保持されています。
田中様（現場）／佐藤様（情報システム）／鈴木部長（管理本部）
この形式には、判断の構造が入っていません。具体的には次が欠けています。
- それぞれが何を判断する立場か
- 判断に順序があるか（誰が先に終わらないと次が動かないか）
- 1人で決まるのか、部門としての合議なのか
- 組織図に出てこない単位が関与していないか
人名リストは「誰と話したか」の記録です。意思決定単位の一覧は「何が決まる必要があるか」の記録です。案件が前進するかどうかを左右するのは後者です。
なお、個々の人物を役割・関心事・影響力で整理する手順は ++関係者マッピングの考え方++ で扱います。本記事は、その上位にある組織としての判断構造を扱います。
意思決定単位は部門と一致しない
実務で構造を読み違える原因の多くは、部門＝単位と考えることにあります。次の4パターンを想定しておくと精度が上がります。
① 1つの部門に、複数の単位が存在する
情報システム部の中に、システム連携を審査する機能と、運用体制を判断する機能が別々に存在することがあります。担当者から技術的な了承を得ても、運用側で別の判断が残っている、という状態です。
② 複数の部門が、1つの単位として動く
委員会形式、合同会議、プロジェクトチームなど、複数部門が集まって1つの判断を下す場合があります。この場合、個別に各部門を説得しても、会議体としての判断が出るまで条件は満たされません。
③ 組織図に現れない単位が存在する
企業グループでは、グループ本部・親会社・シェアードサービス部門が、現場の見えないところで基準を持っていることがあります。現場と本社の両方が合意していても、グループ標準への適合という条件が残っている、という構造です。
④ 外部の単位が関与する
外部監査、コンサルタント、システムインテグレーター、既存ベンダーが、実質的な判断者として関与する場合があります。これらは相手企業の組織図には存在しません。
いずれのパターンも、接点の記録からしか発見できません。組織図を入手しても、そこに単位は書かれていないためです。
単位どうしのつながり方
意思決定単位は、独立して並んでいるわけではありません。案件の進み方を左右するのは、単位間の依存の形です。
| つながり方 | 意味 | 実務上の意味 |
|---|---|---|
| 順序依存 | Aが完了しないとBが着手できない | Bを追いかけても動かない。Aの完了時期が案件の律速になる |
| 並行 | AとBが独立して進む | 同時に進められる。片方の遅延は他方を止めない |
| 条件付き | Aの結果次第でBの要否が変わる | Aの結果が出るまでBの準備は無駄になる可能性がある |
| 合議 | AとBが同じ場で判断する | 個別説得だけでは条件が満たされない |
順序依存の連鎖を把握していないと、営業活動は「動く可能性のない単位」に向かいます。技術審査が終わっていない段階で購買部門に条件を詰めても、購買側は判断できません。
依存関係が実際に案件を止めている場合の切り分けは ++商談が進まない理由の見つけ方++ で扱っています。
決定ノード ― 単位を「条件」として表現する
意思決定単位を管理可能にする方法は、単位ごとに、満たされるべき条件を1文で書くことです。これを決定ノードと呼びます。
書き方の違いは次の通りです。
| 弱い表現 | 決定ノードとしての表現 |
|---|---|
| 情報システム部と調整中 | 既存基幹システムとの連携方式について、情報システム部の技術審査が完了している |
| 予算を確認中 | 次年度予算に本案件の費用が計上されている |
| 経営層に説明予定 | 管理本部長の承認が取得されている |
| 現場は前向き | 使用部門による実機評価が完了し、運用上の不可がないと結論されている |
右側は、満たされたかどうかを yes / no で判定できます。左側は判定できません。この差が、進捗を語れるかどうかの差になります。
決定ノードは2種類の作り方があります。
- 明示的に定義する：案件の初期に、想定される条件を自分で書き出しておく
- 接点の記録から現れる：やり取りの中で「〇〇の確認が必要」と言及されたものを条件として追加する
実務では両方が併存します。初期に定義した想定は、案件が進むと必ず修正が必要になります。
構造の例：多拠点の物流企業グループ
※ 以下は考え方を示すための仮想例です。実在の顧客事例ではありません。
案件：物流企業グループへの業務システム導入。導入対象は主要3拠点。
| 意思決定単位 | 所属 | 決定ノード | 状態 | 依存 |
|---|---|---|---|---|
| 東日本拠点 運用部門 | 拠点 | 現場運用への適合が確認されている | 完了 | ― |
| 西日本拠点 運用部門 | 拠点 | 同上 | 未着手 | 東日本の評価結果を参照予定（条件付き） |
| 本社 情報システム | 本社 | 既存システムとの連携方式が承認されている | 審査中 | ― |
| グループ本部 IT標準 | グループ本部 | グループのIT標準への適合が確認されている | 未接触 | 本社情シスの審査後（順序依存） |
| 本社 購買 | 本社 | 契約条件が合意されている | 未接触 | IT標準適合の確認後（順序依存） |
| 経営会議 | 本社 | 投資案件として承認されている | 未起案 | 上記すべての完了後（合議） |
この構造から読めることは、人名リストからは読めません。
- 現場の評価は1拠点で完了しているが、それは6つある条件のうち1つにすぎない
- グループ本部という単位が、組織図上の取引先（本社）の外側にある
- 購買との条件交渉は、IT標準適合が確認されるまで実質的に動かない
- 経営会議は合議体であり、個別説得だけでは条件が満たされない
営業側が「本社と現場の両方を押さえた」と認識していても、グループ本部の存在に気づいていなければ、承認直前に想定外の要件が出てきます。このパターンは、企業グループを相手にする案件で繰り返し起きます。
部門ごとの進捗をどう運用管理するかは ++複数部門が関わる商談の進め方++ で扱っています。
単位が見えていないときの兆候
構造の欠落は、次のような形で現れます。
- 「確認します」の宛先が説明されない。 誰に確認するのかが曖昧なまま時間が経つ場合、そこに未知の単位がある可能性があります。
- 想定より承認に時間がかかる。 順序依存の連鎖が、認識しているより長い可能性があります。
- 合意済みの内容が、後から覆る。 別の単位の基準が後から適用された可能性があります。
- 相手が「持ち帰り」を繰り返す。 相手自身が単一の判断者ではないことを示しています。
- 窓口が本社所属で、導入先が拠点である。 拠点側に別の単位が存在する可能性が高い構造です。
いずれも、単位を見つけるための質問の起点として使えます。
各単位の状態を、案件の中で保持する ― VINEQRA の考え方
VINEQRA は、複数の関係者が関わる長期案件を担当する営業担当者個人のために設計された iOS 向けの AI CRM です。設計上の前提は、複雑な案件はフラットな連絡先リストではなく、相互に関係する判断主体の集合であるという点にあります。
商談の文脈は次の構造で捉えます。
顧客接点 ＋ 関係者 ＋ 意思決定ポイント ＋ 阻害要因 → 次に取るべき行動（Next Best Action）
（VINEQRA Opportunity Context Model）
本記事の決定ノードは、このうち「意思決定ポイント」にあたります。VINEQRA では2つの扱い方ができます。
- 営業担当者が明示的に定義する：想定される条件やマイルストーンを自分で設定し、AI がそれに対して記録内容を照合する
- 記録から推論する：定義していない場合でも、蓄積された顧客接点から進捗の兆候や未解決の条件を手がかりとして提示する
対応する AI 分析は、Apple Foundation Models を通じて端末内のシステム言語モデルで実行できます。
そして、前提となる原則があります。
VINEQRA は提案します。判断するのは営業担当者です。
単位の構造を最終的に判断するのは担当者です。提示されるのは、記録から読み取れる手がかりです。
よくある質問
Q. 意思決定単位は、どこまで細かく分けるべきですか？ 「その単位が判断しないと案件が進まないか」で分けます。判断を持たない部門は、単位として立てる必要はありません。逆に、1つの部門内に別々の判断があるなら分けます。
Q. 相手企業の組織図があれば、単位は分かりますか？ 分かりません。組織図は指揮命令系統を示すもので、案件ごとの判断構造とは別です。組織図に出てこないグループ本部や外部の関与先が単位になっていることもあります。単位は接点の記録から組み立てます。
Q. 「購買委員会」のような会議体は、日本企業にもありますか？ 形式は企業によって異なります。常設の委員会を持つ企業もあれば、案件ごとに合議の場を設ける企業、稟議の回覧で実質的な合議を行う企業もあります。重要なのは形式名ではなく、1つの判断に複数部門が関与しているかどうかです。
Q. 単位の構造は、いつ作るべきですか？ 初期に想定を書き出し、接点のたびに修正します。最初から正確である必要はありません。想定が外れたときに、どこが違ったかを記録できることに価値があります。
Q. 中小企業が相手の場合も、この考え方は必要ですか？ 単位の数は少なくなりますが、構造自体は存在します。社長が最終決裁者であっても、現場の受け入れと予算の裏付けは別の条件です。単位が3つなら3つとして扱えば十分です。
案件を、判断構造として表現する
相手企業の中で何が起きているか分からないとき、不足しているのは接触量ではなく構造の表現です。誰と話したかの記録を、何が決まる必要があるかの記録に変えると、案件の現在地が言えるようになります。
VINEQRA は、複数部門の関係者と顧客接点を1つの商談として保持し、営業担当者が定義した条件、または記録から読み取れる手がかりをもとに、未解決のまま残っている条件を提示します。
それぞれの意思決定単位を、見える状態に保つ。 → VINEQRAをApp Storeでダウンロード