システム開発の外注ガイド：依頼の流れ・費用・失敗しない進め方

システム開発を外注したいものの、「仕様書が完成していない」「見積もりの違いをどう比べるべきか」「納品後に使えない状態にならないか」と迷う担当者は少なくありません。Webサービス、業務システム、スマホアプリの外注では、開発会社へ依頼する前に、発注側が目的・優先順位・制約・判断体制を整えることが重要です。

この記事では、相談準備から要件整理、費用・期間の比較、依頼先選定、進行管理、受入・検収、運用移管までを順に解説します。自社の条件に合う外注の進め方と、比較・受入の判断基準を整理できます。

外注開発は実装だけで完結しません。相談前の整理から受入・運用移管まで、発注側の確認・判断を工程計画に含めて進めます。

01Section外注相談を始められる状態を確認する

詳細な仕様書がなくても、外注相談は始められます。先に必要なのは、何を作るかを細部まで決めることではなく、「誰のどの課題を、どの状態まで改善したいか」を関係者で共有することです。

外注プロジェクトの全体像を先に把握する

ソフトウェア開発の外注は、相談して見積もりを受け取ったらすぐ実装に入るわけではありません。一般には、構想・課題整理、提案・見積もり、契約・計画、要件定義、設計・開発、テスト、受入、検収、リリース・運用移管という流れで進みます。

このうち発注側が特に見落としやすいのは、要件の確認、社内レビュー、受入テスト、運用準備です。これらを開発会社の作業と切り離して考えると、見積もりやスケジュールに発注側の対応時間が含まれず、後から遅延につながります。

デジタル庁の標準ガイドラインは、要件定義、調達、設計・開発、運用・保守、役割分担を関連する管理領域として扱っています。政府情報システム向けの資料ですが、民間案件でも確認漏れを防ぐ観点として参照できます。

相談前に決めることと、相談後に詰めること

相談前に確定していなくてもよいのは、画面の細かな仕様、技術方式、実装方法です。これらは、業務要件や制約を踏まえて開発会社と検討する余地があります。

一方で、発注側が曖昧なままにしないほうがよいのは、解決したい課題、対象ユーザー、初回リリースの必須範囲、希望時期、予算枠、扱う情報、社内の意思決定体制です。これらがない状態で固定見積もりを急ぐと、各社の前提が異なり、金額や期間を比較しにくくなります。

初回相談で共有する情報と成功指標

まずは、次の項目を埋められるかを確認してください。すべてが確定している必要はありませんが、未確定の項目と、それを決める担当者・時期を明らかにしておくことが大切です。

02Section要件確度に合わせて進め方を選ぶ

仕様書の完成度ではなく、課題・対象・検証仮説・受入条件の整理状況に応じて、先に進めるフェーズを選びます。

要件が曖昧だからといって、外注相談を先延ばしにする必要はありません。ただし、不確実な内容をすべて本開発の固定範囲に含めると、追加費用や日程への影響が見えにくくなります。要件の確度に応じて、先に行うフェーズを分けることが有効です。

要件が未確定でも相談できる範囲

課題、対象ユーザー、利用場面、制約、検証したいことが説明できれば、課題整理や要件定義から相談できます。候補各社から実現方法や進め方の情報を集めることも、要件を具体化する手段の一つです。

ただし、対象業務や優先順位が整理されず、成功条件も決まっていない場合は、開発範囲を固定する前に課題整理を行うほうが適しています。本開発の見積もりと、課題整理・試作の費用を混在させず、各フェーズの成果物と次の判断条件を分けましょう。

課題整理・要件定義・MVP・本開発の違い

MVPは、すべての要望を小さく作ることではありません。検証したい仮説と測定指標に必要な最小範囲を決め、継続・拡張・見直しを判断するためのフェーズです。本開発に必要な受入条件や運用条件まで固まっている場合とは、目的が異なります。

次フェーズへ進む判断条件

次のフェーズへ進むかは、「資料ができたか」だけでなく、判断に必要な不確実性が減ったかで決めます。例えば要件定義後であれば、初回リリースの必須範囲、連携・移行の前提、受入基準、未決事項の扱いを説明できる状態が目安です。

固定のリリース期限がある場合も、要件確認、連携・移行の検証、受入テストを単純に省くのは避けるべきです。後続化できる機能、段階リリースの可否、残すべき品質・受入条件を、業務責任者と最終承認者が記録して判断します。

03Section費用と期間は相場ではなく条件をそろえて比較する

金額だけを並べず、初期費用と年間継続費用を分けたうえで、対象範囲・品質条件・前提をそろえて比較します。

