システム開発の「種類」には、大きく分けて「発注のしかた（契約・体制）」「作り方（構築方法）」「進め方（開発手法）」の3つの軸があります。 「システム開発の種類」で調べると、受託開発・SES・パッケージ・SaaS・スクラッチ・アジャイル…とさまざまな言葉が出てきて混乱しがちですが、これらは別々の軸の話が混ざっているだけです。軸ごとに整理すれば、自社が何を選べばよいかが見えてきます。
本記事は、システム開発をこれから発注する経営者・情シス・DX担当の方に向けて、システム開発の種類を軸ごとに整理し、自社の目的・予算・体制に合う選び方の判断軸をお伝えします。種類別の費用感は業務システム開発の費用相場（種類別）、発注先そのものの見極め方はITベンダーとは（種類・SIerとの違い・選び方）で扱っています。本記事は、その前提となる**「開発の種類そのもの」**を整理します。
目次
- 結論：種類は「発注・作り方・進め方」の3軸で整理する
- 軸1：発注のしかたの種類（受託・SES・派遣・内製）
- 軸2：作り方の種類（スクラッチ・パッケージ・SaaS・ローコード）
- 軸3：進め方の種類（ウォーターフォール・アジャイル）
- 自社に合う種類を選ぶ判断軸
- 目的別・よく選ばれる組み合わせ例
- 種類選びが費用を大きく左右する理由
- 種類選びでよくある失敗
- 種類選び チェックリスト
- よくある質問（FAQ）
- 開発の種類選びで迷ったら
<a id="conclusion"></a>
結論：種類は「発注・作り方・進め方」の3軸で整理する
システム開発の種類は、次の3つの軸に分けると混乱しません。
- 発注のしかた（契約・体制）：受託開発、SES、派遣、内製 — 誰がどんな契約で開発を担うか
- 作り方（構築方法）：スクラッチ、パッケージ、SaaS、ローコード／ノーコード — 何をベースに作るか
- 進め方（開発手法）：ウォーターフォール、アジャイル — どんな流れで開発するか
たとえば「受託開発でスクラッチをウォーターフォールで作る」「準委任のラボ型でSaaSを土台にアジャイルで育てる」というように、3軸の組み合わせで一つの開発の形が決まります。「システム開発の種類」を選ぶとは、この3軸それぞれで、自社に合う選択肢を選ぶことに他なりません。
多くの発注者が種類選びで迷うのは、これらを一つの表に並べて「受託とSaaSとアジャイル、どれがいいのか」と比べてしまうからです。受託は発注のしかた、SaaSは作り方、アジャイルは進め方と、それぞれ別の軸の話なので、同列に比べても答えは出ません。まず軸を分けること——これが種類選びの第一歩です。以下、軸ごとに見ていきます。
<a id="order"></a>
NOCODE EXIT
Bubble／kintone の限界、スクラッチ移行で解消しませんか？
ノーコードの肥大化・応答遅延・カスタマイズ限界を Laravel+Vue 移行で根治。概算費用・移行期間・データ移行設計・並行稼働プランをその場で確認できます。
軸1：発注のしかたの種類（受託・SES・派遣・内製）
まず「誰が、どんな契約で開発を担うか」の種類です。
横にスクロールして確認できます
| 種類 | 概要 | 特徴 |
|---|---|---|
| 受託開発（請負） | 完成責任を負って成果物を納品してもらう | 成果物が明確。要件が固まっている案件向き |
| 準委任（ラボ型・技術者常駐） | 作業（労働）を提供してもらう。完成責任は負わない | 柔軟に進められる。管理力が要る |
| SES | 技術者の労働を提供する契約形態 | 準委任に近い。指揮命令の扱いに注意 |
| 派遣 | 派遣スタッフが自社の指揮下で作業 | 自社が指揮を執る。体制がある場合向き |
| 内製 | 自社の社員が開発する | ノウハウが残る。人材確保が前提 |
発注のしかたを選ぶ際の要点は、要件がどれだけ固まっているかと、社内に管理できる人がいるかです。要件が固まっていれば受託（請負）で完成責任を負ってもらいやすく、固めながら進めたいなら準委任が向きます。準委任やSESは柔軟な反面、発注側の管理力が弱いと成果が薄くなります。
ここで発注側が知っておくべき制約が一つあります。請負・準委任の形で契約していても、発注者が相手方の技術者へ直接指揮命令をすると、実態として労働者派遣に当たると判断されうるという点です。派遣か請負かは契約の名称ではなく実態で判断される、と厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（いわゆる37号告示）が定めており、同省は判断事例をまとめた疑義応答集も公開しています。「常駐してもらっているのだから、うちの担当者が直接作業を指示すればよい」という運用は、この線引きに触れる可能性があります。常駐型を選ぶなら、指示は誰から誰へ出すのかを契約時点で決めておいてください。
契約形態の使い分けは、発注全体の流れとあわせて初めてのシステム開発外注ガイド、請負と準委任の条文上の違いは受託開発とは何かも参考にしてください。
<a id="build"></a>
軸2：作り方の種類（スクラッチ・パッケージ・SaaS・ローコード）
次に「何をベースに作るか」の種類です。ここは費用と柔軟性のトレードオフが大きく出ます。
横にスクロールして確認できます
| 種類 | 概要 | 向く状況 | 弱点 |
|---|---|---|---|
| フルスクラッチ | ゼロから独自に開発 | 独自要件・競争力の中核 | 費用・期間が大きい |
| パッケージ | 既製ソフトを導入・カスタマイズ | 業界標準の業務がある | カスタマイズに限界・費用 |
| SaaS | クラウドの月額サービスを利用 | 標準機能で足りる | 独自要件に対応しにくい |
| ローコード／ノーコード | 部品を組み合わせて開発 | 標準＋軽いカスタム | 複雑・大規模には不向き |
近年は、「全部スクラッチ」か「全部SaaS」かの二択ではなく、組み合わせるのが主流です。標準業務はSaaSやパッケージで賄い、自社の競争力に関わる独自部分だけをスクラッチやローコードで作る、という設計です。作り方を選ぶ判断は、**「その機能は自社の競争力の中核か、汎用的な業務か」**を基準にすると外しにくくなります。競争力の中核は独自開発でノウハウを残し、汎用業務は既製品で割り切る、という切り分けです。種類別の費用感は業務システム開発の費用相場（種類別）を参照してください。
<a id="method"></a>
軸3：進め方の種類（ウォーターフォール・アジャイル）
最後に「どんな流れで開発するか」の種類です。
横にスクロールして確認できます
| 種類 | 概要 | 向く状況 | 注意点 |
|---|---|---|---|
| ウォーターフォール | 要件定義→設計→開発→テストと順番に進める | 要件が固まっている・仕様が明確 | 途中の変更に弱い |
| アジャイル | 小さく作って反復しながら育てる | 要件が変わり得る・検証しながら進める | 発注側の関与とゴール管理が要る |
ウォーターフォールは、作るものが明確で変更が少ない案件に向き、総額や納期を見積もりやすい反面、途中の仕様変更に弱いという特徴があります。アジャイルは、変化に強く検証しながら進められる反面、発注側の関与とゴール管理が甘いと「いつまでも終わらない」状態になりがちです。両者の詳しい比較はウォーターフォールとアジャイルの比較、アジャイルで外注する際の費用はアジャイル開発の外注費用相場にまとめています。どちらが良いかは、要件の固さと変化の可能性で決まります。
<a id="judge"></a>
自社に合う種類を選ぶ判断軸
3軸それぞれの選択肢を、自社の状況に合わせて選ぶための判断軸です。
軸1：要件はどれだけ固まっているか
固まっているなら、受託（請負）＋ウォーターフォールが見積もりやすく確実です。固まっていない・変わり得るなら、準委任＋アジャイルで検証しながら進めます。
軸2：その機能は競争力の中核か、汎用業務か
中核ならスクラッチやローコードでノウハウを残し、汎用業務ならSaaS・パッケージで割り切ります。全部を独自開発しようとすると過剰投資になります。
軸3：社内に管理できる人がいるか
いれば準委任・アジャイルなど柔軟な形が機能します。いなければ、受託で完成責任を負ってもらう方が安全か、まず管理を補う体制づくりが先になります。
軸4：予算とスピードの優先度は
初期費用を抑えたいならSaaS・ノーコード、独自性・拡張性を優先するならスクラッチ、というように、予算と求める水準のバランスで選びます。
<a id="combo"></a>
目的別・よく選ばれる組み合わせ例
3軸を組み合わせると、目的に応じた「開発の形」が見えてきます。あくまで一例ですが、典型的な組み合わせを示します。自社の状況に近いものを出発点にすると、検討が進めやすくなります。
横にスクロールして確認できます
| 目的・状況 | 発注のしかた | 作り方 | 進め方 |
|---|---|---|---|
| 仕様が固まった業務システムを確実に作りたい | 受託（請負） | パッケージ＋一部スクラッチ | ウォーターフォール |
| 新規サービスを検証しながら育てたい | 準委任（ラボ型） | SaaS／ローコード＋一部スクラッチ | アジャイル |
| 標準業務を早く安く回したい | — | SaaS | 導入設定中心 |
| 競争力の中核となる独自システム | 受託／内製 | フルスクラッチ | 案件により選択 |
| 社内にノウハウを残しながら進めたい | 準委任＋内製の併用 | ローコード＋スクラッチ | アジャイル |
この表のポイントは、目的が変われば最適な組み合わせも変わるということです。「他社がこうしているから」ではなく、自社の要件の固さ・競争力か汎用か・体制・予算に照らして組み合わせを選びます。一つの正解があるわけではなく、自社の状況に合った組み合わせが正解です。
<a id="cost-reason"></a>
種類選びが費用を大きく左右する理由
同じ「システムを作る」でも、選ぶ種類によって費用は何倍も変わります。その理由を理解しておくと、見積もりの妥当性も判断しやすくなります。
- 作り方で初期費用が大きく変わる：フルスクラッチはゼロから作るため費用が大きく、SaaSやパッケージは既製の土台を使うため初期を抑えられます。ただしSaaSは月額の継続費用がかかります。
- 発注のしかたで総額の見え方が変わる：受託（請負）は総額が見積もりで確定しやすく、準委任は工数ベースで、進め方次第で総額が変わります。
- 進め方で変更コストが変わる：ウォーターフォールは後からの変更が高くつきやすく、アジャイルは変更を前提に進めるため方向転換の柔軟性があります。
- 組み合わせ次第で無駄が生まれる：汎用業務をスクラッチで作る、独自業務を無理にSaaSへ寄せる、といったミスマッチが、費用の無駄や作り直しを生みます。
つまり、種類選びは費用の設計そのものです。**「どの種類が安いか」だけでなく、「自社の要件に対して、どの組み合わせが最も無駄がないか」**で考えることが、費用最適化につながります。見積もりを比較するときも、各社が前提とする種類（作り方・進め方）が違えば金額も変わるため、前提を揃えて比較してください。費用の読み方はシステム開発の費用・見積もりガイドも参考になります。
<a id="failure"></a>
種類選びでよくある失敗
- 軸を混同して比較する：「受託かSaaSか」のように、別軸の選択肢を同列に並べて迷う。まず軸を分けることが必要。
- 汎用業務までスクラッチで作る：どの会社でも似た機能を独自開発し、費用と期間が膨らむ。
- 独自の競争力までSaaSに寄せる：標準機能に業務を無理に合わせ、現場が回らなくなる。
- 要件が固まっていないのに請負で契約する：変更のたびに追加費用と交渉が発生する。
- 管理できる人がいないのに準委任を選ぶ：人は来たが進まない、工数だけ消化される状態になる。
<a id="checklist"></a>
種類選び チェックリスト
- 「発注のしかた・作り方・進め方」の3軸を分けて検討している
- 要件がどれだけ固まっているかを把握している
- 各機能が競争力の中核か汎用業務かを仕分けた
- 社内に管理できる人がいるかを確認した
- 予算とスピード・独自性の優先度を決めてある
- スクラッチとSaaS等を組み合わせる選択肢を検討した
- 選んだ種類が自社の目的に合っているかを説明できる
<a id="faq"></a>
よくある質問（FAQ）
Q. 受託開発とSESはどう違いますか？ A. 受託（請負）は完成した成果物を納品する契約で、完成責任をベンダーが負います。SESは技術者の労働を提供する契約で、完成責任は前提ではありません。要件が固まっているなら受託、柔軟に進めたいならSESや準委任が向きます。
Q. SaaSとスクラッチ、どちらを選ぶべきですか？ A. その機能が汎用的な業務ならSaaS、自社の競争力に関わる独自要件ならスクラッチが向きます。多くの場合は、標準業務をSaaSで、独自部分だけスクラッチで、と組み合わせるのが現実的です。
Q. ウォーターフォールとアジャイル、どちらがいいですか？ A. 要件が固まっていて変更が少ないならウォーターフォール、要件が変わり得る・検証しながら進めたいならアジャイルが向きます。アジャイルは発注側の関与とゴール管理が前提になります。
Q. 種類が多すぎて選べません。どこから決めればいいですか？ A. まず「発注のしかた・作り方・進め方」の3軸に分け、それぞれで自社の状況（要件の固さ・競争力か汎用か・管理体制・予算）に照らして選びます。軸を混同したまま比較すると混乱します。
Q. 全部スクラッチで作れば間違いないですか？ A. いいえ。汎用業務までスクラッチで作ると費用・期間が膨らみ、過剰投資になります。独自性が必要な部分に絞ってスクラッチを使い、それ以外は既製品を活用する方が合理的です。
Q. パッケージとSaaSはどう違いますか？ A. パッケージは既製のソフトを購入して自社に導入・カスタマイズするもの、SaaSはクラウド上のサービスを月額で利用するものです。パッケージは自社で保有・改変しやすい反面カスタマイズに費用がかかり、SaaSは初期費用を抑えやすい反面、独自要件への対応やデータの持ち出しに制約があることがあります。
Q. ローコード／ノーコードは本格的なシステムに使えますか？ A. 標準的な機能や軽いカスタマイズなら十分実用になりますが、複雑な業務ロジックや大規模・高い性能が求められるシステムには不向きなことがあります。まずローコードで作れる範囲かを見極め、足りない部分だけスクラッチで補う、という組み合わせも有効です。
Q. 種類は途中で変更できますか？ A. 進め方（ウォーターフォール／アジャイル）は開始前に決めるのが基本で、途中変更は混乱を招きます。作り方は、たとえばSaaSで始めて後からスクラッチに移すことも可能ですが、移行コストがかかります。だからこそ、最初の種類選びを丁寧に行うことが重要です。
<a id="cta"></a>
開発の種類選びで迷ったら
システム開発の種類は、「発注のしかた・作り方・進め方」の3軸に分けて整理すれば、自社が選ぶべき選択肢が見えてきます。迷いが生じるのは、たいてい別々の軸の選択肢を同列に並べて比較しているときです。3軸に分け、要件の固さ・競争力か汎用か・管理体制・予算を基準に選ぶ——これが、種類選びで失敗しないための順序です。
種類選びは、その後の費用・期間・成否を大きく左右する最初の分岐点です。ここを製品ありき・手法ありきで決めると、自社に合わない形で開発が進み、後戻りのコストが大きくなります。
GXOは、特定の開発手法や製品を売り込む前に、自社の目的に合う開発の種類の整理と、発注先の選び方の相談からご一緒します。
- 自社の案件にどの種類が合うか整理したい → 発注先・進め方の相談（ベンダー選定）
- 種類別の費用感を知りたい → 業務システム開発の費用相場（種類別）
- 発注先の種類（ベンダー・SIer）から整理したい → ITベンダーとは
- 見積もり・提案に出る工程用語を確認したい → システム開発工程の略語・用語集
- 新規サービスを小さく検証してから作りたい → MVP開発とは
- 受け取った見積もりが妥当か見てほしい → 見積もりセカンドオピニオン
- まず自社のIT・DXの現在地を診断したい → DX成熟度診断
「どの種類がいいか」より先に「軸を分けて、自社の状況に照らして選ぶ」。その整理を、発注を決める前にご一緒します。
