要件定義からテスト・移行・運用保守までの現場視点

この記事は「SE・システム開発入門」2部作の後編です。

前編では、システム開発が「プログラミングだけでは終わらない」ことを整理しています。後編では、そこからさらに実務に踏み込みます。

前編はこちらです。

要件定義、設計、開発、テスト、移行、運用保守の各工程で、初級SEがどこを見ればよいのか。そして、現場でどんな落とし穴があるのか。

教科書的な工程説明では見えにくいポイントを、現場目線で整理していきます。

ここから先では、要件定義、設計、テスト、移行、運用保守の各工程について、現場で実際につまずきやすいポイントを具体的に見ていきます。

要件定義・設計・開発の流れ
テスト・移行・運用保守の流れ
初心者SEが明日から意識すべきこと
まとめ：開発工程が見えると、SEの仕事の解像度が上がる

要件定義・設計・開発の流れ

要件定義：業務要件と非機能要件を整理する工程

要件定義は、システム開発の最初の重要工程です。

一言でいうと、そのシステムで何を実現するのかを決める工程
です。

ここで決めるのは、画面や機能だけではありません。
大きく分けると、要件には次の2種類があります。

機能要件と非機能要件です。

機能要件とは、利用者から見える機能のことです。

申請を登録できる
承認できる
差戻しできる
承認履歴を確認できる
申請一覧を検索できる

一方、非機能要件とは、システムを本番で安定して使うための要件です。

平日8時から22時まで利用できること
画面応答は原則3秒以内であること
サーバ1台の障害では業務停止しないこと
障害時は1時間以内に復旧すること
バックアップを毎日取得すること
監視アラートを運用担当に通知すること
個人情報を暗号化すること
本番移行に失敗した場合は旧システムに切り戻せること

初心者SEが誤解しやすいのは、要件定義を「お客様の要望を聞いて機能一覧を作る工程」だと思ってしまうことです。
しかし、実務ではそれだけでは不十分です。

お客様は、非機能要件を明確な言葉で言ってくれるとは限りません。
「止まらないようにしてほしい」
「早く復旧してほしい」
「普通に使える速度にしてほしい」
「安全にしてほしい」
こうした言葉を、具体的な水準に落とす必要があります。

「止まらない」とは、

サーバ1台障害でも継続するという意味なのか。
データセンター障害でも継続するという意味なのか。
「早く復旧」とは、10分以内なのか。
1時間以内なのか。
翌営業日でよいのか。
「普通に使える速度」とは、画面応答1秒以内なのか。
3秒以内なのか。
10秒でも許容されるのか。

この曖昧さを放置すると、後工程や本番稼働後に大きな問題になります。
ただし、実際のシステム開発では、要件定義でゼロから自由に要件を決めるわけではありません。

多くの案件では、事前にRFP、つまり提案依頼書が提示されます。

そこに、必要な機能、連携先、運用条件、セキュリティ要件、移行条件などがある程度書かれています。

ベンダーはそのRFPを読み、質問期間で不明点を確認し、前提条件を置いたうえで提案・見積・応札します。

その後、受注すると、RFPや提案内容を前提に、要件定義で内容を詳細化し、最終的に確定していきます。

つまり、受注後の要件定義は、完全な白紙から要件を作るというより、
RFPに書かれた内容を、設計・開発・構築・テストできるレベルまで具体化し、お客様とベンダーの認識差を潰す工程です。

ここで難しいのは、RFPの記載が必ずしも十分に具体的とは限らないことです。たとえば、RFPに次のような記載があったとします。

高い可用性を確保すること
必要なログを保管すること
既存システムと連携すること
適切なセキュリティ対策を実施すること

一見すると、それらしい記載に見えます。
しかし、これだけでは設計できません。

どこまで冗長化するのか。
ログは何年分、どのストレージに保管するのか。
外部連携では文字コード変換や異常時の再取込まで必要なのか。
セキュリティ対策の対象は新システムだけなのか、接続するゲートウェイや既存ネットワーク機器まで含むのか。

こうした点を要件定義で具体化していきます。

なお、RFPは必ずしもお客様だけで作っているとは限りません。
大規模案件では、お客様側にコンサルティング会社や外部アドバイザーが入り、RFP作成を支援していることがあります。

そのため、RFPの記載がきれいに整理されていても、実際の業務担当者や運用担当者の現場実態と完全に一致しているとは限りません。

