ベンダーコントロールとは？仕事内容とスキル｜SIer出身で発注側に立つ僕の実務

ベンダーコントロールとは、システムの開発を外部の会社（ベンダー）に任せるとき、発注側が進み具合・品質・費用を管理して計画どおりに完成させる仕事です。作る側の経験があるSIer出身者ほど進めやすい仕事ですが、「頼んだら終わり」ではありません。何を作るかを決め、作られたものを受け入れるかを判断するまでが発注側の役目です。

書いている僕は、2009年に新卒でSIerに入り、2016年にフリーランスのエンジニアとして独立しました。転職はしていません。 2025年4月からは、ある現場に業務委託で入り、情シス（情報システム部門）の立場で働いています。

その現場では、大きなシステムをベンダーに任せています。僕の担当は、要件定義からベンダーコントロール、受入テスト〜リリースまでです。関連するサブシステムは内製で作ることもあり、要件定義から関わりながら開発もしています。いまの現場を選んだのは、上流工程の経験を増やしたかったからです。

社内SEへの転職を考えている人は、SIerから社内SEへ転職する前に知っておきたい、発注側で評価される経験もあわせて読んでみてください。

ベンダーコントロールとは、発注側が外部の開発会社を管理して計画どおりに進める仕事

ベンダーコントロールとは、外部の開発会社に任せた仕事を、発注側が主導して計画どおりに進めることです。作業はベンダーが行い、発注側は「何を作るか」「どこまで進んだか」「受け入れてよいか」を判断します。

僕の担当にあてはめると、入口が要件定義で、出口が受入テストとリリースです。その間でベンダーの作業を見ていくのが、ベンダーコントロールの部分です。入口から出口までが一続きの仕事になっています。

意味と目的は品質・費用・納期を守ること

ベンダーコントロールの目的は、品質（Quality）・費用（Cost）・納期（Delivery）の3つを守ることです。頭文字をとってQCDと呼ばれます。3つは引っ張り合うので、どこを優先するかを発注側が決めるのがこの仕事の中心です。

ベンダーを思いどおりに動かす「支配」ではなく、発注側が方向を示して「リード」する仕事だと説明されることが一般的です。

ベンダーマネジメント・PMO・PMとの違い

似た言葉に、ベンダーマネジメント・PMO・PMがあります。会社によって使い分けが違うので、ここでは一般的な意味で並べます。

実際の求人では、ベンダーコントロールとベンダーマネジメントを区別せずに使うこともあります。

担当するのは社内SE・情シスやPMO

ベンダーコントロールは職種の名前ではなく、仕事の名前です。担当するのは、事業会社の社内SE・情シスや、発注側の管理を手伝うPMOが一般的です。

情シスと同じ意味ではなく、情シスの仕事の一部です。僕の場合は社員ではなく、業務委託で情シスの立場に入っています。

必要とされる理由は丸投げとブラックボックス化を防ぐため

発注側がベンダーコントロールをしないと、開発が丸投げになりやすくなります。丸投げで起きやすいのは次の3つです。

• 社内に知見が残らない：仕様の理由が誰にも分からなくなる（ブラックボックス化）
• 費用が見えなくなる：見積もりが高いか安いか判断できない
• ほかのベンダーに移れなくなる：中身を知るのがそのベンダーだけになる（ベンダーロックイン）

ベンダーコントロールの仕事内容を工程ごとに見る

ベンダーコントロールの仕事内容は、工程ごとに変わります。発注側とベンダーの仕事を並べると、次の図のようになります。

企画・要件定義：社内の要望を整理してベンダーに伝える

要件定義では、業務部門の要望を聞き、優先順位を付けて、ベンダーが作れる形の要件にまとめます。社内調整の比重がいちばん大きい工程で、「仕事の半分は社内調整」と言われることもあります。

部門ごとに食い違う要望から、何を入れて何を次に回すかを決め、理由を社内に説明するまでが発注側の仕事です。

僕自身は、要望と説明の両方を通訳する役回りです。業務部門の言葉はベンダーが作れる言葉に、ベンダーの言葉は業務部門が判断できる言葉に直します。

ベンダー選定と契約：見積もりと役割分担を確かめる

新しく開発を頼むときの一般的な流れは、次のとおりです。

1. 情報を集める：候補の会社に情報提供を依頼する（RFI）
2. 提案を依頼する：作りたいもの・予算・期間を書いた提案依頼書（RFP）を出す
3. 見積もりを比べる：複数社の見積もりを、前提をそろえて比べる
4. 契約を結ぶ：範囲・役割の分担・責任の境目（責任分界点）を書面に残す

