ベンダーコントロールとは？丸投げを防ぐ発注側の進め方と5つの実践ポイント

ベンダーに開発を委託して、毎週の報告は「順調です」の一言だけ。中身が見えないまま数か月が過ぎ、受け入れテストで大量の不具合が見つかって、はじめて事態の深刻さに気づく——外部委託のプロジェクトで繰り返されてきた、典型的な事故です。ベンダーコントロールとは、こうした事故を防ぐために、発注側がベンダーの品質・進捗・スコープを可視化し、能動的に管理していく活動のこと。結論を先に言えば、鍵は契約書の厚さでもベンダーの当たり外れでもなく、「丸投げしない構造」を発注側がつくれるかどうかにあります。この記事では、金融系プロジェクトのPMとして品質管理を叩き込まれた僕の経験と、PMBOKの調達マネジメントの枠組みを重ねて、明日から使える実践ポイントまで落とし込みます。

ベンダーコントロールとは、システム開発や業務の外部委託において、発注側が委託先ベンダーの品質・進捗・コスト・スコープを可視化し、プロジェクトを意図した成果に導くための管理活動を指します。PMBOKでは「調達マネジメント」——プロジェクトに必要な製品・サービス・成果をプロジェクトチームの外部から購入または取得するためのプロセス——として体系化されている領域で、計画・実行・監視の3つのフェーズで整理されます。

なぜこれが発注側に必要なのか。システム開発の成功率は3割と言われる世界だからです。そして失敗したプロジェクトの原因を辿ると、ベンダーの力量不足だけで説明できるケースはむしろ少ない。僕は、プロジェクトの失敗原因は発注側にも受注側にもあると考えていて、発注側の要因の代表格が「契約したら終わり」の丸投げです。

契約は、成果を保証してくれません。契約書に書けるのは「何を・いつまでに・いくらで」までで、その通りに進んでいるかを途中で確かめる行為は、契約書の外側にある。ここを引き受けるのがベンダーコントロールであり、これは発注側にしかできない仕事です。

なお、管理の前提となる準委任・請負・派遣という契約形態の違いと、指揮命令をめぐる偽装請負リスクも発注側の重要論点ですが、本記事では管理の実務に絞って解説します。

僕はYouTubeで調達マネジメントの講座を出していますが、そこでも挙げた丸投げの典型的な破綻パターンは、次の3つに集約されます。

3つに共通するのは、「報告がない＝順調」という誤読です。進んでいないタスクほど、報告には上がってきません。ベンダー側にも、悪い状況を積極的に開示するインセンティブは構造的に働きにくい。動画でも、僕はここをはっきり指摘しました。

format_quote

ベンダーに任せているから、問題があればベンダーの方から報告してきてくれるでしょう——こういうスタンスじゃダメなんですよね。

つまり、待っていても情報は来ない。見に行く構造を発注側がつくるしかないんです。

発注側の管理責任は、分解すると3つあります。要求を明確にする責任、途中で確かめる責任、そして判断する責任。このどれひとつとしてベンダーに委譲できません。丸投げとは、この3つの責任を無自覚に手放した状態のことだと僕は定義しています。

責任論だけでは現場は動かないので、具体的な仕組みに落とします。ポイントは、個人の注意力に頼らず「定型業務」として組み込むことです。

定例レビューは発注側から設計する

週次または月次の定例と、ステータスレポートの場を発注側から設定します。頻度はプロジェクトの特性とベンダーへの信頼度で調整すればいい。立ち上がったばかりの取引先なら週次で細かく、実績のあるベンダーなら隔週で要点だけ、という強弱もありです。大事なのはフォーマットで、進捗率のパーセンテージだけでなく「完了した成果物」「未解決の課題」「次回までの予定」を具体的に書いてもらう。「対応中です」が並ぶレポートは黄色信号です。対応中という言葉は、状況を把握できていないときにも使えてしまう便利な言葉だからです。

format_quote

契約したから安心じゃなくて、常に能動的に目を光らせに行くのがPMの仕事です。

これはPM向けの講座で話した言葉ですが、発注側にそのまま返ってくる言葉でもあります。ベンダーの管理者が機能していないとき、最後にプロジェクトを守れるのは発注側の目だけです。

