運用テストの対象は，ソフトウエアやハードウエアにとどまらない。本番運用を想定して，運用担当者，利用者，運用/復旧手順，連絡体制，ベンダーとの契約内容，などを広くテストする。また，運用テストは稼働前の最後のテストになるため，ここでバグを見落とせば，システム障害に直結してしまう。

IV-(1)：擬似本番テスト

　テスト環境で実施する最後のテスト。開発部門は，「保証取り」の結果をもって運用部門にシステム稼働の承認を取り付けることになり，運用部門は策定した運用設計を「バグ取り」して，本番運用に備える。

　このため，擬似本番テストの方法や具体的な内容は，運用部門の協力のもと，運用設計に基づいてシナリオ化された手順に従う。結果判定も運用部門と共同で協議する。下記にテスト内容の例を示す。

● 画面表示，印刷出力確認

　利用部門の画面や操作は，システム・テスト以前で確認が済んでいる。ここでは，運用設計に照らし合わせて，運用コンソールや帳票が運用業務を遂行するために必要な情報を提供しているかどうかを確認する。運用監視ツールは正常に稼働しているか，誤解を招きやすいエラー・メッセージはないか，アラートのレベルは適切か，などを確認したい。

● 日次～年次処理テスト

　業務システムの運用には，日次/週次/月次/年次など，特定のタイミングで実行される処理がある。個別の処理についての動作確認はシステム・テスト以前で終了している。ここでは，実際に作業スケジュールに沿って日次から年次処理までを実行する。容量不足やキー重複など，処理の蓄積に関連した問題が発見されることもある＊18。

IV-(2)：ユーザビリティ・テスト

　このテストから，テストを実施する主体は運用部門と利用部門になる。目的はシステムの使いやすさを確認すること。

　企業システムの場合は利用者や利用環境が限定されているため，使いやすさの要素は．(1)マニュアルは見やすく分かりやすいか，(2)業務に画面操作が合致しているか，(3)応答時間は十分短いか，(4)障害メッセージは分かりやすいか，(5)オペレーション・ミスをシステムがリカバリしてくれるか——などが挙げられる。このテストで発生した問題は，マニュアルや導入教育に反映することで対策とする。

IV-(3)：試験運用

　試験運用は本番稼働の予行演習である。環境，要員を含め，すべての要素を一定期間本番稼働と同等にして運用を行う。ここで旧システムからの移行を伴っている場合は，並行稼働として新旧システムの比較や検討も行われる（別掲「移行テスト」を参照）。

　テストの目的は，運用設計に基づく操作や処理の時間配分，作業の手順，運用担当者の配置，などを確認すること。利用者や運用担当者の教育も兼ねる。

　さらにここでは，障害が発生した場合の復旧と障害時運用が設計通りに実施できることをテストすることが欠かせない。関連メーカーや業者，自システムと連携している他企業など広い範囲を含めて，手順や連絡経路を確認したい。

　なお，試験運用で問題が発生しても，それが致命的な問題でない限りは，原則として即時にシステムを修正しない。運用で何らかの対策を講じる。発生した問題は改善点として申し送りされ，次期システムの開発や次回改修時に対策されることになる。

IV-(4)：保守性テスト

　システムのインフラ保守上で計画されている作業や操作が，運用設計に基づいて正しく実行できること，他システムや自システムの通常運用に影響を与えないことを確認する＊19。

　特に「ハードウエア障害による保守」に関連した，データやアプリケーションを含んだシステム全体の意図的な待機系への切り替え，切り戻しの確認は欠かせない。24時間365日無停止運用のシステムでは，待機系と本番系を切り替えながら機器の保守点検や入れ替え作業を行うことが多い。しかし，システム稼働直後は，待機系への切り替え失敗や，切り替えた後に戻せなくなる失敗が目立つ。

　インフラの保守は，運用担当者やメーカーSEなどの経験に頼りがちだ。また，品質という観点では見過ごされやすいため，要注意である。

　最近は，短期開発の影響で運用テストが不十分なまま本番稼働する例も散見される。どんなシステムであっても初期不良はあり，稼働直後は安定しないもの。運用テストでしっかり初期不良を洗い出しておきたい。


移行テスト——信頼性を新旧で引き継ぐ——

　ホストからUNIXへのマシン・リプレースや，システムの再構築では，旧システムから新システムへ様々な資産を移行する。例えば，リプレース事例では，既存のプログラムやデータをほとんどそのまま移行する。変わるのはサーバーやDBなどの製品だ。また，再構築事例では，開発言語が変わっても，画面操作などの基本設計を再利用することが多い。顧客情報などのデータも，スキーマ構造は変わっても新システムで引き続き使用される。

　このように既存資産が再利用される場合，移行テストが欠かせない。移行テストには2つの目的がある。1つは移行シナリオの検証。もう1つは仕様が移行されているかどうかの検証だ。

　なお，特に新/旧システムの製造元が異なっている場合，移行テストが疎かにされるケースが散見される。プラットフォームの移行は，システムの信頼性を低下させる恐れがあることを忘れてはいけない。

●移行シナリオ確認テスト

　システムの移行は，「移行設計書」にシナリオ化される。事前準備や切り替え手順，作業者や責任者，移行に失敗した場合の対策方法や連絡先などが記されている。

　移行シナリオ確認テストは，シナリオ内容の確認を目的とし，シナリオに基づいて予行演習を行う。移行に関連する部署や部門が協力し，正常に移行が進む場合はもちろん，移行に失敗して元に戻す手順も欠かさずチェックしたい。

　特に移行失敗のシナリオでは，システム開発の責任者や担当役員，社長にまで判断を仰ぐことが必要なケースもある。稼働開始を急ぐあまり，切り戻しを想定せずに移行計画を立てていることもあるだろう。あらかじめ失敗時のシナリオをテストしておくことには大きな意味がある。

●移行前後の互換性テスト

　旧システムから新システムへの移行では，「同じデータを入力すれば同じ結果を出力する機能」や，「画面の見た目は異なるが操作手順は同じ」といった，既存機能を生かしている部分がある。「互換性テスト」では，この新/旧システムの互換部分が，「同じ意味」の機能を提供しているかどうかを確認する。システムの信頼性も移行対象として，テストが欠かせない。

　互換性テストには，中級以上のスキルが要求される。互換部分を探し出すことは，システムの要求分析や設計，移行前後のプラットフォームなどに詳しくないと難しく，また「同じ入力データ」でも，データ構造や文字コードが異なることもあるなど，テスト設計も難しいためだ。また，利用/運用部門と連携して，運用上の互換性テストを実施する必要もある。


倉田 克徳
エス・キュー・シー 代表取締役
石川 和則
エス・キュー・シー 取締役 事業企画室長