システム開発の工程とは？流れと各フェーズで発注者がやること

システム開発を発注する際、開発会社へ依頼した後に自社が何を決め、いつ確認するのかが見えていないと、認識ずれや判断待ちが起こりやすくなります。工程名を知るだけではなく、業務側の判断、成果物のレビュー、受入準備までを一続きで捉えることが重要です。

この記事では、要件定義から保守・運用までの流れを、発注者の実務に沿って整理します。読後には、自社案件の決定者・確認する成果物・回答期限を工程ごとに整理できるようになり、相談や見積比較の前に社内で決めるべきことを具体化できます。

システム開発は工程を順番に進めるだけでなく、各段階で発注者が範囲・優先順位・受入可否・運用方針を判断しながら進めます。

01Sectionシステム開発の工程は、発注者の判断をつなぐ流れで進む

一般的な受託・委託型のシステム開発は、「要件定義→設計→実装→テスト→リリース→保守・運用」を基本軸として進みます。前の工程で決めた対象範囲、優先順位、利用条件が、後の設計・テスト・運用方法に影響します。

工程、役割、管理資料を体系的に確認する考え方は、デジタル庁のデジタル社会推進標準ガイドラインでも示されています。ただし、これは政府情報システム向けの標準です。民間案件でもそのまま同一の進め方になるわけではなく、以下の表は発注者が確認すべき論点を整理するための代表例として捉えてください。

02Section工程別に見る、発注者が決めることと確認する成果物

発注者が担う中心的な役割は、技術的な実装方法を決めることではなく、業務目的、優先順位、受入可能な状態、運用方針を判断することです。経済産業省の情報システム・モデル取引・契約書も、要件定義、開発、移行、運用・保守を分けて役割分担や契約条件を検討する視点を示しています。

要件定義・設計では、目的、範囲、業務適合性を確認する

要件定義は、何を、なぜ、どこまで作るかを業務の観点から決める工程です。発注者は、現場の困りごと、対象利用者、初回リリースで必要な範囲、対象外にする範囲を整理します。導入目的は、現状値、目標の方向性、測定方法、確認時期、責任者を含むKPIとして仮置きしておくと、リリース後の効果確認につなげやすくなります。

設計では、画面や業務フロー、権限、帳票、外部連携が実際の業務に合うかを確認します。開発会社が作成する資料を技術資料として読み流さず、「誰が、どの場面で、どの情報を見て、どのように処理するか」という利用者の視点でレビューします。

実装・テストでは、判断待ち事項と受入準備を管理する

実装中には、仕様の解釈や追加要望など、発注者の判断が必要な事項が発生します。回答が遅れると、実装やテストの着手待ちにつながるため、質問ごとに回答者と期限を置くことが重要です。追加要望は、初回リリースで必須か、後続改善へ回せるかを業務影響で判断します。

テストでは、開発会社による確認とは別に、発注者・利用部門が業務シナリオで利用できるかを確認する準備が必要です。テスト担当者、テストデータ、利用部門が確認できる期間、修補後の再確認方法を、実装が終わる前から確保します。

リリース・保守では、利用開始と効果確認をつなげる

リリースは、機能が完成したことだけを意味しません。移行、権限設定、利用者への周知、教育、問い合わせ窓口を整え、業務として利用を始められる状態をつくる段階です。

保守・運用では、問い合わせ、障害、利用状況、KPIを確認し、改善要望を業務影響と優先順位で並べます。「リリースした」ことと「導入目的を達成した」ことは別です。運用報告を受け取るだけでなく、改善の判断者と判断時期を決めておきます。

03Section発注者側の体制と承認ゲートを先に置く

開発の遅れは、技術上の問題だけで起こるわけではありません。承認者が不明、利用部門のレビューが後回し、質問への回答期限がないといった状態でも、工程は止まりやすくなります。着手前に、工程ごとの主担当、承認者、レビュー参加者を置きます。

役割は、業務責任者、現場代表、情報システム部門、決裁者といった肩書きで固定せず、案件の体制と社内規程に沿って定めます。各工程で「誰が決めるか」と「いつまでに回答するか」を明確にすることが、判断待ちを防ぐ基本です。

リリースでは利用開始の可否を、保守・運用では利用状況や業務効果を踏まえた改善を、それぞれ別の判断として管理します。KPIも数値だけを置かず、現状値、目標、計測方法、確認時期、責任者を定めると、運用開始後の改善判断につなげやすくなります。

04Section受入条件、受入テスト、リリース判定、検収を分けて確認する

業務で利用できるかの確認と、契約・仕様書に沿った成果物確認は、目的と記録を分けて扱います。

受入テスト、リリース判定、検収は同じ意味ではありません。いずれもプロジェクト終盤に行われることがありますが、目的と確認対象を分けて記録することで、業務上の判断と契約上の手続を混同しにくくなります。デジタル庁の標準ガイドライン解説書も、テストや検収に関する管理観点を扱っています。

