システム開発の工程が一気にわかる｜要件定義から移行・保守まで実務目線で解説

システム開発は、いきなり設計書を書いたり、実装を始めたりするものではありません。実務では、作る前に「何をシステム化するのか」「既存業務や既存システムへどのような影響があるのか」「どれくらいの費用と期間がかかるのか」を整理します。

特に中小企業や小規模プロジェクトでは、すべての工程を重厚に進める必要はありません。一方で、工程を省略する場合でも、何を確認し、何を省略したのかを関係者が理解していることが大切です。

この記事では、小規模〜中規模のWebシステム開発でも使いやすい粒度で、システム開発の工程、主な作業、成果物例を実務目線で整理します。なお、この記事では小規模プロジェクトをおおむね5人月以下の案件として扱います。

実務寄りのシステム開発工程フロー

教科書では「要件定義、設計、製造、テスト」という流れで説明されることが多いですが、実務ではその前後にも重要な工程があります。

見積もりは工程全体の土台になる

全体工程を見る前に押さえておきたいのが、見積もりの重要性です。見積もりは金額を出すだけの作業ではなく、影響調査、要件整理、WBS、スケジュール、成果物の前提を揃える工程です。

全体工程の早見表

全体工程は、まず「何を決める工程なのか」と「どんな成果物が残るのか」で見ると理解しやすくなります。ここでは代表例に絞って整理します。

区分	工程	何を決めるか	代表的な成果物
前工程	1. システム化構想	解決する業務課題とシステム化の方向性	システム化構想書、業務課題整理表、As-Is / To-Be整理資料
前工程	2. 影響調査	既存業務・既存システム・データ・外部連携への影響	影響調査資料、既存システム調査資料、リスク一覧
前工程	3. PoC・技術検証	技術的に実現できるか、本開発に進むべきか	PoC計画書、技術検証結果報告書、採用可否判断資料
前工程	4. 見積もり	費用、工数、期間、体制、スコープ、前提条件	概算見積書、詳細見積書、前提条件一覧、工数見積表
開発工程	5. 要件定義	業務上・システム上で満たすべき条件	要件定義書、業務要件一覧、システム要件一覧、非機能要件一覧
開発工程	6. 基本設計	利用者や外部システムから見える仕様	基本設計書、画面設計書、画面遷移図、API設計概要
開発工程	7. 詳細設計	開発者が実装できる粒度の処理内容	詳細設計書、処理設計書、テーブル定義書、ログ設計
開発工程	8. 製造	設計内容をソースコードとして実装する	ソースコード、コードレビュー記録、ビルド手順、実装メモ
品質確認	9. 単体テスト	機能や処理単位で正しく動くか	単体テスト仕様書、単体テスト結果、不具合票
品質確認	10. 結合テスト	画面間、機能間、API間、外部システム間の連携	結合テスト仕様書、API連携テスト結果、不具合管理表
品質確認	11. システムテスト	システム全体として要件を満たすか	システムテスト計画書、結果報告書、性能テスト結果
後工程	12. 運用テスト	本番運用の手順で業務を回せるか	運用テスト仕様書、運用手順書、問い合わせ対応フロー
後工程	13. 本番移行（リリース）	旧環境・旧データから新環境へ安全に切り替える方法	本番移行計画書、移行手順書、切り戻し手順書、移行完了報告書
後工程	14. 保守	リリース後の安定稼働と継続改善の進め方	保守運用計画、問い合わせ管理表、改修要望一覧
後工程	15. 完了レビュー	成果、課題、残対応、次回への改善点	完了報告書、振り返り資料、残課題一覧、検収資料

工程ごとの実務ポイント早見表

各工程の詳細を文章だけで追うと長くなりやすいため、ここでは「主な作業」「成果物例」「小規模プロジェクトではどこまでやるか」を表で確認できる形にします。

前工程：作る前に失敗要因を減らす