RFPには「既存運用を踏まえる」と書かれていても、現場では月末だけ手作業で補正しているかもしれません。

「外部データを取り込む」と書かれていても、実際には文字コード変換や例外データ処理が必要かもしれません。

つまり、RFPは重要な出発点ですが、現場のすべてを表しているわけではありません。

受注後の要件定義では、RFPの記載と実際の業務・運用のズレを確認し、どこまでを今回のスコープとして扱うのかを整理する必要があります。

要件定義は、単にお客様の要望を聞いて機能一覧を作る工程ではありません。

RFP、提案内容、業務実態、運用制約をすり合わせ、後工程で設計・開発・テストできる状態に具体化する工程です。

この考え方は、要件定義編で詳しく整理しています。

要件定義編はこちらです。

基本設計・詳細設計：使える形に落とし込む工程

要件定義で方向性を決めたら、次は設計です。

基本設計では、利用者から見える仕様とシステム構成の大枠を決めます。
アプリケーション側では、画面レイアウト、入力項目、検索条件、帳票項目、メール通知、外部システム連携などを決めます。

基盤側では、Web/AP/DBをどう分けるか、サーバを何台構成にするか、ロードバランサを配置するか、DBを冗長化するか、監視対象をどうするか、バックアップ方式をどうするか、ネットワーク経路をどうするか、といったことを決めます。

この工程で大事なのは、アプリと基盤を別々に考えすぎないことです。

たとえば、アプリ側で「大量のファイルをアップロードできる機能」を作るとします。

その場合、基盤側では、ファイル保存先の容量、バックアップ対象、ウイルスチェック、アップロード時の通信量、タイムアウト値、ストレージ障害時の扱い、保管期間、削除ポリシーなどを考える必要があります。

アプリ機能の要件は、必ず基盤設計に影響します。
詳細設計では、実際に開発・構築できるレベルまで具体化します。

アプリ側では、処理ロジック、SQL、API、エラー処理、データ更新条件などを決めます。

基盤側では、サーバ名、IPアドレス、CPU、メモリ、ディスク構成、OS設定、ミドルウェア設定、DBパラメータ、ジョブスケジュール、監視閾値、ログ出力先、バックアップ取得時刻、リストア手順、ファイアウォールルールなどを決めます。

初心者SEに知っておいてほしいのは、詳細設計で出てくる論点が、単なる技術設定では終わらないことです。

たとえば、ログ保存期間を決める場合、単にディスク容量の話ではありません。

監査で何年分必要なのか。
障害調査で何日分あればよいのか。
オンラインで即時検索できる必要があるのか。
一定期間を過ぎたら安価なストレージへ退避してよいのか。

こうした前提によって、必要なディスク容量、ストレージ性能、バックアップ容量、運用コストは大きく変わります。

特に、高速ディスクに大量のログを長期間保持する設計にすると、コストは一気に跳ねます。

そのため、ログ保存期間や監査証跡の保管要件は、詳細設計で初めて決める話ではありません。本来は、RFPへの質問、提案時の見積前提、要件定義で明確にしておくべき内容です。

RFPに「必要なログを保管すること」とだけ書かれている場合は危険です。

必要とは何か。
何日分なのか。
何年分なのか。
オンライン保管なのか。
アーカイブ保管でよいのか。
改ざん防止まで必要なのか。

ここを曖昧にしたまま進めると、後から「監査で7年分必要だった」「検索できる状態で残してほしい」と言われ、容量・性能・コストの前提が崩れることがあります。

基盤設計も、業務と無関係ではありません。

開発・構築：アプリとインフラを形にする工程

開発工程では、アプリケーションを作ります。

画面、業務ロジック、API、バッチ、SQLなどを実装します。
一方、基盤側では、設計書に基づいてインフラ環境を構築します。

サーバ構築
OS設定
ミドルウェア導入
DB構築
ネットワーク設定
ロードバランサ設定
監視設定
バックアップ設定
ジョブ設定
セキュリティ設定

ここで重要なのは、アプリと基盤の構築タイミングを合わせることです。
アプリが動くには、基盤が必要です。
基盤のテストをするには、アプリや疑似アプリが必要になることもあります。

さらに現場では、アプリと基盤の間で多くの調整が発生します。

接続先URL、ポート番号、タイムアウト値、ファイル配置先、DB接続設定、ジョブ起動時刻、ログ出力先、文字コードなど、一見すると小さなパラメータ変更でも、アプリ、基盤、DB、ネットワーク、運用、外部システムに影響することがあります。

