システム開発の発注手順チェックリスト｜見積もり依頼から納品までの全工程

IPA「ソフトウェア開発分析データ集2024」によると、プロジェクト失敗の原因の上位3つは「要件の不備」「コミュニケーション不足」「進捗管理の甘さ」だ。これらはいずれも、発注プロセスの各段階で適切なチェックを行うことで防げる問題である。

本記事では、システム開発の発注手順を6フェーズ・60項目超のチェックリスト形式で整理した。「見積もりを依頼する前に何を準備すべきか」「契約時に何を確認すべきか」「納品時に何をチェックすべきか」を、工程ごとに漏れなく確認できるガイドだ。

発注準備フェーズのチェックリスト
見積もり・提案フェーズのチェックリスト
契約フェーズのチェックリスト
開発フェーズのチェックリスト
納品・検収フェーズのチェックリスト
保守・運用フェーズのチェックリスト
レッドフラグ一覧
まとめ
FAQ

1. 発注準備フェーズのチェックリスト

発注準備は、プロジェクト成功の土台を作る最も重要なフェーズだ。ここでの準備が不十分だと、後工程すべてに影響する。

課題・目的の整理（目安：1〜2週間）

現在の業務課題を具体的に書き出した（「誰が」「何をする時に」「どう困っている」の形式）
システム化の目的を定量的に定義した（例：処理時間を50%削減、ミスを月10件→0件にする）
現在の業務フローを図で整理した（As-Is）
理想の業務フロー案を作成した（To-Be）
関係部署へのヒアリングを実施した

予算・体制の確保（目安：1〜4週間）

開発費の予算枠を確保した（経営層の承認済み）
保守・運用費用（開発費の15〜20%/年）も含めた予算を確保した
社内のプロジェクト責任者（意思決定者）を決定した
社内のプロジェクト窓口担当者を決定した
担当者のプロジェクト対応時間を確保した（週5〜10時間）
補助金の活用可能性を確認した

補助金の最新情報は補助金完全ガイド2026で確認できる。また、デジタル化・AI補助金ガイドも参照されたい。

RFP（提案依頼書）の作成（目安：1〜2週間）

プロジェクトの背景・目的を記載した
実現したい機能の一覧を優先順位付きで記載した
現在の業務フロー（As-Is）を添付した
既存システムの情報（連携が必要なシステム、使用中のサービス）を記載した
予算の上限を記載した
希望スケジュールを記載した
非機能要件（同時アクセス数、レスポンス速度、セキュリティ等）を記載した
納品物の一覧（ソースコード、設計書、運用マニュアル等）を記載した

RFP作成の詳細はIT開発会社の選定基準とRFPガイドを参照。

セクションまとめ：発注準備フェーズでは「課題の具体化」「予算と体制の確保」「RFPの作成」の3つが必須。特にRFPの完成度が、後の見積もり・提案の質を左右する。

2. 見積もり・提案フェーズのチェックリスト

見積もり依頼（目安：1〜2週間）

3社以上の開発会社にRFPを送付した
各社にQ&Aの期間（1〜2週間）を設定した
提案書・見積もりの提出期限を設定した
各社の質問に漏れなく回答した
NDA（秘密保持契約）を事前に締結した（必要に応じて）

提案内容の評価

各社の提案書を同じ評価基準で比較した
提案内容がRFPの要件を網羅しているか確認した
開発手法（ウォーターフォール/アジャイル）の提案理由を確認した
使用する技術（言語、フレームワーク、インフラ）の適切性を確認した
チーム体制（PM、SE、PG等の人数と役割）を確認した
同業種・同規模の開発実績があるか確認した
プレゼンテーション（提案説明会）を実施した

見積もりの評価

工程別（要件定義/設計/開発/テスト/PM）の内訳が記載されているか確認した
「一式」表記の項目がないか確認した（ある場合は内訳を依頼）
テスト工数が全体の15〜20%程度確保されているか確認した
PM費用が全体の10〜15%程度か確認した
保守・運用費用が含まれているか、別途見積もりか確認した
追加費用が発生する条件（仕様変更、追加機能等）を確認した
支払い条件（一括/分割/マイルストーン払い）を確認した

見積書の読み方の詳細はシステム開発の見積もり内訳ガイドを参照。

セクションまとめ：見積もり評価では「工程別内訳の有無」「テスト工数の比率」「保守費用の扱い」を重点的に確認する。「一式」表記は必ず内訳を求めること。

3. 契約フェーズのチェックリスト

契約書の確認（目安：1〜2週間）

