システム開発の発注ガイド｜初めてでも迷わないRFPから検収までの全手順

システム開発の発注は、進め方を誤ると予算超過や品質トラブルに直結します。

本記事では、初めての担当者でも迷わないよう、発注前の準備からRFP作成・発注先選定・契約・進捗管理・検収までの全手順を、各工程で「発注者が何をすべきか」に絞って解説します。

システム開発を発注するのはどんなケースか

システム開発を外部に発注すべきなのは、自社だけでは「人材・技術・スピード」のいずれかが不足するケースです。
まずは自社が発注に向いた状況かを整理しましょう。
代表的な3つのケースを解説します。

社内にIT人材が不足している場合

最も多いのが、社内に開発を担えるIT人材がいないケースです。

日本のIT人材不足は今後さらに深刻化すると見込まれており、2030年には最大で約79万人が不足すると予測されています。

自社採用での内製化が難しい場合、開発会社への発注が現実的な選択肢になります。

引用元：経済産業省「IT人材需給に関する調査」　https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf

高度な専門技術が必要な場合

AI・データ基盤・クラウド・モバイルアプリなど、高度な専門技術が必要な開発も発注に向きます。

これらは技術の進化が速く、専門エンジニアを自社で抱え続けるのは負担が大きいためです。

特定領域に実績のある開発会社に任せることで、品質とスピードを両立できます。

老朽化システムの刷新やDX推進を進めたい場合

長年使ってきたシステムの刷新や、DX推進のための新規開発も発注の典型例です。

既存システムは仕様がブラックボックス化していることが多く、刷新には高い技術力と経験が求められます。

外部の知見を取り入れることで、現状の課題を客観的に整理しながら進められます。

発注前の準備｜要件整理と社内合意形成

発注で最も重要なのが、この「発注前の準備」です。
なぜなら、システム開発の成否は準備段階でほぼ決まるからです。

日経コンピュータの調査では、3年を超える大規模プロジェクトの成功率はわずか16%にとどまり、失敗理由の筆頭は「要件定義が不十分」でした。

準備不足のまま発注すると、認識のズレや手戻りでコストと期間が膨らみます。

引用元：日経クロステック「システム開発プロジェクトの5割が失敗、1700件を独自分析」　https://xtech.nikkei.com/atcl/nxt/column/18/00177/022100001/

成功率はわずか16%、失敗の最大要因は「要件定義の不十分さ」！準備にこそ時間をかけましょう！

開発目的と解決すべき課題を明確にする

最初に決めるべきは、「何のために開発するのか」という目的です。

目的が定まると、必要な機能・規模・予算の方向性が自然と決まるためです。

「業務効率化」「顧客管理の一元化」「新サービスの提供」など、目的によって作るべきものは大きく変わります。

目的が曖昧なまま発注すると、開発会社も的確な提案ができず、完成後に「思っていたものと違う」というズレが生じます。

必要な機能を洗い出してリスト化する

目的が決まったら、必要な機能を洗い出してリスト化します。

このとき、機能を「必須機能」と「あれば望ましい機能」の2段階に分けるのがポイントです。

すべてを必須にするとコストも期間も膨らむため、優先順位をつけて整理します。

まず必須機能で小さく始め、段階的に拡張する設計にしておくと、コストとリスクを抑えられます。

予算と納期の目安を設定する

発注前に、おおよその予算と希望納期を決めておきます。

予算と納期の目安がないと、開発会社も適切な提案ができないためです。

予算は初期の開発費だけでなく、リリース後の保守・運用費まで含めた総額で考えます。

納期は「いつまでに稼働させる必要があるか」から逆算し、想定どおり進まないケースを見込んで余裕を持たせます。

RFP（提案依頼書）の作成方法と含めるべき項目

発注先に提案を依頼する際は、RFP（提案依頼書）を作成します。

RFPがあると複数社に同じ条件で依頼でき、提案や見積もりを正確に比較できるためです。

口頭の相談だけで進めると各社の提案がバラバラになり、比較検討が難しくなります。

RFPに記載すべき8つの項目

RFPに盛り込むべき主な項目は、次の8つです。
まず全体像を一覧で示します。

1. 開発の背景と目的
2. 現状の課題
3. 必要な機能の概要（スコープ）
4. 非機能要件（性能・セキュリティなど）
5. 希望納期・スケジュール
6. 予算の上限
7. 技術的な制約や希望（使用言語・クラウド環境など）
8. 提案・契約に関する条件

これらを過不足なく記載することで、開発会社は前提を正しく理解し、精度の高い提案を返せます。

予算は幅を広げすぎると提案の精度が下がるため、上限をできるだけ具体的に示すのがポイントです。

RFPの品質が提案の質を決める

結論として、RFPの品質がそのまま提案の質を左右します。