工程	主な作業内容	成果物例	小規模PJでは
システム化構想	課題整理、As-Is / To-Be整理、対象範囲の検討、投資対効果の概算	システム化構想書、業務課題整理表、As-Is / To-Be整理資料、システム化対象範囲資料、投資対効果の概算資料	1枚の課題整理メモや簡単な図で、発注者と開発者の目的を揃えます。
影響調査	既存画面、DB、API、バッチ、外部連携、運用への影響確認	影響調査資料、既存システム調査資料、業務影響一覧、外部連携影響一覧、データ影響調査表、リスク一覧	「触る画面」「触るデータ」「影響する担当者」を表で確認します。
PoC・技術検証	検証計画、プロトタイプ作成、性能・精度・実現性評価、採用可否判断	PoC計画書、技術検証結果報告書、検証用プロトタイプ、性能・精度・実現性の評価資料、採用可否判断資料	検証項目を1〜3個に絞り、短期間で採用可否を判断します。
見積もり	対象範囲確認、工数算出、前提条件整理、スケジュール案・体制案作成	概算見積書、詳細見積書、前提条件一覧、スコープ定義、工数見積表、体制案、スケジュール案	含む作業、含まない作業、前提条件、概算工数を明記します。

開発工程：合意した内容を形にする

工程	主な作業内容	成果物例	小規模PJでは
要件定義	業務要件、システム要件、非機能要件、画面、帳票、外部インターフェース、権限の整理	要件定義書、業務要件一覧、システム要件一覧、非機能要件一覧、画面一覧、帳票一覧、外部インターフェース一覧、権限要件一覧	要件一覧、画面一覧、対応範囲メモを優先します。
基本設計	画面設計、画面遷移、機能構成、データ概要、API概要、外部連携設計、インフラ概要	基本設計書、画面設計書、画面遷移図、機能一覧、データモデル、テーブル定義の概要、API設計概要、外部連携設計、インフラ構成図、運用設計の概要	画面イメージ、画面遷移、主要項目、主要データを中心に整理します。
詳細設計	処理設計、詳細なテーブル定義、API詳細、バッチ、クラス、エラー処理、ログ設計	詳細設計書、処理設計書、詳細なテーブル定義書、API詳細設計書、バッチ設計書、クラス設計、エラーハンドリング設計、ログ設計	チケット、DB設計メモ、API設計メモで代替できる場合があります。
製造	実装、コードレビュー、単体テスト準備、ビルド手順整理、実装メモ作成	ソースコード、コードレビュー記録、単体テスト仕様書、単体テストデータ、ビルド手順、実装メモ	PR、レビュー記録、テスト観点メモを組み合わせます。

製造工程では、単体テスト仕様書を実装前に作成するか、実装後に整理するかはプロジェクト方針によって異なります。どちらの場合でも、確認すべき観点が曖昧なまま実装を進めないことが重要です。

テスト・後工程：使える状態にして定着させる

工程	主な作業内容	成果物例	小規模PJでは
単体テスト	正常系、異常系、境界値、入力チェック、修正後再テスト	単体テスト仕様書、単体テスト結果、不具合票、修正記録、再テスト結果	テスト観点表と結果を残すだけでも効果があります。
結合テスト	画面間連携、API連携、外部システム連携、データ受け渡し、不具合管理	結合テスト仕様書、結合テスト結果、API連携テスト結果、画面間連携テスト結果、外部システム連携テスト結果、不具合管理表	主要な業務フローに沿って、画面・API・データがつながることを確認します。
システムテスト	業務横断テスト、性能確認、セキュリティ確認、障害時確認	システムテスト計画書、システムテスト仕様書、システムテスト結果報告書、性能テスト結果、セキュリティ確認結果、障害対応記録	本番に近いデータや操作手順で、重要業務を優先して確認します。
運用テスト	業務シナリオ確認、運用手順確認、問い合わせ対応フロー確認、障害対応手順確認	運用テスト仕様書、運用テスト結果、業務シナリオテスト結果、運用手順書、問い合わせ対応フロー、障害対応手順書	簡単な運用手順書と問い合わせ先を整理します。
本番移行（リリース）	本番移行設計、移行手順作成、リハーサル、切り戻し準備、本番反映、完了確認	本番移行計画書、移行設計書、移行手順書、移行リハーサル結果、切り戻し手順書、本番移行作業申請書、本番移行作業エビデンス、移行完了報告書	リリース手順、移行手順、バックアップ、作業エビデンスを最低限残します。
保守	障害対応、問い合わせ対応、改修要望管理、監視、定期点検、保守報告	保守運用計画、障害対応記録、問い合わせ管理表、改修要望一覧、定期点検結果、監視設定資料、保守作業報告書	問い合わせ管理表と改修要望一覧を残すと、対応漏れを減らせます。
完了レビュー	完了報告、振り返り、残課題整理、成果物確認、検収確認、ナレッジ共有	完了報告書、振り返り資料、課題・改善点一覧、残課題一覧、ナレッジ共有資料、成果物一覧、検収資料	30分の振り返りと残課題メモだけでも十分に価値があります。

