システム開発のベンダーコントロールとは？失敗する5つの構造と、進行を取り戻す打ち手【2026年版】

2026-08-15

「『進捗はいかがですか』『順調です』——定例会議がこの2往復で終わる状態が、何週間も続いている」

「複数の開発会社に発注しているが、今どういう状態なのかを自社の言葉で説明できない」

「リリースの1ヶ月前になって、結合テストがまだ始まっていないと知らされた」

情報システム部門やDX推進の現場で、これは珍しい話ではありません。ただしこの詰まりは、担当者の管理能力が足りないから起きるのではありません。発注者側に進行を設計する機能を置かないまま、開発だけを外に出したときに構造的に起きることです。

ベンダーコントロールが効かないのは、詰め方が甘いからではありません。詰めても情報は出てきません。出てくるのは、発注者側が「何を、いつ、どの粒度で受け取るか」を先に決めているときだけです。つまりベンダーコントロールは、厳しく管理して効かせるものではなく、受け取り方の設計で効かせるものです。

この記事では、システム開発のベンダーコントロールを発注者側・進行担当者の目線で整理します。効かなくなる構造とその正体、契約形態ごとの効かせどころ、次の定例から使える打ち手、そして自社にPM機能がない場合の選択肢までを扱います。

なお、発注前の要件整理についてはシステム開発の要件整理｜B2Cで成果を出す3つの視点と進め方で解説しています。本記事は、そのうち「発注後の進行」に絞って深掘りする内容です。

「今、何がどこまで決まっているのか」から一緒に整理します

ベンダーとの進め方に不安がある段階でのご相談も歓迎です。「複数社に頼んでいて全体像が見えない」という状態のままで構いません。現状の棚卸しからご一緒します。

▶ 自社の進め方を無料で相談する

▶ お役立ち資料をダウンロードする

▶ 開発実績を見る

この記事でわかること

• ベンダーコントロールが効かなくなる5つの構造と、その正体
• 請負と準委任で変わる「コントロールの効かせどころ」と、偽装請負・ベンダーロックインの回避
• 進捗・変更・リスクを受け取り直す、明日から効く5つの打ち手
• 要件定義から運用移行まで、工程ごとに受け取るべき成果物と完了条件
• 自社にPM機能がないときの3つの選択肢と、依頼先に投げるべき6つの質問

1. システム開発のベンダーコントロールとは｜ベンダーを管理することではない

ベンダーコントロールとは、開発を外部委託する際に、発注者側が品質・コスト・納期（QCD）とリスクの状態を自社で把握し、判断できる状態を保ち続ける活動です。

「ベンダーを厳しく詰めること」と受け取られがちですが、実務上の中身は逆です。管理の対象はベンダーではなく、自社が判断するために必要な情報の流れだと捉えると、やるべきことが変わります。

1-1. ベンダーマネジメントとの違い

似た言葉に「ベンダーマネジメント」があります。両者は扱う層が違います。

この記事で扱うのは後者です。良いベンダーを選べていても、選定後の進め方が設計されていなければプロジェクトは揺れます。

1-2. 「丸投げ」が成立しない理由は、契約の枠組みにも書かれている

開発を委託しても、発注者側の役割はゼロになりません。IPA（情報処理推進機構）と経済産業省が公開する「情報システム・モデル取引・契約書」第二版（2020年12月公開）では、見直しの主要論点のひとつに「プロジェクトマネジメント義務および協力義務」が挙げられています。両者は双方の義務として整理されており、契約の時点でそれぞれの役割を明確にすることが狙いとされています。

つまり、外注は「作業を渡すこと」であって「判断を渡すこと」ではありません。ここを渡した瞬間、ベンダーは一般的なベストプラクティスで空白を埋めるしかなくなります。

なお、うまく回らない企業が特殊なわけでもありません。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査2025」では、2015〜2024年度の推移として、すべてのプロジェクト規模で「予定どおり完了」の割合が低下傾向にあると報告されています。

2. 契約形態で「コントロールの効き方」は変わる｜請負と準委任

ベンダーコントロールが効かない案件を遡ると、進め方以前に契約形態と期待していたことが噛み合っていないケースが少なくありません。同じ「外注」でも、発注者側がやるべきことは変わります。

実務で多いのは、要件定義は準委任、開発は請負という組み合わせです。ここで起きやすいズレが2つあります。

2-1. 準委任に請負の期待をすると、成果が曖昧になる

「要件定義をお願いしたのだから、要件定義書は完成して出てくるはず」という前提は、履行割合型の準委任では成立しません。準委任で頼むなら、完了条件は何が、どの粒度で、誰の承認をもって完了かを発注者側から出す必要があります。ここを渡さないまま「思っていたものと違う」となるのが、最も多い揉め方です。

