社内SEや情シスの求人を見ていると、「ベンダーコントロール経験者歓迎」「ベンダーコントロール業務あり」という書き方によく出会います。言葉からなんとなく想像はつくものの、実際に何を任されるのか、手を動かさなくなって技術が落ちないのかが分からず、応募の手が止まっていませんか?
先に結論を言うと、ベンダーコントロールとは、システム開発や運用を外部に任せている企業の側で、社内SE・情シスがベンダーの進捗・品質・コスト・契約を管理し、自社が判断を手放さないようにする仕事です。ただし求人票に書かれた「ベンダーコントロール」には、企画から関われるポジションもあれば、問い合わせを取り次ぐだけのポジションも混ざっています。
この記事では、仕事内容と必要なスキルを押さえたうえで、求人票の見方、やめておくべき求人の特徴、探し方と相談先までを順番に解説します。
目次
ベンダーコントロールとは?意味をわかりやすく解説
ベンダーコントロールの意味
ベンダーコントロールとは、システム開発や運用を外部委託している企業(ユーザー企業)の社内SEや情シス(情報システム部門)が、外部ベンダーの進捗・品質・コスト・契約を管理し、自社として必要な判断を下していく業務のことです。
前提として、システムやサービスを提供するIT企業が「ベンダー(売る側)」、それを発注して使う企業が「ユーザー企業(買う側)」にあたります。ベンダーコントロールは独立した職種名ではなく、発注側の社内SE・情シスが担う業務の呼び名です。とはいえ求人票では「ベンダーコントロール担当」のように、職種名に近い使われ方をしている例もあります。
誤解されやすいのが、コントロールという言葉の響きでしょう。ベンダーのエンジニアを思いどおりに動かしたり、強く詰めたりする仕事を想像するかもしれませんが、実態は違います。コントロールする対象は品質・コスト・納期のバランスとプロジェクトの進行であって、ベンダーという会社や人ではありません。
ベンダーの専門性は最大限に借りつつ、自社が決めるべきことは自社で決める。この線引きを守り続けることが、ベンダーコントロールの本質です。
ベンダーコントロールが必要になる理由
外部ベンダーはシステム構築のプロですが、発注側の固有業務や社内事情、現場の運用フローまで知っているわけではありません。自社の業務とシステムの関係を理解している社内SE・情シスが間に立たないと、要件の精度はどうしても落ちます。
開発の現場には、ベンダーだけでは決められないこともあります。追加で出てきた要望の優先順位、仕様変更にともなう納期延長や追加費用の承認、テスト結果を踏まえたリリース可否の判断。いずれも発注側にしか下せない判断で、ここが遅れるとベンダーの作業も止まり、最終的には納期遅延や追加費用として自社に返ってきます。
丸投げによる失敗も、この構造から生まれます。
たとえば情シスがベンダーから「順調です」と報告を受けるだけで、途中の成果物をほとんど確認しないまま開発を進めたとします。受入テストの段階になって初めて、画面や機能が現場の業務フローに合っていないと分かれば、設計まで戻ってやり直すしかありません。途中で一度でも画面イメージを現場に見せていれば、小さな修正で済んだ話です。
外部委託とは作業を渡すことであって、判断を渡すことではありません。
なお、IPA(独立行政法人情報処理推進機構)は「情報システム・モデル取引・契約書」を公開しており、ユーザー企業とITベンダーが開発の各段階で担うべき責務の解説と、契約書のひな型を提供しています(出典:IPA「システム開発の健全化に向けて~『情報システム・モデル取引・契約書』から読み解く~」)。発注側にも果たすべき役割があることは、公的な資料でも前提になっているわけです。
ベンダーマネジメント・PMO・ベンダー調整との違い
実務や求人票で混同されやすい言葉との違いを整理しておきます。
| 用語 | 主な範囲 | 時間軸・視点 |
|---|---|---|
| ベンダーコントロール | 個別プロジェクトの発注後の進行管理が中心 | 着手〜検収までのプロジェクト単位 |
| ベンダーマネジメント | ベンダーの選定・契約・評価・関係維持まで含む | 中長期の取引・調達の視点 |
| PMO | プロジェクト管理の仕組みや事務局機能を支える | プロジェクト横断・組織支援 |
| ベンダー調整・折衝 | 日々の連絡、仕様のすり合わせ、条件交渉 | 日常的なやりとり |
ただ、実際の求人票でこれらの言葉が厳密に使い分けられているとは限りません。受注側のPMOとして客先に常駐する求人に「ベンダーコントロール」と書かれている例もあります。
求人を見るときに頼るべきは言葉ではなく、どの工程に関わり、何を決める立場で、雇用元がどこなのかという中身です。この見方は、後半の求人の見極めでも軸になります。
ベンダーコントロールの仕事内容
工程ごとに見る仕事の流れ
システム開発の流れに沿って、社内SE・情シスが何を担い、どこで判断するのかを並べると、仕事の全体像がつかみやすくなります。
| 工程 | 社内SE・情シスがやること | 発注側が判断する場面 |
|---|---|---|
| 企画・要求整理 | 現場ヒアリング、課題の整理、目的と予算の整理 | 何を作り、何を作らないか |
| ベンダー選定 | RFI・RFP、相見積もり、提案内容の確認 | どのベンダーに任せるか |
| 契約 | 契約形態、納品物、検収条件、責任範囲の確認 | 何をもって完了とするか |
| 設計・開発 | 定例会、進捗・課題・リスクの確認、仕様変更の受付 | 変更を受けるか、追加費用を認めるか |
| テスト・検収 | 受入テスト、不具合の確認、検収準備 | リリースしてよいか、検収するか |
| 運用・保守 | 障害時の窓口、改善要望の管理、保守範囲の確認 | 次の改修の優先度と予算 |
この全工程を一気通貫で担うポジションもあれば、運用・保守の窓口だけを受け持つポジションもあります。同じベンダーコントロールでも、表のどこからどこまでを担当するかで、身につく経験は大きく変わります。
定例会で実際にチェックしていること
ベンダーとの定例会に出て、報告を聞いて終わりでは管理になりません。大事なのは、出てきた情報をそのまま受け取らず、プロジェクトの状態を具体的に把握することです。
たとえば「進捗80%」という報告だけでは、何が終わっているのか分かりません。コードを書き終えた状態を80%と呼ぶ会社もあれば、単体テストまで通った状態を80%と呼ぶ会社もあるからです。そこで「どの機能が単体テストまで終わったのか」というように、工程名と状態で確認します。
会議で出た事項は、決まったこと・検討中のこと・やらないことに分けて管理し、検討中のものには「誰が、いつまでに判断するか」を必ず添えます。まだ起きていない懸念(リスク)と、すでに起きている問題も別々に追います。両者を同じ一覧に混ぜると目の前の火消しばかりが優先され、予防が後回しになるからです。
仕様変更も、その場の交渉で片づけてはいけません。受付窓口、工数・納期・費用への影響を回答する期限、承認者をあらかじめ決めておけば、変更の話は交渉ではなく手続きになります。
「順調です」という報告が何週も続くときは、むしろ聞き方を変えるタイミングです。「今週、予定と違ったことは何でしたか」と具体的に尋ねると、まだ問題になる前の小さな引っかかりが言葉になって出てきます。
社内調整も仕事の半分を占める
名前に反して、ベンダーコントロールでは社内側の調整にもかなりの時間を使います。
利用部門から要望を集めて優先順位を整理し、経営層や上長には進捗・リスク・追加予算の見込みを報告します。予算申請や稟議、社内会議に付議するための資料作りも、多くは情シスの担当です。ITに詳しくない社内ユーザーと、技術用語で話すベンダーの間に入って、双方が理解できる言葉に置き換える翻訳役も欠かせません。
資料作成、会議の運営、根回し。実務は想像以上に泥臭い仕事の積み重ねです。
契約形態によって関わり方が変わる
ベンダーとの契約形態によっても、発注側の関わり方は変わります。
| 契約形態 | ベンダーが負うもの | 使われやすい工程 |
|---|---|---|
| 請負契約 | 成果物を完成させる責任 | 仕様が固まった設計・開発・テスト |
| 準委任契約 | 業務を専門家として適切に遂行する責任 | 要件定義、運用支援など内容が動きやすい工程 |
請負契約なのに、発注側の担当者がベンダーの作業者へ直接こまかく作業指示を出すと、偽装請負とみなされるおそれがあります。ベンダーを詰めて直接動かすやり方は、進行上だけでなく法的にも危ういわけです。請負で効かせるべきは指示ではなく、受入条件と変更手続きの設計です。
もうひとつ押さえておきたいのがベンダーロックインです。ソースコードは納品されていても、設計書や環境構築手順、運用手順が社内に残っていなければ、別のベンダーへの切り替えも、自社での判断もできなくなります。納品物の範囲や権利関係、契約終了時の引き継ぎ条件を契約の段階で確認しておくことも、発注側の大事な仕事です。
ベンダーコントロールに必要なスキルと知識
ベンダーコントロールでいちばん強みになるのは、受注側で開発や運用を経験していることです。見積もりにどの程度の余裕が積まれているのか、「順調です」という報告の裏で何が起きているのかを、作る側の感覚で読めるからです。
開発未経験で情シスに異動した人でも、以下の知識を順番に身につければ担当はできます。
ITの基礎知識(深さより広さ)
求められるのは、ひとつの技術を深く極めることより、幅広く知っていることです。
目安は、ベンダーの提案や見積もりについて会話が成立し、その内容が自社にとって妥当かを判断できる水準。実装そのものはベンダーが担う領域なので、すべてを自分で構築できる必要はありません。開発工程の流れ、ネットワーク・サーバー・クラウドの基礎、データベースやAPI連携の概要、セキュリティの基本あたりを広く押さえておけば、定例会の会話についていけなくなることはまずないでしょう。
インフラ案件を担当するなら、ネットワークやサーバーの知識の比重は一段上がります。
自社の業務と社内システムの理解
技術知識だけでは判断できない場面も多くあります。
現行システムの構成と他システムとの連携、実際の業務フロー、運用ルール、過去の障害や問い合わせの履歴。こうした情報はベンダーの手元にはなく、自社の人間にしか分かりません。ベンダーが持っていない情報を持っていることこそ、発注側の価値です。
技術的にどれだけ優れた提案でも、自社の現場で使えなければ意味がありません。その判定ができるのは、業務を知っている発注側だけです。
進行管理を個人技にしない力
担当者の勘だけで回すのではなく、進行管理を型に落とし込む力も求められます。報告フォーマットを統一する、仕様変更の手続きを決める、課題管理表の更新ルールを作るといった仕組みがあれば、担当者が変わってもプロジェクトの状況を追えるようになります。
この力は転職でも効きます。「課題を管理しました」ではなく「課題管理のルールを作り、複数の関係者が同じ方法で進捗を確認できる状態にした」と説明できれば、面接官に仕事の中身がそのまま伝わります。
伝え方・交渉の力
ベンダーへの依頼は、どう作るか(How)より、何を実現したいのか・なぜ必要なのか(What/Why)を明確に伝えるのが基本です。発注側が実装方法まで細かく指定すると、その方法に欠陥があっても「指示どおりに作りました」で終わってしまい、ベンダーの専門性も活かせません。
依頼内容そのものも具体的にします。「ポイントが付くようにしてほしい」では要件として曖昧すぎます。購入後のどのタイミングで、どんな条件を満たしたときに、何%のポイントを付けるのかまで社内で決めてから渡すのが発注側の仕事です。
ベンダーを下請けのように扱うのも得策ではありません。一方的に責任を押し付ける発注者に対して、ベンダーはリスク分を上乗せした見積もりで身を守り、改善提案も出さなくなります。必要な情報を早く渡す、自社側の承認やテストデータの準備を滞らせないといった振る舞いは、精神論ではなく、コストと品質に直接はね返る実務の話です。
役立つ資格と、状況別の学び方
資格がなくてもベンダーコントロールの仕事はできます。ただ、知識を体系的に整理する教材としては使えます。
開発未経験で情シスに来た人なら、まずは基本情報技術者試験の学習がおすすめです。出題範囲にはプログラミングだけでなく、システム開発の工程、プロジェクトマネジメント、サービスマネジメント、システム戦略まで含まれているため、ベンダーとの会話に出てくる用語を一通り押さえられます。いきなりはハードルが高いと感じるなら、ITパスポートから入っても構いません。
進行管理を体系的に身につけたいなら、プロジェクトマネージャ試験の過去問が実務に近い教材になります。午後の問題は架空のプロジェクトで起きた遅延や品質問題、要件の変更などを題材に、どう対応するかを記述させる形式です。過去問と解答例はIPAのサイトで無料公開されているので、受験しなくても、定例会で判断に迷う場面の引き出しを増やす読み物として使えます。
将来的に上流工程やIT企画を狙う人には、ITストラテジスト試験やITコーディネータが合っています。経営課題からIT投資を組み立てる考え方が問われるため、予算策定や企画から関わる求人を目指すときの土台になります。
契約まわりを押さえたい場合は、資格よりもIPAの「情報システム・モデル取引・契約書」の解説部分を読むほうが近道です。工程ごとに契約形態を分ける考え方や、ユーザー企業とベンダーの役割分担が整理されています。
ベンダーコントロールはきつい?つまらない?向き不向き
きつい・つまらないと言われる理由
ベンダーコントロールがきつい、つまらないと言われる理由は、仕事の性質そのものにあります。
自分でコードを書いてシステムを作るわけではないので、ものづくりの達成感は得にくくなります。社内ユーザーからは「もっと早くしてほしい」と言われ、ベンダーからは「仕様が固まらないと進められない」と返される。そんな板挟みも日常的です。トラブルが起きれば、作ったのがベンダーであっても、社内から説明を求められるのは発注側の情シスです。
忙しさの波もあります。要件定義の時期とリリース前は業務が集中し、安定稼働に入ると落ち着く。プロジェクトの状況しだいで業務量が大きく変わる仕事です。
それでも経験する価値がある理由
受注側ではなかなか経験できない、発注する側の視点が身につくからです。
何を作るかを決め、ベンダーを選び、見積もりを精査し、契約し、進捗を管理して、最後に検収する。この一連の流れを発注側として回した経験があると、システム開発をプロジェクト全体から見られるようになります。PM、IT企画、ITコンサルタントなど、より上流の仕事を目指すなら直接つながる経験です。
職務経歴書にも、「ベンダーと調整した」ではなく「どのシステムで、どの工程から関わり、何を判断したか」まで書けるようになります。
向いている人・向いていない人
コードを書き続けたい人、ひとつの技術を深く極めたい人には、ベンダーコントロールは向いていません。実装に関わる機会がはっきり減るからです。
反対に、将来PMや上流工程、IT企画へ進みたい人にとっては近道になります。曖昧な仕様や返答をそのままにせず具体化できる人、決定事項と経緯を記録に残せる人、社内とベンダー双方の言い分を整理して着地点を作れる人なら、この仕事で強みを発揮できます。
注意が必要なのは、対立を避けたい気持ちが強く、ベンダーに言うべきことを言えない人です。相手の説明をそのまま受け入れ続けると、結果的に丸投げになり、発注側として判断する機会そのものを失います。
「技術力が落ちるのでは」という不安にも答えておきます。実装から離れれば、プログラミングやインフラ構築の腕は確実に鈍ります。ただし、提案や見積もりの良し悪しを見抜く技術の目利きは伸びます。どちらを今後のキャリアの資産にしたいかで、進むかどうかを決めてください。
求人票の「ベンダーコントロール」の見方と見極め方
ベンダーコントロールという言葉が指す業務は、求人によって大きく異なります。給与や休日、残業など社内SE求人全般の見方は別の記事で扱っているので、ここでは「ベンダーコントロール」と書かれた求人に特有の確認ポイントに絞ります。
求人の「ベンダーコントロール」は4タイプに分かれる
求人票に書かれたベンダーコントロールは、大きく4つのタイプに分けて考えると見分けやすくなります。
| タイプ | 求人票での書かれ方 | 身につくもの | 注意点 |
|---|---|---|---|
| 企画・上流主導型 | 「要件定義から」「IT戦略」「システム企画」「予算策定」 | 上流企画、予算管理、IT戦略 | 業務理解や社内調整の負荷も大きい |
| 進行管理型 | 「プロジェクト推進」「進捗・品質管理」「定例会運営」 | QCD管理、リスク管理、PMに近い経験 | 調整業務の比重が高い |
| 取次ぎ・窓口型 | 「ベンダーとの調整」「問い合わせ対応」「窓口業務」 | 調整力、運用対応 | 判断や企画の経験が積みにくい |
| 常駐PMO型 | 「PMO」「顧客先」「プロジェクト先」 | プロジェクト管理の実務 | 雇用元と勤務地の確認が必須 |
同じ「ベンダーコントロール経験者歓迎」でも、身につくものとキャリアへの効き方はまるで違います。見るべきは言葉そのものではなく、その後ろに何が書かれているかです。
求人票で確認したいポイント
最初に見るのは、どの工程に関わるかです。「要件定義から」「ベンダー選定から」と書かれていれば、発注側として上流から関われる見込みがあります。逆に「問い合わせ対応」「ベンダー窓口」としか書かれていない求人は、運用保守の取次ぎが中心と見ておいたほうが安全です。
次に、対象システムとベンダーの体制です。基幹システムの刷新を複数ベンダーと進める立場なら、接点の線引きや全体の進行管理まで任されます。SaaS導入が中心の会社なら、仕事の重心は製品選定と導入後の運用設計に寄ります。担当システムの種類とベンダーの社数が書かれていれば、入社後の仕事はかなり具体的に想像できます。
社内のIT体制も重要です。情シスが何人いるのか、ひとり情シスなのか。ひとり情シスの場合、ヘルプデスクやアカウント管理などの日常業務に時間を取られ、プロジェクトに腰を据えられない可能性が高くなります。
そして見落とせないのが決定権限です。予算、発注、仕様変更、検収について、現場の情シスがどこまで判断できるのか。権限がないのにトラブル時の説明責任だけ負う環境では、ベンダーコントロールの経験は積めません。
内製化の方針も、自分のキャリアとの相性を左右します。今後も外注中心で進めるなら発注側のスキルが伸び、内製化に舵を切るなら自分で手を動かす機会が増えていきます。
最後に、雇用元と勤務地です。社内SEや情シスと書いてあっても、雇用元がSES企業やSIerで、勤務地が顧客先という求人は実際にあります。
求人票に書かれていない項目は、問題がないのではなく、面接で確認すべき項目だと捉えてください。
面接で確認しておきたい質問
求人票だけでは分からないことは、面接で直接聞くのが確実です。質問と、そこから分かることを表にまとめました。
| 質問 | 分かること |
|---|---|
| 現在、何社のベンダーと、主にどのシステムで取引されていますか? | 管理する規模と、マルチベンダー環境かどうか |
| 入社後に担当するのは、どの工程からでしょうか? | 上流から関われるポジションか、運用窓口中心か |
| 仕様変更や追加費用が発生した場合、誰がどのように承認していますか? | 発注側の決定権限がどこにあるか |
| 設計書や運用手順書は、社内にどの程度そろっていますか? | システムのブラックボックス化の度合い |
| 今後、システム開発の内製化を進める予定はありますか? | 入社後に自分で手を動かす機会が増えるかどうか |
| 前任の方は、どのような経緯でこのポジションを離れられたのでしょうか? | 欠員補充か増員か、ポジションの負荷の実態 |
最後の質問は聞きにくいと感じるかもしれませんが、答えの歯切れの悪さそのものが判断材料になります。
やめておくべきベンダーコントロール求人の特徴
ベンダーコントロールと書いてあれば、どんな求人でもよいわけではありません。仕事内容を確かめずに入社すると、想像していた発注側のIT業務ではなく、単なる窓口業務だったということも起こります。求人票や面接で見分けたい4つのパターンを紹介します。
①名ばかりで「取次ぎ」しかしない求人
社内ユーザーからの問い合わせや改善要望をベンダーへ転送し、返ってきた回答を社内に戻すだけの仕事です。仕様の妥当性を確かめたり、設計書をレビューしたり、優先順位を決めたりする場面がありません。
ベンダーコントロールという名前が付いていても、発注側としての判断経験はほとんど残らず、次の転職で職務経歴書に書ける中身も乏しくなります。求人票に「ベンダーとの調整」「問い合わせ対応」としか書かれていないなら、自分がどこまで判断するのかを面接で必ず確かめましょう。
②決める権限がないのに責任だけ負う求人
追加予算の承認、仕様変更の受入可否、リリースの判断は上長や別部署が決めるのに、遅延や障害が起きたときだけ情シスが説明を求められる求人です。
板挟みの負担だけが大きく、判断の経験は積めません。面接では「仕様変更や追加費用は誰が決裁するのか」「現場の担当者にはどこまで決定権があるのか」を具体的に聞いてください。
③社内SE求人に見せかけた常駐PMO求人
求人タイトルには「社内SE」「情シス支援」とあるものの、雇用元はSES企業やSIerで、実際には顧客先に常駐する求人です。
常駐先で発注側に近い業務を経験できる場合はあります。ただ、立場はあくまで外部の要員で、クライアント企業の社員として決裁権限を持つことはなく、契約が終われば現場も変わります。自社に腰を据えて社内SEとして働きたいなら、このタイプはやめておくべきです。
とはいえ、いずれ事業会社の情シスへ移るための足場として、まず発注側に近い実務を経験すると割り切れるなら、選ぶ価値はあります。避けたいのは、社内SEへの転職だと思って応募し、入社してから客先常駐だと気づくミスマッチです。
SESからのキャリアの選び方は、SESからのキャリアアップ方法でも詳しく解説しています。
④ベンダー任せでブラックボックス化した現場を一人で背負う求人
ひとり情シス、長年同じベンダーに任せきり、社内に設計書や手順書がない。この3つが重なる求人には注意が必要です。
システムを立て直すための予算と権限が与えられているなら、大きな経験になります。反対に、権限も予算もないまま入社すると、誰も仕組みを理解していないシステムの責任者として、障害対応と問い合わせに追われるだけになりかねません。
先ほどの面接の質問のうち、設計書の整備状況と、ベンダー変更を含めた改善の権限があるかの2点を聞けば、このパターンはかなりの確率で見抜けます。
ベンダーコントロール求人の探し方・選び方
求人が見つからないときは検索ワードを変える
転職サイトで「ベンダーコントロール」と検索しても、思ったほど求人が出てこないことがあります。企業側が、同じ仕事を別の言葉で書いていることが多いからです。
検索ワードは、次のような言葉にも広げてみてください。
- ベンダーマネジメント
- 外部委託先管理
- システム企画・IT企画
- プロジェクト推進
- 情報システム部門・社内SE
- DX推進(ユーザー企業側)
「PMO」で探す方法もありますが、SES・SIer・コンサル企業が顧客先に常駐する求人が多く混ざります。PMOでヒットした求人は、雇用元と勤務地を必ず見てから判断しましょう。
これまでの経歴から狙う求人タイプを選ぶ
最初に狙う求人タイプは、これまでの経験で決めるのがミスマッチを減らす近道です。
SIerやSESで開発・運用を経験してきた人は、まず進行管理型の社内SE求人を狙ってください。定例会での進捗確認や課題管理は、受注側として見てきた進め方の知識がそのまま活きる領域です。ベンダーの報告の裏側が読めることは、面接でも具体的な強みとして語れます。
リーダーやPMの経験がある人なら、企画・上流主導型まで十分に届きます。要件定義だけでなく、予算策定やIT企画など発注側の意思決定に関わる求人を選ぶことで、マネジメント経験を一段広げられます。
インフラエンジニア出身なら、基盤更改やクラウド移行のプロジェクトを抱えている企業の発注側求人と相性が良好です。自分が詳しい領域の案件から入れば、技術面の強みを武器にしたままベンダーコントロールの経験を積めます。
IT未経験の場合、いきなりベンダーコントロール中心の求人を狙うのはおすすめしません。まずはヘルプデスクや情シスの運用保守など社内システムに触れる仕事から入り、ベンダー対応や小規模な案件管理へと担当範囲を広げていく順番が現実的です。
相談先は社内SE・情シスに強い転職エージェント
ここまでの見極めを、求人票と面接だけで完璧にこなすのは正直難しいところです。取引しているベンダーの社数や内製化の方針、前任者が辞めた理由といった情報は、求人票にはまず書かれません。面接で聞けるのも、選考に進んでからです。
そこで頼りになるのが、社内SE・情シスの求人に強い転職エージェントです。企業の採用担当とやりとりを重ねているエージェントなら、こうした内情をある程度把握しているケースがあり、応募前の段階で確認してもらうこともできます。
職務経歴書の添削でも力を借りられます。「ベンダーと調整した」と書くだけでは、取次ぎ型なのか進行管理型なのかが読み手に伝わりません。何社のベンダーを、どの規模のプロジェクトで、どの工程から管理し、何を判断したのか。この形で整理し直すだけで、発注側の実績として評価されやすくなります。
常駐PMO型の求人を避けたい人なら、社内SE転職ナビのように、客先常駐がないことを社内SEの条件として求人を扱っている専門サービスを使うのも手堅い方法です。
社内SE向けの転職サイト・エージェントの比較は、社内SEにおすすめの転職サイト・エージェントでまとめています。
ベンダーコントロールに関するよくある質問
Q. 未経験でもベンダーコントロールの仕事に就けますか?
IT未経験の人が、いきなりベンダーコントロールを主担当として任される求人は多くありません。ヘルプデスクや情シスの運用保守から入り、社内システムとベンダー対応の経験を積んでから担当範囲を広げるのが現実的なルートです。
Q. 情シスとベンダーコントロールは同じ意味ですか?
同じではありません。情シスは部署の名前で、その仕事にはヘルプデスク、アカウント管理、PCやネットワークの運用、セキュリティ対策なども含まれます。ベンダーコントロールは、その中で外部ベンダーとのプロジェクトを管理する業務を指す言葉です。外注の比率が高い会社ほど、情シスの仕事に占めるベンダーコントロールの割合は大きくなります。
Q. ベンダーコントロールとPM(プロジェクトマネージャー)は何が違いますか?
PMはプロジェクト全体を計画し、最後まで成立させる責任者です。ベンダーコントロールは、発注側の立場から外部ベンダーの進行を管理し、自社として必要な判断を下す業務を指します。
実際には企業ごとに役割分担が異なり、社内SEがPMに近い役割まで担う会社もあります。職種名ではなく、担当範囲で判断するのが確実です。
Q. 英語力は必要ですか?
国内企業同士の取引が中心なら、必須ではないケースがほとんどです。外資系企業や海外ベンダー、オフショア開発、海外拠点とのプロジェクトでは英語でのやりとりが発生するため、求人票に「英語」「海外拠点」「オフショア」といった記載がないかは見ておきましょう。
Q. ベンダーコントロールの仕事で年収は上がりますか?
IT特化型の転職エージェントであるギークリーによると※、同社の支援実績では、ベンダーコントロール経験者の年収帯は400万円台からスタートし、マネジメント経験を積むことで700万円台まで上がった実例もあるとされています。キャリアの広げ方としては、情シスやPMOのほか、SIerのPMやITコンサルタントへ進むパスも挙げられています。
この幅を生むのは、担当範囲の違いです。取次ぎや問い合わせ対応が中心のポジションと、要件定義・ベンダー選定・予算管理まで任されるポジションでは、求められる経験も評価もまったく変わります。年収を比べるときは金額だけでなく、どこまでの工程と判断を任される求人なのかをセットで見てください。
まとめ
ベンダーコントロールとは、発注側の社内SE・情シスが外部ベンダーの進捗・品質・コスト・契約を管理し、自社として必要な判断を下しながらシステム開発や運用を進める仕事です。ベンダーと連絡を取ること自体が仕事なのではなく、発注側として何を決めるかに価値があります。
求人票でこの言葉を見かけたら、関与する工程、決裁権、雇用元の3点を確認してください。取次ぎだけの求人、権限がないのに責任だけ負う求人、社内SEに見せかけた常駐PMO求人、ブラックボックス化したシステムを一人で背負う求人は、応募前に見抜いておきたいパターンです。
求人票と面接だけでは確かめきれない内情は、社内SE・情シスに強い転職エージェントに聞くのがいちばん早い方法です。比較は社内SEにおすすめの転職サイト・エージェントを参考にしてください。


