見積もりで見落としやすいのは、範囲や追加費用の条件といった金額の前提です。運用が始まったあとの対応の水準を、SLA（サービスの品質の取り決め）として結ぶこともあります。

見積もりの妥当性をSIer出身者がどう見られるかは、SIerから社内SEへ転職する前に知っておきたい評価される経験で書きました。

設計・開発中：進み具合・課題・変更を管理する

開発が始まったら、ベンダーとの定例会などで進み具合・課題・リスク・変更の要望を確かめます。決まったことは議事録に、未解決のことは担当と期日を付けて課題の一覧に残します。仕様の変更は、作り終わってからだと作り直しと再テストが要るので、出すなら早いほど影響が小さくなります。

受入テスト：作られたものを業務の目で確かめる

受入テストでは、ベンダーが作ったものが契約どおりか、業務で使えるかを発注側が確かめます。合否の基準は、揉めないようにテストの前に決めておきます。

僕の場合、ベンダーが出してきた修正の受入テストは一般的なものより細かめです。確かめる細かさを単体テストのレベルまで下げ、そのうえで業務の観点からもパターンを洗い出しています。観点の例は社内SEはやめとけと言われる理由に書いたので、ここでは繰り返しません。

リリースと運用保守：切り替えとその後の改修

受入テストが終わったら、本番に切り替えるかを判断します（リリース判定）。切り替えと戻しの手順、社内への案内を確かめてから進めます。

リリースのあとは運用保守です。障害や改修の窓口になり、区切りでベンダーの仕事ぶりを振り返って次の契約に活かす会社もあります。

僕は保守運用も担当しています。大きなシステムはベンダーに任せ、サブシステムは内製で開発することもあります。

請負か準委任かで関わり方が変わる

ベンダーとの契約には、主に請負と準委任があります。

• 請負：ベンダーが完成に責任を持つ。発注側は成果物で確かめる
• 準委任：ベンダーは決めた作業をきちんと行うことに責任を持つ（完成までは約束しない）。進め方を途中で見直しやすい

気をつけたいのは、発注側がベンダーの作業者に直接指示を出してしまうことです。厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）は、請負と認められる条件の一つに、請け負った事業主が自分の雇う労働者への業務の遂行方法の指示などを自ら行うことを挙げています。告示が定める条件を満たさなければ、請負の形でも労働者派遣事業として扱われます。いわゆる偽装請負です。厚生労働省の疑義応答集は、派遣と請負のどちらにあたるかは契約の形式ではなく実態で判断するとしています。契約書の名前だけで決まるものではありません。

発注側の要望は、ベンダーの責任者を通して伝えるのが基本です。自分の現場で何が許されるかは、契約書と社内の法務部門、必要に応じて専門家に確かめてください。

受注側（SIer）と発注側で、同じ工程はこう違って見える

同じ工程でも、受注側のSIerにいるときと発注側に立つときとでは、やることが変わります。工程ごとに並べると、次のようになります。

この章の比べ方は、僕の経歴から来ています。キャリアの初めは作る側（ベンダー側）で、いまは頼む側（発注側）です。どちらの目線にも立てることは、僕にとって良かった点です。

要件定義は「聞き取ってまとめる」から「決めて伝える」へ

受注側の要件定義は、顧客の言葉を聞き取って仕様にまとめる仕事です。発注側では、社内で決めきってから渡す仕事に変わります。

2024年からの官公庁の案件で、僕はリーダーの仕事をしながら実作業も受け持ちました。この案件では、Power Platformで作ると最初に合意していました。そのため、細かい要望が出ても「Power Platformの仕様でできないです」が通りました。前提を先にそろえておくと、あとから出る要望への答え方がはっきりします。決めてから渡す発注側の要件定義でも、同じ考え方が使えます。

進捗管理は「報告する」から「報告を受けて判断する」へ

受注側の進捗管理は、遅れや課題を顧客に報告する仕事です。発注側は報告を受けて、何をするかを判断する側に回ります。

遅れが出たら、範囲を減らすか、期日を延ばすか、優先順位を付け直すかを決めます。社内への説明も要ります。報告を聞いて終わりにすると、判断が遅れた分だけ選べる手が減ります。

作る側の経験があると、遅れの裏で何が起きていそうかに当たりを付けやすくなります。

テストは「作ったものを確かめる」から「受け入れるかを決める」へ

受注側のテストは、作ったものが仕様どおりかを確かめるためのものです。発注側の受入テストは、業務で使えるかを見て、受け入れるかを決めるためのものです。受け入れたあとに見つかった問題は、発注側が社内に説明することになります。