2-2. 請負で指示を出しすぎると、偽装請負のリスクがある

請負契約では、発注者がベンダーの要員に直接指揮命令を行うと偽装請負と評価されるおそれがあります。「詰める」「巻き取る」形のコントロールが危険なのは、進行上の理由だけではありません。請負で効くのは指示ではなく、受け入れ条件と変更手続きの設計です。

2-3. 成果物と権利帰属を曖昧にしない（ベンダーロックインの回避）

コントロールが効かなくなる典型が、自社に何も残っていない状態です。ソースコードだけを納品対象にしていると、設計書・環境構築手順・運用手順が属人化し、他社への切り替えも自社での判断もできなくなります。これがベンダーロックインです。

契約時点で最低限、次の3点を書面にしてください。

• 納品対象：ソースコードに加え、設計書・ER図・API仕様・環境構築手順・運用手順を含めるか
• 権利帰属：著作権の帰属先と、他社が改修に利用できるか
• 引き継ぎ条件：契約終了時に何を、どの形式で受け取るか

「揉めていないから大丈夫」ではなく、切り替える可能性がある前提で書けているかが判断基準です（参考：システム開発の責任範囲はどこまで？発注者と開発会社が「検収間際」で揉めないための切り分け方）。

3. ベンダーに振り回される現場で起きている5つの構造

コントロールが効かなくなる現場には、共通した詰まり方があります。自社に当てはまるものがないか確認してみてください。

3-1. 進捗が「順調です」でしか返ってこない

進捗率80%という報告が3週間続く。嘘の報告ではなく、「何をもって完了とするか」が共有されていないために起きます。実装が終わった状態を80%と呼ぶ会社と、単体テストまで通った状態を80%と呼ぶ会社では、同じ数字がまったく違う意味になります。実態のズレは、遅延が表面化するまで見えません。

3-2. 気づいたら仕様が膨らんでいた

「ついでにこれも」「軽微な変更なので」などの小さな追加が、記録も影響評価もないまま積み上がります。増えた作業は誰かの残業や他工程のしわ寄せで吸収され、表面上は順調に見えたまま、あるタイミングで一気に破綻する。事故ではなく、変更の扱い方を決めていないことの必然です（参考：スコープ管理が崩れる本当の原因｜手戻りを防ぐディレクターの進め方）。

3-3. 複数ベンダーの「あいだ」に落ちるタスク

基幹システムはA社、フロントはB社、データ移行はC社。各社が自社の範囲を誠実にこなしていても、接続の仕様、テストデータの受け渡し、障害切り分けの一次窓口といった「あいだ」の作業は、どの契約書にも書かれていないことがあります。何かが起きた瞬間に押し付け合いに変わるのが、この境界線です。

3-4. 「決めるのは誰か」が決まっていない

要件定義が長引く原因の多くは技術ではなく承認です。意見を言う人、レビューする人、最終的に承認する人が分かれていないと、要望は宙に浮きます。誰も止めず、誰も正式には承認しないまま作業だけが進み、後から上位者のちゃぶ台返しが入る。決裁ラインが定義されていないだけ、というケースが大半です。

3-5. リスクと問題が混ざり、火消しだけが続く

課題管理表に、すでに起きた事象（問題）と、まだ起きていない懸念（リスク）が同じ列で並んでいる。この状態だと、目の前で燃えている問題だけが優先され、リスクは後回しになります。結果として、対応はいつも発生後の火消しになり、コストが最も高いタイミングでしか動けません。

Enlytディレクターの現場から｜ズレは「遅れ」より先に、報告の文面に出る

Enlytのディレクターがリモート・多拠点の案件で見ているのは、数字より先に報告の質感です。それまで具体的だった週次報告が、急に定型文だけになる。質問への返答が短くなる。この段階では、まだ何も遅れていません。ただ、書きにくいことが出てきたサインではあります。そこで問い方を変えます。「順調ですか」ではなく「今週、想定と違ったことは何でしたか」と聞くと、火種は問題になる前に言葉になります。

4. 本当の原因は、発注者側にPM・ディレクション機能がないこと

5つの構造に共通点があります。どれもベンダーの技術力とは無関係で、すべて「誰かが翻訳し、揃え、記録していれば防げたこと」です。その役割を担う人が発注者側にいない。これが最大の原因です。

多くの現場では、この役割を情報システム部門の担当者が兼務で持っています。既存システムの運用や問い合わせ対応と並行して、複数ベンダーの進行まで見る。窓口としては機能しても、要件を構造化し、期待値を揃え、変更を手続きとして処理するところまでは手が回りません。