品質はUAT一発勝負にしない

品質の確認を受け入れテストまで先送りしない。要件定義書・設計書の段階からレビューに入り、開発中のものもテスト環境に定期的にデプロイしてもらって、動くものをこの目で見る。問題は早期に見つけるほど安く済みます。事後対処のコストは事前の3〜5倍かかる——バグひとつでも、後から見つかれば修正・再テスト・横展開の分析・関係者への説明と、雪だるま式に膨らんでいくからです。

支払い条件と成果物を紐付ける

支払いのタイミングは、成果物の納品・検収と連動させます。ベンダーは成果物をきちんと出さないと対価が入らないので真剣になるし、発注側も「払ったのに何も進んでいない」という事態を防げる。地味ですが、双方の緊張感を保つ最もシンプルな仕掛けです。

format_quote

契約後もベンダーを泳がせることなく、きっちり捕まえておくことが大事になります。定例会などを通じて「うまくいってる？」「困ってない？」と声をかけ続けることによって、小さな火種も早めに消せるのかなという風に思います。

「捕まえておく」と言うと監視のように聞こえますが、実態は逆です。声をかけ続けている現場ほど、ベンダーは悪い報告を早く出してくれる。可視化の仕組みは、締め上げる道具ではなく、火種が小さいうちに一緒に消すための土台です。

管理の仕組みが機能する大前提は、そもそも「何ができたら完成なのか」の合意がズレていないことです。遅延や品質問題は症状であって、真因はスコープ定義のズレにあることが多い。ここを放置したまま定例だけ増やしても、ズレたゴールに向かって精度よく進むだけです。

僕が金融系プロジェクトのPMで最初に叩き込まれたのは、品質問題の大半はテスト工程で発見されるが、テスト工程で生まれたものではない、ということでした。根はほぼ例外なく上流にあります。だから僕は仕様合意の場で「何を作るか」「何を作らないか」「判断が変わりうる条件は何か」の3点確認を徹底していました。特に効くのが「何を作らないか」の言語化で、後工程の「これも入っていると思っていた」という認識齟齬を大幅に減らせます。発注側の立場でも、この3点確認はそのまま使えます。こうした書面合意を実践する主戦場が要件定義フェーズで、要件定義でPMOがどう動き、どんな成果物を残すかは別記事で具体的に解説しています。

書面化のプロセスも同じです。まず調達マネジメント計画書として「調達する範囲」「調達のスケジュール」「ベンダーの評価基準」「契約の承認者」「支払い条件」の5項目を固める。この5つが書けていれば、調達計画としてはおおよそ網羅できます。そのうえで、いきなり契約に進まず、RFP（提案依頼書）でこちらの要求を明示し、発注前にベンダーと丁寧にすり合わせる。契約書にはスコープ・納品物・検収条件・支払い条件・変更管理プロセスまで明文化する。口頭の約束は残しません。

format_quote

認識合わせも契約書の作成も、細かすぎるかなと思うぐらいがちょうどいいかなという風に思います。後から揉めるぐらいだったら、最初に少々コストをかけておいてでも、全部紙に書いておいた方がいいんですよね。

書面化には副次的な効用もあります。いざ文字にしてみると「ここが曖昧だった」「認識が食い違っていた」に気づける。明文化の過程そのものが、最も確実な認識合わせになるんです。

そして、合意は一度つくって終わりではありません。プロジェクトが進めば追加要望は必ず出ます。そのたびにコスト・スケジュール・品質への影響を見積もり、決められた承認プロセスを通す。この変更管理が回っていないと、担当者の預かり知らぬところで追加見積もりが積み上がり、気づいたときには予算が別物になっています。

ここまでの内容を、発注側がそのまま使えるチェックリストとして5つにまとめます。