僕自身、いまの立場に入る直前は「発注側は指示を出せば済む楽な仕事」と見ていました。その見立ては外れていて、実際には思っていた以上に手のかかる仕事です。

両方の目線があると伝言ゲームにならない

要望が人から人へ渡るうちに中身が変わっていく伝言ゲームは、昔の僕がつらかったものの一つです。届いた要望を発注側がそのまま流せば、自分がその伝言ゲームの一段になる。いまの立場で、僕はそう感じています。

だから発注側では、受け取った相手がすぐ動ける形に直して渡すことが大切です。要望の背景、決まっていること、まだ決まっていないことを分けて伝えるだけでも、相手の動きやすさは変わります。

一方で、ベンダーに寄りすぎて社内の要望を通せなくなる落とし穴もあります。最後は自社の業務を優先して判断する場面があります。

ベンダーコントロールに必要なスキル

ベンダーコントロールに必要なスキルは、開発の知識・業務の理解・伝える力・管理する力・契約の知識・調整する力の6つです。

開発の流れが分かるIT知識

ベンダーコントロールには、開発の流れを理解しているIT知識が要ります。求められるのは1つの技術の深さより、工程の流れ・見積もりの成り立ち・インフラやセキュリティの基礎といった広さです。僕はいまの現場でも、要件定義から関わりながら開発もしています。

自社の業務とシステムの理解

自社の業務と、いまあるシステムの理解も欠かせません。業務を知らないと要件を正しく伝えられず、受入テストの観点も作れないからです。

要望を言葉にして伝える力

あいまいな要望を、ベンダーが作れる粒度の言葉にする力が要ります。誰が、どの場面で、何に困っているのかまで書いて、作る側が動けるようになります。

僕は実装前の壁打ちや、設計書・テスト仕様書の作成にAIを使っています。曖昧な書き方をするとAIが勝手に解釈して話が進むので、曖昧な部分を残さないよう注意が要ります。そのために壁打ちがけっこう大切です。ベンダーに渡す要件でも、曖昧さを残さないことが大切なのは同じです。

進捗と課題を管理する力

進み具合と課題の管理では、個人の記憶に頼らないことが大切だと言われます。課題には担当と期日を付けて一覧に残し、定例会のたびに見直します。自分が休んでも状況を追える形にしておくと安心です。

契約と役割分担の知識

請負と準委任の違い、責任分界点、SLA、変更が出たときの扱いも知っておきたい知識です。法律の判断は自分だけで決めず、法務部門や専門家に相談するのが一般的です。

感情的にならずに調整する力

社内とベンダーの間で、感情的にならずに調整する力も欠かせません。

いつもすごく怒っているユーザーを相手にした経験が、僕にはあります。そのこともあって、受ける側にいても頼む側にいても、感情的にならずに仕事をしようと思っています。

会議で議論が少し白熱して、言い合いのような雰囲気になりかけたこともあります。そのときは、まず相手の意見をいったん受け入れてから、自分の考えを伝えるやり方を意識しました。おかげで、余計な言い合いに時間を使わずに済みました。

ベンダーコントロールが難しい・きついと言われる理由とよくある失敗

ベンダーコントロールが難しい・きついと言われる理由は、権限と責任のずれ、板挟み、コードを書く時間が減ることの3つです。僕自身も、入る前に思っていたより大変だと感じた一人です。

決める権限がないのに責任を負いやすい

決定権が上司や業務部門にあると、担当者は遅れの説明だけを背負いがちです。誰が何を決めるかは、入る前に確かめておきたい点です。

社内とベンダーの板挟みになる

社内は「早く・安く」を求め、ベンダーは「範囲を決めてほしい」と求めます。両方の事情が分かる人ほど消耗しやすくなります。SIer出身者の強みが、そのまま疲れやすさにつながることもあります。

コードを書く時間が減る

「つまらない」と言われるいちばんの理由は、コードを書く時間が減ることです。ベンダーに任せる体制では、自分で作る機会は少なくなります。

ただし職場によって違います。僕のいまの現場では、サブシステムを内製で開発することもあります。作る仕事を続けたい人は、求人の段階で内製の有無を確かめておくと安心です。

よくある失敗は丸投げ・細かすぎる指示・横流し

よく挙げられる失敗と、防ぎ方をまとめます。

それでも経験する価値がある理由

ベンダーコントロールの経験は、上流工程の経験として評価されやすいものです。2025年に僕が受けた業務委託の面談でも、「上流工程を任せられそうか」が重視されていると感じました。

ベンダーコントロールの経験を活かせるキャリア

ベンダーコントロールの経験を活かせる行き先は、社内SE・情シス、SIerのPM・PL、PMO・ITコンサル、フリーランスの4つです。僕自身は転職を考えずに独立したので、転職の経路は公開されている情報と、面談する側に入っている立場から書きます。