契約形態（請負/準委任/ラボ型）が適切か確認した
成果物の範囲が明確に定義されているか確認した
納期（各工程の期限を含む）が記載されているか確認した
支払い条件と支払いスケジュールを確認した
知的財産権（ソースコード、設計書）の帰属を確認した（発注側に帰属が望ましい）
瑕疵担保責任の期間と範囲を確認した（検収後1年が目安）
仕様変更時の手続き（変更管理プロセス）を確認した
秘密保持条項が含まれているか確認した
再委託の可否と条件を確認した
解約条件と違約金を確認した
損害賠償の上限を確認した
弁護士または法務担当者のレビューを受けた（推奨）

プロジェクト体制の確認

開発会社側の窓口担当者（PM）を確認した
エスカレーション先（PM→上長）を確認した
連絡手段（メール、Slack、Teams等）を合意した
定例会議の頻度と参加者を合意した
議事録の作成ルールを合意した

ベンダーロックインのリスク対策はベンダーロックイン防止戦略ガイドを参照。

セクションまとめ：契約フェーズでは「知的財産権の帰属」「瑕疵担保責任」「変更管理プロセス」の3点が特に重要。口頭での合意は必ず書面に反映すること。

システム開発の発注について相談したい方へ

GXOでは、RFP作成支援から開発・保守まで一貫したサポートを提供しています。「チェックリストを見たが、自社だけでは不安」という方も、まずはお気軽にご相談ください。

※ 営業電話はしません｜オンライン対応可｜相談だけでもOK

無料相談はこちら

4. 開発フェーズのチェックリスト

要件定義（目安：4〜8週間）

要件定義の進め方とスケジュールを合意した
業務フロー（As-Is / To-Be）を詳細レベルで確定した
機能一覧を確定し、優先順位を付けた
画面設計（ワイヤーフレーム）を全画面分レビューした
データ構造（ER図）をレビューした
外部システムとの連携仕様を確定した
非機能要件（性能、セキュリティ、可用性）を確定した
要件定義書に双方が署名（承認）した

要件定義の書き方はシステム開発の要件定義テンプレートを参照。

設計・実装（目安：2〜8ヶ月）

基本設計書のレビューを実施した
週次の進捗報告会議を設定・実施している
進捗管理ツール（Backlog、Jira等）で進捗が可視化されている
中間デモ（プロトタイプ確認）を実施した
仕様変更が発生した場合、変更管理プロセスに従って処理した
スケジュールに遅延が発生していないか確認した
遅延が発生した場合、原因と対策を確認した

テスト

テスト計画書を確認した
単体テスト・結合テストの結果報告を受けた
受入テストの項目書を作成した（実際の業務シナリオに基づく）
受入テストを実施し、全項目をチェックした
バグが見つかった場合、修正と再テストを確認した
性能テスト（同時アクセス、レスポンス速度）を実施した
セキュリティテスト（脆弱性診断）を実施した（推奨）

セクションまとめ：開発フェーズで最も重要なのは「要件定義書の双方承認」と「受入テストの網羅的実施」。この2つが不十分だと、納品後にトラブルが発生する確率が大幅に高まる。

5. 納品・検収フェーズのチェックリスト

納品物の確認

ソースコード一式を受領した
設計書一式（基本設計、詳細設計）を受領した
テスト結果報告書を受領した
運用マニュアルを受領した
管理者向けマニュアルを受領した
インフラ構成図を受領した
各種アカウント情報（サーバー、DB、外部サービス等）を受領した
納品物がRFP・契約で定めた一覧と一致しているか確認した

検収

受入テストの全項目が合格していることを確認した
未解決のバグがないか（または許容範囲か）確認した
本番環境でのデータ移行が正常に完了したことを確認した
ユーザートレーニングが実施されたか確認した
検収書に署名した

リリース準備

旧システム/旧業務フローとの並行運用期間を設定した
障害発生時の連絡体制（緊急連絡先、対応フロー）を確認した
バックアップ体制（頻度、保存先、復元手順）を確認した
リリース日と切り替え手順を合意した

セクションまとめ：納品時は「納品物の漏れがないか」「受入テストの全項目合格」「検収書への署名」を確実に行う。検収書への署名は、瑕疵担保責任の起算日になるため、慎重に判断すること。

6. 保守・運用フェーズのチェックリスト

保守契約の確認

保守契約書を締結した
保守範囲（バグ修正、問い合わせ対応、機能追加の対応）を確認した
保守費用（月額/年額）を確認した
SLA（サービスレベル合意書）を確認した

