--- title: "ベンダーコントロールとは？発注者が進捗・品質・変更を握る方法と偽装請負にならない線引き" url: "https://www.issoh.co.jp/column/details/19770/" published: 2026-11-14 updated: 2026-11-14 categories: ["Webシステム"] publisher: "株式会社一創" --- # ベンダーコントロールとは？発注者が進捗・品質・変更を握る方法と偽装請負にならない線引き ベンダーコントロールとは、システム開発を外部に発注したあと、委託先の進捗・品質・仕様変更を発注者側が把握し、必要な判断を下して統制することです。契約を結んだ時点で発注者の仕事が終わるわけではなく、報告の受け方、変更の決め方、成果物の確かめ方を決めておかないと、遅延や追加費用は「ベンダーの問題」から「双方の争い」に変わります。この記事では、IPAの情報システム・モデル取引・契約書（第二版）の条文を手がかりに、会議体と変更管理の運用、品質の確かめ方、発注者側の体制を整理しました。あわせて、厚生労働省の疑義応答集が示す「指示を出しすぎて偽装請負になる線」と、PMOを外部に任せるべき案件の条件まで扱います。 ## まとめ：ベンダーコントロールは会議体・変更手続・承認期限の3つを契約で決めて握る 発注者がベンダーを握る手段は、強い口調の指示ではありません。定例の協議の場で決まった様式の報告を受け取り、仕様の変更は書面の手続を通し、中間成果物には期限つきで承認を出す。この3つを契約と体制図に書き込んでおけば、遅延は早い段階で数字として見え、変更の費用と納期も揉めずに決まります。 反対に、発注者が受注者側の開発者へ作業の順序や労働時間を直接指示すると、準委任契約であっても偽装請負と判断されます。伝えてよいのは要件・優先順位・判断材料までで、作業の割り振りは受注者の管理責任者を通すのが原則です。社内にPM経験者がいない、複数のベンダーが並行して動く、といった条件に当てはまる案件では、統制の実務を外部のPMOに任せる選択も検討してください。 ## ベンダーコントロールの意味と、ベンダー選定・ベンダーマネジメントとの違い ### 発注後に委託先の進捗・品質・変更を発注者が統制するという定義と範囲 ベンダーコントロールは、契約締結から検収までの期間に、発注者が委託先の仕事の状態を把握し続け、遅れや品質の問題に対して判断を下す活動を指します。対象は大きく分けて進捗、品質、仕様変更、体制（要員の交代や再委託）の4つです。 「コントロール」という語感から、発注者がベンダーの作業を細かく指図するイメージを持たれがちですが、実態は逆です。発注者が握るのは**判断の材料と決定権**であって、作業の手順ではありません。工程管理やEVMといった管理手法そのものは[システム開発のプロジェクト管理の進め方と発注側の役割](https://www.issoh.co.jp/column/details/15670/)で解説しているので、本記事では「発注者が委託先をどう握るか」に絞ります。 ### 発注前のベンダー選定と、複数社を束ねるベンダーマネジメントとの守備範囲 似た言葉との違いは、時期と対象の広さで整理できます。 | 用語 | 時期 | 対象 | 主な成果 | | ---------- | -------- | --------- | ------------------ | | ベンダー選定 | 発注前 | 候補の数社 | 評価表と発注先の決定 | | ベンダーコントロール | 契約から検収まで | 個別の案件の委託先 | 進捗・品質・変更の統制 | | ベンダーマネジメント | 取引期間の全体 | 取引する全ベンダー | 取引先の評価・集約・契約条件の見直し | 発注先を決めるまでの評価方法は[ベンダー選定の流れと評価表の配点設計](https://www.issoh.co.jp/column/details/18684/)で扱っています。ベンダーマネジメントは調達部門が年単位で取引先を見直す活動を含むため、案件単位で動く情報システム部門の担当者が最初に身につけるべきなのはベンダーコントロールの方です。 ### IPAモデル契約第8条と第13条が定める発注者側の分担とマルチベンダー調整の責任 発注者が「お金を払う側」にとどまれない根拠は、契約のひな型にも書かれています。IPAが2020年12月22日に公開した[情報システム・モデル取引・契約書（第二版）](https://www.ipa.go.jp/digital/model/model20201222.html)の第8条（協働と役割分担）は、システム仕様書の早期かつ明確な確定を発注者側の役割と位置づけ、双方が分担作業を遅らせた場合はそれによる損害も含めて責任を負うと定めています。 第13条はさらに踏み込み、発注者が全体のシステムを複数社に分割発注した場合、他社のソフトウェアとの整合性、開発スケジュールの調整、各社の進捗管理は**発注者が責任を負う**としています。マルチベンダー体制では、ベンダーコントロールは努力目標ではなく契約上の義務になると考えてください。 ## ベンダーコントロールが効かなくなる発注者側の原因と、炎上に至る典型的な経過 ### 報告様式を決めずに受け取る進捗報告が「順調」のまま遅延を隠す仕組み もっとも多い失敗は、ベンダーの進捗報告を相手任せの形式で受け取ることです。「全体の進捗率85％」という報告は、残り15％に結合テストのような重い作業が集中していても数字の上では順調に見えます。 遅延が表に出るのは、たいてい工程の終盤です。そこから要員を増やしても、新しく入った人の立ち上げに時間がかかり、遅れはむしろ広がります。報告の様式を発注者側が先に決め、完了した成果物の数と残作業の見積りを分けて書いてもらうだけで、この見落としはかなり減らせます。 ### 口頭やチャットで決めた仕様変更が費用と納期に反映されず揉める経過 定例会の雑談やチャットで「この項目も追加で」と頼み、ベンダーが善意で対応する。これが数十件たまると、ベンダーは検収前に追加費用を請求し、発注者は「当初の範囲内のはずだ」と反論する構図になります。 どちらの言い分が通るかは、変更を記録した書面があるかどうかでほぼ決まります。記録が無い変更は、発注者にとっても範囲外だったと証明できず、交渉の材料になりません。 ### 意思決定者が不在で中間資料の承認が止まり、遅延の原因が発注者側に移る状態 見落とされやすいのが、遅延の原因が発注者側にあるケースです。画面設計書の承認が社内調整で3週間止まれば、その間の待ちはベンダーの責任ではありません。モデル契約第9条は、要件定義書・外部設計書の確定、納入物の検収、変更管理書の交付を発注者側の責任者の権限として列挙しています。 決める人が決められない状態は、ベンダーコントロールの失敗そのものです。承認を担う責任者を契約時に名指しし、代理の決裁者も決めておく必要があります。 ## 進捗・品質・変更を握るための会議体と報告書式、変更管理書の運用方法 ### 連絡協議会の開催頻度と出席者、進捗管理報告に載せる項目の決め方 モデル契約第12条は、業務が終わるまで「連絡協議会」を個別契約で定めた頻度で定期開催し、必要に応じて随時開くと定めています。出席するのは双方の責任者と主任担当者で、議題に必要な人の出席も相手方に求めることが可能です。第4項が示す確認事項は、そのまま報告様式の項目に転用できます。 - あらかじめ取り決めた様式による進捗状況 - 遅延事項の有無と、ある場合はその理由と対応策 - 人員の交代・増減や再委託先の変更など、推進体制の変更の要否 - セキュリティ対策の履行状況 - 個別契約の変更を要する事由の有無と、その内容 開催頻度は、設計から開発工程なら週1回、テスト工程で障害が多い時期は週2回が目安です。毎回1時間を超えるなら、議題が報告の読み上げになっていないかを見直してください。報告は前日までに資料で受け取り、会議では遅延と判断事項だけを扱うと時間が締まります。 ### 変更提案書から変更管理書、変更契約までの流れと記載すべき8項目 仕様変更の扱いは、モデル契約の第33条・第34条・第37条が手続を定めています。流れは次のとおりです。 1. 発注者・ベンダーのどちらかが、変更の内容と理由を書いた「変更提案書」を相手に渡す（第34条） 2. 受け取った側が所定の日数以内に「変更管理書」を交付する（第37条第1項） 3. 連絡協議会で変更の可否を協議し、双方の責任者が変更管理書に記名押印して確定する（同第2項・第3項） 4. 費用・納期・契約条項に影響する変更は、変更契約を書面で結んだ時点で確定する（第33条） 変更管理書に載せる事項は、変更の名称、提案の責任者、年月日、変更の理由、変更に係る仕様を含む詳細、費用の額、検討期間を含むスケジュール、契約条件への影響の8つです。小さな変更でもこの書式を通すと、数十件たまった時点で「どれが範囲内で、どれが追加か」を一覧で示せます。 注意したいのは第37条第4項で、協議が調わない間、発注者からの中断要請などの特段の事情があればベンダーは作業を中断できると書かれています。変更の協議を先延ばしにすると、その間に作業が止まる可能性がある点まで織り込んでおきましょう。 ### 中間成果物を期限つきで承認する工程レビューと、みなし承認の扱い 品質を検収の時点で初めて確かめていては、直す時間が残りません。モデル契約第35条は、ベンダーが中間資料の承認を書面で求め、発注者が所定の点検期間内に結果を返す手続を置いています。期間内に具体的な理由を示した異議を出さなければ、承認したものとみなされます。 つまり、レビューを放置すると品質を確かめないまま承認したことになりかねません。点検期間は社内の決裁日程から逆算して現実的な日数を個別契約に書き、レビューの観点も事前に決めておきます。公共分野の手順として、デジタル庁の[デジタル社会推進標準ガイドライン](https://www.digital.go.jp/resources/standard%5Fguidelines)のページには「工程レビュー実施手順書一式」（2023年4月3日更新）が参考資料として掲載されており、工程の区切りで何を確かめるかを決める際の下敷きになります。最終的な受け入れの確かめ方は[受入テスト（UAT）の進め方と合否基準](https://www.issoh.co.jp/column/details/19414/)を参照してください。 ### 議事録の承認期限と、決定事項・継続検討事項・担当者を残す書き方 会議で決めたことが初めて効力を持つのは、その内容が議事録に残ったときです。第12条第6項は、ベンダーが議事録の原案を所定の日数以内に作り、発注者が受領後の所定期間内に点検し、具体的な理由を示した異議が無ければ承認したとみなすと定めています。第7項は、議事録に決定事項、継続検討事項、その検討スケジュールと担当者を必ず載せるよう求めています。 実務で抜けやすいのは継続検討事項の追跡です。議事録に書いたまま次の会議で触れられず、半年後に「決めていなかった」と判明する。これを防ぐには、継続検討事項を課題管理表に転記して期限と担当者で追う運用が向いています。項目の設計は[課題管理表に必要な項目とステータス設計](https://www.issoh.co.jp/column/details/19764/)にまとめています。 ## 偽装請負にならないベンダーコントロールの線引きと、指示を出す相手の決め方 ### 準委任契約でも発注者の直接指示は偽装請負になるという37号告示の基準 ベンダーコントロールを強めるほど近づくのが、偽装請負の線です。厚生労働省の[37号告示関係疑義応答集](https://www.mhlw.go.jp/bunya/koyou/gigi%5Foutou01.html)のうち[第3集（アジャイル型開発と契約方式）](https://www.mhlw.go.jp/content/001704257.pdf)は、請負だけでなく準委任契約でも、発注者と受注者側の労働者の間に指揮命令関係があれば、契約の形式を問わず労働者派遣事業に当たると明記しています。 判断は契約書の名前ではなく実態で行われます。請負は仕事の完成を目的とする契約（[民法](https://laws.e-gov.go.jp/law/129AC0000000089)第632条）、準委任は事務の処理を委託する契約（同第656条）ですが、どちらも発注者が受注者の労働者を直接指揮することは想定していません。2026年5月25日の更新で加わったQ8は、第3集の考え方がアジャイル以外のシステム開発を請負で行う場合にも当てはまると答えています。ウォーターフォールの案件でも同じ線が引かれると理解してください。 ### 発注者が伝えてよい要件・優先順位と、伝えてはいけない作業手順・労働時間 第3集の回答を整理すると、発注者側の行為は次のように分かれます。 | 発注者側の行為 | 扱い | 疑義応答集の該当 | | ------------------ | --------------- | -------- | | 要求事項の一覧と優先順位を決める | 問題ない | Q4 | | 要件の詳細を開発者へ直接説明する | それだけでは偽装請負にならない | Q4 | | 対等な立場での技術的な議論や提案 | それだけでは偽装請負にならない | Q5 | | 双方全員が参加する会議やチャット | それだけでは偽装請負にならない | Q6 | | 作業の割り付け・順序・緩急を直接指示 | 偽装請負と判断される | Q3 | | 業務の遂行方法や労働時間を直接指示 | 偽装請負と判断される | Q2・Q6 | 境目は「何を作るか」と「どう働くか」です。遅れを取り戻すために「今週はこの機能を先にやって、土曜も出てほしい」と開発者に直接頼むのは、後者に当たります。同じ要望でも、ベンダーの管理責任者に優先順位の変更として伝え、配置と順序の判断を受注者側に任せれば線の内側に収まります。Q3は、管理責任者を選任していても発注者が直接指示してしまえば偽装請負と判断されると明言している点に注意してください。 ### スキルシートの提出要求と、要員の指名・交代要求で線を越える場面の違い 要員の質を確かめたい場面にも線があります。Q7によると、発注者が特定の人を指名して業務に就かせたり、特定の人の就業を拒んだりすると、受注者の労働者の配置に発注者が関与したことになり、適正な請負等とは認められません。一方、技術レベルや経験年数を記したスキルシートの提出を求めること自体は、個人を特定できず、それをもとに指名や就業拒否ができない形であれば直ちに偽装請負とはされません。 要員の能力に不安があるときは、「この担当者を外してほしい」と言う代わりに、成果物の品質や遅延の事実を連絡協議会で示し、体制の見直しをベンダーに求めるのが筋です。モデル契約第11条も、業務従事者の選定と指揮命令はベンダーが行うと定めています。契約形態ごとの条項の書き分けは[業務委託契約書の請負・準委任の書き分けと必須条項](https://www.issoh.co.jp/column/details/19222/)で確認できます。 ## 発注者側の体制づくりと、PMOを外部に委託すべき案件・委託しない案件の判断 ### 責任者と主任担当者の2層で窓口を一本化する発注者側の最小体制 モデル契約は、双方が「責任者」（第9条）と、その下で日常の連絡と調整を担う「主任担当者」（第10条）を選任し、相手方への要請や指示の受け渡しを原則として主任担当者を通じて行うと定めています。この2層構造は、偽装請負を避ける意味でも、情報の行き違いを防ぐ意味でも理にかなっています。 小規模な案件なら、発注者側は決裁権を持つ責任者1名と、実務を回す主任担当者1名で足ります。現場の業務部門から要望が直接ベンダーに流れ込むと、変更管理の手続を素通りした依頼が増えるため、要望は必ず主任担当者が受けて取りまとめる、とルールを社内に周知しておきましょう。 ### 外部PMOに任せるべき案件は複数ベンダー並行と社内PM不在の2条件 統制の実務を外部のPMOに任せるかは、次の2つで判断します。1つは、複数のベンダーが並行して動き、第13条の調整責任を発注者が負う案件です。もう1つは、社内に開発プロジェクトを統制した経験者がいない案件です。どちらかに当てはまれば、進捗報告の読み解き、変更管理書の妥当性確認、工程レビューの観点づくりを外部に任せる価値があります。 ただし、要件の確定や変更の可否、検収の判断といった決定権まで外部に渡してはいけません。外部PMOの役割は判断材料を整えることで、決めるのは発注者側の責任者です。PMOの種類と社内に置く場合の違いは[PMOの役割・種類と外部に任せる判断](https://www.issoh.co.jp/column/details/19156/)で解説しています。一創では、開発を請け負わない立場で発注者側に立ち、進捗・課題・品質の管理や遅延プロジェクトの立て直しを支援する[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)を提供しています。 ### ベンダーコントロールを強めすぎて失敗するパターンと、緩めてよい案件の条件 統制は強いほどよいわけではありません。数百万円規模でパッケージを設定するだけの案件に、週次の連絡協議会と全変更の書面化を求めると、管理の工数が開発の工数に迫り、ベンダーは見積りに管理費を上乗せしてきます。この規模なら、月1回の報告と、費用や納期に影響する変更だけを書面にする運用で十分です。 逆に、緩めてはいけないのは、要件が固まりきらないまま開発に入る案件と、複数社が関わる案件です。前者は第36条の「未確定事項」の扱い、つまり確定予定時期と確定後の追加費用を受け入れることを書面で残す手続が要になります。後者は第13条のとおり、調整の責任が発注者に戻ってくるからです。この2つの条件が揃う案件で統制を省くのは、失敗の確率を自分から上げる判断だと考えてください。 ## よくある質問 ベンダーコントロールについて、発注者側の担当者からよく寄せられる質問をまとめました。 ### ベンダーコントロールとベンダーマネジメントは同じ意味ですか？ 重なる部分はありますが、範囲が違います。ベンダーコントロールは個別の案件で、契約から検収までの間に委託先の進捗・品質・変更を統制する活動を指すことが一般的です。ベンダーマネジメントは、取引しているベンダー全体を対象に、評価や集約、契約条件の見直しまで含めた継続的な管理を指します。情報システム部門の担当者が案件を任されたときに必要になるのは、まずベンダーコントロールの方です。 ### ベンダーコントロールにはどのようなスキルが必要ですか？ プログラミングの技能より、報告書から遅延の兆しを読み取る力と、契約条項を運用に落とす力が問われます。具体的には、完了した成果物と残作業を分けて進捗を見る力、変更が費用と納期に与える影響を見積もる力、社内の要望を取りまとめて優先順位を決める調整力です。IPAのモデル契約第12条や第37条を一度読み、自社の契約書と照らし合わせておくと、会議で何を確認すべきかが具体的になります。 ### 進捗報告はどれくらいの頻度で受けるのがよいですか？ 設計から開発工程は週1回、障害の多いテスト工程は週2回程度が目安です。月1回では、遅延に気づいてから手を打つまでに1か月近くかかります。逆に毎日の報告は双方の負担が大きく、報告書づくりが目的化しがちです。モデル契約第12条も、頻度は個別契約で定め、それに加えて必要なときに随時開催するという形を取っています。定例と臨時を組み合わせ、案件の規模とリスクに応じて契約時に決めてください。 ### 請負契約なら発注者は作業に口出しできないのですか？ 何を作るか、どの機能を優先するかを伝えることは問題ありません。厚生労働省の37号告示疑義応答集第3集でも、要求事項の詳細を説明したり情報を提供したりするだけでは偽装請負にならないとされています。避けるべきなのは、受注者側の開発者へ作業の順序や割り振り、労働時間を直接指示することです。要望はベンダーの管理責任者を通じて伝え、配置や手順の判断は受注者側に任せる、という分担を守れば、必要な統制は十分に効かせられます。 ### ベンダーから想定外の追加費用を請求されたらどうすればよいですか？ まず、請求の対象となった変更が、いつ、誰の依頼で、どの書面に記録されているかを確認します。変更管理書や議事録に記録があり双方が承認していれば、追加費用の協議に応じるのが筋です。記録が無い場合は、当初の要件定義書や外部設計書の範囲内だったかを根拠資料で突き合わせます。いずれにしても、今後の変更はモデル契約第37条のような書面の手続に乗せることを協議で合意し、同じ争いを繰り返さない形にしておきましょう。 ## 関連記事 - [プロジェクト進捗管理とは？遅延を防ぐ見える化の方法と会議運用の実務](https://www.issoh.co.jp/column/details/15672/)：進捗の見える化と会議運用をさらに詳しく扱っています。 - [ベンダーロックインとは？原因と回避策・契約で押さえる条項とリプレイスの判断基準](https://www.issoh.co.jp/column/details/19158/)：特定のベンダーに依存して統制が効かなくなる状態の防ぎ方です。 - [システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割](https://www.issoh.co.jp/column/details/15670/)：管理手法全般と発注者・ベンダーの役割分担の全体像です。 - [ベンダー選定とは？システム開発の発注先を決める流れと評価表の配点設計](https://www.issoh.co.jp/column/details/18684/)：統制しやすいベンダーを発注前に選ぶ観点です。 --- 出典: [ベンダーコントロールとは？発注者が進捗・品質・変更を握る方法と偽装請負にならない線引き]()（株式会社一創）