発注者が要件を整理できているほど、開発会社は的確な提案と見積もりを出せるためです。

逆に、要件が曖昧なRFPでは、各社が異なる前提で見積もるため比較ができず、後の追加費用の原因にもなります。

RFP作成に不慣れな場合は、開発会社にテンプレートを提供してもらうか、無料相談を活用して一緒に整理するのが効率的です。

発注先の選定｜提案評価と見積もり比較のポイント

発注先は、金額の安さだけでなく「実績・提案力・見積もりの中身」を総合的に評価して選びます。
価格だけで選ぶと、品質や進行管理で失敗しやすいためです。
複数社を比較し、自社の要件に最も合う会社を見極めます。

開発実績・得意分野の確認方法

まず確認すべきは、自社の作りたいシステムと近い実績・得意分野があるかです。

開発会社にはそれぞれ得意なジャンルや技術があるためです。

たとえば業務システムを作りたいなら、同種の開発実績が豊富な会社を選びます。

公開されている事例だけでなく、商談時に類似案件の課題と解決方法を具体的に質問すると、実力をより正確に把握できます。

見積もり比較で金額以外に見るべき5つの軸

見積もりは、金額だけでなく次の5つの軸で比較します。

1. 工数・作業範囲の内訳（どこまで含まれるか）
2. 開発体制（担当者の役割・人数）
3. スケジュールの妥当性
4. 保守・運用サポートの範囲
5. 追加費用が発生する条件

システム開発の費用は「人月単価×工数」で算出されるのが一般的です。

人月単価の目安は、プログラマーで約60万〜70万円、システムエンジニアで約80万〜130万円、プロジェクトマネージャーで約70万〜130万円です。

同じ機能でも体制や工数の前提が違えば金額は変わるため、内訳まで踏み込んで比較することが重要です。

プレゼンテーション評価と詳細デモの確認

最終候補が絞れたら、プレゼンテーションや詳細デモで提案内容を確認します。

資料だけでは分からない、提案の具体性や担当者との相性を見極めるためです。

このとき、要望をそのまま受けるだけでなく「なぜそうすべきか」を提案してくれる会社は、信頼できるパートナーになりやすい傾向があります。

レスポンスの速さや説明の分かりやすさも、実際の開発時のコミュニケーション品質を反映します。

契約締結時の注意点｜法的リスクを最小化する

契約は、後のトラブルを防ぐための重要なステップです。
契約内容が曖昧だと、費用・権利・責任の所在をめぐって紛争になりやすいためです。
特に「契約形態」「著作権」「下請法（取適法）」の3点は必ず確認します。

請負と準委任で発注者のリスクが変わる

契約形態には「請負契約」と「準委任契約」があり、発注者のリスクが変わります。

請負契約は成果物の完成を約束する契約で、費用が確定しやすく予算管理がしやすい一方、契約後の仕様変更が難しい点に注意します。

準委任契約は業務の遂行に対して報酬を支払う契約で、仕様変更に柔軟な一方、成果物の完成は保証されません。

仕様が固まっているなら請負、変更が想定されるなら準委任、というように開発の性質で使い分けます。

著作権の帰属と再委託の条件を明確にする

完成したシステムの著作権の帰属は、契約書で必ず明確にします。

何も定めないと、著作権は制作した開発会社に帰属するのが原則だからです。

自社で将来改修・再利用したい場合は、契約書に「著作権の譲渡」を明記する必要があります。

あわせて、開発会社が業務の一部を別の会社に再委託する場合の条件（範囲・責任の所在）も確認しておくと、品質や情報管理のリスクを抑えられます。

下請法改正による発注者の義務を把握する

発注者は、2026年1月1日に施行された改正法（取適法）への対応も必要です。

これは従来の「下請法」が改正され、名称も「中小受託取引適正化法（取適法）」に変わったものです。

システム開発の発注は「情報成果物作成委託」に該当し、一定の取引では発注者（委託事業者）に次の義務・禁止が課されます。

• 発注内容を明示した書面（電子メール等の電磁的方法も可）を交付する
• 受領後60日以内に代金を支払う（手形払いは禁止）
• 受領拒否や、一方的な代金の決定をしない（価格協議に応じる）

違反した場合は、公正取引委員会からの勧告・指導や罰則の対象となることがあります。

適正な取引は、開発会社との良好な関係を保つうえでも重要です。

引用元：公正取引委員会「中小受託取引適正化法（取適法）」　https://www.jftc.go.jp/partnership_package/toritekihou.html

2026年1月から下請法は「取適法」へ！ 発注書面の交付・60日以内の支払いなど、発注者側の義務を必ず確認しましょう！

発注後の進め方｜要件定義への関わり方と進捗管理

発注後も、発注者の主体的な関与が品質を左右します。
開発会社に任せきりにすると、完成後に「使えないシステム」になるリスクが高まるためです。
要件定義・進捗管理・仕様変更の3点で、発注者が果たすべき役割を押さえます。

