システム開発の発注を成功させる方法｜失敗率50%から学ぶ実践的な進め方
システム開発を外部に発注する企業は年々増加していますが、実は約50〜70%のプロジェクトが何らかの問題を抱えているという調査結果があります。
2024年の国内ITサービス市場は約7兆円超に達し、企業のDX推進に伴いシステム開発の需要は拡大の一途をたどっています。一方で、要件定義の不備、コミュニケーション不足、予算超過など、発注側と開発側の認識のズレが原因で失敗に終わるプロジェクトは後を絶ちません。
この記事では、初めてシステム開発を発注する担当者の方でも安心して進められるよう、発注の基本的な流れから、失敗を防ぐための具体的な対策、開発会社の選定ポイント、契約時の注意点まで、実践的なノウハウを網羅的に解説します。
システム開発発注の現状と市場規模
企業のDX推進が加速する中、システム開発を外部に発注する企業は増加傾向にあります。IDCジャパンの調査によると、2024年の国内ITサービス市場は前年比7.4%増の約7兆円規模に達しました。
この成長の背景には、既存システムのクラウド移行、老朽化したシステムの刷新、AI・データ活用への投資拡大など、企業のIT需要の多様化があります。特に受託開発はソフトウェア業務全体の約87%を占め、市場の中核を担っています。
しかし、市場拡大の一方で看過できない事実があります。それは、システム開発プロジェクトの失敗率の高さです。日経コンピュータの2018年度調査では、システム開発プロジェクトの失敗率は47.2%。さらに、大規模な基幹システムの刷新に至っては、失敗率が約70%に達するという調査結果も報告されています。
つまり、2件に1件は何らかの問題を抱えているのが現状です。このような状況を踏まえると、システム開発の発注を成功させるには、単に開発会社を選ぶだけでなく、プロジェクト全体を適切にマネジメントする視点が不可欠といえるでしょう。
システム開発発注が失敗する3つの主な原因
システム開発の失敗には、いくつかの共通したパターンがあります。ここでは、現場で頻繁に見られる代表的な失敗原因を3つ取り上げ、それぞれなぜ起こるのか、どのような影響をもたらすのかを深掘りしていきます。
原因1：要件定義の不十分さ
システム開発における最大の失敗要因は「要件定義の不備」です。要件定義とは、「どのようなシステムを作るか」を明確に定める工程であり、プロジェクト全体の設計図となる重要なフェーズです。
要件定義が曖昧なまま開発に進むと、以下のような問題が連鎖的に発生します。
開発の途中で「やはりこの機能も必要だった」と気づき、仕様変更が頻発する
完成したシステムが発注者の期待と異なり、使えないシステムになってしまう
手戻りが発生し、当初の予算や納期を大幅にオーバーする
要件定義が不十分になる背景には、発注側が「何をどこまで決めればよいか分からない」という知識不足や、開発会社が「発注者の業務内容を深く理解しないまま」要件を固めてしまうケースがあります。
実際の現場では、発注者が「業務管理システム」と一言で伝えても、その中身は千差万別です。在庫管理なのか、顧客管理なのか、売上分析なのか。発注側と開発側で思い描くイメージが異なれば、認識のズレは避けられません。このズレが後工程で発覚すると、プロジェクトは大きく軌道を外れ、最悪の場合はプロジェクト自体が頓挫することもあります。
原因2：発注側と開発側のコミュニケーション不足
要件定義の不備と密接に関わっているのが、コミュニケーション不足です。発注側と開発側では、持っている知識や視点が根本的に異なります。
発注側は業務のプロですが、技術的な知識は限られています。一方、開発側は技術のプロですが、発注者の業務フローやビジネス上の課題を完全には理解していません。この「共通言語の欠如」が、認識のズレを生む大きな要因となります。
たとえば、発注側が「リアルタイムで反映してほしい」と伝えたとします。しかし、「リアルタイム」という言葉の解釈は人によって異なります。数秒なのか、数分なのか、1時間以内なのか。開発側が「1時間以内」と解釈して実装しても、発注側が「数秒」を想定していれば、納品後に「これは使い物にならない」という事態が起こり得ます。
また、進捗報告会で「順調に進んでいます」と報告を受けても、実際には重大な問題が水面下で進行していることもあります。発注側が必要な情報を適切に提供せず、開発側も曖昧な部分を明確にしないまま進めてしまうと、プロジェクトは徐々に迷走していきます。
原因3：発注側の知識・準備不足
システム開発の成功は、開発会社の技術力だけでは決まりません。発注側の準備と関与の度合いが、プロジェクトの成否を大きく左右します。
多くの企業では、システム開発を「外注すれば丸投げできる」と考えがちです。しかし、オーダーメイドのシステム開発では、発注側の協力が不可欠です。裁判例（東京地裁平成16年3月10日判決）でも、発注者には「システム開発への協力義務」があると明示されています。
具体的には、以下のような協力が求められます。
社内の意見を調整し、統一した見解を開発会社に伝える
どのような機能が必要かを明確に伝える
成果物の検収作業を適切に行う
必要な資料や情報を適時に提供する
発注側が「わからないから専門家に任せる」という姿勢では、開発側も正確な提案ができません。結果として、完成したシステムが使えないものになったり、当初の想定とまったく異なるものになったりするリスクが高まります。
システム開発発注の基本的な流れ
システム開発の発注は、大きく「発注前」「発注後」「納品後」の3つのフェーズに分かれます。ここでは、各フェーズで何をすべきか、どのようなポイントに注意すべきかを、時系列で詳しく解説します。
発注前の準備フェーズ
発注前の準備は、プロジェクトの成否を決める最も重要な段階です。ここでの準備が不十分だと、後工程でいくら頑張っても取り返しがつきません。
1. 課題と目的の整理
まず最初に行うべきは、「なぜシステムが必要なのか」「どんな課題を解決したいのか」を明確にすることです。単に「業務を効率化したい」という漠然とした目標ではなく、「月末の集計作業に3日かかっているが、これを1日に短縮したい」といった具体的な目標を設定します。
現場の担当者にヒアリングを行い、実際の業務フローや課題を洗い出しましょう。この段階で関係部署を巻き込み、合意形成を図っておくことが重要です。後から「こんなシステムは使えない」と言われないよう、主要なステークホルダーの意見を反映させておきます。
2. 予算と納期の目安を設定
システム開発の費用相場は、規模や機能によって大きく異なりますが、一般的には500万円からが目安となります。小規模なWebアプリケーションであれば100万円〜300万円、中規模の業務システムなら500万円〜2,000万円、大規模な基幹システムになると数千万円〜数億円規模になることもあります。
納期については、開発規模や機能の複雑さによって変わります。小規模なシステムで3〜6ヶ月、中規模で6ヶ月〜1年、大規模になると1年以上かかるケースもあります。余裕を持ったスケジュールを設定し、社内承認プロセスや準備期間も考慮に入れましょう。
発注成功の鍵：RFP（提案依頼書）の作成
システム開発の発注で最も重要な文書が、RFP（Request for Proposal：提案依頼書）です。RFPとは、発注側が開発会社に対して自社の課題や要望を明確に伝え、具体的な提案を依頼するための文書です。
RFPとは何か、なぜ必要なのか
従来、システム開発の発注は口頭での説明や簡単な資料で行われることが一般的でした。しかし、この方法では情報の伝達漏れや理解の違いが生じやすく、開発段階や稼働段階でトラブルが頻発していました。
RFPを作成することで、以下のようなメリットが得られます。
発注側と開発側の認識のズレを最小限に抑えられる
複数の開発会社から同じ条件で提案を受けられ、公平に比較できる
要件を整理する過程で、自社の課題や目的がより明確になる
後から「言った・言わない」のトラブルを防げる
NTTデータが提供する「RFP診断」の分析結果によると、RFPの記述が充実しているほど、計画規模と実績規模の乖離が小さくなる傾向が確認されています。つまり、質の高いRFPは予算オーバーや納期遅延のリスクを減らす効果があるのです。
RFPに記載すべき主な項目
RFPは、大きく「概要」「提案依頼内容」「選考の進め方」の3つのパートで構成されます。
【概要パート】
RFPの目的と位置づけ：何のための提案依頼書なのかを明記
背景：なぜこのプロジェクトが必要になったのか、経営的背景を説明
現状の課題：解決したい具体的な課題を箇条書きで明記
プロジェクトの目的：品質（Quality）、費用（Cost）、納期（Delivery）の観点でゴールを設定
現行システムの構成：既存システムがある場合は、その構成図やパッケージ名、データ連携方法を記載
組織図：システムの利用部署や権限管理が必要な場合に記載
【提案依頼内容パート】
プロジェクトの範囲：システム開発のみか、IT機器の設置・設定まで含めるのかを明確化
機能要件：システムに実装してほしい機能を具体的に記載
非機能要件：性能、セキュリティ、可用性、保守性などの要求仕様
スケジュール：発注先決定から導入までの想定スケジュールを週・月単位で明示
予算：具体的な金額は記載せず、「初期費用」「月額費用」などの項目を設ける程度にとどめる
成果物：最終的に納品してほしい成果物を明記
【選考の進め方パート】
選考スケジュール：RFP配布から提案期限、選定結果通知までのスケジュール（通常、提案期限まで2週間程度）
提出方法：誰に、いつ、どのような方法で提案書を提出するか
評価基準：選定時に重視するポイント（価格、技術力、実績、サポート体制など）
RFP作成時の重要ポイント
RFPを作成する際は、以下の点に特に注意しましょう。
1. 誰が読んでも同じ解釈になるように書く
「できるだけ速く」「なるべく使いやすく」といった曖昧な表現は避け、「3秒以内に画面が表示される」「5つ以内の操作で目的の機能にアクセスできる」など、客観的な数値や指標を用いて具体的に記載します。
また、社内用語や業界特有の略語は、開発会社には通じないことがあります。初めて読む人でも理解できるよう、必要に応じて用語集を付けるなどの配慮が必要です。
2. 現場へのヒアリングを徹底する
システムを実際に使う現場の担当者にヒアリングを行い、本当に必要な機能を洗い出します。管理者層と現場担当者では見えている課題が異なることが多いため、複数の立場の人から意見を集めることが重要です。
3. 予算は具体的に書きすぎない
RFPに「予算1,000万円以内」と明記すると、もっと安くできる提案でも、その予算に合わせて提案される可能性があります。むしろ予算枠は書かず、各社から自由に提案を受けて比較する方が、コストパフォーマンスの良い提案を引き出せることがあります。
開発会社の選び方｜失敗しない5つの評価ポイント
複数の開発会社から提案を受けた後は、どの会社に発注するかを選定します。価格だけで決めてしまうと後悔することが多いため、以下の5つの観点から総合的に評価しましょう。
1. 自社の業界・業種に関する実績と専門性
開発会社によって得意分野は異なります。Webアプリケーション開発が得意な会社、業務システムの構築に強い会社、AI・データ分析に特化した会社など、それぞれに強みがあります。
自社と同じ業界や類似の業務システムを手がけた実績があるかを確認しましょう。業界特有の商習慣や法規制を理解している会社であれば、要件定義の段階から的確な提案を受けられます。
具体的には、過去の開発事例、導入企業名（公開可能な範囲で）、プロジェクト規模、使用技術などを確認します。単に「実績があります」と言われるだけでなく、具体的な成果物や効果を示してもらいましょう。
2. コミュニケーションの取りやすさ
システム開発は数ヶ月〜1年以上にわたる長期プロジェクトです。その間、開発会社と頻繁にやり取りをすることになるため、コミュニケーションが円滑に取れるかは非常に重要です。
提案段階でのやり取りで、以下の点をチェックしましょう。
質問に対して迅速かつ的確に回答してくれるか
専門用語を使わず、わかりやすく説明してくれるか
こちらの意図を正しく理解しようと努めているか
問題点やリスクを隠さず、率直に伝えてくれるか
また、担当者との相性も重要です。プロジェクトマネージャーとなる人物と実際に会話し、信頼関係が築けそうか、長期的に協力し合えそうかを見極めましょう。
3. 開発体制とリソース
プロジェクトに必要な人員を確保できているか、技術力のあるエンジニアがアサインされるかを確認します。
特に以下の点を確認しましょう。
プロジェクトマネージャーの経験年数と実績
開発メンバーのスキルレベル（使用する技術への習熟度）
下請け・孫請けへの外注比率（多重下請け構造はリスクが高い）
オフショア開発を含む場合、品質管理体制がしっかりしているか
また、希望する納期に対して十分な人員を確保できるかも重要です。人手不足でスケジュールが遅延するケースは珍しくありません。
4. 価格と見積もりの妥当性
見積もりを比較する際は、金額だけでなく内訳を詳しく確認することが重要です。「一式」でまとめられた見積もりは、後から追加費用が発生しやすいため注意が必要です。
見積もりには通常、以下の項目が含まれます。
要件定義費：プロジェクトの土台作りにかかる費用
設計費（基本設計・詳細設計）：システムの設計図作成費用
開発費（製造費）：プログラミングにかかる費用（人月単価×工数で算出）
テスト費：品質担保のための検証費用
プロジェクト管理費：進行管理にかかる費用
保守・運用費：納品後のランニングコスト
極端に安い見積もりには注意が必要です。品質の低いエンジニアがアサインされたり、必要な工程が省略されたりする可能性があります。逆に高すぎる見積もりも、工数が過大に見積もられていないか確認しましょう。
複数社の見積もりを比較し、業界相場を把握することが大切です。一般的な人月単価は、ジュニアエンジニアで50〜80万円、シニアエンジニアで100〜150万円程度が目安となります。
5. アフターサポートと保守体制
システムは納品して終わりではありません。運用開始後の保守・サポート体制も重要な選定ポイントです。
以下の点を確認しましょう。
無償保証期間の有無と期間（通常1〜3ヶ月程度）
保守契約の内容と費用（月額費用、対応範囲、対応時間）
障害発生時の対応体制（24時間365日対応か、営業時間内のみか）
機能追加や仕様変更への対応可否
特に基幹システムなど、業務に直結するシステムでは、トラブル時の迅速な対応が不可欠です。サポート体制が手薄な会社は避けるべきでしょう。
契約時の重要な注意点
開発会社を選定したら、次は契約の締結です。システム開発の契約には、主に「請負契約」と「準委任契約」の2種類があり、それぞれ責任範囲が異なります。
請負契約と準委任契約の違い
【請負契約】
請負契約は、「成果物の完成」が契約の目的です。開発会社は、合意した仕様通りのシステムを完成させる義務を負います。
メリット：
成果物が完成しなければ報酬を支払う必要がない
費用が事前に確定するため、予算管理がしやすい
デメリット：
仕様変更があると追加費用が発生しやすい
要件定義が不十分だと、開発会社との責任の押し付け合いになることがある
【準委任契約】
準委任契約は、「一定期間の労働力の提供」が契約の目的です。開発会社は、合意した期間・人数で業務を遂行する義務を負いますが、成果物の完成義務はありません。
メリット：
仕様変更に柔軟に対応できる
アジャイル開発など、段階的に要件を固めていく開発手法に適している
デメリット：
成果物が完成する保証がない
最終的な費用が予測しづらい
一般的には、要件が明確に決まっている場合は請負契約、要件を柔軟に変更しながら進めたい場合は準委任契約が向いています。
契約書で必ず確認すべき項目
契約書は専門的な内容が多く難しく感じるかもしれませんが、以下の項目は必ず確認しましょう。
1. 業務範囲（スコープ）
どこまでが開発会社の責任範囲かを明確にします。システム開発だけなのか、テストやデータ移行、運用マニュアルの作成まで含むのか。曖昧だと「それは契約範囲外です」と言われかねません。
2. 成果物と納期
何を、いつまでに納品するのかを具体的に記載します。「要件定義書」「設計書」「ソースコード」「テスト結果報告書」「運用マニュアル」など、納品物をリストアップし、それぞれの納期を設定します。
3. 費用と支払条件
総額だけでなく、支払タイミングも重要です。一般的には、契約時に着手金（総額の30〜50%）、中間納品時に中間金（30〜40%）、最終納品・検収後に残金（20〜30%）という分割払いが多く見られます。
また、仕様変更が発生した場合の追加費用の算定方法も明記しておきましょう。
4. 著作権・知的財産権
開発したシステムの著作権やソースコードの所有権がどちらに帰属するかは、契約形態によって異なります。発注側に譲渡されるのか、開発会社に留保されるのかを確認しましょう。
権利が開発会社側に残る場合、将来的に他社へシステムを転用されたり、保守費用が高額になったりするリスクがあります。
5. 瑕疵担保責任（契約不適合責任）
2020年の民法改正により、従来の「瑕疵担保責任」は「契約不適合責任」に変更されました。これにより、納品後に不具合が見つかった場合の開発会社の責任範囲が拡大しています。
無償修正の期間（通常1〜3ヶ月）や、修正できない場合の損害賠償の上限額などを明記しておきましょう。
6. 機密保持・再委託
開発の過程で発注側の機密情報が開発会社に渡ります。秘密保持契約（NDA）の内容や、情報管理体制を確認しましょう。
また、開発会社が下請けに再委託する場合の条件も重要です。発注側の承諾なしに再委託できるのか、再委託先の選定基準はあるのかを確認します。
発注後のプロジェクト管理で成功を確実にする
契約を締結し、開発がスタートしたら終わりではありません。むしろ、ここからが本当の勝負です。発注側がプロジェクトに適切に関与し、進捗を管理することで、失敗のリスクを大幅に減らせます。
定期的な進捗確認とコミュニケーション
開発会社との定期的なミーティングを設定しましょう。週次または隔週で進捗報告会を開き、以下の点を確認します。
当初のスケジュールに対する進捗状況
発生している問題や課題
次週までの作業予定
発注側が対応すべき事項
ここで重要なのは、開発会社から「順調です」という報告を鵜呑みにせず、具体的な成果物やデモを見せてもらうことです。実際に動くものを確認することで、認識のズレを早期に発見できます。
要件変更への適切な対処
開発の途中で「やはりこの機能も必要だ」と気づくことは珍しくありません。しかし、無計画な仕様変更はプロジェクトを破綻させる最大の要因です。
変更が必要な場合は、以下のプロセスを踏みましょう。
変更の必要性と優先度を検討する（本当に必要か、後回しにできないか）
開発会社に影響範囲を見積もってもらう（工数、費用、納期への影響）
社内で承認を得る（追加費用や納期延長が発生する場合）
変更内容を文書化し、開発会社と合意する
特に下流工程（プログラミングやテスト段階）での変更は、上流工程に立ち戻る必要があるため、コストと時間が膨大になります。できるだけ早い段階で気づき、対処することが重要です。
受入テストと検収の重要性
開発会社からシステムが納品されたら、発注側で必ず受入テストを実施します。開発会社が行ったテストだけでは不十分です。
受入テストでは、実際の業務フローに沿って、以下の点を確認します。
要件定義で決めた機能がすべて実装されているか
操作性や使い勝手に問題はないか
データの整合性は保たれているか
エラー処理は適切に行われるか
パフォーマンスは十分か（レスポンス時間など）
問題が見つかった場合は、すぐに検収せず、修正を依頼します。一度検収してしまうと、後から不具合を指摘しても無償で対応してもらえないことがあります。
検収時には、チェックリストを作成し、漏れなく確認することをお勧めします。可能であれば、現場の担当者にも実際に使ってもらい、フィードバックを集めましょう。
システム開発発注に関するよくある質問
Q1. システム開発を発注する際、社内にIT担当者がいない場合はどうすればよいですか？
A1. 外部のITコンサルタントやプロジェクトマネージャーを雇うことを検討しましょう。発注側の立場で要件定義のサポートや、開発会社との調整、進捗管理などを代行してくれます。費用はかかりますが、失敗のリスクを大幅に減らせます。
Q2. 見積もりは何社から取るのが適切ですか？
A2. 一般的には3〜5社程度が適切です。1社だけでは比較ができず、相場感もつかめません。逆に多すぎると、RFPの作成や提案の評価に時間がかかりすぎます。
Q3. 開発の途中で仕様変更はできますか？
A3. 可能ですが、変更の規模やタイミングによっては、追加費用や納期の延長が必要になります。特に下流工程（プログラミングやテスト段階）での大幅な変更は、コストと時間が膨大になるため、できるだけ避けるべきです。
Q4. 納品されたシステムの著作権はどうなりますか？
A4. 契約形態によって異なります。一般的な請負契約では、著作権は開発会社に留保されることが多く、発注側は「利用権」を得る形になります。著作権を譲渡してもらいたい場合は、契約書に明記し、その分の費用を見込む必要があります。
Q5. 保守・運用費用はどのくらいかかりますか？
A5. システムの規模や内容によって異なりますが、一般的には初期開発費用の10〜20%程度が年間の保守費用として発生します。月額に換算すると、数万円〜数十万円が目安となります。
まとめ：システム開発の発注を成功させるために
システム開発の発注は、決して簡単なプロセスではありません。しかし、適切な準備と進め方を実践すれば、失敗のリスクは大幅に減らせます。
この記事で解説したポイントをまとめると、以下のようになります。
システム開発の失敗率は約50〜70%と高いが、主な原因は「要件定義の不備」「コミュニケーション不足」「発注側の準備不足」の3つ
発注前の準備として、課題と目的を明確にし、RFP（提案依頼書）を作成することが成功の鍵
開発会社の選定は、価格だけでなく、実績、コミュニケーション、体制、サポートを総合的に評価する
契約時は、業務範囲、費用、著作権、瑕疵担保責任などを明確にする
発注後も定期的な進捗確認を行い、受入テストでは妥協せず徹底的にチェックする
システム開発は、開発会社に丸投げするのではなく、発注側も主体的に関わることが不可欠です。専門知識がなくても、この記事で紹介したポイントを押さえれば、プロジェクトを成功に導くことができるでしょう。
最後に、失敗を恐れすぎないことも大切です。多くの企業が試行錯誤を経て、自社に最適なシステムを構築しています。この記事が、あなたのシステム開発プロジェクトの成功の一助となれば幸いです。
