「相見積もりを取って比較表を作って」と上長から指示され、複数の開発会社に声をかけたところ、ある会社は「うちはSIerです」、別の会社は「受託開発専門です」、また別の会社からは「SES契約で柔軟に対応します」と、それぞれ異なる形態で提案を受けた——こうした場面に戸惑う発注担当者は少なくありません。
各形態の単体解説記事を読んでも、「SIerとは」「受託開発とは」「SESとは」とそれぞれ独立して説明されているため、横並びで比較できず、結局「自社の案件にはどれが合うのか」の判断軸が手元に残らないことが多いものです。さらに上長や経営層への稟議では、「なぜその形態を選んだのか」を論理的に説明できなければ承認は通りません。
本記事では、システム開発会社の主要4形態（SIer・受託開発・SES・オフショア開発）を発注者視点で横断比較し、契約形態・責任範囲・コスト構造の違いを統一軸で整理します。その上で、自社案件の特性5軸から候補形態を絞り込むフレームワークと、6つの典型ケースで「どの形態を選び、どの形態を避けるべきか」の判断根拠を解説します。
読み終えたとき、自社案件に対する候補形態の優先順位と、稟議資料に書ける選定ロジックが手元にある——そのゴールを目指して構成しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発会社の種類は大きく4つに分かれる
発注者が遭遇するシステム開発会社の形態は、契約形態・責任範囲・提供価値の違いから、大きく次の4種類に整理できます。本記事ではこの4分類を軸に比較を進めます。
4形態の一行定義
形態 | 一行定義 |
|---|---|
SIer（System Integrator） | 要件定義から運用保守まで一括で請け負う総合インテグレータ。請負契約が基本で、成果物責任を負う |
受託開発会社 | 案件単位でシステム開発を請け負う会社。SIerより小規模・特定領域特化型が多く、請負契約が基本 |
SES（System Engineering Service） | エンジニアの労働力を提供する形態。準委任契約が基本で、成果物責任ではなく業務遂行責任を負う |
オフショア開発 | 海外ベンダー（ベトナム・フィリピンなど）に開発を委託する形態。コストメリットを目的とすることが多い |
「SIer」と「受託開発」はどちらも請負契約で成果物を納品する形態という点で重なりますが、業界では一般的に「大手・総合型 = SIer」「中堅・特化型 = 受託開発会社」のニュアンスで使い分けられます。「SES」は契約形態が根本的に異なり、「オフショア」は地理的な軸（海外委託かどうか）での区分という点で、4軸は同列ではありません。この点を踏まえて読み進めてください。
SIerと受託開発の違いをどう捉えるか
実務では「SIer」と「受託開発会社」を厳密に区別する明確な基準はなく、両者は連続的な関係にあります。判断の目安としては、以下のような違いで捉えると整理しやすくなります。
- 対応範囲: SIerは要件定義・設計・開発・テスト・運用保守の全工程を一括で対応するのが基本。受託開発は「開発工程中心」「特定領域特化」のことが多い
- 案件規模: SIerは数千万円〜数十億円規模の案件が中心。受託開発は数百万円〜数千万円規模が中心
- 契約形態: 両者とも請負契約が基本だが、受託開発はアジャイル型の準委任契約も増えている
ただし、自社を「SIer」と名乗る中堅企業も多く、呼称だけで判断するのは危険です。本記事では便宜上、「大規模・総合対応型 = SIer」「中堅・特化型 = 受託開発」として整理しますが、相見積もり段階では呼称ではなく対応範囲・契約形態・実績で判断することをおすすめします。
本記事で用いる比較軸
以降のセクションでは、4形態を以下の9軸で比較します。
- 契約形態（請負 / 準委任）
- 報酬の対価構造（成果物 vs 労働時間）
- プロジェクト責任の所在（ベンダー側 vs 発注者側）
- 要件変更への柔軟性
- コスト水準の目安
- 開発スピード
- 品質管理責任
- 発注者側のコミュニケーション負荷
- 向く案件規模・特性
なかでも意思決定で特に効くのは「契約形態 × 責任範囲 × 要件変更耐性」の3軸です。この3軸を押さえれば、相見積もり段階で形態を横並びに比較する土台ができあがります。
4形態の特徴を横断比較表で把握する
本記事の中核となる横断比較表です。SIer・受託開発・SES・オフショア開発の4形態を、発注者の意思決定に必要な9軸で統一して整理しました。
比較軸 | SIer | 受託開発 | SES | オフショア |
|---|---|---|---|---|
契約形態 | 請負（一部準委任） | 請負（アジャイル型は準委任） | 準委任 | 請負または準委任（受託形式が多い） |
報酬の対価 | 成果物（システム） | 成果物（システム） | 労働時間（人月） | 成果物または労働時間 |
プロジェクト責任 | ベンダー側 | ベンダー側 | 発注者側 | ベンダー側（ただしブリッジSE経由） |
要件変更への柔軟性 | 低（変更管理プロセスを経る） | 中〜高（アジャイル型なら高） | 高（追加要件にも柔軟） | 低〜中（仕様書精度依存） |
コスト水準（人月単価目安） | 80万〜200万円 | 60万〜120万円 | 60万〜100万円 | 30万〜50万円（ベトナム・プログラマー単価約40万円（2026年最新版）） |
開発スピード | 遅（手続き重視） | 中 | 速（即着手可能） | 中〜遅（コミュニケーション工数依存） |
品質管理責任 | ベンダー側 | ベンダー側 | 発注者側 | ベンダー側（ただしブリッジSE依存） |
コミュニケーション負荷 | 低（PM経由） | 中 | 高（自社でマネジメント必要） | 高（時差・言語・文化差） |
向く案件規模 | 大規模（5,000万円〜） | 中規模（500万〜5,000万円） | 規模問わず（社内体制次第） | 中〜大規模（1,000万円〜） |
この比較表だけでも、各形態の本質的な違いがかなり鮮明になります。特に注目すべきは以下の3点です。
- プロジェクト責任の所在: SES契約は「労働力の提供」が対価のため、プロジェクトの完成責任は発注者側に残ります。SIerや受託開発（請負契約）と決定的に異なるのはこの点です
- 要件変更への柔軟性: 一見、柔軟性が高いSES・アジャイル型受託が魅力的に見えますが、その代わり発注者側のマネジメント負荷も増します
- コスト: 単価だけ見ればオフショアが圧倒的に有利ですが、コミュニケーション工数・ブリッジSE費用を加算すると差は縮みます
なお、契約形態の法的な違い（請負契約と準委任契約の違い）について簡潔に補足しておきます。請負契約はベンダーが「仕事の完成義務」を負い、成果物に契約不適合があれば契約不適合責任（旧: 瑕疵担保責任、2020年4月の民法改正で名称変更）を負います。一方、準委任契約はベンダーが「善良な管理者の注意」をもって業務を遂行する義務（善管注意義務）を負うのみで、原則として仕事完成義務はありません（参考: IT法務.COM「請負契約と準委任契約」）。この違いを理解せずにSES契約を選ぶと、トラブル発生時の責任所在が不明確になります。
SIerの特徴と4つのサブタイプ
ここからは各形態を個別に深掘りします。まずはSIerから見ていきましょう。
SIerが提供する価値
SIerの最大の価値は、要件定義から運用保守までを一括で対応できる総合力にあります。具体的には次のような強みを持ちます。
- 大規模案件の対応力: 数十名〜数百名規模のエンジニアを動員でき、数億円規模の基幹系刷新に対応可能
- PMO機能: 専任のプロジェクトマネージャー（PM）・PMO（Project Management Office）が品質・スケジュール・コストを統制する
- 業務知識: 特定業界（金融・公共・製造など）に特化したノウハウを蓄積している
- 責任の集約: 一社で全工程を引き受けるため、トラブル時の責任所在が明確
一方、デメリットも明確です。コスト水準が高く（人月単価80万〜200万円が目安）、要件変更への柔軟性が低い（変更管理プロセスを経る必要がある）点です。また、大手SIerほど稟議や手続きが多重化し、開発スピードが遅くなりがちです。
メーカー系・ユーザー系・独立系・コンサル系の違い
SIerは出自によって4つのサブタイプに分類されます。発注者視点では、案件特性によって最適なサブタイプが異なるため、この分類を押さえておくと相見積もり段階で声をかける先を絞れます。
サブタイプ | 出自 | 強み | 典型的な案件規模 | コスト水準 |
|---|---|---|---|---|
メーカー系SIer | ハードウェアメーカーのソフトウェア部門が独立 | 自社ハードとセットで提案可能。経営基盤が安定 | 数千万〜数十億円 | 高 |
ユーザー系SIer | IT以外を本業とする大企業の情シス部門が独立 | 親会社の業界知識（金融・商社・製造など）に強い | 数千万〜数十億円 | 高 |
独立系SIer | 親会社を持たず、独立して受注 | 製品中立。中堅規模で小回りが利く | 数百万〜数億円 | 中〜高 |
コンサル系SIer | ITコンサルティングファーム由来 | 経営戦略・業務改革とセットで上流から対応 | 数千万〜数十億円 | 最高 |
参考: エンジニア就活「SIer企業の4分類」 によると、大企業や官公庁の社会インフラに関わる大規模案件は確立された技術を展開する傾向が強く、独立系・コンサル系は中堅規模で多様な案件を扱う傾向があります。
サブタイプの選定目安は次のとおりです。
- 大手企業の基幹系刷新: メーカー系・ユーザー系SIer（親会社の業界に近いユーザー系が特に有力）
- 中堅企業の業務システム: 独立系SIerの中堅クラス
- 経営改革を伴うDX案件: コンサル系SIer（ただしコストは最も高い）
SIerが向く案件・避けるべきケース
向く案件
- 大規模（人月50人月以上、予算5,000万円以上）の基幹系刷新
- 要件がある程度固まっており、長期計画で進められる案件
- ベンダー側に総合的なプロジェクト管理を任せたい案件
- 社内にIT専任のマネジメント人材が不足している案件
避けるべきケース
- 小規模・短期で進めたい案件（手続きコストが過大になる）
- 要件が流動的で、頻繁な仕様変更が見込まれる案件
- コスト最優先の案件（単価が高めに設定されている）
受託開発会社の特徴
続いて受託開発会社です。SIerとの境界はあいまいですが、本記事では「中堅・特化型 = 受託開発」と整理して扱います。
受託開発の基本構造
受託開発会社は、案件単位で開発を請け負う形態です。契約形態は請負契約が基本で、成果物の納品・検収によって報酬が発生します。この点はSIerと同じです。
SIerとの違い
SIerと受託開発会社の差分は、主に次の4点に集約されます。
比較軸 | SIer | 受託開発 |
|---|---|---|
案件規模 | 大規模（5,000万円〜数十億円） | 中規模（500万〜5,000万円） |
専門性 | 業界横断・総合対応 | 特定領域・技術特化（Web系・モバイル系・特定業界など） |
経営との距離 | 階層構造で意思決定が遅い | 経営者が直接案件に関与することも多く意思決定が速い |
伴走性 | 契約範囲内で対応 | 小回りが利き、契約範囲外の相談にも柔軟 |
「SIerほど大規模ではないが、SESほど社内マネジメント負担を増やしたくない」という中間ゾーンの案件で、受託開発会社は有力候補となります。
アジャイル型受託の広がり
近年は、要件が完全に固まっていない段階から伴走するアジャイル型受託開発が増えています。これは準委任契約をベースに、スプリント単位で要件を整理・実装していくスタイルで、新規Webサービスやスマホアプリ、PoC（概念実証）/MVP（実用最小限の製品）開発に多く採用されています。
アジャイル型受託の特徴は、要件確定度が低い段階でもプロジェクトを開始できる点です。従来の請負型では「要件が固まらないと見積もりが出せない」状態でしたが、アジャイル型では「最初の3ヶ月で要件を固めつつ最小機能をリリース」といった進め方が可能になります。
ただし、準委任契約となるためベンダーは仕事完成義務を負いません。発注者側にもプロダクトオーナーとしての関与が求められる点は理解しておく必要があります。
受託開発が向く案件・避けるべきケース
向く案件
- 中規模（500万〜3,000万円）の業務システム新規開発
- 新規Webサービス・モバイルアプリの開発
- PoC/MVP段階のプロダクト
- 継続的な機能拡張が見込まれる案件
- 経営層が直接ベンダーとやり取りしたい案件
避けるべきケース
- 数億円規模の大規模基幹系（PMO機能が不足する可能性）
- 24時間365日の運用監視が必須の案件（運用体制が手薄なことが多い）
- 業界特化の深い業務知識が必須の案件（汎用受託会社では対応困難）
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
SES（システムエンジニアリングサービス）の特徴
SESは契約形態が根本的に異なる形態です。発注者にとってのメリット・注意点を慎重に押さえる必要があります。
SESの基本構造
SESは準委任契約に基づき、エンジニアの労働力（労働時間）に対して対価を支払う形態です。エンジニアは発注者側のオフィスに常駐するか、リモートで業務に参加します。
請負契約との決定的な違いは、ベンダー側に「仕事の完成義務」がない点です。準委任契約ではベンダーは「善良な管理者の注意」をもって業務を遂行する義務（善管注意義務）を負うのみで、成果物に契約不適合があった場合の契約不適合責任は原則として負いません（参考: IT法務.COM「請負契約と準委任契約」）。
受託との決定的な違い: 責任の所在
SESと受託開発（請負契約）の最も重要な違いは、プロジェクト全体の完成責任が発注者側に残ることです。
観点 | 受託開発（請負） | SES（準委任） |
|---|---|---|
ベンダーの義務 | 仕事の完成義務 | 善管注意義務 |
成果物責任 | あり（契約不適合責任） | なし（原則） |
プロジェクトマネジメント | ベンダー側のPMが担う | 発注者側で必要 |
進行管理・指示 | ベンダー側で完結 | 発注者側で必要 |
「エンジニアを常駐させてもらえれば、自社で開発が回る」という前提が成立する案件、つまり自社にPMや技術リーダーがいて、彼らがエンジニアを統制できる案件でないと、SESは機能しません。
SESが向く案件・避けるべきケース
向く案件
- 社内に既存の開発チームがあり、特定スキルを補完したい（フロントエンド・モバイル・データエンジニアなど）
- 要件が流動的で、リソースだけ確保したい案件
- 短期間（3ヶ月〜1年）の体制強化が必要な案件
- 社内にPM・技術リーダーが在籍している案件
避けるべきケース
- 社内にマネジメントできる人材がいない案件（プロジェクトが破綻するリスクが高い）
- 成果物の品質をベンダーに完全に委ねたい案件
- 「とりあえずエンジニアを安く確保したい」だけの動機
SES発注者が知っておくべきリスク
SESを発注する際は、以下のリスクを認識した上で社内体制を整える必要があります。
1. 偽装請負リスク
偽装請負とは、形式上は請負契約だが実態として発注者がエンジニアに直接指揮命令している状態を指します。SES（準委任契約）でも、発注者がエンジニアに直接指揮命令を行うと労働者派遣事業に該当し、違法となります（厚生労働省告示「労働者派遣事業と請負により行われる事業との区分に関する基準」、参考: BUSINESS LAWYERS「SI業界・SEの偽装請負の判断基準」）。
発注者側が違法と判断されるリスクのある具体的なシチュエーションは以下のとおりです（参考: SES偽装請負の判例から学べるリスクや防止策）。
- 発注者がSESエンジニアの勤務時間を直接決めている
- 発注者側のメンバーがエンジニアに作業指示を直接出している
- 発注者がエンジニアの作業工程・タスクを決定している
- 発注者がエンジニアの評価・昇給・昇進を決定している
違反した場合、厚生労働省による行政監督の対象となり、企業名公表のリスクもあります。SES発注時は、指揮命令は必ずベンダー側のリーダーを経由する運用ルールを徹底し、契約書・業務報告フロー・指示経路を事前に整備しておくことが重要です。
2. 品質のばらつき
SESは「人」が商品です。ベンダー会社のブランドではなく、配属されるエンジニア個人のスキルで品質が大きく変動します。事前面談（顔合わせ）で技術スタック・実務経験を確認することが必須です。
3. マネジメント負担の増加
社内PMの工数は、SES契約のエンジニア数に比例して増加します。「エンジニアを増やせばスピードが上がる」とは限らず、PMがボトルネックになるとむしろ進行が遅くなるケースもあります。
オフショア開発の特徴
最後にオフショア開発です。コストメリットが強調されがちですが、管理コストとのトレードオフを冷静に評価する必要があります。
オフショア開発の基本構造
オフショア開発は、海外ベンダーにシステム開発を委託する形態です。ベトナム・フィリピン・インド・中国などが主要委託先で、現在の主流はベトナムです。
委託形態としては、海外ベンダーが日本側との橋渡しを行うブリッジSEを配置するパターンが一般的です。ブリッジSEは日本語または高度な英語で要件を整理し、現地エンジニアに翻訳・伝達します。
コストメリットの実態と管理コストのトレードオフ
オフショア開発の最大の魅力はコストです。オフショア開発.comの2026年最新調査によると、ベトナムのプログラマー単価は約40万円（2026年最新版）が目安で、職種・スキル帯によって30万円台前半から50万円程度まで分布します。国内SIerの人月単価（80万〜200万円）と比べると、単純計算で1/2〜1/4のコストです。
ただし、単価差がそのまま総コスト差にはなりません。次の管理コストを加算する必要があります。
- ブリッジSE費用: 日本人または日本語ができるブリッジSEを介す場合、その分の単価（60万〜100万円）が加算される
- 仕様書作成コスト: 海外エンジニアに伝わるよう、国内開発より詳細な仕様書が必要
- コミュニケーション工数: 時差・言語・文化差により、レビュー・修正のサイクルが長くなる
- 品質管理コスト: 日本側で受け入れテスト・品質チェックを丁寧に行う必要
これらを加味すると、実質的なコストメリットは20〜40%程度に縮小するのが一般的です。さらに10人月以下の小規模案件では、固定費（ブリッジSE費用・仕様書作成）が割合的に大きくなり、コストメリットが消失することもあります。
主要な委託先国の特徴
ベトナム以外の選択肢も含めて、主要委託先国の特徴を簡潔に整理します。
国 | 人月単価目安 | 特徴 |
|---|---|---|
ベトナム | 30万〜40万円 | 親日的・若年層多く拡大中。日本語人材も増加。現在の主流 |
フィリピン | 30万〜40万円 | 英語に強い。BPO（業務委託）と組み合わせやすい |
インド | 40万〜60万円 | エンジニア人口が多くスキル高い。英語必須 |
中国 | 40万〜60万円 | 単価上昇傾向で価格優位性は薄まっている |
なお、近年は時差・言語負担を軽減したニアショア開発（国内地方都市への委託）も選択肢として広がっています。沖縄・北海道・東北などが代表的で、人月単価は60万〜80万円程度です。
オフショアが向く案件・避けるべきケース
向く案件
- 中〜大規模（人月20人月以上、予算1,000万円以上）の案件
- 要件が明確に固まっており、仕様書を詳細に作成できる案件
- 継続開発が見込まれ、現地チームとの長期関係を構築できる案件
- 国内エンジニアが不足する特定スキル（AI/機械学習・特定言語など）の補完
避けるべきケース
- 小規模（10人月以下）の案件
- 要件が流動的で頻繁な仕様変更が見込まれる案件
- 短納期（3ヶ月以内）の案件
- 機密性が極めて高い案件（情報セキュリティ要件が複雑になる）
案件特性別に最適形態を選ぶフレームワーク
ここまでで4形態の特徴を整理しました。ここからは、自社案件の特性から候補形態を絞り込むためのフレームワークを提示します。
自社案件を整理する5つの軸
自社案件を以下の5軸で整理してください。この5軸の組み合わせが、候補形態を決定します。
-
案件規模（人月）
- 小: 〜10人月
- 中: 10〜50人月
- 大: 50人月〜
-
要件確定度
- 固まっている: 業務フロー・機能要件がドキュメント化済み
- 流動的: 検討中の要素が多く、進めながら詰める必要がある
-
継続改善の有無
- 単発: 納品して終わり、保守は最小限
- 継続: リリース後も機能追加・改修が続く
-
社内マネジメント体制
- あり: 社内にPM・技術リーダーが在籍
- なし: ベンダーにマネジメントも任せる必要がある
-
コスト上限の厳しさ
- 厳しい: コストが選定の決定要因
- 余裕あり: 品質・スピードを優先できる
案件特性 × 推奨形態マトリクス
5軸を組み合わせた推奨形態の早見表です。
案件規模 | 要件確定度 | 継続改善 | 社内マネジメント | コスト | 第1候補 | 第2候補 |
|---|---|---|---|---|---|---|
大（50人月〜） | 固まっている | 単発 | なし | 余裕あり | 大手SIer（メーカー系・ユーザー系） | 中堅独立系SIer |
大（50人月〜） | 固まっている | 単発 | なし | 厳しい | オフショア（ブリッジSE体制） | 中堅独立系SIer |
中（10〜50人月） | 固まっている | 単発 | あり | 中庸 | 中堅独立系SIer | 受託開発会社 |
中（10〜50人月） | 流動的 | 継続 | あり | 中庸 | アジャイル型受託開発 | SES |
小（〜10人月） | 流動的 | 継続 | あり | 厳しい | アジャイル型受託開発 | SES |
小（〜10人月） | 流動的 | 継続 | あり | 余裕あり | アジャイル型受託開発 | （単独で十分） |
規模問わず | — | 継続 | あり（強い） | 厳しい | SES | 受託開発（運用契約） |
このマトリクスはあくまで目安です。実際は5軸の重みづけ（どの軸を最優先するか）によって順位が入れ替わります。とはいえ、自社案件をこの5軸で整理するだけでも、候補形態を2〜3個に絞り込むことができます。
複数形態を組み合わせる選択肢
単一形態にこだわる必要はありません。むしろ、案件のフェーズや領域ごとに複数形態を組み合わせることで、コスト・品質・スピードのバランスを最適化できるケースが多くあります。
代表的な組み合わせパターンは以下のとおりです。
- PoC → 本開発の段階分け: PoC/MVPはアジャイル型受託で素早く実証 → 本開発は中堅SIerで品質・規模を確保
- 本開発 + コスト圧縮: 中堅SIerが上流（要件定義・設計）と品質管理を担当 → 実装の一部をオフショアで圧縮
- 本開発 + スキル補完: SIerが本開発をリード → 特定スキル（AI・モバイルなど）はSESで補完
- 保守の効率化: 開発フェーズは受託開発 → 運用フェーズはSESでコスト圧縮
組み合わせ型は契約・進行管理がやや複雑になりますが、大規模案件・長期案件ほど効果が大きくなります。
ケース別に見る推奨形態と判断根拠
フレームワークを6つの典型ケースに当てはめます。各ケースで「推奨形態」「次点候補」「避けるべき形態」を構造化して示します。
ケース1: 大規模基幹系の刷新（数億円規模）
案件概要: 製造業の生産管理システム刷新。数百拠点・数千ユーザーが利用する基幹系。予算3〜10億円、開発期間2〜3年。
項目 | 内容 |
|---|---|
推奨形態 | 大手SIer（メーカー系・ユーザー系） |
次点候補 | 中堅独立系SIerの大型案件対応チーム |
避けるべき形態 | SES（プロジェクト管理が破綻するリスク高）/ オフショア単独（業務知識・品質統制が困難） |
判断根拠: 規模と業務複雑性が極めて高く、PMO機能・既存業務との連携・大人数のリソース確保が必須。要件が固まっていれば請負契約で責任を集約できる大手SIerが最も合理的。コスト圧縮目的でオフショアを併用する場合も、上流はSIer主導とすべき。
ケース2: 中規模業務システムの新規開発（500万〜3,000万円）
案件概要: 中堅企業の在庫管理・顧客管理・販売管理など、業務系Webアプリの新規開発。予算500万〜3,000万円、開発期間4〜8ヶ月。
項目 | 内容 |
|---|---|
推奨形態 | 中堅独立系SIer または 受託開発会社 |
次点候補 | アジャイル型受託（要件が流動的な場合） |
避けるべき形態 | 大手SIer（コスト過大）/ オフショア（管理コストが割合的に大きい） |
判断根拠: 大手SIerに依頼するには規模が小さすぎ、コスト効率が悪い。逆にSESでは社内マネジメント負担が増す。中堅独立系SIerまたは特化型受託開発が最もバランスが良い。
ケース3: 新規SaaSプロダクトのMVP（200〜500万円・要件流動的）
案件概要: 新規事業として立ち上げるSaaSプロダクトのMVP（実用最小限の製品）開発。市場検証が目的で、要件は走りながら詰める。予算200〜500万円、3〜4ヶ月で初版リリース。
項目 | 内容 |
|---|---|
推奨形態 | アジャイル型受託開発 |
次点候補 | SES（社内に強いCTOがいる場合） |
避けるべき形態 | 大手SIer（柔軟性なし）/ オフショア（仕様変動に弱い） |
判断根拠: 要件流動性が高い案件は、請負型では発注も見積もりも成立しない。準委任ベースで伴走できるアジャイル型受託が唯一の現実解。SaaSの世界観や設計判断を共有できるパートナーシップ型のベンダーを選ぶこと。
ケース4: 既存システムの保守・継続改善（月額継続）
案件概要: リリース済みシステムの保守・小規模改修。月10〜30人日程度の継続発注。
項目 | 内容 |
|---|---|
推奨形態 | 受託開発会社（継続契約）または SES |
次点候補 | オフショア（一定規模を継続発注できる場合） |
避けるべき形態 | 大手SIer（保守単価が高い） |
判断根拠: 開発時のベンダーをそのまま継続するのが最も合理的（業務知識の引き継ぎコストゼロ）。社内に開発を巻き取りたい意向があるならSESに切り替えてナレッジ移管する選択肢もあり。
ケース5: 社内開発体制の一部スキル補完（特定技術の人員不足）
案件概要: 社内に既存の開発チームがあるが、フロントエンド・モバイル・データエンジニアなど特定スキルの人材が不足。即戦力を3〜6ヶ月確保したい。
項目 | 内容 |
|---|---|
推奨形態 | SES |
次点候補 | フリーランス（業務委託） |
避けるべき形態 | SIer（オーバースペック・コスト過大）/ オフショア（即戦力性に欠ける） |
判断根拠: 社内マネジメント体制が整っており、必要なのは特定スキルの労働力。SESが最適。ただし偽装請負リスクには注意し、指揮命令はベンダー側リーダー経由とすること。
ケース6: 中〜大規模で要件確定済み・コスト厳しい
案件概要: 業務系Webシステムの新規開発。要件は固まっており仕様書も詳細に作成可能。予算は1,500万〜5,000万円で、国内SIerだと予算オーバー。
項目 | 内容 |
|---|---|
推奨形態 | オフショア（ブリッジSE体制が前提） |
次点候補 | 中堅独立系SIer + オフショア併用 |
避けるべき形態 | SES（社内マネジメント負担で総コストが上がる） |
判断根拠: 要件が固まっており仕様書を詳細化できることがオフショア成功の前提条件を満たす。コスト圧縮効果が出やすい中〜大規模で、ブリッジSE体制を整えれば成功確率が高い。
開発会社の比較・選定で失敗しないための確認ポイント
ここまでで候補形態が絞れたとします。次のステップは、絞り込んだ形態の中で個別のベンダーを比較することです。形態を揃えた上で何を比較するか、形態ごとに優先度の高い確認ポイントを整理します。
形態を絞った後にベンダー個社を比較する観点
「複数社から相見積もりを取って横並びで比較」する段階では、以下5つの軸で評価するのが標準的です。ただし、どの軸を重視すべきかは選定した形態によって変わります。
確認軸 | 内容 | 重視すべき形態 |
|---|---|---|
実績 | 自社の業界・規模・技術領域に近い案件の実績数 | SIer・受託（請負責任のため実績重要） |
コミュニケーション | 提案段階のレスポンス速度・質問への返答の的確さ | 全形態（特にオフショア・SES） |
契約条件 | 請負/準委任の選択肢・契約不適合責任の期間・変更管理プロセス | 請負系（SIer・受託・オフショア請負型） |
継続性 | 経営状況・離職率・キーパーソンの定着 | 継続契約を想定する場合（保守・運用フェーズ） |
PM体制 | プロジェクトマネージャーの経験・関与度合 | SIer・受託（PMが品質を左右する） |
形態別の重点ポイントは以下のとおりです。
- SIer選定時: 業界実績とPM経験。「自社に近い業界の大型案件を直近3年で何件成功させたか」を必ず確認
- 受託開発選定時: 専門性と経営者・PMの距離感。「経営層や技術責任者が直接案件に関与してくれるか」を確認
- SES選定時: エンジニア個人のスキル評価（事前面談で技術スタック・実務経験を確認）と、偽装請負を回避する運用ルールの合意
- オフショア選定時: ブリッジSEの日本語力・業務知識と、仕様書テンプレート・コミュニケーション運用の合意
相見積もりで比較する際の注意点
形態が混在した相見積もりは、そのままでは比較できません。例えば、SIerは「総額3,000万円（要件定義から運用保守まで一括）」、SESは「月額150万円×6ヶ月=900万円（エンジニア2名常駐）」、オフショアは「総額1,500万円（実装のみ、要件定義は別途）」のように、見積もりの前提が異なります。
横並び比較するためには、以下を統一する必要があります。
- スコープ: 各社が含めている工程（要件定義・設計・実装・テスト・運用保守）を表で整理
- 期間: 開発期間・保守期間を統一して総コスト換算
- 追加コスト: 自社で負担する工数（マネジメント・受け入れテスト・ブリッジSE等）も加味
ここまで揃えてはじめて、各形態の総コスト・総便益が比較可能になります。費用相場の読み方はシステム開発の費用相場も併せて参照してください。
まとめ - 形態の違いを理解すれば、自社案件に合った発注ができる
ここまで、システム開発会社の4形態（SIer・受託開発・SES・オフショア開発）を発注者視点で横断比較し、選定フレームワークと6つのケース別推奨を解説しました。要点を整理します。
1. 4形態の本質は「契約形態・責任範囲・コスト構造」の違いに集約される
- SIer・受託開発: 請負契約が基本。成果物責任をベンダー側が負う
- SES: 準委任契約。労働力の対価で、完成責任は発注者側
- オフショア: 海外委託形態。請負/準委任の双方ありうるが、コミュニケーション設計が成否を分ける
2. 案件特性5軸でフレーム化すれば候補形態は絞れる
- 案件規模 / 要件確定度 / 継続改善有無 / 社内マネジメント体制 / コスト上限の5軸を整理する
- マトリクスに当てはめれば候補形態が2〜3個に絞り込める
3. 単一形態にこだわらず組み合わせも選択肢
- PoCはアジャイル型受託、本開発はSIer + オフショア併用、保守はSES、といった組み合わせが効果的
- 規模・期間が大きい案件ほど、組み合わせの効果が大きい
次のアクション
本記事を読み終えた今、次の3ステップを実行することをおすすめします。
- 自社案件を5軸で整理する: 案件規模・要件確定度・継続改善有無・社内マネジメント体制・コスト上限を稟議資料用に整理する
- 候補形態を2〜3個に絞る: マトリクスに当てはめて候補を絞り、稟議資料に「なぜその形態を選んだか」の根拠を記載する
- 絞り込んだ形態のベンダー3〜5社に相見積もりを依頼する: 形態を揃えた上で、本記事の確認ポイント5軸（実績・コミュニケーション・契約条件・継続性・PM体制）で評価する
形態の選定は、ベンダー個社の選定よりも前段で行うべき、より戦略的な意思決定です。本記事のフレームワークを稟議資料に転用し、自社案件に最適な発注を進めてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
