はじめに
システム開発は、要件定義、設計、開発・構築、テスト、移行、運用保守といった工程に分けて進みます。
工程表だけを見ると、それぞれが順番に並んだ独立した作業のように見えるかもしれません。
実際のプロジェクトでは、そうではありません。
要件定義で曖昧なまま残した条件は、設計で判断に迷います。設計で見落とした条件は、テストで問題として表面化します。移行や運用を十分に考えずに作ったシステムは、本番切替や稼働後に手戻りを生みます。
前工程で何を決めたかが、次工程の前提条件になります。
この記事では、要件定義で何を決め、それを基本設計・詳細設計へどう落とし込み、開発・構築したシステムをどのようにテストし、本番へ移行して運用につなげるのかを整理します。
工程の名前を覚えることが目的ではありません。前工程の判断が次工程へどう引き継がれ、どこで認識差や設計漏れが手戻りにつながるのかを、アプリケーションとシステム基盤の両面から見ていきます。
システム開発を、プログラミングだけでなくアプリケーション、システム基盤、非機能まで含めた全体像から整理したい方は、以下の記事も参考にしてください。
要件定義・設計・開発の流れ
要件定義：何を実現し、どの水準で成立させるかを決める
要件定義は、システムで何を実現するのかを具体化し、後続の設計・開発・構築・テストができる状態にする工程です。
ここで決めるのは、画面や業務機能だけではありません。要件は大きく、機能要件と非機能要件に分けて考えます。
機能要件は、利用者から見えるシステムの機能です。
- 申請を登録できる
- 承認・差戻しができる
- 承認履歴を確認できる
- 申請一覧を検索できる
非機能要件は、その機能を本番環境で継続して使うための条件です。
- 平日8時から22時まで利用できる
- 画面応答を原則3秒以内とする
- サーバ1台の障害では業務を停止させない
- 障害発生後1時間以内に復旧する
- バックアップを毎日取得する
- 監視アラートを運用担当へ通知する
- 個人情報を暗号化する
- 本番移行に失敗した場合は旧システムへ切り戻せる
要件定義で注意したいのは、「お客様の要望を聞いて機能一覧を作れば終わり」と考えないことです。
実際の利用部門から出てくるのは、「止まらないようにしてほしい」「普通に使える速度にしてほしい」「障害時は早く戻してほしい」「安全なシステムにしてほしい」といった言葉であることも少なくありません。
これだけでは設計できません。
「止まらない」とは、サーバ1台の障害までなのか、拠点やAZ単位の障害まで考えるのか。「早く復旧」とは10分なのか1時間なのか。「普通の速度」とは画面応答1秒なのか3秒なのか。
曖昧な要求を、設計・試験で確認できる具体的な水準へ落とすことが要件定義です。
ここを曖昧なまま進めると、設計工程だけでなく、テストや本番稼働後まで影響が残ります。
要件定義は白紙から始まるとは限らない
実際のシステム開発では、受注後にゼロから自由に要件を考える案件ばかりではありません。
特に大規模案件では、事前にRFP（提案依頼書）が提示され、必要な機能、外部連携、性能、運用、セキュリティ、移行などの条件がある程度示されています。
ベンダーはRFPを読み、不明点を質問し、必要に応じて前提条件を置いたうえで提案・見積を行います。受注後の要件定義では、それらを起点として、設計・開発できる粒度まで内容を具体化していきます。
たとえばRFPに、次のような記載があったとします。
- 高い可用性を確保すること
- 必要なログを保管すること
- 既存システムと連携すること
- 適切なセキュリティ対策を実施すること
一見すると要件らしく見えますが、このままでは設計できません。
どこまで冗長化するのか。ログを何年間、どこへ保存するのか。外部連携で文字コード変換や異常データの再取込まで必要なのか。セキュリティ対策の対象範囲をどこまで含めるのか。
こうした条件を具体化し、発注者と受注者の認識を合わせていきます。
RFPだけでは現場の実態まで分からない
RFPは重要な出発点ですが、そこに業務や運用のすべてが書かれているとは限りません。
大規模案件では、コンサルティング会社や外部アドバイザーがRFP作成を支援することもあります。文書としてきれいに整理されていても、実際の業務担当者や運用担当者が行っている作業まで完全に反映されているとは限りません。
「既存運用を踏襲する」と書かれていても、月末だけ手作業でデータを補正しているかもしれません。「外部データを取り込む」と書かれていても、実際には文字コード変換、例外データの補正、再取込が必要かもしれません。
要件定義では、RFP、提案内容、見積前提、実際の業務・運用をすり合わせ、後工程で「聞いていない」「想定していなかった」をできるだけ残さない状態まで具体化します。
要件定義の進め方や、RFP・質問回答・提案内容・見積前提との関係については、以下の記事で詳しく整理しています。
基本設計・詳細設計：要件を実装できる形へ落とし込む
要件定義で確定した内容を、実際に作れる形へ変換するのが設計工程です。
基本設計では、利用者から見える仕様とシステム構成の大枠を決めます。
アプリケーション側では、画面レイアウト、入力項目、検索条件、帳票、メール通知、外部システム連携などを設計します。システム基盤側では、Web/AP/DBをどう構成するか、サーバを何台にするか、どこを冗長化するか、ネットワークをどう接続するか、監視やバックアップをどう実現するかといった全体構成を決めます。
ここで重要なのは、アプリケーションとシステム基盤を別々に設計しすぎないことです。
たとえば、「大量のファイルをアップロードできる」という機能を追加するとします。
アプリケーション側ではアップロード処理を実装すれば終わりに見えますが、システム基盤側では、ファイル保存先の容量、通信量、タイムアウト、ウイルスチェック、バックアップ、保管期間、削除方法、ストレージ障害時の扱いまで検討する必要があります。
アプリケーションの要件は基盤設計に影響し、基盤側の制約もアプリケーション設計に影響します。
詳細設計では、基本設計で決めた方針を、実際に開発・構築・テストできる粒度まで具体化します。
アプリケーション側なら、処理ロジック、SQL、API、エラー処理、データ更新条件などです。システム基盤側なら、サーバ名、IPアドレス、CPU、メモリ、ディスク構成、OS設定、ミドルウェア設定、DBパラメータ、ジョブスケジュール、監視閾値、ログ出力先、バックアップ取得時刻、ファイアウォールルールなどに落とし込みます。
詳細設計で初めて決めてはいけないこともある
詳細設計で具体的な値を決めるからといって、その前提条件まで詳細設計で決めればよいわけではありません。
たとえば、ログの保管を考えます。
監査のために7年間必要なのか、障害調査用として数か月あればよいのか。すべてオンラインで検索できる必要があるのか、一定期間を過ぎたら安価なストレージへ退避できるのか。改ざん防止まで求められるのか。
この違いによって、必要なディスク容量、ストレージ性能、バックアップ容量、運用方法、コストは大きく変わります。
RFPに「必要なログを保管すること」とだけ書かれた状態で詳細設計まで進み、後から「監査で7年間必要だった」「すべて検索できる状態で残してほしい」と判明すれば、容量やコストの前提が崩れます。
詳細設計で決めるのは実装値です。その値を決めるための業務要件や非機能要件は、上流工程で明確にしておく必要があります。
基本設計については、以下の記事で詳しく整理しています。
開発・構築：アプリと基盤を同じゴールへ向けて形にする
設計が固まると、アプリケーション開発とシステム基盤の構築が進みます。
アプリケーション側では、画面、業務ロジック、API、バッチ、SQLなどを実装します。システム基盤側では、設計書に基づいてサーバ、OS、ミドルウェア、DB、ネットワーク、ロードバランサ、監視、バックアップ、ジョブ、セキュリティなどを構築します。
両者は別チームで進むことが多いものの、独立しているわけではありません。アプリケーションが動くためには基盤が必要で、基盤側の結合試験や性能試験には、アプリケーションや疑似アプリケーションが必要になる場合があります。
図 システム開発フローの全体像
アプリケーション側とシステム基盤側では、担当する領域や成果物は異なります。各エンジニアが設計・構築・テストでどのような役割を担うのかについては、以下の記事で詳しく整理しています。
システム開発では、接続先URL、ポート番号、タイムアウト値、ファイル配置先、DB接続情報、ジョブ起動時刻、ログ出力先、文字コードなど、アプリケーションと基盤の境界に多くの調整事項があります。
こうした値を「少し変えるだけ」と考えるのは危険です。
1つの変更が、アプリケーション、基盤、DB、ネットワーク、運用、外部システムのテスト前提に影響することがあります。
仕様や設定を変更するときは、影響範囲を確認し、関係チームと認識を合わせ、必要に応じて変更管理のプロセスを通します。
システム開発では、作る技術だけでなく、変更を管理することも品質を守る仕事です。
テスト・移行・運用保守の流れ
テスト：動くことではなく、本番で使えることを確認する
テストは「バグを見つける作業」だけではありません。
作ったシステムが、要件どおりに動き、本番環境で業務に使える状態になっていることを確認する工程です。
プロジェクトによって名称や切り分けは異なりますが、単体テスト、結合テスト、システムテスト、性能テスト、障害復旧テスト、運用テスト、移行テストなどがあります。
テストでは、まず次の2つの観点を押さえます。
- 機能が正しく動くか
- 本番環境で継続して運用できるか
アプリケーション側では、申請、承認、差戻し、検索、帳票出力などの業務機能を確認します。
システム基盤・非機能の観点では、本番相当のデータ量で性能が出るか、アクセス集中に耐えられるか、サーバ障害時にも業務を継続できるか、DB障害から復旧できるか、バックアップからリストアできるか、監視やジョブの異常を検知して対応できるかを確認します。
特に重要なのは、正常時だけを確認しないことです。
サーバが1台停止したらどうなるのか。DBとの接続が切れたらどうなるのか。夜間ジョブが途中で異常終了したらどこから再開するのか。バックアップから戻したデータの整合性は保たれるのか。
「壊れないか」だけでなく、「壊れたときにどうなるか」を確認することが、本番運用を想定したテストです。
設計とテストの対応関係については、以下の記事で詳しく整理しています。
運用テスト：手順書と運用ワークフローが本当に回るかを確認する
運用テストは、本番稼働後の作業や手続きが、設計したとおりに実行できるかを確認するテストです。
運用というと、サーバへログインしてコマンドを実行する、ジョブを起動する、ログを見る、といった技術作業を想像しやすいかもしれません。
実際の運用では、その前後に作業申請、承認、関係者への連絡、実施可否判断、証跡取得、異常時のエスカレーションなどがあります。
運用テストでは、たとえば次のような観点を確認します。
- 日次・月次・年次ジョブが前提条件と順序を含めて実行できるか
- 外部システムから受領したデータを所定の手順で取り込めるか
- ジョブ異常や監視アラートを運用担当者が検知し、一次切り分けできるか
- 異常終了後のリスタートポイントと復旧手順が決まっているか
- バックアップ取得だけでなく、実際にリストアできるか
- 定常・臨時作業の申請、承認、実施、証跡取得まで流れるか
- 障害時のエスカレーション先と判断者が明確になっているか
- 夜間・休日でも連絡・承認・判断の流れが成立するか
たとえば、外部システムから月1回ファイルを受領し、夜間バッチで取り込む業務を考えます。
「取込ジョブが正常終了する」だけでは、運用テストとして十分ではありません。
外部システム側の処理完了を確認し、対象ファイルの到着と件数・形式を確認し、取込ジョブを起動する。結果を確認して後続処理へつなぎ、異常があれば運用担当者が検知して復旧する。
個々の機能が動くだけでなく、その前後を含めた一連の運用が成立するかを確認します。
特にジョブネットがあるシステムでは、日次、月次、年次の運用を疑似的に流し、処理順序や前提条件、異常時の復旧まで確認することが重要です。
運用テストを軽視すると、本番稼働後に「システムは動いているのに、運用が回らない」という問題が起きます。
運用テストで確認する内容は、テスト工程になってから考えるものではありません。ジョブ管理、監視、ログ、バックアップ・リストア、起動停止、開局・閉塞、運用日付管理など、本番稼働後にどう運用するかを事前に設計しているからこそ、運用テストで成立性を確認できます。
運用設計で検討する項目や、運用設計書の構成については、以下の記事で目次サンプルとともに整理しています。
移行：新システムへ切り替えるだけではない
移行は、旧システムから新システムへデータをコピーするだけの工程ではありません。
本番切替では、データ移行以外にも多くの作業を決められた時間内に実施します。
- 旧システムのデータを新システムへ移行する
- ユーザー情報を登録・移行する
- 権限を設定する
- 外部システムとの接続先を切り替える
- DNSやネットワーク経路を切り替える
- ジョブを有効化する
- 監視を開始する
- 旧システムを停止する
- 問い合わせ窓口や運用体制を新システムへ切り替える
移行の難しさは、こうした複数の作業を限られた時間で連携させる必要があり、失敗した場合の業務影響も大きいことにあります。
たとえば、次のような問題が起こります。
- データ移行に想定以上の時間がかかる
- 移行前後で件数や金額が一致しない
- 文字化けやコード変換の問題が発生する
- ユーザーや権限が正しく移行されていない
- 外部システムとの接続が切り替わらない
- 新システムで重大障害が見つかる
- 切り戻し手順が成立しない
移行では、旧システムに蓄積されたデータそのものも大きなリスクになります。
実際の現場では、古いシステムの日付項目に「昭和70年」のような存在しない日付が残っていることもあります。旧システムでは登録できていた値でも、新システムの入力チェックやDB制約では受け付けられないことがあります。
この場合、移行前にデータを補正するのか、変換ルールを設けるのか、移行対象外にするのかを業務担当者と決めなければなりません。
本番移行当日に初めて見つけるのでは遅いため、事前に実データを確認し、存在しない日付、必須項目の空欄、コード値の不整合、桁数オーバー、文字化け、移行前後の件数・金額差異などを洗い出します。
移行とは、旧システムに残っている過去の運用、例外データ、入力ミス、暫定対応を、新システムでどう扱うかまで決める工程です。
設計書だけでなく、実際のデータを見る必要があります。
本番稼働・運用保守：リリース後に設計の結果が見える
本番リリースは開発プロジェクトの大きな節目ですが、システムそのものにとっては運用の開始点です。
本番環境では、テスト環境では再現できなかったことが起きます。想定以上の利用者がアクセスする、データ量が増える、外部システムの応答が遅れる、監視アラートが多発する、夜間バッチが長時間化するといった事象です。
本番稼働直後には初期流動期間を設け、通常より厚い体制で監視、問い合わせ、障害対応を行うことがあります。
その後は運用保守へ移ります。
運用保守では、障害対応、問い合わせ対応、監視、バックアップ・ジョブ確認、パッチ適用、証明書更新、権限変更、性能監視、セキュリティ対応、小規模改修などを継続して行います。
「問題なく動いている」ことを説明できるようにする
運用では、単にシステムが停止していなければよいわけではありません。
月次や週次の運用報告では、システム稼働率、障害件数、アラート件数、バックアップ結果、ジョブ結果、外部データ取込状況、CPU・メモリ・ディスク使用率、問い合わせ件数などを確認します。
「今月も問題ありませんでした」と口頭で伝えるだけではなく、SLAを満たしていることや、システムが正常に運用されていることを数字と記録で示す必要があります。
運用保守には、システムを動かすだけでなく、正常に動いていることを説明できる状態を維持する役割もあります。
キャパシティ管理で将来の変化を見る
運用中は、CPU、メモリ、ディスク、ネットワーク、DB接続数などの利用状況を継続的に確認します。
リソース使用率が増え続けていれば、将来的な性能不足を予測して増強を検討します。クラウド環境でCPUやメモリが長期間ほとんど使われていないのであれば、インスタンスタイプや台数、稼働時間を見直す余地があります。
本番運用で得られた実績は、次の更改や設計変更の重要な入力情報になります。
運用保守は設計品質の答え合わせであり、同時にシステムを継続的に改善していく工程です。
工程をまたいで見るための3つの視点
ここまで各工程を見てきましたが、個々の作業だけを覚えても、プロジェクト全体の動きは見えにくいままです。
工程同士のつながりを見るために、次の3つを意識すると整理しやすくなります。
1. 今どの工程で、何を決めるべきかを見る
要件定義、基本設計、詳細設計、構築、テスト、移行、運用では、判断すべき内容が違います。
会議や設計書を見るときに、「これはどの工程で、何を決めるための話なのか」を意識すると、プロジェクト全体の中で自分の作業を位置づけやすくなります。
2. 自分の担当領域だけで完結させない
アプリケーションの要件は基盤へ影響し、基盤の制約はアプリケーションへ影響します。DB、ネットワーク、運用、外部システムも同じです。
すべての専門技術を自分で実装できる必要はありません。
重要なのは、自分の設計や変更が、隣の領域に何を要求するのかを見ることです。
3. 「動くか」ではなく「本番で使えるか」を考える
機能が動いても、性能が出ない、障害から復旧できない、バックアップから戻せない、運用担当者が対応できないのであれば、本番システムとしては不十分です。
設計やテストで迷ったときは、
「この状態で実際の業務を継続できるか」
と考えると、見るべき論点が見えやすくなります。
まとめ：工程をまたいで見ると、手戻りが起きる理由が分かる
システム開発は、要件定義、設計、開発・構築、テスト、移行、運用保守という工程に分けて進みます。
各工程が独立しているわけではありません。
要件定義で曖昧だった条件は設計で判断に迷い、設計で残した抜けはテストで不具合や手戻りとして表面化します。移行や運用を十分に考えずに作ったシステムは、本番切替や稼働後に問題を残します。
逆に、前工程で決めた内容が次の工程へ正しく引き継がれ、アプリケーション、システム基盤、DB、ネットワーク、運用などの各領域がつながっていれば、問題を早い段階で見つけやすくなります。
すべての技術を一人で深く理解する必要はありません。
まずは、いま何を決めているのか、その判断が次の工程や別の担当領域にどう影響するのかを見ることが重要です。
工程同士のつながりが見えるようになると、会議、設計書、テスト、移行、運用で行っていることが一本の線としてつながります。
それが、システム開発を「自分の担当作業」ではなく、プロジェクト全体として理解するための土台になります。
関連記事
システム開発の各工程や設計・テスト・運用に関する記事は、以下のカテゴリにまとめています。
システム開発に関する開発プロセス、プロジェクトマネージメントの解説
コメント