受入テストによる業務利用の確認と、検収による契約上の成果物確認は分けて扱います。

• 受入条件は、業務利用の可否を判断する基準です。誰が、どの業務シナリオとデータで、何を合格とするかを定めます。
• 受入テストは、受入条件に沿って利用可否を確認する活動です。合否の根拠、不具合、残課題、暫定対応を記録します。
• リリース判定は、受入結果に加え、移行、教育、窓口、切戻し、残課題の業務影響を踏まえた利用開始の判断です。
• 検収は、契約・仕様書で定めた成果物や条件を確認する手続です。

成果物、検収条件、変更時の見積・承認、責任分担を確認する際は、システム開発の契約で確認したいポイントもあわせて確認すると、契約上の論点を整理しやすくなります。

05Section手戻りを防ぐために、変更とリスクを工程ごとに管理する

手戻りを減らすには、問題が起きてから対応するのではなく、早い段階で確認すべき論点と判断経路を置くことが有効です。IPAの機能要件の合意形成技法は、要件の合意形成が不十分な場合、下流工程で手戻りにつながり得ることを示しています。

要件・非機能要件は、対象外も含めて確認する

業務フロー、例外処理、権限、外部連携だけでなく、性能、セキュリティ、運用、移行も早期に確認します。すべてを初回リリースに含める必要はありませんが、対象外にする事項と、その理由を記録しないと、後から要件漏れか追加要望かを判断しにくくなります。

意思決定と変更要求は、記録で管理する

変更は要望の可否だけで決めず、業務影響と各工程への影響を確認したうえで、判断内容を記録します。

変更を口頭やチャットだけで進めると、対象範囲、費用、日程、品質への影響が共有されないまま実装に入るおそれがあります。変更の必要性と影響を確認し、誰がいつ判断したかを残します。

受入・移行・運用準備をリリース前に終わらせる

受入担当者、テストデータ、修補期間、移行手順、教育、問い合わせ窓口、障害時の連絡先は、リリース直前にまとめて決めると不足が出やすい項目です。リリース判定の前提として、担当と完了条件をそれぞれ置きます。

06Section期間と費用は、相場ではなく工程範囲と前提条件で比べる

期間と費用は、機能数だけでは決まりません。要件の確実性、外部連携、データ移行、非機能要件、テスト・移行支援、発注者側のレビュー体制、保守範囲などで変わるため、一般的な費用レンジを一律に当てはめるのではなく、見積もりの対象範囲と前提条件をそろえて比較します。

期間の妥当性確認には、IPA「ソフトウェア開発分析データ集2022」が示す近似式、開発5工程の工期（月）＝0.40×開発5工程の工数（人時）^0.33を参照できます。ここでの開発5工程は、基本設計、詳細設計、製作、結合テスト、総合テスト（ベンダ確認）を指します。要件定義、社内承認、受入テスト、移行、教育などの工程外の期間は含まないため、契約全体の期間や利用開始日、費用相場には転用できません。

希望リリース日からの逆算計画や工程外日程の置き方は開発スケジュールの立て方で、費用層の分け方や見積書の比較方法は見積もりの取り方・見方で詳しく解説しています。見積額に差があるときは、金額だけで判断せず、対象範囲、連携・移行、品質確認、発注者側に求められる作業、保守範囲、除外事項が同じ条件になっているかを質問します。

07Sectionウォーターフォール型とアジャイル型は、発注者の運用可能性で選ぶ

ウォーターフォール型とアジャイル型の違いは、工程があるかないかではなく、要件・設計・実装・テスト・レビューをどの単位で進め、いつ意思決定するかにあります。デジタル庁のアジャイル開発実践ガイドブックは、反復的な開発を含む進め方を選択肢として整理しています。

ウォーターフォール型でも変更やレビューは発生します。一方で、アジャイル型でも、導入目的、優先順位、レビュー方法、成果確認、責任分担を決めずに進められるわけではありません。手法名よりも、変更の頻度に対して自社がどの程度レビュー・判断できるか、分割リリースが業務上可能かを確認します。

08Section相談・見積比較の前に、確認観点をそろえる

初回相談の時点で、すべての要件を確定する必要はありません。ただし、課題や対象範囲、未定事項の決め方が共有されていないと、提案や見積もりの比較条件がそろいにくくなります。

未定事項は空欄のままにせず、「誰が」「いつまでに」決めるかを付けて共有します。これにより、開発会社は前提条件を明示しやすくなり、発注者側も提案内容の違いを金額以外の条件で比較できます。

要件を具体化する段階では、要件定義とは?発注者が主導すべき理由と進め方・成果物を参照してください。成果物、検収条件、変更時の見積・承認、責任分担は、システム開発の契約で確認したいポイントとあわせて、提案書・見積書・契約書で確認します。

Webアプリ・SaaS開発の相談先を比較する

要件や未定事項、希望時期を整理したうえで、開発体制や支援範囲を比較したい場合は、対応可能なパートナーを確認できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の相談先を見る