Webサービスやスマホアプリ、業務システムの開発を外部へ依頼するときは、「受託開発」という名称だけで進め方を決めると、見積もりや体制、受入の前提がずれることがあります。完成させたい成果物を任せたいのか、継続的に開発するチームを確保したいのかを最初に分けて考えることが重要です。
この記事では、受託開発・SES・ラボ型開発・自社開発の違いと、費用比較、相談準備、会社選定、発注後の管理方法を整理します。形態名ではなく、自社の条件に合う開発の進め方を選べるようになります。
開発形態は名称だけで決めず、任せる範囲、変更の多さ、発注側で判断できる体制を基準に比較します。どの形態でも、目的・優先順位・受入・変更承認の役割を明確にすることが重要です。
01Section受託開発とは何か：形態名ではなく任せる範囲で考える
受託開発は、Webサービス、スマホアプリ、業務システムなどを外部の開発会社へ委託する際に使われる一般的な呼称です。要件整理から設計、実装、テスト、保守までのどこを依頼するかは案件ごとに異なります。
受託開発
外部の開発会社にシステムやアプリの開発を委託する際の一般的な呼称です。請負・準委任などの契約類型と一対一に対応するものではなく、工程ごとの作業範囲、成果物、受入、変更条件を確認する必要があります。
契約や取引上の論点は、呼称ではなく提案書、見積書、個別契約、実際の運用を合わせて確認します。IPAの情報システム・モデル取引・契約書も、受託開発や保守運用、アジャイル開発の外部委託を対象別に扱っています。
4つの形態を同じ軸で比較する
4つの形態は、目的や変更の扱い、受入方法、発注側の関与を同じ軸で比較します。契約や運用上の責任範囲は、形態名ではなく個別の条件で確認します。
| 比較軸 | 受託開発 | SES | ラボ型開発 | 自社開発 |
|---|---|---|---|---|
| 発注目的 | 定めた目的・範囲の実現 | 技術支援・開発リソースの確保 | 継続チームによる開発・改善 | 開発能力を社内に蓄積する |
| 内容の具体化 | 初回範囲や対象外を合意して進める | 発注側が依頼内容や優先順位を整理する | 優先順位を継続的に見直す | 自社で決める |
| 日々の管理 | PM運営、会議、報告の範囲を確認する | 窓口、連絡方法、優先順位、管理分担を確認する | プロダクト判断とチーム運営方法を確認する | 自社で実施する |
| 成果物・受入 | 成果物、テスト、受入基準を明確にする | 稼働だけでなく成果確認・受入方法を決める | リリース単位の成果物と受入条件を確認する | 自社で決定・実施する |
| 変更対応 | 影響、費用、納期、承認者を確認して進める | 契約・体制内で優先順位を見直す方法を確認する | バックログの変更ルールを確認する | 自社の体制内で対応する |
| 発注者の関与 | 目的、レビュー、受入、変更承認を担う | 依頼整理、優先順位付け、成果確認を継続する | プロダクト判断を継続する | 最も大きい |
ラボ型開発
継続的な開発チームを確保し、優先順位を見直しながら開発・改善する形態として使われる呼称です。専任度、最低利用期間、メンバー交代、品質管理、成果物・権利の条件は提供会社ごとに異なります。
契約名や形態名だけで責任範囲を決めない
受託開発、SES、ラボ型開発は契約類型そのものではありません。作業の依頼方法、検収・受入、再委託、成果物や権利、保守の扱いは、提案書・見積書・個別契約・実運用で確認してください。
SES・ラボ型で特に確認すること
SESでは、名称だけで、発注者が外部要員へ直接作業指示できるかを決めるべきではありません。誰を依頼窓口にするか、誰が優先順位を決めるか、進捗報告・品質確認・受入をどう行うかを、契約と実運用に沿って定めます。厚生労働省の請負・派遣に関するガイドも、契約名称だけでなく実態を踏まえた確認の重要性を示しています。
ラボ型では、固定チームかどうかだけで判断せず、専任度、最低期間、交代時の引継ぎ、優先順位変更の方法、PM・テスト・デザインの担当範囲を確認します。継続体制を選んでも、目的、優先順位、変更、受入の最終判断を誰が担うかは発注側で明確にします。
02Section自社案件に受託開発は向くか：5条件で判断する
受託開発は、初回リリースで実現したい目的、利用者、必須機能、対象外、受入条件を一定程度説明できる案件で主軸にしやすい選択肢です。一方、仮説検証を繰り返し、優先順位が頻繁に変わる案件では、継続チームや内製化を含めて比較する必要があります。
5条件を順番に確認する
受託開発が向くかは、要件の固まり具合だけでは決まりません。変更頻度、社内の判断体制、継続開発、内製化の方針を順に確認し、必要に応じてフェーズごとに進め方を組み合わせます。
- 要件確度：初回リリースの目的、利用者、必須機能、対象外、受入条件を説明できるなら、受託開発の範囲を設定しやすくなります。説明が難しい場合は、要件整理や試作を先に置きます。
- 変更頻度：節目ごとに変更を評価できるなら初回範囲を定めやすくなります。毎週・隔週で優先順位が大きく変わるなら、継続的に判断できる体制と変更管理が必要です。
- 発注側の体制と初回期限：依頼整理、レビュー、受入、変更承認を担う担当者がいるか確認します。動かせない期限がある場合は、必須機能と後続化する項目、受入条件を分けます。判断できない場合は、まず発注者側の責任者と回答期限を定め、期限だけを固定して範囲を広げ続ける進め方は避けます。
- 継続開発量：初回リリース後も改善・追加開発が続くなら、都度発注だけでなく固定チーム、保守改善、内製化の体制を比較します。
- 内製化方針：将来、自社が技術・運用知識を持つ必要があるなら、ソースコード、設計書、クラウドアカウント、運用手順、引継ぎを初期条件に含めます。
開発形態を広く比較したい場合は、開発アウトソーシングの選び方も参照すると、外注の選択肢を整理しやすくなります。海外リソースの活用まで比較対象に含める場合は、言語、時差、連絡体制、セキュリティなどを追加で確認できるオフショア開発の基礎知識を確認してください。
混在条件ではフェーズごとに組み合わせる
バックログ
実装候補の機能、改善、調査事項を優先順位付きで管理する一覧です。継続的に改善する案件では、変更対象と優先順位を共有するために使われます。
要件が不確実で、初回期限もある場合は、要件整理・試作を行い、必須範囲だけを受託開発で初期リリースし、その後に段階リリースする方法を検討します。この場合、事業責任者が優先順位と対象外を決裁できることが前提です。
初期リリースを急ぎ、将来は内製化したい場合は、初期開発を外部へ委託し、運用担当や内製担当への並走・引継ぎを早期に始めます。発注側は、受入・運用の担当者を開発終盤ではなく着手時点で確保します。
継続改善量が多く、社内PMがいる場合は、外部の継続チームや技術支援と、自社のプロダクト管理を組み合わせる方法が候補になります。優先順位を定期的に決める会議体と、バックログの変更ルールを運用できることが必要です。
03Section費用と期間は総額ではなく、前提と費目を分けて確認する
開発費用は、工程、体制、品質条件、外部サービス、外部連携、データ移行、保守範囲によって変わります。公開情報だけでは、これらを同じ条件にそろえた価格比較が難しいため、金額相場だけで予算や発注先を判断することは避けるべきです。
ポイント
見積総額だけでは比較しない
初年度予算を5つの費目で比較する
開発予算は総額だけでなく、要件整理、初期開発、外部費用、保守・運用、変更枠に分けて比較します。各費目の対象範囲と除外事項をそろえることが、見積差の確認につながります。
初年度予算は、次のように分けて確認します。
初年度予算 ＝ 要件整理 ＋ 初期開発 ＋ 初期外部費用 ＋ 初年度保守・運用 ＋ 承認済み変更枠
| 費目 | 見積書でそろえる前提 | 含有・除外の確認 | 稟議で残す判断 |
|---|---|---|---|
| 要件整理 | 目的、対象範囲、未決事項、成果物 | 業務整理、画面検討、調査、レビュー回数 | 初期開発と重複計上していないか、次工程へ進む条件は何か |
| 初期開発 | 必須機能、対象外、品質、期限 | PM、UI/UX、設計、実装、テスト、移行・受入支援 | 機能を削る・後続化する条件と、受入基準 |
| 初期外部費用 | 利用する外部サービスと契約主体 | クラウド、API、ストア、第三者サービス、接続試験 | 月額・従量費・一時費用を開発費と分けて管理する |
| 初年度保守・運用 | 運用開始後の対象範囲 | 監視、障害対応、脆弱性対応、問い合わせ、追加開発との境界 | 対応時間、連絡方法、追加費用となる条件 |
| 承認済み変更枠 | 想定される未決事項や変更要因 | 変更時の調査、再見積、優先順位変更 | 費用・納期・品質への影響を誰が承認するか |
候補各社には、目的、必須・希望・対象外、連携、品質、期限、未決事項を同じ資料で渡します。見積差が生じた場合は、機能数だけでなく、役割別体制、テスト、受入支援、外部費用、保守、変更条件のどこが異なるかを確認します。
工期データは日程点検の補助にとどめる
IPAのソフトウェア開発分析データ集2022は、工数と工期に関する公開データを提供しています。ただし、個別案件の金額、確定納期、Webサービスやスマホアプリの相場を示す資料ではありません。
提案日程を点検する際に参照する場合も、見積上の工数定義と対象工程が資料の条件と一致しているかを確認します。要件整理、UI/UX、外部連携、データ移行、受入、保守などがどこまで工数に含まれるかが異なるなら、同じ基準で比較できません。短い日程の提案には、対象外になっている工程、依存先、発注側の回答期限を確認します。
04Section相談前にそろえる情報と、社内で決める役割
要件が完全に固まっていなくても相談はできます。ただし、確定していること、仮説として検証したいこと、まだ決まっていないことを分けずに伝えると、候補ごとに見積前提が変わり、比較が難しくなります。
要件、作業内容、成果物、体制を明確にする考え方は、デジタル社会推進標準ガイドラインでも示されています。行政向けの資料であるため、民間案件では案件規模に合わせて必要な範囲に絞って活用します。
初回相談・見積依頼の前に整理する5項目
- ✓
目的と利用者
解決したい課題、対象利用者、利用場面、成功を判断する基準を記載する。
- ✓
必須事項と対象外
初回リリースで必要な機能・業務・品質条件と、今回実施しない範囲を分ける。
- ✓
連携・データ・制約
既存システム、API、データ移行、個人データ、利用端末、社内規程を整理する。
- ✓
期限・予算制約
動かせない期限、希望時期、予算上限または稟議時期を共有する。未定の場合も未定と明記する。
- ✓
確定事項・仮説・未決事項
未決事項には決定者、決定予定日、見積・日程への影響を記載する。
発注側では、目的と投資判断を行う事業責任者、日常連絡と情報整理を担う実務窓口、業務観点で受入を判断する受入責任者、範囲・費用・納期への影響を承認する変更承認者を任命します。個人データ、再委託、権利、契約条件に関わる場合は、法務または情報セキュリティ担当がいつ確認するかも決めます。
外部にPM支援などを依頼する場合でも、目的、優先順位、変更、受入の最終決裁者を発注側で置くことが、判断遅延を防ぐ基本になります。
05Section開発会社は、比較可能な見積もりと5つの評価軸で選ぶ
相見積もりは、候補各社へ同じ版の依頼資料を渡すところから始めます。依頼資料や質問への回答が候補ごとに異なるままでは、価格差が対象範囲の差なのか、品質・体制の差なのかを判断できません。
前提が異なる見積もりを総額だけで比較しない
要件整理、テスト、受入支援、移行、外部費用、保守、変更条件の含有範囲が異なる見積もりは横並びで比較できません。前提をそろえ直すか、差分を費目ごとに説明できる状態にしてから選定します。
まず、必須機能・対象外・主要な前提、希望期限への工程表、個人データなどの管理方法、引渡し・保守の説明があるかを確認します。そのうえで、類似案件の件数と、自社の利用者・業務・連携・品質条件への適合根拠を分けて評価します。
| 評価軸 | 確認する内容 | 選定理由として残すポイント |
|---|---|---|
| 対象範囲 | 必須機能、対象外、未決事項、期限内に実現しない範囲 | 自社の目的と初回リリース範囲に合っているか |
| 体制・継続性 | PM、設計、実装、テストの担当、代替要員、引継ぎ、会議体 | 担当交代や継続開発があっても運営できるか |
| 品質・受入 | テスト方針、品質条件、欠陥の扱い、受入支援、リリース判定 | 誰が何を確認し、受入と判断するかが明確か |
| 費用透明性 | 工程別の内訳、外部費用、除外事項、変更時の扱い | 総額の差を対象範囲・品質・体制の差として説明できるか |
| 保守・移管 | コード、設計書、テスト結果、アカウント、運用手順、障害対応 | 運用開始後や会社変更時にも保守できるか |
商談では、未決事項をどの工程で誰が決めるか、変更をどう受け付けて再見積するか、個人データや再委託をどう管理するか、何を引き渡すかを全候補に同じように質問します。比較の根拠は、提案書の説明だけでなく、確認した回答と前提条件も一緒に記録します。
06Section発注後に失敗しないための進め方とリスク管理
発注後も、目的、優先順位、業務レビュー、受入、変更承認の役割は発注側に残ります。開発会社へ任せる範囲を明確にしながら、節目ごとに判断できる状態を維持することが、手戻りや認識ずれを抑える方法です。
ポイント
発注後も、目的・優先順位・受入の責任は残る
3つの節目で確認する
受託開発を進める際の確認手順
- Step01
要件整理
発注側は、目的、利用者、業務ルール、優先順位、対象外を判断します。開発会社と、要件一覧、画面や業務フロー、未決事項、受入観点を確認し、未決事項には決定者と期限を置きます。
- Step02
設計・実装
設計内容、例外処理、テスト方針、進捗、課題を定例で確認します。仕様変更は口頭で進めず、変更内容、理由、費用・納期・品質への影響、承認者を記録します。
- Step03
受入・保守
受入テスト、リリース判断、未解決課題の扱い、引渡し、保守条件を確認します。運用開始後の障害連絡、保守範囲、追加開発との区分も文書で共有します。
受入テスト
発注側が、合意した業務・機能・品質条件を満たしているかを確認するテストです。誰が何を確認し、どの結果をもって受入とするかを事前に決めます。
障害時の対応条件
受付時間、連絡方法、初動の目安、対応対象、費用条件などの取り決めです。保守範囲と追加開発の境界も合わせて確認します。
個人データ・引渡し・保守は着手前から確認する
変更は、内容、理由、費用、納期、品質への影響、承認者を記録して管理します。受入では、重要な業務シナリオ、品質条件、未解決課題を確認します。引渡しでは、ソースコード、設計書、テスト結果、クラウドやストアなどのアカウント、運用手順を、誰にいつどの形式で渡すかを明確にします。
個人データを扱う場合、委託先の安全管理措置、アクセス権限、再委託、取扱状況、事故時の連絡方法を確認します。個人情報保護委員会のガイドラインでは、個人データの取扱いを委託する場合に、委託先を必要かつ適切に監督する必要があるとされています。
個人データを扱う案件で確認する事項
委託先の安全管理措置
開発環境、データの保管場所、取扱担当者、必要な管理方法を確認する。
アクセス権限
誰が、どのデータに、どの期間アクセスするかを整理し、不要になった権限を見直す。
再委託の有無と管理方法
再委託先の有無、役割、データへのアクセス範囲、管理方法を確認する。
事故時の連絡方法
連絡窓口、報告の流れ、初動対応で共有する情報を事前に定める。
契約不適合、検収、再委託、権利帰属、損害賠償などは、案件の契約条件によって確認内容が変わります。必要に応じて社内法務、情報セキュリティ担当または専門家に確認し、契約上の論点はシステム開発の契約で確認すべきポイントも参照してください。
受託開発で誤解しやすいポイント
受託開発と請負契約は同じですか？+
受託開発は一般的な呼称であり、請負契約と必ず同じ意味ではありません。工程ごとの作業範囲、成果物、受入、変更条件は、提案書・見積書・個別契約で確認します。
SESなら発注側が直接タスクを割り振れますか？+
SESという呼称だけでは判断できません。依頼窓口、優先順位の決定者、進捗報告、品質確認、受入の方法を、契約と実際の運用に沿って確認します。
要件が固まっていなくても受託開発を相談できますか？+
相談は可能です。確定事項、仮説、未決事項を分け、未決事項には決定者と決定予定日を添えると、要件整理や試作を含めた提案を比較しやすくなります。
納品後の保守やソースコードの引渡しは自動的に含まれますか？+
自動的に含まれるとは限りません。引渡し対象、アカウント管理、保守範囲、障害対応、追加開発との区分を、着手前から確認します。
まずは、目的、初回範囲、未決事項、期限、発注者側の役割を一つの依頼資料に整理します。その同じ資料を候補各社へ渡し、前提と含有・除外をそろえたうえで、見積もりと提案内容を比較してください。
Webアプリ・SaaS開発の依頼先を比較する
初回範囲や未決事項を整理したうえで、開発会社の体制、対応範囲、見積もり条件を比較したい場合に活用できます。
Webアプリ・SaaS開発4593社掲載
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。
