【業界マップ】ITシステム関係者の役割図鑑｜SIer・ベンダー・コンサルの違いと最適な関与方法

ITシステムの企画や運用に関わるようになると、「ベンダー」「SIer」「コンサル」など、さまざまな立場の関係者とやり取りをすることになります。

しかしながら、それぞれがどのような役割を担っているのかを理解せず話を進めていくと、「誰に何を相談すればよいか分からない」「複数社の提案や見積の違いが読み取りにくい」といったモヤモヤを抱えがちです。

一方で、ITシステムの企画・導入・運用のプロセスに、どのような関係者が関与しており、それぞれがどこまでを担当するのかを大まかに押さえておくと、日々のコミュニケーションはぐっと楽になります。

例えば、「自分たちだけでは何から考えればよいか分からないので、最初の整理はITコンサルティング会社のような専門家に手伝ってもらう」「細かな設計やシステムづくりは、自社では人手やスキルが足りないので、SIerに任せる」といった形で、「自社だけでは対応しきれない部分」を見極め、その部分だけ外部に頼るという考え方が取りやすくなります。

また、ユーザー企業として自社が主体的に判断・管理すべき範囲と、外部の専門家に検討や作業を依頼できる範囲との切り分けもしやすくなります。

本記事では、こうした「ITシステムに関わる関係者」の全体像を頭の中に描けるようになることを目指し、まず主な関係者の役割を整理します。

そのうえで、典型的なシステム導入・更改の場面を取り上げながら、どのように役割分担が行われることが多いのかを確認し、最後に、ユーザー企業としてどの範囲を自社の責任領域とし、どの範囲を外部の事業者に委託することが適切かを検討するための視点を紹介します。

ITシステム開発に関わる主な4つのプレイヤーと役割

ITコンサルティング会社：戦略策定と要件整理の支援

ITコンサルティング会社は、システムそのものを作る会社というよりも、「そもそも何のためにシステムを入れるのか」「どのような形で業務を変えていきたいのか」といった戦略や方針を一緒に整理することを主な役割とする会社です。

経営や業務の課題を整理し、それを踏まえてシステム化の方向性を考える、といった場面で関わることが多くなります。

具体的には、現状の業務やシステムの課題を洗い出したうえで、「どの業務から手を付けるか」「どのような機能が必要か」といった要求事項を整理したり、RFP（提案依頼書）の作成を支援したりします。

また、そのRFPにもとづいてベンダー各社から提案を受け取り、内容を比較・評価する場面でも、発注者側の立場で検討をサポートすることがあります。

こうしたことから、「どの製品を導入するかを決める前の段階」で相談しやすい相手と言えます。

なお、一口に「ITコンサル」といっても、その得意分野や立ち位置はさまざまです。

なかには、自社で扱っている業務パッケージやクラウドサービスの導入を前提としてコンサルティングを行う企業もあります。

そのため、コンサルティング会社を選ぶ際には、「どのような立場で助言してくれるのか」「特定の製品ありきではないか」といった点も含めて確認し、複数社を比較検討しながら自社に合ったパートナーを選ぶことが重要です。

ソフトウェアベンダー（業務システムメーカー/パッケージベンダー）：パッケージ製品の企画・提供

ソフトウェアベンダーは、自社で企画・開発した業務システムやパッケージ製品を提供する会社です。

会計システムや販売管理システム、人事給与システムなど、特定の業務に特化した製品をラインナップとして持ち、その製品をさまざまな企業に販売する立場にあります。

発注者との関わり方としては、「この製品でどのようなことができるのか」「標準機能でどこまで自社の業務に合いそうか」といった相談を受ける場面が多くなります。

デモンストレーションを通じて画面イメージや操作感を説明したり、オプション機能や上位エディションの違いを案内したりすることも、ソフトウェアベンダーの典型的な役割です。

また、導入後の問い合わせ対応や、バージョンアップに関する情報提供など、一部の保守サポートを担うケースもあります。

一方で、ソフトウェアベンダーが提案した製品を、その会社自身が最後まで直接導入してくれるとは限りません。

製品の提案や機能説明まではソフトウェアベンダーが行い、実際の詳細設計や周辺システムとの連携、データ移行などの作業は、提携しているSIerや、発注者企業が選定したSIerが担うケースも多く見られます。

