ベンダーマネジメントの実務設計

DXプロジェクトにおいて、ベンダーとの関係構築と管理は避けて通れない実務です。システム開発、データ基盤構築、AIモデルの実装、クラウドインフラの設計。これらを完全に自社リソースだけで賄える企業は少なく、何らかの形でベンダーとの協業が発生します。

しかし、多くの現場でベンダーマネジメントは「担当者の経験と交渉力」に依存した属人的な運営になっています。その結果、以下のような問題が頻発します。

RFPが曖昧なまま提示される。「何を」「どのレベルで」「いつまでに」求めるかが不明確なRFPを出すと、ベンダーからの提案の粒度が揃わず、比較評価が困難になります。結果として、価格だけで選定するか、過去の付き合いで決めるか、どちらも最適な判断とは言えない意思決定に陥ります。

責任分界が曖昧なまま開発が始まる。「この部分は誰の責任か」が契約段階で明確に定義されていないと、プロジェクト中盤以降に「それはうちの範囲ではない」「聞いていない」という衝突が発生します。特にマルチベンダー体制では、ベンダー間の責任の隙間にタスクが落ちるリスクが高まります。

スコープ変更がコントロールされていない。DXプロジェクトでは、要件の変更は「起きるかどうか」ではなく「いつ、どの程度起きるか」の問題です。変更管理（CR: Change Request）のプロセスが定義されていないと、「口頭での依頼」が積み重なり、スケジュールとコストが管理不能になります。

本記事では、ベンダーマネジメントを属人的な交渉術ではなく、構造的に設計できるスキルとして整理します。RFPの作成、ベンダー評価のスコアリング、責任分界の設計、変更管理のプロセス、会議体の設計。この5つの実務を、テンプレートと判断基準付きで解説します。

RFP（Request for Proposal：提案依頼書）の品質は、ベンダーの提案品質を直接左右します。曖昧なRFPからは曖昧な提案しか返ってきません。逆に、論点が構造化されたRFPを提示すれば、ベンダーはその構造に沿って具体的な提案を作成できます。RFPの設計力は、ベンダーマネジメントの出発点です。

RFPに最低限含めるべき項目を整理します。

失敗1：スコープが「やること」しか書かれていない。「やらないこと」を明示しないと、ベンダーは自社に都合の良い解釈でスコープを狭めるか、逆にすべてを含めた高額な提案を出してきます。「Out of Scope」を明記することで、見積もりの前提条件が揃います。

失敗2：評価基準を開示していない。何を重視して選定するかをベンダーに伝えないと、提案の力点がバラバラになり、比較が困難になります。「技術力を最重視する」のか「コストを最重視する」のか「実績を最重視する」のかを事前に伝えることで、ベンダーは自社の強みを最も効果的にアピールできる提案を作れます。

失敗3：予算を一切開示しない。予算感をまったく示さないと、ベンダーは「松竹梅」の全パターンを含めた提案を作るか、保守的に高めの見積もりを出すことになります。概算レンジ（「○○万円〜○○万円の範囲で提案してほしい」）を提示するほうが、提案の精度は上がります。ただし、入札制度で予算開示が制限されるケースもあるため、自社のルールを確認した上で判断します。

RFPに対して複数のベンダーから提案が返ってきた後、どう評価・選定するかを事前に設計しておくことが重要です。評価基準が事前に定義されていないと、「雰囲気」「過去の付き合い」「声の大きい人の意見」で選定が決まります。

ベンダー評価の軸は、プロジェクトの特性によって異なりますが、一般的に以下の5軸が基本です。

重要なのは、配点の「重み付け」を選定前に確定し、関係者の合意を取っておくことです。選定後に「やっぱりコストのほうが大事だった」と言い出すと、選定プロセス自体の信頼性が崩れます。RFPの段階で評価軸と配点を開示し、選定委員会の合意を経ておくのが健全なプロセスです。

ベンダー評価は「提案書の書面評価」と「プレゼンテーションの対面評価」の2段階で行うのが一般的です。書面評価では技術力・コスト・実績の定量面を評価し、プレゼン評価ではチーム体制の具体性、質疑応答の対応力、コミュニケーションの質を評価します。

プレゼン評価で特に確認すべきは「提案書に書かれていない情報」です。実際にプロジェクトを担当するメンバーの顔が見えるか、質問に対して提案書を読み上げるのではなく自分の言葉で回答できるか、想定外の質問に対してどう対応するか。これらは書面では評価できない重要な判断材料です。

ベンダーとの協業で最も多いトラブルは「責任の所在が不明確」であることに起因します。RACI（Responsible / Accountable / Consulted / Informed）は、この責任分界を可視化するための標準的なフレームワークです。

RACIの4つの役割は以下の通りです。

• R（Responsible）：その作業を実際に行う担当者
• A（Accountable）：その作業の最終的な承認・責任を持つ者。各タスクにAは1人だけ
• C（Consulted）：作業の前に相談を受ける者。双方向のコミュニケーション
• I（Informed）：作業の結果を通知される者。一方向の情報共有