- 対応時間（平日のみ/24時間365日）

- 障害対応の優先度分類と対応時間 - 月次報告の内容

保守契約の期間と更新条件を確認した

運用体制

日常的な運用手順が文書化されている
定期的なバックアップが自動化されている
セキュリティアップデートの適用ルールを確認した
ログ監視の仕組みが導入されている
定期的な性能監視が行われている
障害発生時の手順書（復旧マニュアル）がある

セクションまとめ：保守フェーズでは「保守範囲の明確化」「SLAの合意」「運用手順の文書化」が重要。保守契約を結ばずに運用を開始するのは、最も避けるべきパターンだ。

7. レッドフラグ一覧

以下の兆候が見られたら、注意が必要だ。

フェーズ	レッドフラグ	リスク
見積もり	他社より極端に安い（30%以上の差）	テスト不足、品質低下の可能性
見積もり	「一式」表記で内訳がない	何にいくらかかるか不透明
見積もり	テスト工数が10%未満	品質リスクが高い
契約	知的財産権が開発会社に帰属	将来の乗り換えが困難
契約	瑕疵担保責任が3ヶ月未満	納品後のバグ対応が不十分
要件定義	開発会社が業務ヒアリングを十分にしない	要件漏れのリスク
開発	週次報告がない、または内容が曖昧	進捗の実態が見えない
開発	デモや中間レビューの機会がない	完成品が要件と乖離するリスク
開発	PM/担当者が頻繁に変わる	ナレッジの断絶、品質低下
テスト	受入テスト前に十分なテスト結果が提示されない	品質保証が不十分

セクションまとめ：レッドフラグが1つでも該当する場合は、開発会社に理由を確認する。複数該当する場合は、プロジェクトの継続判断を含めて検討が必要だ。

8. まとめ

システム開発の発注は、6フェーズ・60項目超のチェックポイントで管理する。特に重要なのは以下の3点だ。

発注準備：RFPを作成し、要件と予算を明確にしてから見積もりを依頼する
契約：知的財産権の帰属、瑕疵担保責任、変更管理プロセスを書面で確認する
テスト・検収：受入テストを網羅的に実施し、納品物の漏れがないことを確認する

本チェックリストを各フェーズの開始時に確認し、抜け漏れを防ぐことで、プロジェクトの成功確率を大幅に高めることができる。

初めてのシステム開発外注の全体的な進め方は初めてのシステム開発外注ガイドも参照されたい。費用の全体感は中小企業のシステム開発費用ガイドで確認できる。

まずは無料相談から始めませんか？

GXOでは、システム開発の発注に関する無料相談を実施しています。「チェックリストの項目で不明な点がある」「自社に合った開発会社の選び方を知りたい」など、お気軽にご相談ください。

※ 営業電話はしません｜オンライン対応可｜最短翌営業日に回答

まずは無料相談する

FAQ

Q1. チェックリストの全項目を確認しないと危険ですか？ 全項目の確認が理想ですが、プロジェクトの規模に応じて優先度をつけてください。小規模案件（100万円以下）では契約と検収の項目を、中〜大規模案件ではすべてのフェーズの項目を確認することを推奨します。

Q2. RFPなしで見積もりを依頼しても良いですか？ RFPなしでも見積もりは取れますが、各社に同じ情報を伝えることが難しく、提案・見積もりの比較が困難になります。簡易版でも良いのでRFPを作成することを強く推奨します。

Q3. 契約書は開発会社の雛形をそのまま使って良いですか？ 基本的には開発会社が用意する雛形をベースにしますが、知的財産権の帰属、瑕疵担保責任の期間、変更管理プロセスの3点は必ず確認・交渉してください。可能であれば弁護士のレビューを受けることを推奨します。

Q4. 受入テストはどのくらい時間をかけるべきですか？ プロジェクト全体の5〜10%の期間が目安です。6ヶ月プロジェクトであれば2〜3週間程度です。実際の業務データを使って、全業務シナリオを通してテストすることが重要です。

Q5. 保守契約は必ず必要ですか？ はい。システムは稼働後にバグの発見、セキュリティアップデート、機能改善が必要になります。保守契約なしで運用すると、問題発生時に対応してもらえず、事業に重大な影響が出る可能性があります。

参考資料

IPA「ソフトウェア開発分析データ集2024」（2024年10月公表）
JISA「情報サービス産業基本統計調査 2024年版」
経済産業省「情報システムの信頼性向上に関するガイドライン」