外注費用や期間は、対象業務、機能、連携、データ移行、体制、品質条件、発注側のレビュー体制によって変わります。公開情報だけでは同じ条件での比較が難しいため、固定的な市場相場ではなく、候補各社への依頼条件をそろえて比較することが実務的です。

初期費用と継続費用の構造を分ける

初期費用と、運用開始後に継続する費用を混ぜると、初年度の予算や翌年度以降の負担を判断しにくくなります。クラウド、SaaS、APIなどの利用料は、利用規模や契約条件で変わるため、公式価格ページまたは個別見積もりで確認してください。

工程期間を左右する条件を把握する

実装工程だけでは期間は決まりません。要件の確度、レビュー回数、承認経路、連携先との調整、移行対象のデータ品質、受入シナリオ数、対象環境、未解決事項の有無によって変動します。

候補各社には、工程別の開始条件・完了条件、発注側の回答期限、連携先が担う作業、遅延しやすい前提を回答してもらいます。見積もりでは規模、工数、工期、コスト、変動要因を分けて考えることが重要であり、IPAの定量的見積りに関する資料も、要件・仕様変更が見積もりや日程に与える影響を整理する参考になります。

予算化・工程計画ワークシートで比較可能にする

下表を案件ごとに埋め、全候補に同じ条件で回答を求めます。初期費用合計は「構想・要件整理＋初期構築＋連携・移行＋リリース支援＋初期設定費」、年間継続費用合計は「保守＋監視・基盤＋外部サービス＋障害対応」で集計します。初年度総額は、この二つを合算して確認します。

金額や月数を比較する前に、対象範囲、品質条件、前提・除外項目、発注側作業の差分を解消してください。予算を超える場合は、目的検証に直結する必須機能を残し、後続化する機能、その影響、判断者、決定期限を記録します。

04Section相見積もりと二段階選定で依頼先を決める

選定は、採択できない条件を先に確認してから、提案・体制・品質を比較する二段階に分けると判断根拠を残しやすくなります。

候補ごとの提案内容が異なる状態では、見積額だけを並べても適切に比較できません。候補を探す際は開発サービスの一覧も参照できますが、候補を絞った後は、全候補へ共通の資料を渡し、同じ条件で回答を受けることが重要です。

全候補へ渡す共通資料と回答依頼

共通資料には、背景・目的、対象業務・対象ユーザー、必須機能と後続候補、連携・移行、扱う情報、希望時期、発注側のレビュー・承認条件を含めます。

回答は必ず二つに分けて依頼します。一つは共通要件に対する提案・見積もりです。もう一つは、候補独自の追加・代替提案です。後者には、追加・代替する内容、目的、費用・期間への影響、利点、留意点を記載してもらいます。これにより、提案の工夫を評価しつつ、共通条件の費用と混在させずに済みます。

商談では、未確定要件を誰がどの工程で整理するか、前提・除外項目、テスト・受入支援、連携・移行の責任分担、保守・終了時の移管条件を確認しましょう。公開事例が少ない候補でも、守秘義務に配慮した範囲で、課題類型、担当範囲、体制、品質管理、運用・移管の進め方を説明できるかは確認できます。

必須条件による一次選定

一次選定では、評価点をつける前に、満たせないと採択できない条件をPass／Failで確認します。例として、予算枠内で初回範囲を提案できるか、希望時期または段階リリースに対応できるか、必須連携・認証・対象プラットフォームに対応できるか、扱う情報に必要な確認体制を置けるか、契約・調達条件を満たせるかを確認します。

解消できないFail項目がある候補は、二次選定の高得点だけで採択しない運用にします。解消可能な条件かどうかを確認してください。

提案・体制・品質を比べる二次選定

二次選定では、案件特性に応じて重みを変えます。要件が曖昧な案件では要件整理力、固定期限がある案件では体制・品質、個人データを扱う案件では情報の取扱いに関する一次条件を重視するなど、重みを変えた理由も残します。合計点だけで決めず、低得点項目と未解決事項を最終判断に併記してください。

05Section発注側の体制と工程管理を先に決める

外注しても、発注側の意思決定、業務確認、受入テストは外部へ任せ切りにできません。開発開始後に担当者を探すのではなく、相談・選定の段階で役割と関与時期を決めます。

発注側に必要な役割と関与工程

レビュー・承認を工程計画へ組み込む

工程表には、開発会社の設計・実装予定だけでなく、発注側のレビュー依頼日、回答期限、承認者、代理者、期限を超えた場合の連絡先を記載します。必要な発注側の負荷は一律の工数ではなく、レビュー回数、承認経路、連携先数、移行対象、受入シナリオ数から見積もります。