そのため、仕様変更や設定変更が発生した場合は、影響調査を行い、関係チームに確認し、必要に応じて変更管理の場で承認を取ります。

「このくらいなら影響ないだろう」と勝手に変更すると、後から他チームのテスト前提が崩れたり、凍結した仕様と違っていたりして、大きな手戻りになることがあります。

システム開発では、作る技術だけでなく、変更を管理するプロセスも非常に重要です。

テスト・移行・運用保守の流れ

テスト：業務機能と本番運用の両面から確認する工程

テスト工程は、システム開発の中でも非常に重要です。
初心者は、テストを「バグを見つける作業」と思いがちです。
もちろん、それもあります。

しかし、テストの本質は、作ったシステムが本番で使える状態になっているかを確認することです。

テストには、単体テスト、結合テスト、システムテスト、性能テスト、障害復旧テスト、運用テスト、移行テストなどがあります。
プロジェクトによって呼び方や切り分けは異なります。

ただし、初心者SEはまず、以下二つの観点があることを理解しておくとよいです。

機能が動くかを見るテスト
本番で運用できるか、すなわち手順と手続きを見るテスト

アプリ側のテストでは、申請できるか、承認できるか、差戻しできるか、検索できるか、帳票が出るかといった機能を確認します。

一方、基盤側のテストでは、本番運用に必要な品質を確認します。

本番相当のデータ量で性能が出るか
ピーク時のアクセスに耐えられるか
サーバ障害時に片系で業務継続できるか
DB障害時に復旧できるか
バッチ異常終了後にリスタートできるか
バックアップからリストアできるか
監視アラートが正しく通知されるか
運用手順書どおりに対応できるか

ここで重要なのは、システムテストは、単なる業務シナリオ確認だけではないということです。

申請、承認、差戻しといった業務の流れを確認することも大切です。

しかし同時に、本番運用に耐えられるかを確認する必要があります。
特にインフラエンジニアの視点では、正常時よりも異常時が重要です。

「壊れないか」ではなく、
「壊れたときにどうなるか」

を確認します。

サーバが1台落ちたらどうなるか。
DB接続が切れたらどうなるか。
ジョブが途中で異常終了したらどう再開するか。
バックアップから戻したときに業務データは整合するか。
切り戻しが必要になったときに旧システムへ戻れるか。

ここまで確認して初めて、本番で使えるシステムに近づきます。

運用テスト：手順書と運用ワークフローが本当に回るかを確認する

テストの中で、初心者が見落としやすいものに運用テストがあります。

運用テストとは、簡単に言えば、本番稼働後の運用作業と運用手続きが、手順書や運用ルールどおりに本当に回るかを確認するテストです。

運用というと、サーバにログインしてコマンドを実行する、ジョブを起動する、ログを確認する、といった作業を思い浮かべるかもしれません。

しかし実際の運用では、その前後に、作業申請、承認、関係者への連絡、実施可否の判断、作業記録、証跡取得、異常時のエスカレーションといった手続きが発生します。

機能そのものは、単体テスト、結合テスト、システムテストの業務シナリオ確認で一通り確認済みであることが前提です。

そのうえで、運用テストでは次のようなことを確認します。

日次ジョブが決められた順番で起動するか
月次処理が前提データを取り込んだ状態で実行できるか
年次処理が手順書どおりに実行できるか
外部システムから受領するデータを取り込めるか
ジョブが異常終了したときに運用担当者が検知できるか
異常終了後、どこからリスタートすればよいか手順化されているか
ログやメッセージを見て一次切り分けできるか
監視アラートが正しい宛先に通知されるか
バックアップ取得、リストア、退避、削除などの手順が実行できるか
定常作業や臨時作業の申請・承認フローが定義どおりに回るか
作業実施前に、関係者への連絡や作業可否判断ができるか
作業結果、確認結果、証跡を所定の形式で記録できるか
異常時に、一次対応者から二次対応者、主管部門、顧客担当者へエスカレーションできるか
夜間・休日など、通常体制と異なる時間帯でも連絡・承認・判断の流れが成立するか

たとえば、外部システムから月1回データを受領し、それを夜間バッチで取り込む運用があるとします。
この場合、単に「取込ジョブが動くか」だけを確認しても不十分です。

