システム開発を発注したいと思っても、どの順番で相談すればよいのか、要件定義や設計の工程で発注者が何を確認すればよいのかは分かりにくいものです。開発会社に任せれば進む部分もありますが、目的、業務の前提、優先順位、検収条件は発注者側で決めなければなりません。
特に初めて開発会社へ依頼する場合、発注の流れを知らないまま見積もりを取ると、会社ごとに提案範囲がずれ、金額だけでは比較できなくなります。要件定義の段階で社内合意が取れていないと、設計や開発に入ってから追加費用や納期遅延が起きやすくなります。
この記事では、システム開発の発注の流れを、相談前の整理からRFP、見積もり、要件定義、設計・開発、検収、運用保守まで実務目線で解説します。工程名を覚えるだけでなく、発注者がどの成果物を見て何を判断すべきかまで整理します。
この記事のポイント
- システム開発の発注は相談前の整理、RFP、見積もり、要件定義、設計開発、検収の順に進める
- 発注者の役割は作業を丸投げせず、目的、業務範囲、優先順位、承認者を決めること
- 見積もりは金額だけでなく、含まれる工程、成果物、変更条件、運用保守の範囲で比べる
- 要件定義書に合意内容を残すと、設計、開発、検収で判断基準に戻りやすくなる
開発会社へ相談する前に、目的、現状フロー、利用者、必要な機能、予算、希望時期を簡単に書き出しておくと、発注後の会話がかなり進めやすくなります。
反対に、何を作るかだけを急いでしまうと、開発会社は業務の背景を推測するしかありません。初回相談では、今の作業で困っている場面、既存の帳票やシステム、承認者が気にする条件、リリース後に誰が運用するかまで共有できると、発注の流れ全体で手戻りを減らせます。
目次
システム開発の発注の流れと工程
相談前に目的と課題を整理する
システム開発の発注は、開発会社へ問い合わせる前から始まっています。最初に整理するのは、作りたい機能名ではなく、何の業務課題を解決したいのか、誰が使うのか、どの状態になれば成功と言えるのかです。
たとえば「受発注管理システムを作りたい」だけでは、見積もりの前提が広すぎます。「電話とメールで受けている注文を一元管理し、入力漏れを減らし、月次集計を早くしたい」まで具体化すると、必要な機能、連携先、運用担当者が見えやすくなります。
この段階では完璧な資料を作る必要はありません。現状の業務フロー、困っている作業、利用部門、既存システム、予算感、希望時期、絶対に外せない条件を箇条書きにするだけでも、開発会社は初回相談で質問しやすくなります。
RFPで提案条件をそろえる
複数の開発会社へ相談する場合は、RFP、つまり提案依頼書を用意すると比較しやすくなります。RFPには、プロジェクトの目的、現状課題、希望する業務範囲、必要な機能、スケジュール、予算感、提案してほしい範囲を書きます。
RFPがないまま各社と個別に打ち合わせると、A社には予算を伝えたがB社には伝えていない、C社には運用保守を含めたがD社には含めていない、といった差が出ます。その結果、見積もり金額の差が、開発会社の違いなのか、前提条件の違いなのか判断しにくくなります。
RFPの書き方を詳しく整理したい場合は、システム開発のRFPの書き方を先に確認すると、発注の流れの中で何を資料化すべきか分かりやすくなります。
見積もりと提案を同じ条件で比べる
見積もりを受け取ったら、金額の安さだけで判断しないことが重要です。システム開発の見積もりには、要件定義、設計、開発、テスト、導入、運用保守、プロジェクト管理など、さまざまな作業が含まれます。安い見積もりでも、要件定義やテストが薄ければ、後で追加費用が発生する可能性があります。
比較するときは、各社の提案が同じ範囲を前提にしているかを確認します。開発範囲、画面数、連携先、非機能要件、テスト範囲、検収方法、運用保守の有無、変更時の費用条件が揃っていない場合は、同じ条件に直して再確認した方が安全です。
見積もりの根拠が分かりにくい場合は、システム開発の見積もり根拠を確認する方法を参考に、工数、成果物、前提条件、管理工数を分けて見てください。
| 発注工程 | 発注者が行うこと | 確認する成果物 |
|---|---|---|
| 相談前整理 | 目的、課題、利用者、予算感をまとめる | 現状メモ、業務フロー、課題一覧 |
| RFP作成 | 各社へ同じ提案条件を伝える | RFP、提案依頼メール、質問回答表 |
| 提案・見積もり | 提案範囲、費用、体制、契約条件を比べる | 提案書、見積書、契約条件 |
| 要件定義 | 業務範囲、機能、優先順位、承認者を決める | 要件定義書、画面一覧、業務フロー |
| 設計・開発 | 成果物を確認し、変更判断を行う | 設計書、画面案、進捗報告 |
| テスト・検収 | 業務で使えるかを確認し、受け入れ判断をする | テスト結果、検収チェックリスト、マニュアル |
要件定義で作る範囲を決める
要件定義は、システム開発の発注工程の中でも特に重要です。ここで決めるのは、開発会社が作る機能だけではありません。業務上の目的、利用者、対象範囲、画面や帳票、外部連携、権限、性能、セキュリティ、運用方法、スケジュール、予算、検収条件まで、開発後の判断基準になる情報を固めます。
IPAのDX SQUAREでも、要件定義はユーザー企業とベンダー企業の認識を合わせるために大切な工程として整理されています。発注者が業務の前提を出し、開発会社が技術面から具体化を支援する、という役割分担で進めると、丸投げにも独りよがりにもなりにくいです。
要件定義書を作るときは、目的、現状フロー、ステークホルダー、機能要件、非機能要件、互換性、スケジュール、予算を分けて書くと整理しやすくなります。発注前に資料化したい場合は、要件定義書の作り方と成果物サンプルもあわせて確認してください。
設計・開発・テストを確認する
設計以降は開発会社の作業が中心になりますが、発注者が関わらなくてよいわけではありません。外部設計では画面、操作、帳票、データの見え方を確認し、業務の流れと合っているかを判断します。内部設計や実装は技術的な内容が多いため、細部をすべて理解する必要はありませんが、進捗、リスク、未決事項、変更要望の扱いは定期的に確認します。
テスト工程では、開発会社がプログラムの不具合を確認するだけでなく、発注者側も実際の業務シナリオで使えるかを見ます。単体テストや結合テストは開発会社が中心になりますが、総合テストや受入テストでは、利用部門の担当者も参加した方が現場の認識ずれを見つけやすいです。
途中で仕様変更が必要になった場合は、すぐに口頭で進めず、変更内容、理由、追加費用、納期影響、誰が承認するかを記録します。発注の流れの中で変更管理を曖昧にすると、最後に「どこまでが契約内だったのか」が分からなくなります。
検収から運用保守へ引き継ぐ
納品前後の検収では、要件定義書や設計書で合意した内容に沿って、システムが業務で使える状態かを確認します。画面が開くか、データが登録できるかだけでなく、実際の利用者が業務手順として回せるか、マニュアルや権限設定が揃っているか、障害時の連絡先が明確かも見ます。
検収で問題が見つかった場合は、不具合なのか、仕様変更なのか、追加要望なのかを分けて判断します。不具合なら修正対象ですが、当初合意していない機能追加であれば、追加費用や納期調整が必要になることがあります。
システムは納品して終わりではありません。リリース後の問い合わせ対応、軽微な修正、障害対応、データバックアップ、セキュリティ対応、改善要望の受付まで、運用保守の範囲を契約前に確認しておくと、稼働後の不安を減らせます。
システム開発の発注の流れで確認すること
各工程の成果物を確認する
発注者がシステム開発の工程を知る意味は、専門用語を覚えることではなく、どの成果物を見れば判断できるかを押さえることです。要件定義書、設計書、画面案、テスト仕様書、テスト結果、マニュアル、運用設計書などは、次の工程へ進むための判断材料になります。
成果物を受け取ったら、細かな技術仕様をすべて理解しようとするより、自社の業務と合っているか、利用者が迷わないか、社内承認者が判断できる情報になっているかを確認します。特に画面や帳票は、開発会社よりも発注者側の業務部門の方が違和感に気づきやすいです。
| 成果物 | 確認する観点 | 発注者側の関係者 |
|---|---|---|
| 要件定義書 | 目的、対象範囲、優先順位、検収条件が明確か | 決裁者、業務責任者、情シス |
| 画面案・設計書 | 現場の業務手順と合っているか | 利用部門、運用担当者 |
| 進捗報告 | 遅延、リスク、未決事項が見えているか | プロジェクト責任者、窓口担当 |
| テスト結果 | 重要な業務シナリオで問題がないか | 利用部門、受入テスト担当 |
| 運用資料 | 問い合わせ、障害、改善要望の流れが明確か | 運用担当者、管理者 |
丸投げにしない役割を決める
システム開発でよくある失敗は、発注者が「専門的なことは分からないので、良い感じにお願いします」と丸投げしてしまうことです。開発会社は技術や進め方を提案できますが、発注者の業務目的、社内事情、優先順位、承認ルールまでは勝手に決められません。
発注者側では、プロジェクト責任者、業務部門の代表、情シス担当、承認者、運用担当者を決めておきます。窓口が複数あると、開発会社への指示がばらばらになり、どの要望を優先すべきか分からなくなります。窓口は一本化しつつ、裏側では関係者の意見を集める体制にすると進めやすいです。
分からない専門用語や設計内容が出てきた場合は、その場で説明を求めてかまいません。理解しないまま承認すると、後から「そういう意味だとは思っていなかった」となり、修正の責任範囲が曖昧になります。
変更と追加費用の条件を見る
システム開発では、途中で変更が起こること自体は珍しくありません。業務部門から新しい要望が出る、既存システムとの連携条件が変わる、法律や社内ルールが変わる、テストで必要な機能が見つかる、といったことは実務でよく起きます。
大事なのは、変更を悪者にすることではなく、変更をどう判断するかを決めておくことです。契約前または要件定義の段階で、変更依頼の方法、見積もりの出し方、追加費用の承認者、納期への影響、優先順位の決め方を確認しておきます。
変更時の確認項目
- 変更内容は既存要件の修正か新しい要望か
- 追加費用、納期、テスト範囲への影響はどれくらいか
- 誰が承認すれば作業に入れるか
- 後続フェーズへ回しても業務上問題ないか
社内承認のタイミングを置く
発注工程の中では、社内承認のタイミングをあらかじめ置いておくことも重要です。見積もり承認、契約承認、要件定義承認、設計承認、検収承認のように、誰が何を見て承認するのかを決めておくと、後戻りを減らせます。
特に要件定義と設計の承認は、後の費用と納期に直結します。業務部門の代表が確認しないまま承認すると、開発後に現場から「この運用では使えない」と言われるリスクがあります。逆に、関係者を増やしすぎると意思決定が遅くなるため、意見を出す人と最終判断する人は分けておきます。
承認のたびに完璧な会議体を作る必要はありません。承認対象、判断観点、期限、差し戻し条件を短く決めておくだけでも、発注者と開発会社の双方が次の工程へ進みやすくなります。
また、承認結果はメールや議事録に残しておきます。後から担当者が変わった場合でも、どの時点で何に合意したのかを追えるため、検収時の判断や追加要望の整理に役立ちます。