そのため、「製品を提供する会社（ソフトウェアベンダー）」と「その製品を組み込んだシステム全体を作る会社（SIer）」が分かれていることを前提に、どこまでを誰に依頼するのかを整理しておくことが大切です。

SIer・受託開発ベンダー：全体設計から構築・移行まで

SIerや受託開発ベンダーは、合意された要件にもとづいてシステムを具体的な形にしていくことを主な役割とする会社です。

ユーザー企業やITコンサル、ソフトウェアベンダーとの議論を通じてまとまった要件を受け取り、それをもとにシステム全体の構成を考え、設計・開発・テスト・本番導入までを担当します。

案件によっては、要件定義の段階から議論に参加することもあります。

得意とする領域は、要件定義や基本設計といった上流の一部から、プログラムを作る詳細設計・開発、テスト、本番環境への切り替えといった一連の作業です。

導入後も、障害対応や軽微な改修などの保守を継続して請け負うケースが多く、「決まった方針や要件を、具体的なシステムとして形にしてもらう相手」として関わることが一般的です。

前の項目でも触れたとおり、パッケージ製品の導入では、「製品を提供する会社（ソフトウェアベンダー）」と「その製品も含めてシステム全体を作る会社（SIer）」が分かれていることがあります。

製品の紹介や契約の話はソフトウェアベンダーが担当し、実際の設定や周辺システムとの連携、データ移行などの作業はSIerが担当する、といった役割分担です。

一方で、ソフトウェアベンダー自身がSIerの機能も持ち、一社で導入まで対応するケースもあります。

自社の案件ではどこまでをソフトウェアベンダーが行い、どこからをSIerが行うのかをあらかじめ確認しておくとよいでしょう。

さらに詳しい位置づけや役割については、以下の記事もあわせて参照してみてください。

参考記事リンク：SIer（エスアイヤー）とは？サービス内容や種類、SEとの違いや選び方のポイントについて解説

運用・保守事業者/アウトソーシング事業者：稼働後の監視と定型業務の実行

運用・保守事業者やアウトソーシング事業者は、稼働中のシステムを安定して動かし続けることを主な役割とする会社です。

具体的には、システムの監視、障害発生時の一次対応、バックアップの実施、バッチ処理や帳票出力の実行といった、日々の運用業務を担当します。

また、ヘルプデスクとしてユーザーからの問い合わせを受け付ける役割を担うこともあります。

得意とする領域は、本番稼働後の運用フェーズ全般です。

システムを止めないための監視や、トラブル発生時の切り分け・復旧対応、定型的なオペレーション作業などを継続的に対応します。

発注者側から見ると、「システムを安定して動かし続けること」と「日々の運用作業にかかる社内の負荷を減らすこと」を目的として、業務の一部または全部を委託する相手となります。

一方で、運用や保守の業務は、システムを構築したSIerがそのまま引き受けることも少なくありません。

SIerが行う保守は、障害対応や軽微な改修などが中心であり、アプリケーションの不具合修正や機能追加など、設計・開発と地続きの対応が得意です。

これに対して、運用・保守事業者は、24時間365日の監視体制や、複数システムをまとめて運転する仕組みなど、「運用の仕組みや体制そのもの」を専門にしている場合が多く、オペレーションの標準化や工数削減に強みを持つことがよくあります。

また、運用・保守だけでなく、請求処理やデータ入力など特定の業務プロセスそのものを代行するアウトソーシングサービスを提供している会社もあります。

この場合は、「システムの運用を任せる」というより、「業務そのものを任せる」色合いが強くなります。

自社のシステムや業務のどこまでをSIerの保守に任せ、どこからを運用・保守事業者やアウトソーシング事業者に委ねるかを検討することで、社内の負荷やコスト、求めるサービスレベルに応じた分担を考えやすくなります。

【事例】基幹システム刷新における関係者の役割分担チャート

経理・販売・在庫管理など、会社の中核となる業務を支える「基幹システム」を入れ替える場面を例に、各関係者がどのような役割を担うことが多いのかを解説していきます。

