いよいよ新ＩＴシステムのリリースが近づいてきています。
そのため、利用・運用に向けたタスクをリリース前段階で実行していくことになります。
運用テストと受入テストの違いとは
運用テストは、受入テストと兼ねて実行される場合もあります。
受入テストは、ＩＴシステムが完成しているかを検収のために確認するものです。
運用テストは、業務運用およびシステム運用を稼働する前に確認するものです。
運用テストは本来的にはＩＴシステムのバグを検出するものではありません。
しかし、実態はそうはいかないことが多いです。
運用テスト、総合テスト、受入テストの順序
実施する順序は、総合テスト→運用テスト→受入テストとなるケースもあれば、総合テスト→受入テスト→運用テストとなるケースもあります。
この違いは、プロジェクトによるものですが、2つの特性から勘案されることが多いです。
一つは、ＩＴシステム環境によるものです。
新ＩＴシステムが既存に影響することなく、新たな環境であれば現行運用を意識せずにテストが可能です。
よって、新ＩＴシステムとしての運用テストを十分に実施してから、稼働を迎えるという計画にできます。
もう一つは、ユーザへの参画度合によるものです。
ユーザが受入テストや運用テストを計画して実行できる場合は、総合テスト完了後に、自ら両観点で進めていけるでしょう。
ところが、自ら実行できるユーザはそう多くはありません。
よって運用テストや受入テストですら、開発を受託したベンダーが設定を支援しているケースもあります。
ベンダーが設定したテストケースに基づいて、確認したら不具合が次々と出てきて、混乱しているプロジェクトも多々あります。
このように、各テストの位置づけは微妙に異なることはあるのですが、本来の意味は理解して実行すべきです。
運用テスト・利用開始準備のタスク
運用テストは、ＩＴシステムのリリース前の段階で、業務運用とシステム運用を実際に実施してみて確認することです。利用を開始するための教育等利用準備タスクと近いものです。
よって同時に説明していきます。
運用テスト環境準備と実施計画
運用テストでは運用に即したテストを実施するため、それなりの環境が必要となります。
総合テスト以前のテストではその目的に応じて、必要最低限のテスト環境があればよかったのですが、運用テストとなると、実際に利用するユーザ環境が必要ということになり、データも準備が必要になります。
よって他の作業を含めて、実際に用意できるタイミングを含めて計画する必要があります。
運用テストでは、ユーザに教育をし、必要に応じてマニュアルを参照しながらテスト参加していきます。
またシステム運用者によるテストも行いますので、業務運用面だけでなく、本番運用を想定したテストを行います。
それらは物としてのＩＴシステムの環境準備と関わる人に対する準備が必要となるということです。
教育準備・マニュアル作成
ユーザへの教育は、運用テスト参加者に対して実施することが望ましいです。
運用テストはできる限り利用する人すべてが参加するほうが、運用開始時点での混乱は避けられます。
しかし、実際は一部の人しか参加できないことのほうが多いです。だからと言って、教育準備が中途半端になることは問題です。
また、マニュアルや教育は、一律のものではないことのほうが多いでしょう。
管理者とエンドユーザではやることが異なります。また、エンドユーザでも承認者などのフロー上の立場の違いや、部門による権限の違い等もあるでしょう。
したがって、違いを考慮した準備が必要となります。
業務サイクルテスト仕様・データ準備
運用テストのユーザ側のテストとしては、業務サイクルテストが中心となります。
業務は入力して参照して、また入力して、という手続きがあります。そして、日次でのサイクルを終わり、週次や月次サイクルで実施する業務も場合によっては存在します。
そのような一連の業務手順に応じて、テストを行っていきます。
サイクルをどのように動かすかという観点と、どのようなケースとデータで実施するかという観点で、準備が必要となってきます。
本番さながらのデータということになりますが、実際にはできないことも存在するため、できる限り網羅できるようにします。
教育展開
教育展開は、ユーザごとに異なった展開計画に応じて展開されます。
WEB会議やマニュアル配布だけで実行できることもありますが、現地で環境設定し説明しなければならないケースもありますので、そのような計画も含めて、漏れなく展開していくことになります。
業務運用テストの実施
業務運用テストは、業務サイクルに基づいて実行されていきます。
サイクルのシナリオが順次実行されていくのと同時に、利用ユーザが確実に実行していることを確認しながら進めることになります。
システム運用テスト
システム運用テストはシステム管理者が行います。
システム運用テストの観点は、通常運用における運用と、異常時の対応を含めた運用におけるテストとなります。
まず、確認すべきことは、通常の監視とそのための通知に関するテストです。
通知されるのは、資源のキャパシティに関する情報、性能に関する情報、ジョブの正常・異常、セキュリティ面での警告等になります。
次に、通常実施する運用フローに応じたテストを実行します。
監視項目に対する対応、そして定期的に実行する保守作業やパッチ作業をテストします。
そして、障害時の復旧テストも実施します。バックアップが正常に行われていることの確認を前提として、バックアップからのリストアを試みます。
ここまでの説明でお分かりかと思いますが、特にシステム異常テスト時には、業務サイクルは中断されることになります。よって、段取りを予め組んでおく必要があるということです。
運用テストの結果評価
運用テストが実施されたら、結果を評価します。
運用テストは本番運用に則って運用できるかという観点ですので、想定どおりでなければ、不具合か課題となります。
不具合は障害として修正すべきものか、運用にはやや支障があるが、仕様は変えなくてもいいものか、判断が必要となります。
都度判断されるべきものですが、大きな意思決定は評価会議等にて決定されることとなります。
結果評価は、実行すべきものがすべて実行されているか、不具合・課題は運用上問題ないかという観点での評価となります。
業務運用上の観点もありますが、システム運用での観点もあります。
そして教育観点での評価も含まれます。マニュアルなどを配布し教育を実施したが、十分であったか、あるいは教育の浸透度は十分であったか、という観点での評価となります。
運用テストの結果を受けた対策実行
運用テストの結果により、不具合・課題については、その対策を実行していくことになります。
また、教育に関しては、十分と判断されなければ、充実するための対策を検討し、実行することになります。
運用テスト・利用開始準備のマネジメント法
運用テストの計画
運用テストにおいては、先に説明した通り、作業に制約が発生します。
本番に近いサイクルを実行しなければならず、また運用の障害時復旧テストも実行しなければなりません。
よって、期間設定を予め綿密に計画しなければなりません。
また、サイクルを実行するにあたって実行するテストケースの割り当てを事前に行い、確実にエンドユーザをその時期に参加してもらう計画とします。
そして、不具合・課題は必ず発生するとして、最終的に対処を行う期間を設定したうえで、完了できる計画とします。
進行のマネジメント
計画に則って、進められているかをマネジメントします。
監視することとして、まずテストのサイクルが予定どおり実行されているか、という観点があります。
テストサイクルをスムーズに実行するには環境準備ができていないと進みません。
進んでいるように見えて、実は中身が伴っていないという事態もあり得ます。
よって、実際上の進捗を見ていきます。
そして、テストケースが進んでいるかを監視します。テストケースはエンドユーザが参画しないと進みません。
参画していても、何かに躓いていては進んでいません。よって、
進捗を見るのと同時に、思わしくなかった時の原因を考えていきます。
定量的に予実をまず見ていきますが、加えて妨げとなっている事象の原因を見ていきます。
不具合・課題のマネジメント
総合テストや場合によって受入テストまで実施している状態ではありますが、この場面においても不具合や課題は発生します。
不具合は障害と少し違います。
不具合は何らか運用に支障があるものです。
運用テストを本番運用前に確認している状況ですので、不具合が発生するのは想定内です。
しかし、それは内容にもよります。要求を要件定義し、仕様化し、ITシステムを作ってきているわけですが、いざ運用という段階になって、支障が出ているということになるので、どこかの時点でうまく実装できなかったことになります。
多くは要件定義からして考慮できていなかったというものになります。
できる限り要件を潰したいところですが、潰しきれないことがいくつかあるのは、普通のことです。
この段階となっていれば、いかに対処して進めるかということが重要となってきます。
ベンダーとの責任問題は当然ありますが、プロジェクトへの影響を鑑みて判断していくこととなるでしょう。
切替・稼働を意識した意思決定マネジメント
運用テストは稼働前にテストにて運用を確認している段階ですので、この時点での不具合・課題は、実運用に支障が出る問題となります。
直ぐに潰せるものは潰していくマネジメントを実施していきますが、実運用に支障が出るかもしれない案件については、場合により大きな意思決定が必要となります。
大きな意思決定であることは、責任者が判断するのと同時に、関係者も多く出てくる必要があるかもしれません。
よって、テスト途中段階であっても何らか意思決定が必要になることを計画しておいたほうがよいでしょう。
具体的には、社長と関係役員の会議日程を決めておくなどです。
また意思決定にあたって、万が一稼働がずれることも想定しておくことです。切替・稼働の直前となっては意思決定ができませんので、意思決定できるタイミングで、意思決定のできる材料を出せるよう、マネジメントしていきます。
運用テスト・利用開始準備でのありがちな問題
ユーザが実は参画できていない
利用開始の準備段階であるため、運用テストや教育にエンドユーザが参画してもらう必要があります。
しかし、教育もテストも順調に進んでいるかに見えて、実は参加予定数に達していないということがあります。
これは、準備不足ということは否めないですが、そればかりの理由ではなく、よくあることです。
エンドユーザは、わざわざ準備に参加するより日常を優先します。
運用され始めたら利用開始すればよいと考えています。
しかし、そういう人に限って、こんな機能とは思っていなかったので、見積書が間に合わなくなっただの、文句が出ます。
そうは言っても、人は未来を想定しづらいので、未来のための準備は疎かにしてしまうものです。
また、始まってから発生するユーザの利用浸透度も、想定はしてもその通りとなるかはわかりません。
一部のエンドユーザの反応を見て、その他のユーザの反応を想定することは可能ですので、対処方法を考えつつ、稼働を迎えましょう。
期間が短すぎた
運用テストや教育に関して、プロジェクトの全体工程を想定していた時は、直前で少しやればいい、という考えになっていることがあります。
その後、そのままプロジェクトは進んでいて、いざこの時になってみたら、期間が足りないと思うことはよくあります。
期間内訳の詳細を検討する前は、ざっくり最終期日が設定されているものです。
そして、人は得てして、最終期日のぎりぎりで仕事するものです。それは、大きな仕事でも小さな仕事でもです。
よって、最後のほうにある運用テストは、それ以前のタスクがぎりぎりまでかかっていて、期間を見直す時がなかった、というのがよくある実情です。
現状と変えたところが忘れられていて、不具合が多発
ＩＴの導入・システム開発においては、現行が存在し、新たにＩＴシステムが導入されることがよくあります。
新システムになったとしても、現行の業務はそのまま実行され、一部は変更され、また新たな業務が追加され、移行されるものです。
一部変更された業務について、要件定義時点で決めたものの、実際運用段階まで数カ月の時間があるため、運用テスト段階で試してみたところ、ミスが多発するといったことがあります。
時間が経ってしまうと、以前取り決めたとしても忘れてくるものです。
取り決めたと言っても、細かな操作上の話であれば忘れることも多いでしょう。しかし、運用上はその細かな仕様に注意が必要で、実業務に影響を与えてしまうことがあります。
運用テスト・利用開始準備で本当にやるべきこと
運用テストや利用開始準備は、いよいよ本番運用開始に向けた取り込みとなりますので、真剣になってくるところかと思います。
しかし、そうかと思いきや、エンドユーザについては、あまり意識していませんので、推進側と比べると熱はそれほど高くなっていないのほうが多いのではないでしょうか。
そのような背景もあり、すんなりうまくいくと思っていた利用開始準備と運用テストは、意外とうまくいかないこともあります。
推進側として、ここまでの工程が順調であれば、準備を入念にできますが、必ずしも順調でないと、準備が不十分で、結果、半ば強引に稼働させるようなことになってしまいます。
やはり利用開始に向けたユーザ関連タスクは、稼働前に慌てて実行するのではなく、要件定義や外部設計段階から、ＩＴシステム構築と並行して取り進める必要があります。
ＩＴシステム構築につまずくと、並行が難しくなりますので、予め並行体制を組んで取り組みたいところです。
その際に、取り組みたいのは、目的、特に達成したいことにフォーカスしマネジメントしていくことです。
達成したいことは、経営者自らが率先しなければならない場面もあるかもしれません。よって、プロジェクトに関与し、当初目的を到達できるようマネジメントしていくことで、稼働後スムーズに運用していけるようにしたいです。
なお、稼働・切替に向けて、実施すべきことの内、重要なことがまだ説明できていません。それはデータ移行です。
この点もまた、目的に合わせて推進していかないと失敗しますので、次回説明していきます。
コメント