社内SE・情シスに移る

いちばん直結する行き先が、事業会社の社内SE・情シスです。求人の見分け方は、このあとの章で書きます。

SIerの中でPM・PLに進む

転職せずに、SIerの中でPM・PLに進む道もあります。ベンダー側で計画を率いる立場です。発注側が何を気にするかを知っていると、提案や報告の質が上がると言われます。PMに進む道筋は、SIerのキャリアパスで整理しています。

PMO・ITコンサルに移る

管理と調整を専門にしたいなら、PMOやITコンサルも候補です。ITコンサルを含めた比べ方は、SIerからの転職先の選び方にまとめています。

フリーランスとして発注側の案件に入る

フリーランスとして発注側の案件に入る道もあります。僕がいまやっている働き方です。

僕は2024年から、上流工程やリーダーの経験をしたくて案件を選ぶようにしました。その狙いはかないました。官公庁の案件ではリーダーの仕事をしながら実作業も受け持ち、2025年4月からの現場では要件定義から関わりながら開発もしています。2025年に案件を切り替えたときは、提案が5〜6件くらいあり、2社と面談してどちらも合格しました。期間は1か月くらいです。

会社員のうちから相談できるエージェントもあります。たとえばMidworksは、正社員からフリーランスへの転向を考えている人向けの案内も出しています。対象は、勤務地が関東・関西・愛知・福岡で、21〜59歳、エンジニアの経験がある方です。僕自身は使ったことがありません（対象の条件は2026年10月2日に、正社員向けの案内は2026年10月23日に公式サイトで確認）。

年収の目安は公開データで確かめる

厚生労働省の令和7年賃金構造基本統計調査（職種・第1表）から、IT系の2つの職種を取り出しました。

統計に「年収」の欄は無いので、表の「きまって支給する現金給与額」（毎月決まって支給される給与。残業代を含む）の12か月分に「年間賞与その他特別給与額」を足して、このサイトで計算した目安です（企業規模計〈10人以上〉・男女計・産業計の一般労働者の平均。1万円未満は四捨五入。出典の掲載は2026年10月23日に確認）。統計は「社内SEかどうか」では分かれていないので、上流の職種ほど高めに出る傾向として見てください。

ベンダーコントロールの経験は面接でどう伝わるか

ベンダーコントロールは伝える仕事なので、面接では受け答えそのものが見られます。ここで書くのは、業務委託のエンジニアを受け入れる面談で、僕が面談する側に入ったときの視点です。正社員の採用面接には関わったことがありません。

面談する側は質問と答えが噛み合うかを見ている

面談する側に入って感じるのは、質問と答えが噛み合っているかどうかが大きいということです。噛み合っていない人とは仕事がしにくそうだと感じ、受け答えがしっかりしている人には安心して任せられそうだと感じます。スキルシートでは、まずスキルが現場に合っているかを見ます。合っていなくても、それでもいいと思える観点があれば大丈夫です。

ベンダーコントロールも、質問の意図を外さずに答え続ける仕事です。面接の受け答え自体が、その力の証拠になります。

上流を任せられそうかが見られた2025年の面談

2025年4月に案件を切り替えたとき、僕は受ける側として面談に臨みました。技術的なことも聞かれましたが、どちらかというと「業務の話ができそうか」「質疑応答がずれていないか」「上流工程を任せられそうか」が重視されていると感じました。

僕は「これまでの開発経験を活かして、上流工程の経験を増やしていきたい」と説明しました。会社員時代に要件定義やリーダーの仕事を少ししていたので、その経験をもっと増やしたいという形で話しています。盛りすぎず、印象良く伝わるようには意識しました。

職務経歴書には工程と場面を書く

職務経歴書では、「ベンダー管理を担当」の一行で済ませず、工程と場面を書くのが一般的なコツです。

• 関わった工程（要件定義・ベンダー選定・進捗管理・受入テスト・リリース判定など）
• 自分が決めたこと（優先順位、仕様、リリースの可否）
• 受入テストで見つけた問題の種類と、その後の対応

受注側での見積もりや要件定義の経験も書けます。書き方は職務経歴書の書き方で、答え方は転職面接でよく聞かれる質問で詳しく書いています。

求人票の「ベンダーコントロール」の見分け方

求人票の「ベンダーコントロール」は、関わる工程の広さと決める権限の有無で見分けます。同じ言葉でも、中身はかなり違います。

理想は右上の「上流から任される」です。右下の「責任だけ重い」には注意します。

取り次ぎだけか、要件定義から関わるか