小規模プロジェクト向けの簡略版工程

5人月以下を目安とする小規模プロジェクトでは、15工程をすべて別々のフェーズとして扱うと、ドキュメント作成だけで重くなりすぎることがあります。その場合は、次のようにまとめても構いません。

この簡略版は、中小企業の小さなWebシステム開発だけでなく、SESで上流工程に関わる人や、個人事業主として受託開発を行う人にもおすすめの考え方です。工程名をシンプルにしておくと、発注者にも説明しやすく、作業範囲の合意もしやすくなります。

簡略工程	主な目的	成果物例
相談・課題整理	困りごとと対応方針を整理する	ヒアリングメモ、課題整理表、対応方針メモ
影響調査・簡易見積もり	影響範囲、費用感、期間感を確認する	簡易影響調査メモ、概算見積、スケジュール案
要件整理	対応する範囲と優先順位を決める	要件一覧、画面一覧、対応範囲メモ
設計	実装前に画面・データ・APIの考え方を揃える	簡易設計書、画面イメージ、DB設計メモ、API設計メモ
実装	合意した内容をコードにする	ソースコード、実装メモ、コードレビュー記録
テスト	利用者の操作と重要な条件で動作を確認する	テスト観点表、テスト結果、不具合一覧
リリース・本番移行	安全に本番へ反映する	リリース手順書、移行手順書、作業エビデンス
保守・改善	問い合わせや改善要望を継続的に扱う	問い合わせ管理表、改修要望一覧、保守対応記録

V字モデルとの関係

一般的なV字モデルは、「要件定義〜設計〜実装〜テスト」の対応関係を示す考え方です。ただし実務では、V字の前にシステム化構想、影響調査、PoC、見積もりがあり、V字の後に運用テスト、本番移行（リリース）、保守、完了レビューがあります。

AIを使う場合は工程ごとに分ける

生成AIを使うと、要件整理、設計、実装、テスト観点作成、ドキュメント作成を効率化できます。ただし、AIに「要件定義からテスト計画まで一気に作って」と依頼すると、細かな前提や業務上の制約が抜けることがあります。

工程ごとにAIを使うと、些細な漏れを取りこぼしにくくなり、後工程での手戻りを減らせます。AIは一括作成の道具というより、各工程のレビュー担当として使う方が実務では扱いやすいです。

実務で成果物を活かす考え方

各工程で作る成果物は、作ること自体が目的ではありません。成果物は、関係者間の認識を揃えるためにあります。

また、見積もりは一度で終わるものではありません。システム化構想の段階では概算、要件定義後は詳細見積もり、設計後はより精度の高い計画というように、工程が進むごとに精緻化されます。

PoCは本開発ではなく、判断材料を得るための検証です。本番移行（リリース）はリリース直前に考えるのではなく、設計段階から考慮すべきものです。このように、工程ごとの目的を理解しておくと、資料作成や会議の意味が見えやすくなります。

まとめ

システム開発の工程は、単に順番通りに資料を作るためのものではありません。構想、影響調査、PoC、見積もりで作るべきものを見極め、要件定義と設計で認識を揃え、製造とテストで品質を確認し、本番移行（リリース）・保守・完了レビューまで含めて業務に定着させるための流れです。

小規模プロジェクトでは、すべてを重厚に進める必要はありません。大切なのは、必要な工程を適切な粒度で実施し、省略した内容を関係者が理解していることです。

株式会社織翔では、システム化構想、業務整理、要件定義、既存システム保守、Webシステム開発、AI活用/DX支援まで、状況に応じて支援できます。まだ何を作るべきか決まっていない段階でも、課題整理から相談できます。