システム開発の発注チェックリスト｜フェーズ別に確認すべき全ポイント
システム開発の発注で失敗する多くのケースは、「何をいつ確認すべきか」が整理されていないことに起因します。発注前・要件定義・開発中・納品の各フェーズで確認すべき項目を事前に把握しておくだけで、トラブルの大半は未然に防げます。本記事では、発注担当者がすぐに実務で活用できるチェックリストをフェーズ別にまとめました。
システム開発の発注チェックが重要な理由
Photo by Arnold Francisca on Unsplash
発注失敗の主な原因はチェック不足にある
システム開発の発注トラブルでよく聞かれるのは、「完成したシステムが要件と違った」「追加費用が想定外に膨らんだ」「納期が大幅に遅れた」といった問題です。これらの多くは、特定のフェーズで確認が抜け落ちたことが原因です。
- 発注前：業者の実績や契約条件を十分に比較しなかった
- 要件定義：認識のすり合わせが不十分なまま開発が始まった
- 開発中：進捗の確認頻度が低く、問題の発見が遅れた
- 納品時：検収基準が曖昧で、不具合を見落とした
どのフェーズでも「確認した」という事実を記録として残すことが、後々のトラブル防止につながります。
フェーズごとに確認タイミングを分ける考え方
システム開発は一度に全体を把握しようとすると混乱しやすいため、フェーズを区切って順番に確認するのが効果的です。本記事では以下の4フェーズに分けて解説します。
| フェーズ | 主な目的 |
|---|---|
| フェーズ1：発注前 | 業者選定・見積比較・契約条件の確認 |
| フェーズ2：要件定義 | 仕様の明確化・認識齟齬の解消 |
| フェーズ3：開発中 | 進捗管理・仕様変更対応 |
| フェーズ4：納品・検収 | 動作確認・納品物の受け取り・保守体制の確認 |
【フェーズ1】発注前の業者選定チェックリスト
Photo by Austin Distel on Unsplash
開発実績・得意分野の確認
発注先を選ぶ際は、自社の要件に近い開発実績があるかを最初に確認しましょう。
- 同業種・同規模の開発実績があるか
- 得意とする技術領域（Webシステム、スマホアプリ、業務系など）が自社ニーズと合っているか
- 過去の納品事例や参考サイトを提示してもらえるか
- 担当者がプロジェクトの内容を正確に理解しているか（ヒアリング精度の確認）
開発体制とエンジニアのスキル確認
開発を担当するエンジニアの体制を把握することで、品質リスクを事前に評価できます。
- プロジェクトに関わるエンジニアの人数と役割が明示されているか
- プロジェクトマネージャー（PM）が専任で配置されるか
- 外注（二次請け・三次請け）が発生する場合、その範囲と管理体制が説明されているか
- 担当エンジニアが途中で交代する可能性とその際の引き継ぎ方針が確認できるか
情報セキュリティ体制の確認
自社の業務データや顧客情報を扱う場合、セキュリティ体制の確認は必須です。
- 情報セキュリティに関する社内規程・ポリシーが整備されているか
- Pマーク（プライバシーマーク）やISMS（情報セキュリティマネジメントシステム）などの認証取得状況を確認したか
- 秘密保持契約（NDA）の締結が可能か
- 開発環境と本番環境が分離されているか
見積書の内容と契約条件の比較
見積書は金額だけでなく、含まれる作業範囲と含まれない作業範囲を明確に確認することが重要です。
- 見積書に作業範囲（スコープ）が明記されているか
- 仕様変更時の追加費用の算出ルールが記載されているか
- 支払い条件（前払い・後払い・分割など）が明確か
- 瑕疵担保責任（かしたんぽせきにん：納品後に不具合が発見された場合の対応義務）の期間が契約書に記載されているか
- 知的財産権（ソースコードの著作権）の帰属先が明示されているか
【フェーズ2】要件定義・仕様書のチェックリスト
要件定義書に盛り込むべき項目の確認
要件定義書は、発注者と開発会社が「何を作るか」を共有するための最重要ドキュメントです。以下の項目が含まれているか確認してください。
- システムの目的・解決したい課題が明記されているか
- 利用ユーザーの種類と想定利用シーンが記載されているか
- 必須機能と優先度の低い機能が区別されているか
- 非機能要件（処理速度、同時接続数、セキュリティ要件など）が定義されているか
- 既存システムとの連携が必要な場合、その仕様が記載されているか
発注者と開発会社の認識齟齬をなくす確認方法
言葉の解釈の違いがトラブルの温床になります。以下の方法で認識を揃えましょう。
- 画面イメージ（ワイヤーフレームやモックアップ）を使って視覚的に確認したか
- 「〜のような機能」という曖昧な表現を具体的な動作仕様に落とし込んだか
- 要件定義書の内容を発注者・開発会社の双方が署名・承認したか
- 不明点や懸念事項を議事録として記録し、双方で共有しているか
仕様書と発注書の内容が一致しているかのチェック
仕様書と発注書（注文書）の内容が食い違っていると、後から「言った・言わない」の問題が起きます。
- 発注書に記載された作業内容が仕様書の内容と一致しているか
- 納期・金額・支払い条件が双方の書類で統一されているか
- 仕様変更が発生した場合の変更管理手順が合意されているか
【フェーズ3】開発中の進捗管理チェックリスト
定例ミーティングと報告頻度の確認
開発中は定期的な情報共有の仕組みを最初に決めておくことが、問題の早期発見につながります。
- 週次・隔週など定例の進捗報告の頻度と形式が合意されているか
- 進捗報告に使うツール（メール・チャット・プロジェクト管理ツールなど）が決まっているか
- 報告内容に「完了タスク・進行中タスク・課題・リスク」が含まれているか
- 発注者側の確認・承認が必要なタイミングが事前にスケジュール化されているか
納期遅延リスクの早期察知ポイント
遅延は早めに察知するほど対処の選択肢が広がります。以下のサインに注意しましょう。
- マイルストーン（中間目標）の達成状況を定期的に確認しているか
- 「問題ない」という回答だけでなく、具体的な進捗数値（完了機能数など）を確認しているか
- 担当エンジニアから直接ヒアリングできる機会があるか
- 遅延が発生した場合の対応方針（スコープ削減・納期延長・追加リソース投入）を事前に合意しているか
仕様変更が発生した場合の対応手順確認
開発途中での仕様変更は珍しくありませんが、手順を決めておかないと費用・納期の混乱を招きます。
- 仕様変更の申請は書面（メール可）で行うルールになっているか
- 変更内容・影響範囲・追加費用・納期への影響を開発会社から書面で提示してもらえるか
- 発注者側の承認者が明確になっているか
- 変更履歴が管理されており、最新仕様書が常に共有されているか
【フェーズ4】納品・検収時のチェックリスト
テスト項目と動作確認の範囲
納品物を受け取る前に、検収基準を明確にしておくことが重要です。
- 検収の合否を判断する基準（テスト仕様書）が事前に合意されているか
- 全機能の動作確認（機能テスト）を発注者側でも実施したか
- 実際の業務データに近いデータを使ったテストを行ったか
- 複数のブラウザ・デバイスでの動作確認が必要な場合、その範囲が明確か
- セキュリティに関するテスト（不正アクセス・データ漏洩リスクなど）の実施有無を確認したか
ドキュメント・ソースコードの納品物確認
システム本体だけでなく、将来の保守・改修に必要なドキュメント類も受け取ることが重要です。
- ソースコード一式を受け取ったか（著作権の帰属が自社になっている場合）
- システム設計書・テーブル定義書・API仕様書などの技術ドキュメントが揃っているか
- 操作マニュアル（管理者用・一般ユーザー用）が納品されているか
- サーバー・データベースの設定情報や認証情報が安全な方法で引き渡されているか
- 使用しているライブラリ・フレームワークのバージョン情報が記録されているか
保守・運用サポート体制の確認
納品後のサポート体制を確認しておくことで、稼働後のトラブルに迅速に対応できます。
- 瑕疵担保期間（一般的に納品後数ヶ月〜1年程度が多いですが、契約による）と対応範囲が明確か
- 保守契約の有無・費用・対応内容（障害対応・機能追加・バージョンアップなど）が確認できるか
- 緊急時の連絡先と対応時間（営業時間内のみか、24時間対応かなど）が明示されているか
- 将来的に別の会社に保守を移管する場合の手続きについて合意できているか
発注チェックをスムーズに進めるための3つのコツ
1. チェックリストを「社内共有ドキュメント」として管理する
個人のメモではなく、関係者全員が参照・更新できる形式（スプレッドシートやプロジェクト管理ツールなど）で管理すると、確認漏れを防ぎやすくなります。
2. 確認した内容は必ずメール等で記録に残す
口頭での合意は後から証明が難しいため、重要な確認事項はメールや議事録として記録を残す習慣をつけましょう。「〇〇について確認しました。認識に相違がなければご返信ください」という一文を添えるだけでも有効です。
3. 発注者側の窓口を1人に絞る
複数の担当者が開発会社に個別に連絡すると、指示が錯綜して混乱を招きます。発注者側の窓口担当者を1名に絞り、情報を集約する体制を作ることで、コミュニケーションコストを大幅に削減できます。
よくある質問（FAQ）
システム開発の発注で最初に確認すべきことは何ですか？
最初に確認すべきは「自社が何を解決したいのか」という目的の明確化です。目的が曖昧なまま業者選定を始めると、見積もりの比較ができず、適切な業者を選べません。次に、予算と大まかなスケジュールの目安を社内で合意しておくと、業者とのやり取りがスムーズになります。
見積書と発注書の内容が違う場合はどうすればいいですか？
発注書に署名・押印する前に必ず内容を照合し、相違点を書面で指摘して修正を求めてください。内容が異なる書類に署名してしまうと、後から修正が難しくなる場合があります。不明点は「確認中」として保留し、双方が合意した内容で書類を揃えてから手続きを進めましょう。
要件定義書は発注者が作るべきですか、開発会社が作るべきですか？
一般的には、発注者が「何を実現したいか」を整理した上で、開発会社がヒアリングを経て要件定義書を作成するケースが多いです。ただし、最終的な内容の責任は発注者にあります。開発会社が作成した場合でも、内容を発注者が確認・承認するプロセスを必ず設けてください。
開発中に仕様変更が発生した場合、追加費用はどう判断すればいいですか？
変更内容の規模と、当初の仕様書に含まれていたかどうかで判断します。当初の仕様に含まれていない機能追加や大幅な変更は追加費用が発生するのが一般的です。費用が発生する場合は、変更前に書面で金額・納期への影響を確認し、承認してから作業を進めてもらうルールを徹底してください。
納品物として受け取るべきドキュメントにはどんなものがありますか？
プロジェクトの規模や内容によって異なりますが、一般的には「操作マニュアル」「システム設計書」「テーブル定義書」「インフラ構成図」「テスト仕様書・結果報告書」などが挙げられます。将来の改修や保守を考えると、ソースコードと合わせてこれらのドキュメントを受け取っておくことが重要です。
発注先のセキュリティ体制はどのように確認すればいいですか？
PマークやISMSなどの第三者認証の取得状況を確認するのが一つの目安になります。認証がない場合でも、情報セキュリティポリシーの有無、開発環境の管理方法、従業員教育の実施状況などをヒアリングすることで、体制の成熟度をある程度把握できます。また、秘密保持契約（NDA）の締結は必須と考えてください。
初めてシステム開発を発注する場合、特に注意すべき点は何ですか？
「要件定義の重要性を甘く見ないこと」が最も大切です。初めての発注では、自社の要望を言語化することに慣れていないため、曖昧な仕様のまま開発が進みやすくなります。画面イメージや業務フロー図を使って視覚的に確認する習慣をつけると、認識のズレを早期に発見できます。また、小規模なプロジェクトから始めて、開発会社との信頼関係を段階的に築くアプローチも有効です。
納期が遅延しそうなとき、発注者はどう対応すればいいですか？
まず遅延の原因と影響範囲を書面で報告してもらい、現実的な対応策（納期延長・スコープ削減・追加リソース投入など）を開発会社と協議してください。感情的な対応よりも、「いつまでに何が完成するか」を具体的に確認することが解決への近道です。遅延が契約上の問題に発展する可能性がある場合は、契約書の遅延損害金条項などを確認しておくことも必要です。