「窓口」と「PM・ディレクション機能」は別物です。窓口は情報を通す役割ですが、後者は曖昧な相談を実行可能な形に翻訳し、決まっていないことを可視化する役割。前者だけでベンダーコントロールを期待するのは無理があります。

関連する構造はなぜシステム開発は「合意したはず」なのに揉めるのか｜合意形成のズレを防ぐ進め方を、仕様どおりのものが上がってこない理由は仕様書は渡したのに、なぜ違うものが上がってくるのか｜解釈のズレを生む構造と防ぎ方もあわせてご覧ください。

5. ベンダーコントロールの実務｜明日から効く5つの打ち手

次の定例から使える形で整理します。どれも特別なツールは要りません。

5-1. 進捗を「％」ではなく「完了条件」で受け取る

「進捗80%」ではなく「この機能は単体テストまで完了・結合テスト未着手」と、工程名と状態で受け取る。あわせて、次の1週間で完了予定のものと、完了しなかった場合に何が止まるかを併記してもらいます。数字は割れますが、工程名は割れません。

5-2. 「決定」「検討中」「対象外」を分けた台帳を持つ

打ち合わせを重ねると、決まったことと決まっていないことが同じ資料に混ざります。これが「合意したはず」問題の温床です。検討中の項目には必ず「誰が」「いつまでに」「何を判断すれば決定になるか」を併記し、この台帳はベンダーではなく発注者側が持ちます。

5-3. 変更管理を「交渉」から「手続き」に変える

問題は要件が変わることではなく、変わったときの扱いが決まっていないことです。変更要望の受付窓口、影響（工数・納期・費用）を回答するまでのリードタイム、誰の承認で確定とするか、軽微な変更の線引き。この4点を着手前に決めておくと、変更の話が交渉から手続きに変わります。請負契約では、この手続きがそのまま契約変更の入口になります。

5-4. 複数ベンダーの境界を、接点単位で書き出す

会社単位ではなく接点単位で担当を書きます。API仕様の決定権はどちらか、テストデータは誰がいつ用意するか、障害発生時の一次切り分けは誰か、環境の払い出しは誰の責任か。空欄が残った行が、そのまま後で揉める行です。

5-5. リスクと問題を分けて、週次で追う

管理表を2列に分けます。問題（すでに起きた事象）は対処の期限と担当を、リスク（まだ起きていない懸念）は発生確率・影響・監視方法を書く。分けるだけで、週次会議の議題が火消しから予防に変わります。

Enlytディレクターの現場から｜最初にやるのは、ルールを足すことではない

進行が乱れた案件に発注者側から入るとき、Enlytのディレクターが最初にやるのは新しい管理ルールの導入ではありません。既存の議事録とメールを遡り、「決定済み」「検討中のまま止まっている」「誰も引き取っていない」を1枚に分け直す作業です。ルールを増やすと、現場は報告のための報告を始めます。打ち手を足すのは、そのあとでも遅くありません。

6. 工程別｜どのフェーズで、何を受け取るか

打ち手を「いつ使うか」に落とすと、工程ごとの受け取り物として整理できます。空欄の列が、その工程で見えていないものです。

すべての工程で完璧にやる必要はありません。ただし、要件定義の「承認者」と検収の「合格基準」の2つが空欄のまま着手するプロジェクトは、ほぼ確実に終盤で揉めます。

7. 「必要なスキル」を数える前に、様式を決める

ベンダーコントロールを調べると、IT知識・交渉力・リーダーシップ・判断力といったスキル一覧に行き当たります。どれも間違いではありませんが、この整理には落とし穴があります。スキルの話にすると、うまくいくかどうかが担当者個人の資質に紐づいてしまうことです。

その担当者が異動すれば、コントロールは同時に失われます。実際、多くの企業で「あの人がいたときは回っていた」という状態が繰り返されています。発注者側が先に用意すべきなのは、能力ではなく様式です。

技術知識がゼロでよいわけではありません。ただし発注者側に求められるのは、実装方法を判断する力ではなく、ベンダーの説明を自社の言葉に翻訳し、リスクの大きさを見積もる力です。そしてその力は、様式があるほど短期間で身につきます。様式がなければ、経験を積んでも「勘が良くなる」だけで、組織には残りません。

8. 複数ベンダー・多拠点でも進行品質を落とさないための仕組み

ここまでの打ち手は、優秀な担当者がひとりいれば実践できます。しかし、その進め方がその人だけのものに留まっていると、異動や退職の瞬間に品質が崩れます。個人技を組織として再現できる形に引き上げるのがPMOの役割です。