外部システム側の処理が完了している
取込対象ファイルが所定の場所に配置されている
ファイル件数やフォーマットを確認する
取込ジョブを起動する
取込結果をログで確認する
後続ジョブが起動する
異常があれば運用担当者が検知し、手順書に沿って対応する

運用テストでは、この一連の流れを、できるだけ本番運用に近い形で確認します。

特にジョブネットがあるシステムでは、日次、月次、年次の運用を疑似的に流してみることが重要です。

個別のジョブが正常に動いても、前提条件や順序、外部データの到着タイミング、異常時のリカバリ手順が曖昧だと、本番運用で詰まります。

運用テストを軽視すると、本番稼働後に「機能は動くが、運用が回らない」という状態になります。

移行：旧システムから新システムへ切り替える工程

移行は、初心者が見落としやすいですが、非常に重要な工程です。

移行とは、旧システムや既存業務から、新システムへ切り替えることです。

新しいシステムを作ったとしても、いきなり本番利用できるわけではありません。

旧システムのデータを移す
ユーザー情報を登録する
権限を設定する
外部システムとの接続を切り替える
DNSやネットワーク経路を切り替える
ジョブスケジュールを有効化する
監視を開始する
旧システムを停止する
問い合わせ窓口を切り替える

こうした作業が必要です。
移行で怖いのは、失敗したときに業務影響が大きいことです。

データ移行に想定以上の時間がかかる
移行後の件数が合わない
文字化けする
権限設定が誤っている
外部連携がつながらない
新システムに切り替えたが重大障害が見つかる
切り戻し手順が不十分で旧システムに戻せない

こうなると、本番切替は大きなトラブルになります。
さらに、移行で怖いのは、既存システムのデータが必ずしもきれいではないことです。

実際の現場では、古いシステムの日付項目に「昭和70年」のような存在しない日付が入っていた、ということもあります。

普通に考えればおかしな値です。

しかし、古いシステムでは入力できてしまっていたり、過去の運用上の都合でそのまま残っていたりします。

新システム側では、そのような値を想定していないため、移行時にエラーになります。移行前にデータ補正するのか、一時的な変換ルールを作るのか、移行対象外にするのかを、お客様である業務担当者と決める必要があります。

こうした問題は、本番移行当日に見つかると非常に危険です。

そのため、移行では事前にチェックリストを作り、存在しない日付、必須項目の空欄、コード値の不整合、桁数オーバー、文字化け、移行前後の件数・金額差異などを確認しておくことが重要です。

移行は、単にデータをコピーする作業ではありません。旧システムに残っている過去の運用、例外データ、入力ミス、暫定対応をどう扱うかを決める作業です。

だからこそ、移行工程では「設計上どうなっているか」だけでなく、実データがどうなっているかを見ることが重要です。

本番稼働と運用保守：リリースして終わりではない

本番稼働とは、新システムを実際の業務で使い始めることです。

初心者は、本番リリースをゴールだと思いがちです。

しかし、現場感覚では、リリースはゴールではありません。むしろ、ここからが本番です。

本番環境では、テスト環境では起きなかったことが起きます。

想定より多くの利用者がアクセスする
利用者が想定外の操作をする
データ量が想定より多い
外部システムの応答が遅い
監視アラートが多発する
バッチ処理が想定より長くかかる
権限設定ミスが見つかる
問い合わせが集中する

そのため、本番稼働直後は初期流動期間として、通常より厚めの体制で監視・問い合わせ対応・障害対応を行うことがあります。

そして、本番稼働後は運用保守が始まります。
運用保守とは、システムを安定して使い続けるための活動です。

障害対応
問い合わせ対応
監視
バックアップ確認
ジョブ確認
パッチ適用
証明書更新
権限変更
データ補正
性能監視
小規模改修
セキュリティ対応

運用保守では、日々の監視や障害対応だけでなく、定期的に運用報告会を行うこともあります。

月次や週次で、システム稼働率、障害件数、アラート件数、バックアップ結果、ジョブ実行結果、外部データ取込状況、CPU・メモリ・ディスク使用率、問い合わせ件数などをお客様へ報告します。

そのため、運用担当は監視ログ、ジョブ結果、障害対応記録、問い合わせ履歴、リソース使用状況などを集計し、報告資料や運用帳票を作成します。

システムは安定して動いていても、「問題ありませんでした」と口で言うだけでは不十分です。