ITコンサルティング会社、パッケージ製品を提供するソフトウェアベンダー、システムを実際に作るSIer、稼働後の運用を担う運用・保守事業者などが、どのタイミングでどのように関わるのかを見ていくことで、関係者ごとの役割イメージをつかみやすくなるでしょう。

ユーザー企業（発注者）：目的の明確化と最終決定

基幹システムを刷新するプロジェクトでは、まずユーザー企業自身が「現状のどこに困りごとがあるのか」「将来どのような業務の進め方にしていきたいのか」といった点を整理していく役割を担います。

経理・販売・在庫などの担当部門から意見を集め、「どの業務を優先して改善したいのか」「システム導入によって何を実現したいのか」といった方向性を社内で合わせていくことが求められます。

そのうえで、どの程度の費用をかけるのか、いつまでに刷新を完了させたいのかといった投資判断や最終方針の決定も、ユーザー企業側で行う必要があります。

あわせて、ITコンサルティング会社やソフトウェアベンダー、SIerといった候補の中から、どの事業者と組んでプロジェクトを進めていくかを選定することも重要な役割です。

プロジェクトが具体的に動き出してからは、選定した事業者と協力しながら、要件定義やテストにも関わっていきます。

業務担当者の目線で「この仕様で実務が回るか」「この画面や帳票で支障がないか」を確認し、必要に応じて修正を依頼することで、最終的に自社の業務に合ったシステムになるよう調整していくことが、ユーザー企業の大きな役割となります。

ITコンサルティング会社：現状課題の可視化とベンダー選定支援

ITコンサルティング会社は、ユーザー企業と一緒に「今の業務やシステムがどうなっているか」を整理し、現状の課題を可視化するところから関わることが多いです。

現場の担当者へのヒアリングや現行システムの確認を通じて、「どの作業にムダが多いか」「どの部分で手作業や二重入力が発生しているか」といった点を洗い出し、改善の方向性を言語化していきます。

そのうえで、「どの業務をどこまでシステム化するか」「どのような機能が必要か」といったシステム化構想や要求事項の整理を支援します。基幹業務パッケージを導入する前提であれば、複数のパッケージ製品を候補として挙げ、それぞれの特長や得意な業務領域を比較するところまでサポートすることもあります。

RFP（提案依頼書）の作成や、各ベンダーから出てきた提案内容・見積の評価を手伝い、ユーザー企業がベンダー選定を行う際の判断材料を整理する役割も担います。

また、プロジェクトの進め方によっては、要件定義以降の工程にも一定程度関わることがあります。

たとえば、開発工程の進捗管理や仕様調整の場に同席し、「当初の目的や方針から外れていないか」「業務側の意図がきちんとシステム仕様に反映されているか」といった観点でユーザー企業をサポートするケースもあります。

ソフトウェアベンダー：製品機能の提供と適合性の提示

ソフトウェアベンダーは、自社で開発した基幹業務パッケージの機能や特長を説明する立場でプロジェクトに関わります。

経理・販売・在庫といった業務ごとに、どのような画面や帳票が用意されているのか、どの業務プロセスを前提に設計されているのかといった点をデモンストレーションなどを通じて紹介し、「この製品を使うと、どのような業務がどのように変わるのか」を具体的にイメージできるようにする役割を担います。

あわせて、「標準機能だけで対応できる範囲」と「個別の追加開発や設定が必要になる範囲」を切り分けて提示することも、ソフトウェアベンダーの重要な役割です。

どこまでを製品の枠内で対応できるかが見えてくることで、発注者側は、自社の業務をどの程度パッケージ側に合わせる必要があるのかを検討しやすくなります。

そのうえで、ライセンスの考え方（ユーザー数やサーバー単位など）や年間保守費用、バージョンアップ時の扱いなど、製品に関する契約条件もあわせて提示します。

一方で、ソフトウェアベンダーが自社製品の説明や条件提示を担い、システム全体の設計や構築は別のSIerが担当する、という形態もよく見られます。

この場合、ソフトウェアベンダーとSIerは、それぞれの役割を分担しながら、製品の仕様や制約事項などについて情報共有・連携を行っています。

ソフトウェアベンダーが「製品としてできること・できないこと」や推奨される使い方を提供し、それを踏まえてSIerがシステム全体の設計や作り方を検討していく、というイメージです。