ただしPMOは置けば効くものではありません。機能しているPMOとの差は、次の点に表れます。

• 週次で、リスクと問題を切り分けて第三者の目で再評価しているか
• ある案件で見つかった火種を、他案件の確認項目として横展開しているか
• 契約・請求・残工数まで含めて、数字として追えているか
• エスカレーションの条件が、担当者の判断ではなくルールとして決まっているか
• 暫定対応で終わらせず、標準そのものを更新しているか

開発チームが海外拠点にある場合、確認すべきは「多様性を尊重していますか」ではなく、どこを標準化し、明文化し、誰が翻訳し、どこでズレを早期発見しているか、です（参考：開発プロセス標準化が「現場の自由を奪う」と誤解される本当の理由）。

Enlytディレクターの現場から｜ベンダーを「採点」しない

発注者側の立場で入るとき、Enlytのディレクターが意識しているのは、ベンダーを評価する側に立たないことです。採点される場では、都合の悪い情報がいちばん遅く出てきます。代わりに置くのは、まだ問題ではない引っかかりを言っても損をしない場です。週次で拾った違和感はPMOに上げ、リスクとして扱うか様子を見るかを第三者の目で切り分けます。

9. 自社にPM機能がないときの3つの選択肢

必要だと分かっても、明日から人が湧いてくるわけではありません。現実的な選択肢は3つです。

9-1. 依頼先に投げるべき6つの質問

3つ目を選ぶ場合に見るべきは、体制図の見栄えではなく進め方を持っているかどうかです。商談では、提案の華やかさではなく回答の具体性を見てください。

1. 進捗は何をもって完了とし、どの様式で可視化しますか
2. 要件が途中で変わったとき、どの手続きで扱いますか
3. 非機能要件（速度・同時利用者数・停止の許容範囲）は、どの段階で誰が決めますか
4. 複数ベンダー間の「あいだ」の作業は、誰がどう線引きしますか
5. 仕様は誰が翻訳して、開発チームに渡しますか
6. 似た案件で、一番揉めたのは何でしたか

特に6つ目が有効です。揉めた経験を構造として説明できる相手は、同じ火種を先回りして潰す設計を持っています。「特に問題は起きませんでした」という答えは、そのままでは安心材料になりません。

9-2. 回答の具体性は、どこで判定するか

返ってくる答えは大きく2種類に分かれます。ひとつは「ケースバイケースです」「都度ご相談ください」と、条件を提示しない答え。もうひとつは「この場合はこう、この場合はこう」と、条件と扱いをセットで示す答えです。判断すべきは知識量ではなく、曖昧さを残さずに答えられるかどうかです。

そのうえで、次の3点が回答に含まれているかを見てください。

• 前提と除外事項が明示されているか（「〜は本支援に含みません」が書かれているか）
• 報告様式・変更管理・リスク管理表を、現物のフォーマットとして見せられるか
• 担当者が代わっても同じ進め方が再現される仕組み（標準・PMO）を持っているか

3つ目は、開発体制が社内・協力会社・海外拠点のいずれであっても効きます。要件を実装できる形に構造化する役割が体制図の中に見当たらない場合、その工数は誰かの善意で吸収されているか、後から追加費用として現れるかのどちらかです。費用の目安や見積もりが割れる理由はWebシステム開発の外注費用｜相場と失敗しない会社の選び方【2026年】で整理しています。

よくある質問（FAQ）

Q.ベンダーコントロールとベンダーマネジメントは何が違いますか？

ベンダーマネジメントは、取引先の選定・契約・評価・依存リスクといった中長期の調達方針を扱います。ベンダーコントロールは、選定後の個別プロジェクトで進捗・品質・仕様変更・課題をどう自社主体で把握し判断するかという実務です。

Q.請負契約と準委任契約で、コントロールの仕方は変わりますか？

変わります。請負では発注者がベンダー要員に直接指揮命令を行うと偽装請負と評価されるおそれがあるため、効かせどころは指示ではなく受け入れ条件と変更手続きです。準委任（履行割合型）では成果物の完成義務が原則ないため、「何をもって完了とするか」を発注者側から定義しないと成果が曖昧になります。

Q.社内にIT人材がいなくてもベンダーコントロールはできますか？

技術的な実現方法を判断する必要はありません。発注者側にしか出せないのは、何を実現したいか、何をやらないか、誰が承認するか、現場の例外運用は何か、という情報です。技術判断はベンダーに委ね、意思決定と情報提供は自社に残す。この線引きができていれば、専門知識がなくても進行はコントロールできます。

Q.どんなツールで管理すればよいですか？