1. 発注前に、調達範囲と要求を書き切る——どの作業を委託し、何を内製するのか。要件と成果物の定義を、ベンダーに声をかける前に固める。曖昧なまま発注した部分は、ほぼ確実に泥沼になります。
2. 評価基準・承認者・支払い条件を先に決める——複数社コンペで何を基準に選ぶのか、契約を誰が承認するのか、何を満たせば支払うのか。選定を行き当たりばったりにしない。
3. RFPと事前のすり合わせで認識の溝を埋める——「こんなはずじゃなかった」の総量は、発注前の対話量でほぼ決まります。丁寧すぎるくらいでちょうどいい。
4. 定例レビューで品質・進捗をこちらから見に行く——報告を待たない。中間成果物のレビューと、テスト環境での動作確認をプロジェクト計画に組み込む。
5. 変更管理プロセスを回し続ける——追加要望は必ず影響評価と承認を通す。契約書に書いた変更管理を、書いただけで終わらせず「使う」。

1と2が調達の計画、3が実行、4と5が監視。つまりこの5つは、PMBOKの調達マネジメントの3プロセスをそのまま発注実務に翻訳したものです。なお、委託先が海外の場合はこの5つに距離と言語の壁が加わります。応用編としてオフショア開発でのベンダーコントロールも別記事で扱っています。3つのプロセスごとの失敗例と対策は、動画で一つずつ解説しています。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「【PM講座 #11/12】PMBOK式 外注トラブルを回避する調達マネジメント【プロジェクトマネジメントの教室】」

仕組みは分かった。でも回す人がいない——ここが多くの発注側企業の本当の壁だと思います。情シスの担当者が本業の傍らで定例を設計し、設計書をレビューし、変更管理を運用するのは現実には厳しい。開発経験者が社内にいなければ、ベンダーの成果物や見積もりの妥当性を判断すること自体が難しいからです。

この壁を越える選択肢が、外部PMOの活用です。ベンダーコントロールの実務——管理フレームの設計、定例会議体の設計とファシリテーション、成果物レビュー、変更管理の運用——を、発注側の立場に立って代行・伴走してもらう使い方です。ベンダーと同じ言葉を話せる人間が発注側に一人いるだけで、報告の解像度も交渉の力学も変わります。こうした管理機能を組織のどこに置くかという体制論（発注者側PMOの設置パターンと業務範囲）は、別記事で詳しく整理しています。

ひとつ強調したいのは、ベンダーコントロールは特別な才能ではなく、体系化された手順の積み重ねだということです。体系化さえされていれば、専任の凄腕がいなくても組織として70点の管理は出せる。だから外部PMOを入れる価値は、管理の代行そのものよりも、仕組みを社内に残せることにあります。僕たちがPMO支援で何を大事にしているかはPMO支援サービスにまとめているので、あわせて参考にしてください。

• 契約は成果を保証しない。品質・進捗を途中で確かめる行為は契約書の外側にあり、発注側にしかできない
• 丸投げの破綻は「報告がない＝順調」という誤読から始まる。情報は待たず、見に行く構造をつくる
• 合意形成は「何を作るか」だけでなく「何を作らないか」「判断が変わりうる条件」まで書面化する
• 支払いと成果物を紐付け、変更管理プロセスを回し続ける
• 回す人がいなければ、外部PMOで仕組みごと導入し、社内に残す

ベンダーコントロールという言葉から、ベンダーを疑って締め上げる姿を想像したなら、それは半分だけ正解で半分は誤解です。確認の構造がある現場ほど、ベンダーは悪い報告を早く出せるし、関係は健全に保たれる。あなたが今つくろうとしているのは監視体制ではなく、火種が小さいうちにベンダーと一緒に消せる関係です。その設計は、契約書にサインする前から始まっています。

※本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

---

ベンダー管理の「見えない不安」を仕組みに変えたい方へ

「ベンダーの報告が信じきれないが、何をどう確認すればいいか分からない」「成果物をレビューできる人が社内にいない」「すでに雲行きが怪しいが、どこから手を付けるべきか判断できない」——外部委託のプロジェクトでこうした不安を抱えている方は、一度状況を整理するところから始めませんか。

クリエイティブテックスタジオでは、発注側の立場に立ったベンダーコントロールの仕組みづくりと伴走を行っています。無料相談では、現在のプロジェクト状況を伺ったうえで、まず何を可視化すべきかを一緒に整理します。外部支援を入れるまでもなく社内で対処できるケースや、他社のサービスが適しているケースでは、その旨も正直にお伝えします。

丸投げの構造は、気づいた時点で手を打てば立て直せます。無料相談はこちらからお気軽にどうぞ。