発注者からは一つのプロジェクトチームのように見えていても、その中で「製品を提供する会社」と「システム全体を組み上げる会社」が役割分担しながら連携している、という構図を押さえておくと、それぞれに何を期待できるかが理解しやすくなります。

SIer・受託開発ベンダー：全体設計から構築・移行まで

SIer・受託開発ベンダーは、実際に導入するシステムを構築する立場でプロジェクトに関わります。

現場の担当者から出てきた要望や、ITコンサルが整理した要求事項を聞き取り、「どのような画面や機能があればよいか」といった形に落とし込んでいきます。

現場の人が話す業務のイメージを、システムとして実現できるように整理し直す役割を担うイメージです。

パッケージ製品を採用する場合には、選ばれたパッケージを前提に、アドオン開発やカスタマイズ、他システムとの連携などを含めた全体設計を行います。

そのうえで、設計した内容に基づきプログラムを作り、テストを行い、データ移行や本番環境への切り替えまで、一連の作業を担当します。

本番稼働後も契約内容に応じて、障害が発生したときの調査・復旧対応や、画面や帳票の軽微な修正・機能追加などを継続的に請け負うことがあります。

運用・保守事業者が日々の監視やオペレーションを担当し、SIerがシステムそのものの修正を担当する、といった形で役割を分けるケースも多いです。

運用・保守事業者/アウトソーシング事業者：稼働後の監視と定型業務の実行

運用・保守事業者はシステムが稼働したあとに、そのシステムを安定して利用するために必要な運用保守業務を担当します。

具体的には、サーバーやシステムの状態を監視したり、定期的なバックアップを実行したり、夜間バッチやレポート出力などのジョブを決まった時間に動かしたりといった、日々の運用業務をまとめて受託することが多いです。

また、体制によっては、障害が発生した際の一次受付や、ユーザーからの問い合わせに対応するヘルプデスク業務、決められた帳票の出力・配布といった、一部の業務プロセスそのものを含めて代行する場合もあります。

ユーザー企業から見ると、「システムが止まらないように監視してもらう」「日々の定型作業を任せて、社内の負荷を減らす」といった目的で利用することが多いです。

ユーザー企業の責任領域と外部委託の切り分け方

ユーザー企業が主体的に判断すべき「決定」と「検収」

ITシステムの構築や運用では、実際の設計・開発・運用作業の多くを外部事業者に依頼することが一般的です。

とはいえ、責任をすべて外部に任せられるわけではありません。

なぜならばシステムを使うのはあくまで自社であり、その結果として得られる効果や、万一トラブルが起きた場合の影響を負うのもユーザー企業側です。

この意味で、最終的な責任はユーザー企業にある、という前提は変わりません。

そのため、どの業務領域から着手するのか、どこまでの範囲を今回のプロジェクトで対象とするのかといった優先順位付けや、どの程度の投資金額を許容するのか、いつまでに稼働させたいのか、といったスケジュールに関する意思決定は、外部事業者に任せきりにはできない範囲です。

外部事業者から提案や見解をもらうことはできますが、「自社としてどうするか」を決めるのはユーザー企業の役割になります。

また、プロジェクトの終盤で行われる受入テストや検収の場面でも、「このシステムで業務が回ると言えるか」「残っている不具合や懸念を許容できるか」といった最終判断は、ユーザー企業側が行う必要があります。

外部事業者は、テストの進め方や観点を提案したり、技術的なリスクを説明したりする立場ですが、「この成果物でよいかどうか」を最終的に決める責任までは引き受けられません。

どの範囲を外部に頼る場合でも、「方針・優先順位・投資判断・検収の可否」といった中核部分は、ユーザー企業が主体的に判断・管理する前提でプロジェクトを実行することが重要です。

専門家に任せやすい「検討プロセス」と「実作業」

一方で、ITシステムに関する専門的な設計や構築、日々の運用作業まで、すべてをユーザー企業だけで対応することは現実的ではありません。

業務要件にもとづいて「どのようなシステム構成にするか」を検討することや、複数の製品・サービスを比較して選ぶこと、決まった方針にもとづいて詳細設計・開発・テストを行うことなどは、高い専門性と一定の工数が必要になるため、外部事業者に委託しやすい領域です。