ツールの種類は本質ではありません。決めるべきは「進捗を工程名と完了条件で受け取る」「決定・検討中・対象外を分ける」「リスクと問題を別列で持つ」の3点で、これが満たせるならスプレッドシートでも十分です。逆に、この3点が決まっていない状態で高機能なツールを導入しても、更新されない管理表が1つ増えるだけです。

Q.すでに炎上している案件でも、途中から立て直せますか？

可能です。ただし着手順があります。最初にやるのは新しい管理ルールの導入ではなく、決定事項・検討中・対象外の棚卸しです。今どこが決まっていないかを全員が同じ資料で見られる状態を作ってから、変更管理と報告様式を整えます。順番を逆にすると、報告のための報告が増えるだけです。

まとめ｜ベンダーコントロールは、縛ることではなく「判断できる状態」を保つこと

ベンダーに振り回されていると感じるとき、足りていないのは管理の厳しさではありません。何をもって完了とするか、変更をどう扱うか、誰が決めるか、リスクと問題をどう分けるか、この設計が発注者側にないだけです。

この記事の要点

• ベンダーコントロールは監視ではなく、発注者側の情報設計。詰めても情報は出てこない
• 外注は作業を渡すことであって、判断を渡すことではない。意思決定と情報提供は発注者側にしか出せない
• 請負では指示ではなく受け入れ条件と変更手続きで効かせる。準委任では完了条件を発注者側が定義する
• 納品対象・権利帰属・引き継ぎ条件を書面にしておかないと、判断材料ごと失う
• 進捗は「％」ではなく工程名と完了条件で受け取る
• 要件は「決定」「検討中」「対象外」に分け、検討中には期限と担当を必ず併記する
• 変更管理は揉める前に決める。窓口・影響回答のリードタイム・承認者・軽微の線引きの4点
• マルチベンダーでは会社単位ではなく接点単位で担当を書く。空欄が後で揉める行になる
• リスクと問題を分けて週次で追う。分けた瞬間に、議題が火消しから予防に変わる
• スキルを数える前に様式を決める。様式がなければ、経験は個人にしか残らない

進行の再現性は、丁寧さではなく仕組みで決まる

完了条件を工程名で受け取る。決定と検討中を分けて残す。変更管理を揉める前に決める。リスクと問題を切り分けて週次で追う。どれも特別な技術ではなく、標準の進め方として持っているかどうかの差です。そしてこの差が、そのまま問題発生の量になります。

ここで価値を発揮するのは、進捗を見張る管理者ではありません。曖昧さを減らし、期待値を揃え、事後発生を先回りして防ぎながら、プロジェクトを前に進めるPM/ディレクターです。ベンダーコントロールとは、この機能を発注者側が持っているかどうかの問題です。

Enlytでは、受注前の要件整理から、要件・完了条件の構造化、UI/UX起点の体験設計、見える化された進行管理までをワンチームで支援しています。日本のディレクターがブリッジとなり、ベトナム・ダナンの開発拠点へ仕様を翻訳・構造化して渡す体制を、属人的な調整力ではなく標準化された運用として持っています。どの言葉を具体化してから渡すかという観点までチームで共有しているため、担当ディレクターが誰であっても、開発チームに届く要件の粒度が揃う。これが、多拠点でも進行品質を落とさずに進められる理由です。

同じ設計は、発注者側の立場に立ったPMO・ディレクション機能としても提供できます。「全体像が見えない」「今の案件を立て直したい」などの段階からでも、現状の棚卸しからご一緒します。

ベンダーとの進め方、いちど棚卸ししてみませんか

「前回の開発で何がまずかったのかを言語化したい」といったご相談からで構いません。進行中の案件でも、これからの発注でも、何を先に決めておくべきかを整理するところからお手伝いします。

▶ 自社の場合、何から整理すべきか 無料で相談する

▶ お役立ち資料をダウンロードする

▶ 開発実績を見る

あわせて読みたいEnlytの記事

▶ なぜシステム開発は「合意したはず」なのに揉めるのか｜合意形成のズレを防ぐ進め方

▶ システム開発の責任範囲はどこまで？発注者と開発会社が「検収間際」で揉めないための切り分け方

▶ 開発プロセス標準化が「現場の自由を奪う」と誤解される本当の理由

白武 歩実

Enlytにて主に開発ディレクションおよびUI/UX設計を担当。 マクアケ、京セラ、大手通信キャリアなど、豊富な経験を持ち、エンジニア・デザイナー・クライアント間の橋渡し役としてプロジェクトを円滑に推進。 技術とデザイン、両方の視点を理解したコミュニケーションを強みとしている。

View More