質問への回答やレビューが遅れた場合は、単に「急ぐ」のではなく、どの工程に何日の影響があるかを更新し、範囲、日程、追加の確認体制のいずれを変えるかを決めます。口頭合意だけで進めず、判断内容と承認者を残すことが重要です。

固定期限がある場合の調整方法

期限を動かせない場合は、初回に必要な機能を絞り、後続化する機能を明確にします。その際も、受入テスト、連携・移行の確認、運用開始に必要な準備を削るのではなく、初回範囲で守るべき条件として残します。

後続化の判断では、対象機能、利用者・業務への影響、代替手段、次回判断日、承認者を記録してください。品質や受入条件を下げる判断が必要な場合は、業務影響と残存リスクを把握できる責任者が判断します。

06Section変更・連携・移行・情報管理のリスクを管理する

外注開発の失敗は、問題が発生したこと自体よりも、兆候がある段階で影響と判断者を整理できないことから大きくなりがちです。構想、選定、要件定義、開発、受入、リリース準備の定例で、リスクを更新しましょう。

変更は追加要望ではなく影響管理として扱う

変更が発生したら、目的、影響範囲、追加費用、期限への影響、品質への影響、対応しない場合の影響、承認者を記録します。口頭やチャットだけで依頼を受けると、範囲や責任分担が不明確になります。

影響を確認する前に実施を決めず、採用、後続化、不採用のいずれにするかを判断します。特に、初回リリースの必須範囲を変更する場合は、受入基準やテスト計画への影響もあわせて更新します。

連携・移行・回答遅延を早期に管理する

連携・移行は、テスト直前ではなく要件定義から確認します。連携先の責任者、データ項目、データ品質、件数、例外処理、照合方法、移行リハーサル、復旧方法、相手先との調整期限を明らかにします。

発注側の回答遅延も主要なリスクです。質問やレビュー依頼ごとに担当者、回答期限、代理者を割り当て、期限超過時はPJ窓口から業務責任者・最終承認者へ上げるルールを置きます。運用準備についても、監視、バックアップ、障害連絡、問い合わせ窓口、手順書、アカウント管理の担当と期限をリリース前に確認します。

個人データ・機密情報の確認範囲を整理する

個人データを扱う委託では、委託先に対する必要かつ適切な監督が求められます。個人情報保護委員会のガイドラインを参考に、委託範囲、再委託の有無、アクセス権、取扱状況の確認方法を、選定・契約・運用の各段階で整理してください。

07Section受入テスト・検収・運用移管を判断する

納品物を受け取る段階で初めて品質を考えるのでは遅すぎます。契約・要件を固める段階から、何を満たせば利用可能とするのか、誰が確認し、未解決事項を誰が判断するのかを決めます。

受入基準・受入テスト・検収の違い

開発会社によるテストは、実装が仕様どおりに動くかを確認するものです。一方、受入テストでは、実際の業務手順、利用者の権限、例外処理、連携・移行、対象環境で利用できるかを発注側が確認します。開発会社のテストと、発注側による受入テストは、どちらも必要です。

受入基準に入れる条件と証跡

受入基準には、業務シナリオ、正常系・異常系、権限、連携、移行、対象端末・ブラウザなどの利用環境、成果物、運用準備を含めます。各条件には、判定条件、テスト結果やログなどの証跡、確認者、未達時の扱いを置きます。

運用移管では、成果物の一覧・保管先、アカウントと権限、監視・バックアップ、障害時の連絡先、問い合わせ窓口、運用手順書、保守対象、改善要望の受け付け方を確認します。対象範囲、役割分担、成果物、変更、保守・移管の契約上の論点は、経済産業省のモデル取引・契約書を確認観点の整理に利用できます。個別条項の判断は、法務・調達部門または専門家に確認してください。

未解決不具合と運用移管の判断

未解決の不具合がある場合、件数だけで検収可否を決めません。不具合ごとに、重大度、業務影響、影響範囲、暫定回避策、修正期限、再テスト方法、残存リスク承認者を記録します。

契約形態によって確認の進め方や責任分担が変わるため、詳細はシステム開発の契約形態を参照してください。契約書、見積書、要件資料の対象範囲や検収条件が整合しているかは、システム開発契約のチェックポイントも参考に確認できます。

システム開発の外注先を探す

目的、初回必須範囲、連携・移行条件、希望時期を整理したうえで、外注に対応できる開発会社を比較できます。

Webアプリ・SaaS開発4593社掲載

開発会社を比較する