システム開発の流れとは？工程の全体像と各フェーズのポイントをわかりやすく解説

システム開発を外部に依頼するとき、全体の流れを知らないままでは、いま何が行われていて、自社が何を判断すべきかが見えません。本記事では、要件定義から運用保守までのシステム開発の流れを工程ごとに整理し、各フェーズの目的・成果物・発注側が関与すべきポイントを俯瞰できる形で解説します。

まとめ：システム開発の流れは「要件定義、設計、実装、テスト、リリース、運用保守」の6段階で捉える

システム開発は、細かな呼び方の違いはあっても、要件定義、設計、実装、テスト、リリース、運用保守という6段階の流れで進むのが基本形です。要点は次の通りです。

• 工程を順に進める基本形はウォーターフォールと呼ばれ、各工程の完了条件と成果物が明確なため、進捗と品質を管理しやすい
• 設計とテストは対応関係にあり、この対応をV字で表したV字モデルを知っておくと「どのテストで何を確かめるのか」が理解しやすくなる
• 発注側の関与が特に濃い工程は、最上流の要件定義と、リリース直前の受け入れテストの二つ
• 手戻りコストは下流に行くほど膨らむため、各工程の完了時に成果物をレビューして次へ進む「区切りの規律」が品質を支える
• アジャイル開発でもこの6段階の活動自体はなくならず、反復の中に畳み込まれる形で繰り返される

システム開発の流れの全体像を理解する

基本形としてのウォーターフォール

ウォーターフォール型は、水が上から下へ流れるように工程を順に完了させていく進め方で、日本の受託開発ではいまも標準的な進行モデルです。各工程に完了条件（成果物とレビュー）が定義されているため、契約・見積もり・進捗管理と結びつけやすい点が強みといえます。一方、原則として前の工程に戻らない構造のため、上流の誤りが下流で見つかったときの手戻りが大きく、上流工程の品質がプロジェクト全体のリスクを決める構造を持ちます。

V字モデル：設計とテストの対応関係

工程の流れを理解するうえで役に立つのがV字モデルです。左辺に要件定義、基本設計、詳細設計と下りていく工程を、右辺に単体テスト、結合テスト、総合テスト、受け入れテストと上っていく工程を置くと、同じ高さの工程同士が検証の対応関係になります。詳細設計の内容は単体テストで、基本設計の内容は結合テストで、要件定義の内容は総合テスト・受け入れテストで確かめる、という対応です。この構造を知っておくと、テスト工程で見つかった不具合が「どの工程で作り込まれた誤りか」を遡って考えられるようになります。

ウォーターフォール以外の進行モデル

基本形を押さえたうえで、派生的な進行モデルも知っておくと開発会社との会話が滑らかになります。プロトタイプ型は、要件定義や設計の途中で試作品を作って利用者に触ってもらい、認識のずれを早期に解消する進め方で、画面中心のシステムと相性が良い方式です。スパイラル型は、リスクの高い部分から反復的に開発と評価を繰り返す進め方で、大規模で不確実性の高い開発に採られてきました。短い反復で動くソフトウェアを積み上げるアジャイル型も含め、いずれも「誤りの発見を早める」という同じ課題への異なる答えだと捉えると、モデル間の違いが理解しやすくなります。

各工程の目的と成果物を順に検討する

1. 要件定義：作るものの範囲を確定させる

最初の工程では、解決したい業務課題をもとに、システムで実現する機能・性能・制約を整理し、要件定義書として確定させます。発注側の参画がもっとも濃い工程であり、業務を説明できる担当者と仕様を決断できる責任者の確保が前提条件になります。ここでの決定事項が以降のすべての工程の判断基準になるため、開発全体の2〜3割程度の期間を充てる計画が一つの目安です。

2. 設計：基本設計と詳細設計

設計工程は二層に分かれます。基本設計（外部設計）では、画面・帳票・外部システムとの連携方式など、利用者や外部から見える振る舞いを定めます。詳細設計（内部設計）では、プログラムの内部構造やデータベースの物理構成など、開発者向けの実装指針を定める役割です。システム全体の骨格となるアーキテクチャの選定は基本設計の重要論点で、選択肢の整理にはシステムアーキテクチャの種類と選び方が参考になります。関係者への説明に使う構成図の描き方に迷った場合は、アーキテクチャ図に「正解」がない理由と背景も判断の助けになります。

3. 実装：設計を動くコードにする

実装（開発・プログラミング）工程では、詳細設計書に基づいてコードを書き進めます。発注側から見ると進捗が見えにくくなる期間のため、週次の進捗報告の形式や、課題が出たときのエスカレーション経路を事前に合意しておくと安心です。コーディング規約やレビューの運用など、開発会社側の品質管理の仕組みは、この工程の品質を左右します。

4. テスト：単体・結合・総合・受け入れの4段階