要件定義は発注者が主体で進める

要件定義は、開発会社任せにせず発注者が主体で進めます。

自社の業務やユーザーのことは、発注者が最もよく理解しているためです。

ここでの認識のズレは後工程で大きな手戻りになるため、内容に不明点があればその場で確認することを習慣にします。

定期的な進捗確認で問題を早期発見する

開発中は、定例ミーティングなどで定期的に進捗を確認します。

問題は、後になるほど修正コストが大きくなるためです。

週次や隔週で進捗・課題・次のアクションを共有し、認識のズレを早期に解消します。

発注者側の確認や返答が遅れると開発全体が遅延するため、フィードバックは迅速に行います。

仕様変更は慎重に合意プロセスを踏む

開発途中の仕様変更は、ルールを決めて慎重に進めます。

仕様変更は追加費用や納期遅延に直結するためです。

変更を依頼する手順、追加費用と納期への影響の確認方法、変更の優先度（必須か、リリース後に回せるか）をあらかじめ取り決めておきます。

変更そのものは悪いことではありませんが、無計画な変更はプロジェクトを混乱させます。

検収・納品の進め方｜受入テストで品質を確認する

納品時は、受入テスト（検収）で品質を必ず確認します。
検収を通すと、原則として成果物を受け入れたとみなされるためです。
ここで問題を見逃すと、後の改修が自社負担になるリスクがあります。

受入テストの計画と実施方法

受入テストは、発注前に計画し、納品時に実施します。

要件定義で定めた機能が満たされているか、実際の業務シナリオに沿って確認するのが効果的です。

不具合や仕様の過不足が見つかった場合は、修正の範囲と期限を開発会社と合意してから検収を完了します。

検収後の保守・運用体制の構築

検収後は、リリース後の保守・運用体制を整えます。

システムは公開後も、不具合対応・OSアップデート・機能追加などの継続的な運用が必要だからです。

保守の範囲・費用・対応窓口を契約時に確認しておくと、トラブル時にスムーズに対応できます。

将来的に自社で運用・改善できるよう、ドキュメントの整備や内製化支援まで見据えると、長期的な負担を減らせます。

発注時によくある失敗パターンとその回避策

最後に、発注でよくある失敗パターンと回避策を押さえておきます。
失敗の多くは、発注者側の準備と確認で防げるものです。
代表的な2つを解説します。

要件が曖昧なまま発注してしまう

最も多い失敗が、要件が曖昧なまま発注してしまうケースです。

前述のとおり、失敗プロジェクトの筆頭原因は「要件定義の不十分さ」です。

回避策は、発注前に目的と機能を整理し、RFPに落とし込んでから依頼することです。

社内の関係者全員で要望を洗い出し、優先順位を合意しておくことで、開発途中の要件追加を防げます。

最安値の会社を選んで品質トラブルに発展する

費用を抑えたいあまり、最安値の会社を選んで失敗するケースも多く見られます。

安い見積もりには、工数の過少見積もりやテスト工程の省略、経験の浅い体制といった理由が隠れていることがあるためです。

回避策は、金額だけでなく開発体制・品質保証のプロセス・実績を総合的に評価することです。

見積もりは複数社（目安として2〜3社）から取り、内訳まで比較したうえで判断します。

まとめ｜発注の成否は「準備」で8割決まる

システム開発の発注は、発注前の準備と発注者の主体的な関与で成否の大半が決まります。
本記事の要点を整理します。

• 発注が向くのは、人材・専門技術・スピードが社内で不足するケース
• 成功の鍵は準備。目的・機能・予算を整理し、RFPに落とし込む
• 発注先は金額だけでなく、実績・提案力・見積もりの内訳で選ぶ
• 契約は請負／準委任の使い分け、著作権、取適法（2026年1月施行）を確認する
• 発注後も要件定義・進捗管理に主体的に関わり、検収で品質を確認する

発注チェックリスト

発注前から納品後までのチェックリストです。

【発注前】

• 開発目的と課題を明確にした
• 必須機能と優先順位を整理した
• 予算と納期の目安を決めた
• RFPを作成した

【選定時】

• 複数社から見積もりを取った
• 実績と得意分野を確認した
• 見積もりの内訳を比較した

【契約時】

• 契約形態・著作権・再委託の条件を確認した
• 取適法上の義務（発注書面・支払期日など）を確認した

【発注後】

• 要件定義に主体的に関与した
• 定例で進捗を確認した
• 受入テストと保守体制を整えた

自社にとって最適な発注先や進め方に迷う場合は、要件定義の段階から相談できる開発会社に早めに声をかけてみてください。
要件整理から伴走できる会社に相談すれば、準備の精度を高めながら、失敗しない発注を進められます。