SLAを満たしているか。
障害通知が何件あり、そのうち本当の障害は何件だったのか。
バックアップや外部データ取込は正常に完了しているのか。
リソース使用率に増加傾向はないのか。

こうした内容を数字で示す必要があります。

つまり、運用保守では、システムを動かすだけでなく、問題なく動いていることを証明することも重要な仕事になります。

また、運用保守ではキャパシティ管理も重要です。

キャパシティ管理とは、CPU、メモリ、ディスク、ネットワーク、DB接続数などの利用状況を継続的に見て、システムに必要なリソースが足りているか、または過剰になっていないかを確認することです。

オンプレミス環境では、一度サーバを購入すると簡単には増減できませんでした。そのため、将来の利用増加を見込んで、ある程度余裕を持ったサイジングをすることが一般的でした。

一方、クラウドでは考え方が少し変わります。

AWS上でEC2を使っている場合、CPU使用率が常に低く、メモリにも大きな余裕があり、夜間や休日はほとんど使われていないのであれば、

次回の更改や見直しタイミングでインスタンスタイプを下げる、台数を減らす、スケジュール停止を検討する、といった選択肢があります。

逆に、ピーク時間帯にCPUやメモリが逼迫しているなら、インスタンスタイプを上げる、台数を増やす、オートスケールを検討する、DBやストレージのボトルネックを確認する、といった対応が必要になります。

運用保守は障害対応だけではありません。

安定して動かす
障害時に復旧できる
将来の利用増加に備える
必要以上にコストをかけすぎていないかを見直す
問題なく動いていることをお客様に説明できる状態にする

これらも含めて、運用保守は設計品質の答え合わせであり、同時にシステムを継続的に改善していく活動です。

初心者SEが明日から意識すべきこと

初心者SEが現場でまず意識すべきことは、次の3つです。

1. 今の工程を確認する

自分のプロジェクトが、今どの工程にいるのかを確認してください。
要件定義なのか。
基本設計なのか。
詳細設計なのか。
構築なのか。
テストなのか。
移行なのか。
本番稼働後なのか。
工程によって、重視すべきことは変わります。
まずは、自分が今どこにいるのかを意識するだけで、会議や資料の見え方が変わります。

2. アプリと基盤の両方を見る

画面や機能だけでなく、その裏側も見る癖をつけてください。
この機能は、どのDBを使うのか。
どれくらいのデータ量になるのか。
障害時にどう復旧するのか。
ログは出るのか。
監視できるのか。
バックアップ対象なのか。
運用担当者は対応できるのか。
この視点を持つだけで、システムの見え方が変わります。
アプリケーションとシステム基盤は別々のものではありません。
アプリの要件は、基盤設計に影響します。
基盤の制約は、アプリの作り方に影響します。
この関係が見えるようになると、SEとしての理解は一段深くなります。

3. 「本番で使えるか」を考える

開発中は、どうしても「動くか」に注目しがちです。

しかし、現場で重要なのは、本番で使えるかです。

本番で使えるとは、次のような状態です。

利用者が業務時間中に使える
必要な速度で動く
障害時に復旧できる
データを守れる
運用担当が対応できる
セキュリティリスクが抑えられている
将来の変更に耐えられる

「機能が動くか」だけでなく、「本番で安心して使えるか」
を見る。

これが、システム開発を理解するうえで非常に大切な考え方です。

まとめ：開発工程が見えると、SEの仕事の解像度が上がる

この記事では、システム開発の全体像を整理しました。

システム開発は、プログラミングだけではありません。
要件定義で何を作るかを決め、設計で具体化し、開発・構築で形にし、テストで確認し、移行で本番へ切り替え、運用保守で安定稼働を続けます。

そして、その流れの中では、アプリケーション開発とシステム基盤構築が並行して進みます。利用者から見える画面や機能だけでなく、サーバ、DB、ネットワーク、監視、バックアップ、セキュリティ、性能、障害復旧、移行まで含めて、システム開発です。

この全体像が見えるようになると、SEの仕事の解像度は一気に上がります。

会議で話されていること。
設計書に書かれていること。
テストで確認していること。
移行で慎重になる理由。
本番稼働後に監視する理由。

それぞれが、一本の線でつながって見えるようになります。
最初からすべてを理解する必要はありません。

まずは、システム開発はプログラミングだけでは終わらない
ということを理解してください。

そして、機能が動くことと、本番で使えることは違うという視点を持ってください。

それだけでも、システム開発の見え方は大きく変わります。