このとき、「方針や最終判断」と「具体的な検討・作業」を分けて考えると、外部に依頼しやすい範囲が整理しやすくなります。

例えば、「どの業務を優先して改善するか」「どの程度の費用と期間で進めるか」といった方針決定はユーザー企業が担い、その方針をもとにしたシステム構成の検討や設計・開発・運用といった具体的な作業は、ITコンサルティング会社やSIer、運用・保守事業者などの外部事業者に任せるイメージです。

このように役割を切り分けることで、限られた社内リソースを生かしながら、専門家の力も取り入れやすくなります。

各プレイヤーの得意領域（ポジション）を活かしたチーム作り

役割分担を考える際には、「誰がどの作業を担当できるか」だけでなく、関係者ごとの立場や関心の置きどころの違いも意識しておくことが大切です。

たとえば、ソフトウェアベンダーは、自社で開発したパッケージ製品を軸に提案を行う立場にあります。

製品の強みや標準機能を踏まえ、「このパッケージであれば、こういった業務にフィットしやすい」といった観点で話をしてくれる存在です。

これに対して、SIerは、選定されたパッケージや既存システム、周辺の連携要件などを踏まえながら、「システム全体をどのような形で組み上げるか」を考える立場にあります。

ソフトウェアベンダーと連携しつつ、アドオン開発やカスタマイズ、データ移行なども含めて、合意された要件を具体的なシステムとして実現していくことに重心があります。

一方、ITコンサルティング会社は、特定の製品を前提にせず、現状の課題整理やシステム化構想、要求事項の整理、ベンダー選定の支援などを行うことが多い関係者です。

どの製品・どのベンダーを採用するかを決める前の段階で、選択肢の整理や比較を手伝ってくれる立ち位置と言えます。

ユーザー企業としては、こうした違いを踏まえたうえで、「自社として何を社内で判断するのか」「どの論点について、どの関係者の力を借りるのか」を考えていくことが重要です。

たとえば、「どの業務を優先して改善するか」「どの程度の投資まで許容できるか」といった方針決定は社内で行い、製品ごとの違いを整理したい場面ではITコンサルティング会社の支援を受け、選んだ製品をどう組み込むかという具体的な設計・開発はSIerに依頼するといった組み立て方が考えられます。

このように、関係者ごとの立場を意識して役割を整理することで、外部事業者をより効果的に活用しやすくなります。

まとめ：自社の責任と外部の専門性を組み合わせてプロジェクトを成功させる

本記事では、ITシステムに関わる主な関係者の役割、基幹業務システム刷新を例にした関わり方、そしてユーザー企業としての責任領域と外部事業者に委託しやすい範囲について整理してきました。

実務では1社が複数の役割を兼ねることもありますが、それぞれの立場や得意領域を押さえておくことで、誰に何を相談し、どの業務範囲を依頼すれば適切なのかを判断しやすくなります。

以下は、本記事の内容を改めて整理した表です。

新しい案件の企画や既存システムの見直しを行う際には、ここで整理した観点を参考にしながら、「自社で考えるべきこと」と「外部の力を借りる部分」を切り分けて検討していくと、プロジェクトの進め方を整理しやすくなるはずです。

なお、IT調達ナビの運営会社であるGPTech（グローバル・パートナーズ・テクノロジー）は、発注者側の立場に立ってシステム導入の支援を行うサービスを提供しています。

弊社では専門的な知見を持ったコンサルタントによりお客様の立場に立った最適なご支援が可能ですので、ITコンサルティング企業への発注をお考えの方は、ぜひお気軽にお問い合わせください！

ここまでお読みいただき、ありがとうございました！

この記事の編集者

錦戸 優輝

約10年自治体の情報システム部門の職員としての経験があり、三層分離やマイナンバー制度開始時の対応など様々な業務に携わってきた。自治体退職後は民間企業のSIerでクラウドサービスを運用するSEとして勤務し、その後IT調達ナビの運営会社である（株）グローバル・パートナーズ・テクノロジーに中途入社。ITコンサルティング業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するメディア運営業務にも携わる。応用情報技術者。

この記事をシェアする

X

Facebook

LinkedIn