サーバーリプレースで、一番削られやすいのがテストです。
そして、一番削ってはいけないのもテストです。
私はこれまで、何度もリプレース案件に関わってきました。うまくいった案件と、そうでなかった案件。その差はどこにあったかというと、ほとんどがテストの質でした。
正直に言うと、私も若いころは「動いたからOK」で済ませていました。サービスが起動して、画面が開けば大丈夫だろうと。
でも、それで痛い目を見ました。移行の翌月、月次バッチが動かない。連携先から「データが来ていない」と連絡が入る——テストしていない部分は、必ずどこかで露呈します。
今回は、現場で実際に確認しているテスト項目を、区分ごとに一覧でまとめます。チェックリストとして使ってもらえる形にしました。
リプレース全体の進め方については、別記事にまとめています。合わせて読むと流れがつかめると思います。
なぜ、テストは削られてしまうのか
項目の前に、構造の話を少しだけ。
テストが削られる理由は、だいたい決まっています。
1. スケジュールが押している
構築や移行準備が遅れると、しわ寄せが最後のテストに来ます。「テストは削れる」と思われやすいからです。
2. 効果が見えにくい
テストをしっかりやっても、何も起きなければ「無事に終わった」で終わります。やった価値が見えない作業なんです。
3. 見積の段階で工数を取っていない
これが根本原因です。最初から工数に入っていなければ、後から確保するのは不可能に近い。
だから対策も逆算になります。見積の段階でテスト工数を明示的に確保しておく。これしかありません。この話は最後にもう一度書きます。
テスト区分の全体像
リプレースのテストは、大きく6つに分けて考えると漏れがなくなります。
- 単体テスト — 単体で正しく動くか
- 連携テスト — 他システムとつながるか
- バッチ・定期処理テスト — 決まった時刻に動くか
- 性能テスト — 負荷に耐えられるか
- 障害テスト — 異常時に想定通り動くか
- 運用テスト — 運用作業が回るか
多くの現場で抜けやすいのが、3のバッチ・定期処理と6の運用テストです。ここが後から問題になります。
以下、区分ごとに具体的な項目を挙げていきます。
①単体テスト：まず単体で動くか
一番基本の部分です。ここは比較的抜けにくいですが、一覧にしておきます。
確認項目
- OSが正常に起動する
- 各サービス・プロセスが自動起動する
- サービスの起動順序が正しい
- アプリケーションが正常に動作する
- ログが正しい場所に出力されている
- ログローテーションが機能する
- ディスク容量、パーティション構成が想定通り
- 時刻同期（NTP）が正常
- ホスト名、IPアドレス、DNS設定が正しい
見落としやすいのは「自動起動」です。手動で起動したら動いた、で終わらせず、サーバーを再起動して確認すること。本番で再起動がかかったとき、サービスが上がってこないのが一番怖いです。
②連携テスト：他システムとつながるか
単体で動いても、つながらなければ意味がありません。ここが一番重要な区分です。
確認項目
- 接続先システムへの疎通（送信方向）
- 接続元システムからの疎通（受信方向）
- ファイアウォール・セキュリティグループの穴あけ
- 認証情報（アカウント、証明書、APIキー）が有効
- 名前解決（DNS、hostsファイル）
- 通信の暗号化設定（TLSバージョンなど）
- ファイル転送（FTP、SFTP、共有フォルダ）
- データベース接続
- 監視サーバーからの監視が正常に動作する
- メール送信（アラート通知含む）
双方向で確認するのがポイントです。こちらから送れても、向こうから来ない、というケースがあります。
そして忘れやすいのが監視の疎通です。移行後に監視が止まっていて、障害に気づけなかった——これは実際によくある事故です。
③バッチ・定期処理テスト：決まった時刻に動くか
最も見落とされやすい区分です。
理由は明快で、テスト期間中に実行タイミングが来ないものが多いからです。月次バッチ、四半期処理、年次処理——これらはテスト中に自然には動きません。
確認項目
- 日次バッチが正常に動作する
- 週次バッチが正常に動作する
- 月次バッチが正常に動作する（時刻を変えて強制実行して確認）
- 年次・四半期処理の存在確認と動作確認
- スケジュールタスク・cronの設定内容
- バッチ実行ユーザーの権限
- バッチのログ出力先
- 処理失敗時の通知が飛ぶか
- 前後関係のあるバッチの実行順序
月次バッチは、必ず時刻を変えて実行してみてください。 「設定されているから大丈夫」ではなく、実際に動かして確認する。ここを省くと、移行の翌月に問題が起きます。
そして、そもそも「どんなバッチが存在するか」の洗い出しが前提です。現行環境の調査が甘いと、この区分は丸ごと抜けます。
④性能テスト：負荷に耐えられるか
新しい環境が、想定される負荷に耐えられるかを確認します。
確認項目
- 通常時のレスポンス（現行環境と比較）
- ピーク時想定の負荷での動作
- 同時接続数の上限
- CPU、メモリ、ディスクI/Oの使用率
- ディスク容量の増加ペース
- バッチ処理の実行時間（現行より遅くなっていないか）
見るべきは絶対値ではなく、現行環境との比較です。「新しいサーバーだから速いはず」と思い込むと危険で、設定次第では遅くなることもあります。
特にバッチの実行時間は要注意です。夜間バッチが業務開始までに終わらなくなると、大問題になります。
⑤障害テスト：異常時に想定通り動くか
正常系だけでなく、異常系も確認します。ここまでやる現場は多くありませんが、やっておくと安心感が違います。
確認項目
- サーバー再起動後の自動復旧
- サービス停止時のアラート発報
- 冗長構成のフェイルオーバー動作
- バックアップの取得
- バックアップからのリストア
- ディスク枯渇時の挙動
- 接続先が停止しているときの動作
リストアテストは、可能なら必ずやってください。 バックアップが取れていても、戻せなければ意味がありません。「取得できている」と「復旧できる」は別の話です。
⑥運用テスト：運用作業が回るか
意外と抜けるのが、ここです。
システムが動くことと、運用できることは違います。
確認項目
- 手順書通りに作業ができるか
- 運用担当者がログインできるか（権限含む）
- 監視画面で正しく状態が見えるか
- アラートが運用チームに届くか
- ログの調査ができるか（アクセス権、検索性）
- 定期作業（再起動、パッチ適用など）の手順が有効か
- 運用ドキュメントが新環境の内容に更新されているか
運用担当者が実際に触って確認するのが理想です。構築した人には当たり前でも、運用する人には分からないことがあります。
特に見落としやすい5項目
ここまでの中から、経験上とりわけ抜けやすいものを再掲します。
1. サーバー再起動後の自動起動
手動起動で確認して終わらせない。必ず再起動する。
2. 月次・年次バッチ
テスト期間中に動かないものは、時刻を変えて強制実行する。
3. 監視の疎通
移行後に監視が死んでいるのが一番怖い。
4. バックアップからのリストア
取得できることと戻せることは別。
5. 証明書の有効期限
移行のタイミングで証明書を新しくした場合、期限と自動更新の設定を確認する。
テスト工数を確保するために
最後に、現実的な話をします。
どれだけ立派なテスト項目を並べても、工数がなければ実行できません。
私がやっているのは、シンプルに2つです。
1. 見積の段階で、テスト工数を独立した項目として計上する
「構築費用に含む」ではなく、テストを独立した行として見積に出します。そうすると、削るときに「テストを削る」という明確な判断が必要になる。曖昧に消えていくのを防げます。
2. テストを削った場合のリスクを、文書で共有する
それでも削られることはあります。そのときは、「このテストを実施しない場合、〇〇のリスクがあります」と文書で残します。
これは責任逃れではなく、判断材料を顧客に渡すという意味です。リスクを知ったうえで削るなら、それは顧客の判断です。知らないまま削られるのが、一番まずい。
まとめ
サーバーリプレースのテスト項目を、6区分でまとめます。
テスト区分
- 単体テスト — 起動、自動起動、ログ、基本設定
- 連携テスト — 疎通（双方向）、認証、監視、メール
- バッチ・定期処理テスト — 日次/週次/月次、実行順序、失敗通知
- 性能テスト — 現行との比較、バッチ実行時間
- 障害テスト — 再起動復旧、フェイルオーバー、リストア
- 運用テスト — 手順書、権限、監視画面、ドキュメント
特に見落としやすい5項目
- サーバー再起動後の自動起動
- 月次・年次バッチ
- 監視の疎通
- バックアップからのリストア
- 証明書の有効期限
工数を確保するために
- 見積でテストを独立項目として計上する
- 削る場合はリスクを文書で共有する
テストは、やっても何も起きなければ評価されない作業です。地味だし、時間もかかります。
でも、移行後に問題が起きなかったのは、テストをやったからです。そこは自分たちで誇っていい部分だと思っています。
次のリプレースで、この一覧が少しでも役に立てば嬉しいです。
コメント