テストは粒度の小さい順に、プログラム部品単位の単体テスト、部品を組み合わせた結合テスト、システム全体を業務の流れで検証する総合テスト、そして発注側が実施する受け入れテスト（UAT）と進みます。受け入れテストは「開発会社のテストの再実行」ではなく、実際の業務シナリオと実データに近い条件で、業務が回るかを発注側の目で確かめる工程です。ここで確認を怠って稼働後に問題が出ると、業務停止という形で自社が影響を受けるため、テストシナリオの準備と実施体制は発注側の重要な責務になります。

5. リリース：本番環境への移行

リリース工程では、本番環境の構築、既存システムからのデータ移行、利用者への教育、切り替え手順の実行を行います。一斉に切り替えるか、部門や機能を区切って段階的に移行するかは、業務停止リスクとの兼ね合いで判断します。切り替えに失敗した場合に旧環境へ戻す手順（切り戻し）を事前に用意しておくことが、リリース計画の質を測る指標です。移行リハーサルを本番相当のデータで実施できているかも、あわせて確認しておきたいポイントといえます。

6. 運用保守：使い続けられる状態を保つ

稼働後は、監視・障害対応・問い合わせ対応・法改正や業務変更に伴う改修という運用保守フェーズに入ります。システムのライフサイクル全体では開発期間より運用期間の方が長く、累計コストも大きくなりがちです。開発契約とは別に保守契約の範囲（対応時間帯、対応範囲、改修の扱い）を確認し、開発時のドキュメントが保守に引き継げる状態かを見ておくことが、長期コストを左右します。

流れを踏まえて発注側が判断すべきこと

工程の区切りごとにレビューと承認を行う

ウォーターフォールの利点は、工程の区切りという判断のタイミングが構造的に用意されていることです。要件定義書、基本設計書といった成果物を区切りごとにレビューし、承認してから次工程へ進む規律を守ることで、手戻りの芽を早期に摘めます。レビューを形式的な儀式にせず、「この成果物で次の工程に進めるか」という問いで点検する姿勢が要ります。

発注側の関与が薄くなる中流工程こそ接点を保つ

実装からテスト前半にかけては発注側の作業が減り、プロジェクトへの関心が薄れやすい期間です。しかしこの期間に仕様の確認事項は継続的に発生し、回答の遅れはそのまま開発の遅れになります。週次の定例と課題管理表の共有を続け、質問への回答期限をルール化しておくと、中流工程の停滞を防げます。

進め方の選択：ウォーターフォールか反復型か

本記事で示した流れはウォーターフォールを基本形としていますが、要件の不確実性が高い開発では、この6段階の活動を短い反復に畳み込むアジャイル型の進め方が向く場合もあります。要件と納期が固定的なら計画駆動、探索しながら作るなら反復型、という軸で開発会社と協議してください。当社（株式会社一創）も業務システム開発において、案件の性質に合わせた進め方の設計を含め、要件定義などの上流工程から支援しています。

システム開発の流れに関するよくある質問（FAQ）

各工程の期間の配分に目安はありますか？

案件によって幅があるものの、要件定義に全体の2〜3割、設計に2割前後、実装に2〜3割、テストに2〜3割という配分が一つの目安です。実装に比べてテストの期間が極端に短い計画は、品質リスクを抱えている可能性があるため、根拠を確認することを推奨します。

要件定義の前には何をするのですか？

企画・構想フェーズとして、経営課題や業務課題の整理、システム化の目的と投資対効果の検討、予算枠の確保、RFP（提案依頼書）の作成と開発会社の選定が行われます。この段階の検討が浅いまま要件定義に入ると、目的の議論からやり直しになるため、構想段階の言語化が流れ全体の質を決めます。

工程を省略して短縮することはできますか？

活動そのものの省略は推奨できません。短縮するなら、対象範囲を絞って各工程を小さくする、優先度の低い機能を後続フェーズに回す、という範囲側の調整が健全です。特にテストと要件定義の圧縮は、稼働後の障害や手戻りという形で結局コストが返ってくる典型的な失敗パターンといえます。

ウォーターフォールでは仕様変更に対応できないのですか？

対応はできますが、変更管理の手続きを踏む必要があります。変更内容の影響（費用・期間・品質）を評価し、承認を経て計画に反映する流れです。変更が頻発することがあらかじめ見込まれるなら、変更を前提とした反復型の進め方を最初から検討する方が現実的です。

開発会社に流れを任せておけば問題ありませんか？

進行管理は開発会社が主導するとしても、要件の確定、成果物の承認、受け入れテストの実施は発注側にしか担えない役割です。工程の流れを理解したうえで、自社がいつ何を判断するのかをプロジェクト計画の段階で確認しておくことが、任せきりによる失敗を防ぐ第一歩になります。

関連記事

• システム開発とは？種類・工程・依頼方法までの全体像をわかりやすく解説
• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説
• アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説