ITサービスマネージャ 2012年 午後1 問03
アプリケーションの受入れに関する次の記述を読んで、設問1～3に答えよ。
E社は、旅行代理店向けにサービスを提供する会社である。E社は、旅行代理店のシステムから宿泊予約が成立した旨の通知を受け、全国に約1万軒あるホテル、旅館など（以下、宿泊施設という）に宿泊予約者の情報を送信するサービス（以下、宿泊通知サービスという）を提供している。
〔宿泊通知サービスの概要〕
宿泊通知サービスは、旅行代理店ごとに契約している宿泊施設の宛先を、あらかじめ登録することによって、複数の旅行代理店のシステムから受信した、宿泊予約者の情報（以下、宿泊通知という）を、宿泊施設のPC及びファクシミリ装置（以下、FAXという）宛てに送信することができる。宿泊施設のPCでは、E社が開発した専用ソフトウェアを利用して、通知を受信したり、過去に受信した通知を再度取り出したりすることができる。宿泊通知サービスのシステム構成を、図1に示す。
旅行代理店のシステムは、VPN経由で宿泊通知管理システムに接続する。旅行代理店のシステムからの通知を宿泊通知管理サーバが受信した後、宿泊施設に送信する。宿泊施設のPCへの通知は、VPN経由でPCの専用ソフトウェアに送信される。宿泊施設のFAXへの通知は、FAX送信サーバから公衆電話網経由で送信される。
宿泊通知管理システムは、E社のシステム部が運用している。旅行代理店及び宿泊施設からの問合せは、システム部が運営するサポートデスクで受け付けている。
〔宿泊通知サービスの機能〕
宿泊通知サービスの機能を表1に示す。
〔宿泊通知管理システムのリニューアル〕
E社では、サービス拡大のために、旅行代理店が宿泊通知の送信状況をリアルタイムに把握できる機能（以下、送信状況確認機能という）を追加することにした。宿泊通知管理システムは、利用開始から7年が経過し、その間に、接続する旅行代理店数及び宿泊通知件数が大幅に増加し、処理能力の増強やソフトウェア構成の大幅な見直しも必要となってきたので、リニューアルを行うことにした。現在の宿泊通知管理システムは、独立したハードウェアで稼働しているが、新システムではハードウェア費用を低減させるために、E社が既に運用しているサーバ上に本番環境を構築することにした。このサーバでは、E社がサービスを提供する多数のシステムが稼働している。深夜には、各サービス用システムでバッチ処理及びバックアップ処理が行われていて、ファイル書込み処理の負荷が高い。
システム部のF部長は、ITサービスマネージャのK氏に、新システムの受入れテストの実施、及びリスクが最小限となるようなシステム移行計画の作成を指示した。
〔旅行代理店のグループ分けと保有ファイル〕
宿泊通知サービスを利用する旅行代理店は、契約している宿泊施設が表1に示す蓄積データ取出し機能を利用しているかどうか、及び宿泊通知サービスに何らかのトラブルが発生した場合に旅行代理店のシステムから宿泊通知を再送できるかどうかによって、表2に示す四つのグループに分類できる。K氏は、新システムに移行するファイルについて検討するために、宿泊通知管理システムが保有しているファイルを調査し、その結果を表3にまとめた。
〔受入れテストの実施〕
K氏は、新システムへの切替えが可能かどうかを評価するために、受入れテストを行った。受入れテストでは、機能確認テスト、障害テスト及び負荷テストを実施する。K氏は、本番環境と同一の性能がある開発環境を利用して、機能確認テストと障害テストを実施した。機能確認テストでは、表1に示す機能、及び新機能である送信状況確認機能について、正常系、異常系の動作を検証し、問題がないことを確認した。さらに、旅行代理店との間で取り決めているメンテナンス日に本番環境を使って、大量の宿泊通知を送信する負荷テスト用ソフトウェアを利用し、疑似的な複数の旅行代理店のシステムからテスト用の宛先に大量のテストデータを送信し、新機能である送信状況確認機能を利用する負荷テストを実施した。現在のシステム構築時に想定した旅行代理店数及び宿泊通知件数のテストデータを用いて負荷をかけても、処理性能に問題がないことを確認した。K氏は、以上のテスト結果から、新システムは切替え可能な品質であると判断した。
〔新システムへの移行方式の検討〕
K氏は、旅行代理店向けのサービス提供に支障が出ないように、1か月程度、新旧システムを並行稼働させ、旅行代理店ごとに順次新システムに移行するシステム移行計画をまとめた。接続方式には変更がなく、宿泊施設のPCの専用ソフトウェアも変更する必要がないので、旅行代理店のシステムの接続先を、現システムから新システムに変更することで、旅行代理店ごとに移行することができる。切替え回数を減らすために、表2のグループ単位で複数の旅行代理店をまとめて新システムに移行することにした。この方式では、新システム移行後に不具合が見つかり、切戻しが必要となった場合でも、グループ単位で現システムに戻すことができる。K氏はリスクを低減するために、表2のグループについて、(ア)前半でグループ1、グループ3の順に切り替え、後半でグループ2、グループ4の順に切り替えることにした。
〔ファイル移行計画の検討〕
宿泊通知サービスのサービス提供時間は、午前4時から翌日午前3時までであり、システム移行に利用できる時間は1時間しかない。表3の全てのファイルを移行するには、1時間では足りない。ファイル移行時間を短縮するために、並行稼働開始前に、新システムに全ての宛先ファイルを移行しておき、全ての旅行代理店の新システムへの移行が完了するまで、新旧のシステムで宛先の追加、変更及び削除について同一の処理を行うことにした。また、ログファイルは新旧のシステムで形式が異なるので移行は不要と判断した。
K氏は開発環境のサーバを利用してファイル移行テストを実施し、1時間以内に移行が完了することを確認した。
〔新システムへの切替え〕
K氏は、システム移行計画をF部長に報告し、承認を得たので、新機能である送信状況確認機能と旅行代理店ごとの移行計画について、サポートデスクに説明した。サポートデスクは、旅行代理店からの問合せに対応できるように必要な問合せ対応マニュアルを整備した。
K氏は、新システムへの移行を開始した。グループ1の切替えが予定どおり終了したところで、グループ3の旅行代理店から送信状況確認機能の早期リリース要請を受けた。そこで、K氏は、F部長と相談し、システム移行計画を当初予定から1週間前倒しして、グループ3の切替えを実施した。
グループ3の切替えを行ったところ、サービス利用量が最大となる午前9時頃に処理が遅延する障害が発生した。原因を調査した結果、複数の旅行代理店が、宛先が異なるPC及びFAXに大量の通知を送信したときに、新機能である送信状況確認機能を利用したところ、処理が遅延していたことが分かった。また、この障害発生時に、サポートデスクでは一部の旅行代理店からの問合せに対して、K氏から説明された時点の移行計画に基づいて現システムの調査をしたので、回答に時間を要するなど、（イ）対応に手間取った。
設問1：
問題文を見る〔新システムへの移行方式の検討〕について、本文中の下線（ア）のように後半でグループ2とグループ4を切り替えることにした理由を、50字以内で述べよ。
模範解答
・後半のグループは切戻し時に宿泊通知の再送ができないので、本番業務に影響を与えるリスクがあるから
・前半のグループは切戻し時に宿泊通知の再送ができるので、本番業務に影響を与えるリスクが少ないから
解説
解答の導き方
-
表2では、グループ1とグループ3はトラブル時に「宿泊通知の再送」ができます。一方、グループ2とグループ4は再送できません。後半にするグループを判断するうえでは、この違いが重要です。
-
本文には、新システムへの移行後に不具合が見つかった場合、「グループ単位で現システムに戻すことができる」とあります。つまり、移行後に問題が発生すれば、切戻しを行う可能性があります。
-
切戻し時に宿泊通知を再送できるグループなら、通知を再送して本番業務への影響を抑えやすくなります。反対に、グループ2とグループ4は再送できないため、切戻しによって宿泊通知の処理に支障が出るリスクがあります。
-
そこで、まず再送できるグループ1とグループ3を切り替え、その後に、切戻し時の影響が大きくなるおそれのあるグループ2とグループ4を切り替える順序にしています。
誤りやすいポイント
- グループ2とグループ4の後半への切替えを、蓄積データ取出し機能の利用有無だけで説明しないようにします。重要なのは、トラブル時に宿泊通知を再送できるかどうかです。
- 「後半にするのはリスクが高いから」とだけ書くと、何のリスクかが伝わりません。切戻し時に再送できず、本番業務への影響が大きくなるおそれまで説明します。
- グループ1とグループ3も後半にする理由として挙げる場合は、トラブル時に再送できるので、先に切り替えても影響を抑えやすい点につなげます。
FAQ
Q: グループ1とグループ3を前半にする理由は何ですか？
A: トラブル時に宿泊通知を再送でき、切戻しが必要になったときの本番業務への影響を抑えやすいからです。
A: トラブル時に宿泊通知を再送でき、切戻しが必要になったときの本番業務への影響を抑えやすいからです。
Q: グループ2とグループ4の違いは、切替え順に関係しますか？
A: 蓄積データ取出し機能を利用するかどうかは異なりますが、どちらもトラブル時に宿泊通知を再送できないため、後半に切り替える点では共通しています。
A: 蓄積データ取出し機能を利用するかどうかは異なりますが、どちらもトラブル時に宿泊通知を再送できないため、後半に切り替える点では共通しています。
関連キーワード: システム移行、切戻し、再送、リスク評価、段階移行
設問2：〔ファイル移行計画の検討〕について、(1)～(3)に答えよ。
設問2（1）
問題文を見る宛先ファイルを並行稼働開始前に新システムに移行し、新旧システムで宛先の追加、変更及び削除について同一の処理を行うことによる利点を、ファイル移行時間短縮以外の観点から40字以内で述べよ。
模範解答
運用開始後に切戻しを行った場合でも、宛先ファイルの移行が不要な点。
解説
解答の導き方
この設問は、宛先ファイルを先に新システムへ移し、移行期間中に新旧両システムへ同じ更新を行うことの利点を、移行時間の短縮以外から考える問題です。
本文には、全ての宛先ファイルを並行稼働開始前に新システムへ移し、その後は「宛先の追加、変更及び削除について同一の処理を行う」とあります。つまり、移行期間中も新旧両システムの宛先ファイルが同じ内容に保たれます。
この状態で新システムに不具合が見つかり、現システムへ切り戻すことになった場合を考えます。現システム側にも最新の宛先情報が反映されているため、切戻し時に宛先ファイルを改めて移行する必要がありません。したがって、移行時間の短縮以外の利点は、切戻し時に宛先ファイルの移行が不要になることです。
誤りやすいポイント
- 宛先ファイルを事前に新システムへ移すことだけに注目し、移行期間中に新旧両方へ同じ更新を行う意味を見落とすことがあります。
- 「両システムで同じ処理を行う」利点を、通常の移行作業の時間短縮だけで説明すると、設問が求める観点から外れます。
- 宛先ファイルについての利点を問われているため、ほかのファイルも切戻し時に移行不要だと広げて述べないようにします。
FAQ
Q: なぜ新旧両システムに同じ宛先の更新を行うのですか？
A: 移行期間中も両システムの宛先ファイルを同じ状態に保ち、切戻し後も現システムを最新の宛先情報で使えるようにするためです。
A: 移行期間中も両システムの宛先ファイルを同じ状態に保ち、切戻し後も現システムを最新の宛先情報で使えるようにするためです。
Q: 切戻し時に、どのファイルも移行しなくてよいということですか？
A: ここで導けるのは宛先ファイルについての利点です。ほかのファイルまで移行不要とはいえません。
A: ここで導けるのは宛先ファイルについての利点です。ほかのファイルまで移行不要とはいえません。
関連キーワード: 並行稼働、切戻し、データ同期、ファイル移行
設問2（2）
問題文を見るファイル移行計画を見直すことで、切替え当日のファイル移行時間を短縮することができる。作業内容を具体的に、30字以内で述べよ。
模範解答
過去分の蓄積ファイルを事前に新システムに移行する。
解説
解答の導き方
-
問われているのは、切替え当日に行うファイル移行の作業量を減らすため、事前にどのファイルを新システムへ移すかです。すでに宛先ファイルは並行稼働開始前に移行する計画なので、それ以外のファイルに着目します。
-
蓄積ファイルを切替え当日に移すのではなく、過去分をあらかじめ新システムへ移しておけば、当日の移行対象を減らせます。よって、作業内容は過去分の蓄積ファイルを事前に移行することです。
誤りやすいポイント
- すでに計画されている宛先ファイルの事前移行を、追加の作業内容として答えてしまうことです。
- ログファイルは形式が異なるため移行不要とされています。移行時間を減らすためにログを削除すると答えるのは適切ではありません。
- 蓄積ファイルは過去の宿泊通知を取り出すために必要です。移行しないのではなく、切替え当日より前に移行します。
- 送信ファイルは送信中の宿泊通知を記録するファイルです。過去分の履歴を保持する蓄積ファイルとは用途が異なります。
FAQ
Q: なぜ蓄積ファイルを新システムに移す必要があるのですか？
A: 過去に受信した宿泊通知を取り出す機能を新システムでも提供するためです。蓄積ファイルを移さなければ、過去分の取出しに支障が出ます。
A: 過去に受信した宿泊通知を取り出す機能を新システムでも提供するためです。蓄積ファイルを移さなければ、過去分の取出しに支障が出ます。
Q: 事前に移行することで、なぜ切替え当日の作業時間を短縮できますか？
A: 切替え当日に移行するファイルの量を減らせるためです。移行に使える時間が限られているので、前もって移せるデータを切り替えておくことが有効です。
A: 切替え当日に移行するファイルの量を減らせるためです。移行に使える時間が限られているので、前もって移せるデータを切り替えておくことが有効です。
関連キーワード: ファイル移行、データ移行、並行稼働、履歴データ
設問2（3）
問題文を見るK氏が実施したファイル移行テストではテスト要件として不十分な内容がある。テスト要件として適切な内容を40字以内で述べよ。
模範解答
本番環境で発生する負荷の高い状況でも1時間以内にファイル移行が完了できること
解説
解答の導き方
この設問で問われているのは、ファイル移行テストで何を確認すべきだったかです。単に移行にかかる時間を測るだけでなく、本番環境で移行作業を行うときの条件を考える必要があります。
まず、移行作業に使える時間には制約があります。本文には「システム移行に利用できる時間は1時間しかない」とあるため、ファイル移行はこの時間内に完了しなければなりません。
一方、本番環境では「深夜には、各サービス用システムでバッチ処理及びバックアップ処理が行われていて、ファイル書込み処理の負荷が高い」とされています。ファイル移行もファイルへの書込みを伴うので、こうした処理と重なると、移行時間が長くなる可能性があります。
K氏は「開発環境のサーバを利用してファイル移行テストを実施し、1時間以内に移行が完了することを確認」しています。しかし、開発環境で1時間以内に終わっても、本番環境のようにほかのサービスの処理が重なり、ファイル書込みの負荷が高い状況でも同じ時間で終わるとは限りません。開発環境の性能が本番環境と同等であっても、本番環境で発生する負荷状況まで再現できているかは別に確認する必要があります。
したがって、テスト要件には、本番環境で発生する負荷の高い状況を考慮し、その条件下でも移行が1時間以内に完了することを確認する内容を含めます。
誤りやすいポイント
- 開発環境で1時間以内に完了したという結果だけで、本番環境でも問題ないと判断してしまうことです。ファイル書込みの競合による負荷も考慮します。
- ファイル移行の対象や手順を見直すことを答えてしまうことです。この設問は、移行計画ではなく、移行テストで確認すべき要件を問うています。
- 本番環境の負荷を考慮しても、移行可能時間である1時間以内に完了するという条件を落としてしまうことです。
FAQ
Q: 開発環境と本番環境の性能が同じなら、開発環境でのテストで十分ではありませんか？
A: サーバ自体の性能が同等でも、本番環境で同時に動くバッチ処理やバックアップ処理による負荷まで再現できているとは限りません。ファイル書込みが高負荷となる条件も考慮します。
A: サーバ自体の性能が同等でも、本番環境で同時に動くバッチ処理やバックアップ処理による負荷まで再現できているとは限りません。ファイル書込みが高負荷となる条件も考慮します。
Q: テストでは何を確認すればよいですか？
A: 本番環境で発生する高負荷の状況でも、ファイル移行が利用可能時間内に完了することを確認します。
A: 本番環境で発生する高負荷の状況でも、ファイル移行が利用可能時間内に完了することを確認します。
関連キーワード: ファイル移行、負荷テスト、性能試験、共有サーバ、バッチ処理
設問3：〔新システムへの切替え〕について、(1)、(2)に答えよ。
設問3（1）
問題文を見る処理が遅延する障害が発生したのは、受入れテストに問題があったからである。受入れテストの問題点を、40字以内で述べよ。
模範解答
負荷テストにおいて旅行代理店数及び宿泊通知件数の増加を考慮していない。
解説
解答の導き方
-
まず、受入れテストのうち、処理性能を確かめる負荷テストに注目します。本文では、複数の旅行代理店のシステムからテストデータを送信し、送信状況確認機能を利用する負荷テストを実施しています。したがって、複数の旅行代理店から同時に利用される状況自体は、テストで想定されています。
-
次に、テストデータの量が適切だったかを確認します。本文には、テストデータについて「現在のシステム構築時に想定した旅行代理店数及び宿泊通知件数」とあります。一方、新システムへのリニューアルの背景には、利用開始後に旅行代理店数及び宿泊通知件数が大幅に増加したことが挙げられています。
-
つまり、テストでは複数の旅行代理店を想定していたものの、その数や宿泊通知件数は、増加後の利用規模を反映していません。実際の障害は複数の旅行代理店が大量の通知を送信し、送信状況確認機能を利用したときに発生しています。そのため、受入れテストの問題点は、旅行代理店数及び宿泊通知件数の増加を考慮せずに負荷テストを行ったことです。
誤りやすいポイント
- 複数の旅行代理店からテストデータを送っているため、負荷テストは十分だったと判断してしまうことです。複数の利用者を想定したかだけでなく、利用者数や通知件数の規模が適切かも確認します。
- 本番環境を使ってテストしたことを、負荷テストの十分性と混同することです。本番環境と同じ性能の環境でも、テストデータの量が実際の想定負荷に届かなければ、性能上の問題を見つけられないことがあります。
- 実際の障害がPCやFAXへの送信先の違いに関係していたことだけに注目することです。この設問で問われている受入れテスト上の問題点は、負荷テストで旅行代理店数及び宿泊通知件数の増加を考慮していなかったことです。
FAQ
Q: 複数の旅行代理店を使った負荷テストを実施していても、不十分になるのはなぜですか？
A: 複数の旅行代理店を想定していても、テストデータの量が過去の想定規模にとどまり、増加後の利用規模を再現できていないためです。
A: 複数の旅行代理店を想定していても、テストデータの量が過去の想定規模にとどまり、増加後の利用規模を再現できていないためです。
Q: 本番環境でテストを行えば、処理性能を十分に確認できますか？
A: 本番環境の性能を確認できても、想定する負荷をかけなければ、負荷が高まったときの遅延を検出できないことがあります。環境だけでなく、テストデータの量も適切に設定する必要があります。
A: 本番環境の性能を確認できても、想定する負荷をかけなければ、負荷が高まったときの遅延を検出できないことがあります。環境だけでなく、テストデータの量も適切に設定する必要があります。
関連キーワード: 負荷テスト、受入れテスト、性能試験、ピーク負荷、処理能力
設問3（2）
問題文を見る本文中の下線（イ）の再発防止のために実施すべき内容を、40字以内で述べよ。
模範解答
移行計画が変更された場合は、サポートデスクに最新のリリース計画を説明する。
解説
解答の導き方
-
サポートデスクは旅行代理店からの問合せを受け付けるため、各旅行代理店が新システムへ移行済みかどうかを把握している必要があります。本文では、K氏が「旅行代理店ごとの移行計画」をサポートデスクに説明したとあります。
-
その後、グループ3から早期リリースの要請があり、グループ3の切替えを当初の予定より1週間前倒ししました。つまり、サポートデスクに説明した計画と実際の切替え状況にずれが生じています。
-
本文には、サポートデスクが「K氏から説明された時点の移行計画に基づいて現システムの調査をした」とあります。古い計画のままでは、問合せの対象となる旅行代理店がどちらのシステムを利用しているかを正しく判断できず、回答に時間がかかります。
-
したがって、移行計画を変更したときは、サポートデスクにも変更内容を伝え、最新のリリース計画に基づいて問合せに対応できるようにする必要があります。
誤りやすいポイント
- サポートデスクの対応に時間がかかった原因を、問合せ対応マニュアルの内容不足だけに求めないようにします。本文では、古い移行計画に基づいて調査したことが原因として示されています。
- F部長と相談して移行計画を変更しただけでは、問合せ対応上の問題は解消しません。旅行代理店から問合せを受けるサポートデスクにも、変更後の計画を共有する必要があります。
- 「サポートデスクに説明する」だけでなく、計画変更後の最新情報を伝える点が重要です。
FAQ
Q: なぜサポートデスクへの情報共有が必要なのですか？
A: 旅行代理店からの問合せに対し、移行状況に応じて適切なシステムを調査できるようにするためです。
A: 旅行代理店からの問合せに対し、移行状況に応じて適切なシステムを調査できるようにするためです。
Q: 問合せ対応マニュアルを整備していれば十分ですか？
A: マニュアルがあっても、実際の移行計画が変更されていれば情報が古くなります。変更後の計画をサポートデスクに伝える必要があります。
A: マニュアルがあっても、実際の移行計画が変更されていれば情報が古くなります。変更後の計画をサポートデスクに伝える必要があります。
Q: 共有するのはどのような情報ですか？
A: 旅行代理店ごとの切替え状況を把握できる、最新のリリース計画です。
A: 旅行代理店ごとの切替え状況を把握できる、最新のリリース計画です。
関連キーワード: システム移行、変更管理、リリース計画、情報共有、問い合わせ対応