求人票の言葉は、次のように読み分けられます。

• 「ベンダーとの調整」：連絡の取り次ぎが中心のこともある
• 「ベンダー管理」「ベンダーコントロール」：進捗の管理が中心か、要件定義から入るかは求人による
• 「PMO」：発注側の社員か、外部からの常駐かを確かめる

決める権限と体制を確かめる

決める権限と職場の体制も、次の点で確かめておきます。

• 情シスの人数と、自分の役割
• 付き合うベンダーの数
• 予算や仕様を最終的に誰が決めるか
• 内製で開発する部分があるか
• 外部の会社から常駐するPMOを、社内SEとして募集していないか

面接で聞くと分かること

求人票で分からないことは、面接の逆質問で聞くのが確実です。

僕が業務委託の面談で実際にした質問の一つが、「現場で、私に求められている役割はどういうことがありますか？」です。転職の面接でもそのまま使えます。

ほかに、次のような質問も考えられます（僕の実例ではなく作例です）。

• 入社後、最初に担当する工程はどこですか
• ベンダーとの定例会には、どなたが出ていますか
• 仕様を最終的に決めるのは、どの部署の方ですか

答えから、図のどこに近い仕事かが見えてきます。

社内SEの求人に強いサービスで探す

求人探しには、社内SEの求人に強い転職サービスが近道です。サービスには型があります。

• 社内SE特化型：社内SE・情シスの求人に絞って探せる
• エージェント型：担当者と相談しながら、求人の紹介や面接の準備を進める
• 転職サイト型：自分で求人を検索し、企業からのスカウトも届く

転職をしていないので、ここで紹介する3つは僕自身どれも使ったことがありません。行き先別の選び方は、SIerの転職エージェントの選び方で比べています。

ベンダーコントロールに役立つ資格とよくある質問

資格は必須ではない

ベンダーコントロールに必須の資格はありません。僕自身、IT系の資格は持っていません。基本情報技術者試験は2009年の入社前後に2〜3回くらい、応用情報技術者試験は2010年過ぎにたぶん1回くらい受けましたが、どちらも不合格でした。

当時はなんだか楽観的で、無くてもいけるだろうと思っていました。実際、資格が無くて実務で困ったことはありません。ただ、資格は要らないと言いたいわけではありません。取れるに越したことはなく、僕は取れなかっただけです。資格が役立つ場面と、資格なしで働いてきた経緯はエンジニアに資格はいらない？にまとめています。

役立つ資格

ベンダーコントロールに関わる知識は、IPA（情報処理推進機構）の情報処理技術者試験で学べます。

• ITパスポート試験・情報セキュリティマネジメント試験：ITと情報セキュリティの基礎。業務部門との会話の土台になる
• 応用情報技術者試験：技術から管理・戦略まで、上流に必要な知識を広く問われる
• プロジェクトマネージャ試験：プロジェクトの計画と管理を担う人向け
• ITストラテジスト試験：経営の戦略にもとづくIT活用の計画
• ITサービスマネージャ試験：システムの運用とサービスの改善
• システム監査技術者試験：システムを独立した立場で評価する監査

IPAは、2027年度から新試験制度に移行することを予定していると公表しています（情報処理技術者試験制度の見直し、2026年10月23日確認）。これから受ける人は、試験区分を公式サイトで確かめてから準備してください。

未経験でも担当になれる？

開発か業務の経験のどちらかが入口になることが多いと言われます。この記事で紹介した3つの転職サービスは、いずれも未経験の方が対象外になることがあります。

英語は必要？

国内の開発なら多くはありません。外資系の企業や海外のベンダーと組む案件では、英語の資料を読む力が求められることがあります。

残業や忙しさはどのくらい？

忙しさは、リリースの前や障害のときに偏るのが一般的です。職場による差が大きいので、面接で聞いておくと安心です。僕の場合は、月20日ほど、9時から18時までのフルリモートで働いています。

まとめ：ベンダーコントロールは作る側の経験を発注側で活かす仕事

ベンダーコントロールは、発注側がベンダーに任せた開発の品質・費用・納期を管理して、計画どおりに完成させる仕事です。

• 工程ごとに中身が変わる：要件を決め、見積もりを確かめ、進み具合を見て、受け入れるかを決める
• 受注側の経験は活きる：相手の事情が分かるのは強み。社内で決めきる力は発注側で身につける
• 求人は工程と権限で見分ける：取り次ぎだけか、要件定義から任されるかを確かめる

作る側の経験は、発注側に立っても無駄になりません。社内SE以外も含めた行き先と進め方は、SIerからの転職先と進め方で全体を整理しています。