1. Accountable（A）は各タスクに必ず1名。Aが不在のタスクは「誰も最終責任を持たない」状態になり、問題が起きたときに判断が止まります。Aが2名以上いるタスクは「責任の押し付け合い」が発生するリスクがあります。

2. ベンダー間の「隙間タスク」を明示的に割り当てる。マルチベンダー体制では、「ベンダーAのシステムとベンダーBのシステムの接続テスト」のような、どちらのスコープにも入っていないタスクが発生しがちです。こうした隙間タスクをRACIの段階で洗い出し、明示的にRとAを割り当てておくことが重要です。

3. RACIは「契約前」に合意する。プロジェクト開始後にRACIを作成すると、すでに「それは契約範囲外です」という主張が出てきます。RACIはRFPの段階で概要版を提示し、契約時に詳細版の合意を取るのが理想的なタイミングです。

DXプロジェクトでは、要件の変更は必ず発生します。ビジネス環境の変化、ユーザーからのフィードバック、技術的な制約の発覚。問題なのは変更そのものではなく、変更が管理されていない状態です。

変更管理（CR: Change Request）のプロセスが定義されていないと、現場で「ちょっとこれも追加してほしい」という口頭依頼が積み重なり、いつの間にかスコープが膨張します。結果として、スケジュールが遅延し、コストが超過し、「誰がこの追加を承認したのか」が不明確な状態に陥ります。

変更管理のプロセスは、以下の5ステップで設計します。

Step 1：変更の起票。変更を依頼する側が、所定のフォーマットで変更内容・理由・期待する効果を記載して起票します。口頭依頼は受け付けない、というルールを徹底します。

Step 2：影響分析。変更がスケジュール、コスト、品質、他の機能に与える影響を、ベンダーが分析して報告します。影響分析なしで変更を承認しないルールを設けます。

Step 3：承認判断。影響分析の結果を踏まえて、変更を「承認」「却下」「延期」のいずれかに判断します。承認権限者を事前に定義しておきます。

Step 4：実施・追跡。承認された変更を実施し、進捗を追跡します。変更管理台帳で全CRの一覧を管理します。

Step 5：振り返り。プロジェクト完了後に、発生したCRの傾向を分析します。「なぜこの変更が発生したか」を振り返り、次のプロジェクトのRFP設計にフィードバックします。

特に重要なのはStep 1の「口頭依頼を受け付けない」ルールです。最初は運用負荷が上がるように感じますが、これを徹底することで「スコープが管理不能になる」リスクを構造的に排除できます。

ベンダーマネジメントの日常運用は、会議体の設計に集約されます。どの会議で何を議論し、誰が参加し、どんな頻度で開催するか。この設計が不適切だと、「全員が参加する長時間の会議で何も決まらない」状態になります。

実務で機能しやすい会議体は、以下の3層構造です。

週次：ワーキングレベル。各ワークストリームの担当者が、進捗・課題・ブロッカーを共有します。意思決定は求めず、課題の早期検知に集中。30分以内。

隔週 or 月次：PMOレベル。プロジェクトマネージャー同士が、全体の進捗・リスク・CRの状況をレビューします。クロスファンクショナルな課題（ベンダー間の調整、スコープの微調整等）の意思決定はここで行います。60分以内。

月次 or 四半期：ステアリングコミッティ。経営層・事業責任者レベルが、プロジェクト全体の健全性を評価し、継続/方針変更/中止の判断を行います。報告は「アウトカム（事業への影響）」を中心に設計。45分以内。

会議体設計のポイントは「議論の場」と「報告の場」を分けること。ワーキングレベルの課題をステアリングコミッティに持ち込むと、経営層が細部の技術議論に時間を取られ、戦略的な判断ができなくなります。各層の役割を明確にし、エスカレーションの基準を事前に定義しておくことが重要です。

本記事では、ベンダーマネジメントの実務を5つの設計領域に分けて整理しました。

• RFP設計：ベンダーの提案品質を決めるのは「こちら側」の設計力。スコープのIn/Out、評価基準、予算レンジを明示する
• ベンダー評価：5軸のスコアリングと配点の事前合意で「なんとなく良い」を排除する
• 責任分界（RACI）：各タスクのAccountableを1名に定め、隙間タスクを明示的に割り当てる
• 変更管理（CR）：5ステップのプロセスで「口頭依頼」を仕組みで防ぐ
• 会議体設計：3層構造で「議論の場」と「報告の場」を分ける

ベンダーマネジメントは、担当者の交渉力や経験に依存させるものではなく、構造的に設計するものです。RFPの段階で選定の精度を上げ、RACIで責任を可視化し、CRプロセスでスコープを管理し、会議体で情報の流れを構造化する。この一連の設計があることで、ベンダーとの協業は「相性の問題」ではなく「プロセスの問題」として管理可能になります。

DXプロジェクトの成否は、技術選定だけでなく、それを実装するベンダーとの協業の質に大きく左右されます。ベンダーマネジメントの設計力は、DXを推進するすべての人にとって不可欠な実務スキルです。