平成25年度 秋期 午後Ⅰ

本文の根拠

表 2 案2

夜間のオフライン業務時間帯に，Y 市拠点を VPN 接続から切り離して Z 市拠点を VPN に接続し，店舗サーバと新本部サーバ間で発注情報送信テストを実施する。

表 2 案1

店舗設置機器が一時的に Z 市拠点設置機器と接続されるように設定を変更し，オンライン業務開始前の早朝に，店舗サーバと新本部サーバ間で発注情報送信テストを実施する。

表 1 発注情報処理

各店舗サーバから送信された発注情報に基づいて，本部サーバの発注情報ファイル及び経営者が意思決定に使用する経営情報データベース（以下，経営情報 DB という）を更新する。本社社員が，更新された発注情報ファイルを本社業務端末から参照し，仕入先に対して商品を発注する。

下線（ア）は案 1 のテストのあとの切り戻しである。戻し忘れると，店舗の発注情報はまだ本番でない新本部サーバに送られ続け，現本部サーバの発注情報ファイルは更新されない。

本社社員は現本部サーバの発注情報ファイルを見て仕入先に発注している。店舗が送った発注がそこに載らないので，仕入先に正しく発注できず，店舗に商品が届かなくなる。講評のとおり，「データベースが更新されない」で止めず，業務への影響まで書く。

50字。解答例は「現本部サーバの発注情報ファイルが更新されず，仕入先に対して正しく商品発注が行われない。」で42字など3つ。どれも「仕入先への発注が正しく行われない」まで書いている。

採点講評（IPA）

設問1は，業務への影響の観点からインシデントの内容を問うたものの，単にデータベースが更新されないといったシステム上の事象の指摘にとどまった解答が少なからず見られた。また，設問2についても，システム作業におけるリスクの観点からの解答が多かった。ITサービスマネージャとして，顧客へのサービスを管理及び提供する視点の重要性を認識して，業務を遂行してほしい。

本文の根拠

冒頭

C 社の事業年度は 4 月から翌年 3 月までで，決算月の 3 月には毎年，全店舗で決算セールを行っており，3 月の来店客数と売上高は通常月の約 2 倍となっている。

〔全体スケジュールの検討〕

その結果，早ければ 3 月に移転切替えが可能であったが，4 月の第 4 水曜日に決定した。

3 月は決算セールで，来店客数も売上高もふだんの約 2 倍になる。この月に切り替えて不具合が起きれば，発注や売上の管理が滞り，影響が一番大きくなる。

スケジュールの上では 3 月でも間に合ったが，あえて繁忙期を避けて 4 月にした。講評のとおり，システム作業のリスクではなく，顧客へのサービスや業務への影響の観点から理由を書く。

55字。解答例は「C社の売上高が多い時期を避けることで，移転切替えで不具合が発生した場合の業務影響を小さくできるから」で48字。「売上高（来店客）が多い時期を避ける」と「不具合時の業務影響を小さくする」をつなげる。

本文の根拠

〔移転切替え当日の作業スケジュールの検討〕

テープ媒体に順次データを取得し，全ての移行対象データの取得完了後，Z 市拠点へ運搬する。

表 4

項番1 発注情報ファイル，項番2 売上情報集約ファイル，項番3 売上情報ファイル（注1），項番4 経営情報 DB。

データは現本部サーバからテープに取り，運んで新本部サーバに入れる。途中で抜けや取り違えがあれば，入れた先の件数が元と合わなくなる。

移行対象の 4 種類それぞれについて，元の現本部サーバ（またはテープ）の件数と，新本部サーバに入った件数が一致しているかを確かめれば，漏れがないと判断できる。

55字。解答例は「移行対象データ4種類のデータ件数が，現本部サーバと新本部サーバで一致していることを確認する。」で45字。「4 種類」「件数」「どことどこを比べるか」を入れる。

採点講評（IPA）

設問3(1)は，多くの受験者が移行対象データの現新比較には着目できていたが，移転切替え当日に拠点間で連絡を取りながら実施する具体的内容に欠く解答が目立った。(3)は，設問の文中で除外対象として挙げているにも関わらず，移行対象データの移送方式を指摘する解答も見られた。移行計画の立案に当たり，考慮すべき前提条件を正確に把握することの重要性を認識してほしい。

本文の根拠

表 1 売上情報処理

売上情報レコードのバックアップのために，毎週月曜日の 8 時に各店舗サーバから本部サーバに，過去 1 週間分の売上情報レコードから成る売上情報ファイルを送信する。

〔全体スケジュールの検討〕

4 月の第 4 水曜日に決定した。

表 3

2 時 50 分 売上情報ファイル（注1）40 分

前日までに移せるのは，切替えまでに中身が変わらないデータである。発注情報ファイルはオンライン中に随時，売上情報集約ファイルは毎晩，経営情報 DB は毎晩のバッチで更新されるので，当日まで変わり続ける。

売上情報ファイルだけは，毎週月曜日の 8 時に 1 週間分がまとめて送られてくる。切替えは水曜日なので，その週の月曜日に届いたあとは水曜日まで変わらない。月曜日 8 時以降，前日までに移しておける。

答えは項番「3」。表 3 で一番時間の掛かる 40 分と 30 分の作業なので，当日の短縮効果も大きい。

本文の根拠

〔販売管理システムの概要〕

これによって，現本部サーバで 120 分掛かっている夜間バッチ処理が，Z 市拠点に新たに導入されるサーバ（以下，新本部サーバという）では 80 分に短縮される見込みである。

表 3

0 時 00 分：Y 市拠点で夜間バッチ処理，120 分。2 時 00 分：移転切替え作業開始。2 時 00 分：Y 市拠点で現ルータ電源切断，10 分。

表 3

5 時 40 分：Z 市拠点で新ルータ電源投入（注2）・起動確認，10 分。

表 3 で順番に並んでいる作業のうち，同時にできるものや，速い場所に回せるものを探す。移送方式の工夫は除くという条件である。

ア群：現本部サーバで 120 分掛かる夜間バッチを，データ移行のあとに新本部サーバで 80 分で行う。イ群：現ルータの電源切断，または新ルータの電源投入・起動確認のどちらかを，データ移行作業と並行して行う。ウ群：その 2 つの両方をデータ移行作業と並行して行う。

55字。(b)と同じ群の組合せで答える。ルータの作業は VPN の切替えだけで，データの取得や投入とは関係しないので並行できる。

本文の根拠

表 3

6 時 50 分：移転切替え作業完了。

ア群：夜間バッチを移すと，0 時からデータ移行を始められる。ルータ切断 10 分，取得 100 分，運搬 50 分，投入 60 分，ルータ投入 10 分で 3 時 50 分，バッチ 80 分で 5 時 10 分，確認 60 分で 6 時 10 分。6 時 50 分より「40」分早い（120 分と 80 分の差）。

イ群：ルータの作業 1 つ（10 分）が並行になるので「10」分。ウ群：2 つとも並行なので「20」分。

(a)と同じ群の数値を答える。ア群ならバッチ 120 → 80 分の差がそのまま効き，他の作業の順番を入れ替えても合計は変わらない。

本文の根拠

表 2 項番2

災害発生時には，社長を対策本部長とする対策本部を設置し，意思決定機関として BCP の実施を指揮する。対策本部長の下に生産，販売といった機能別のチーム体制を編成し，情報システム部からは T 部長が対策本部に加わる。

〔事業継続計画の検討〕

プロジェクトでは，北陸に地震が発生し，交通の混乱，通信障害及び大規模停電によって，本社，工場及び DC-A が 1 週間稼働できない事態を想定した。

想定は北陸の地震で，交通の混乱や通信障害が起きる。社長をはじめ，決められた人が対策本部にすぐ集まれるとは限らない。

集まれない人がいても本部が動くよう，あらかじめ代わりの要員を決めておく。あるいは，集まれた人数で役割をどう分けるかを決めておく。

35字。解答例は「予定された要員を招集できない場合に備えて代替要員を定める。」（28字）と「要員が不足する場合は，招集できた要員で役割分担を決める。」（27字）の2つ。

採点講評（IPA）

設問1は，代替要員の必要性に着眼していない解答が多く，正答率が低かった。災害が発生した当初は，関係者全員を招集できるとは限らない。そこで，事業継続計画においては，構成要員の一部が対策本部に参集できない場合を想定し，要員のバックアップ体制に関する検討が必要であることを理解しておいてほしい。

本文の根拠

〔事業継続計画の検討〕

災害発生から 3 時間以内に待機系システムで販売管理システムのオンライン機能を正常に使用できるようにすることを，事業継続の要件として取り決めた。

〔事業継続計画の検討〕

また，当日のオンライン開始から災害発生までに登録された注文情報については，販売部が注文伝票を基に再入力することとした。

RTO は，何時間以内に使えるようにするかである。要件は「災害発生から 3 時間以内に待機系でオンライン機能を正常に使える」なので，a は「3 時間」。

RPO は，どの時点のデータまで戻すかである。当日のオンライン開始から被災までに入った注文は，販売部が伝票から入れ直す。つまりシステムで戻すべきなのは，当日のオンライン開始の時点まででよい。b は「当日のオンライン開始」。

a は 5 字，b は 15 字以内。b は「前日の日次バッチ終了」でも中身は近いが，本文の再入力の範囲に合わせて書く。

採点講評（IPA）

設問2(1)は，RTOについての正答率は高かったが，RPOについての正答率が低かった。サービス継続マネジメントを行う上で基本となる，RPOやRTOの定義については，是非理解しておいてほしい。

本文の根拠

表 1

週次バッチ処理（注2）：2-1 業務日付（注1），受注情報及び受注実績のバックアップを取得して，取得情報を DC-B のファイルサーバに転送する，1 時間。

表 1 注2）

週次バッチ処理は，毎週金曜日の日次バッチ処理終了後に実行される。

〔サービス継続計画の作成〕

サービス継続計画が発動された場合は，待機系システムを起動し，転送済みのバックアップから必要なデータをリストアした上で，待機系システムに切り替える予定である。

待機系は DC-B に転送済みのバックアップから戻す。ところが DC-B に送っているのは週次バッチの 2-1 で，金曜日の夜だけである。月曜日に被災すると，金曜日の時点までしか戻せず，RPO の「当日のオンライン開始」に届かない。

2-1 を毎日の日次バッチに移せば，毎晩 DC-B にバックアップが届く。受注情報と受注実績を作る 1-3 が終わったあとに実行すれば，その日の確定分まで含められる。バッチの時間枠は 9 時間で，日次の 6 時間 5 分に 1 時間を足しても収まる。

50字。解答例は「ジョブ番号2-1を週次バッチ処理から日次バッチ処理に変更し，ジョブ番号1-3の後に実行する。」で45字。「日次に変える」ことと「どのジョブのあとか」を書く。

本文の根拠

〔サービス継続計画の作成〕

また，平常運用フェーズではオンラインの応答時間の目標値を 3 秒以内としているが，業務再開フェーズと業務回復フェーズでは待機系システムでのサービス提供になるので，応答時間の目標値は 5 秒まで許容することにした。

業務再開フェーズでは待機系で販売管理システムを動かす。機能が動くことに加えて，サービスとして使える速さが出ているかも確かめる必要がある。

本文では，業務再開フェーズと業務回復フェーズの応答時間の目標を 5 秒と決めている。待機系でこの 5 秒以内が守れているかを確認する。

35字。解答例は「販売管理システムのオンラインの応答時間が5秒以内であること」で28字。平常時の 3 秒ではなく，このフェーズの目標値 5 秒を書く。

採点講評（IPA）

設問3(1)は，正答率が低く，サービスの設計経験に乏しい受験生が多いと類推された。ITサービスマネージャは，サービスの設計段階で，情報システムの機能面だけではなく，性能要件などの非機能面についてのサービス仕様の定義が必要であることを認識してほしい。

本文の根拠

表 3

項番3 業務回復：サービス運用の拡大，生産管理システムの起動及び提供サービスの正常稼働確認，実機訓練。項番4 全面復旧：全面復旧手順の確認，c，実機訓練。

〔主要システムの構成〕

ただし，DC-B は仮想サーバで構築されている関係から，待機系システムが稼働する際は売上分析システムの停止が必要になる。

全面復旧は平常運用に戻すフェーズである。業務再開フェーズで行ったことを逆にたどればよい。

業務再開では，売上分析システムを止め，待機系を起動して切り替えた。全面復旧では，販売管理システムを DC-A の本番系に切り戻し，止めていた売上分析システムを起動し直し，それぞれのサービスが正常に動くことを確かめる。

55字。解答例は「販売管理システム（本番系システム）への切り戻し，売上分析システムの起動及び提供サービスの正常稼働確認」で49字。表 3 の他の行と同じ「〜の起動及び提供サービスの正常稼働確認」の形でそろえる。

本文の根拠

〔販売管理用端末の増設〕

本番系システムの設定変更を待機系システムへ反映する作業については，変更をできるだけ早く展開する必要があるが，売上分析システムの稼働スケジュールとの関係から，3 か月に 1 回設けられている売上分析システムの次回定期保守日に行うことにしている。

〔販売管理用端末の増設〕

規定に従い，本番系システムの変更に合わせて，“待機系システムの変更に必要なリリース”及び“リリースの展開に必要な関連文書”を，DC-B に設置されているファイルサーバに格納し，DC-B の情報システム部員に通知した。

〔サービス継続計画の試験〕

原因は，売上分析システムの定期保守日に実施予定であった変更リリースが展開される前に試験を実施したからであり

待機系への変更の反映は，3 か月に 1 回の定期保守日にまとめて行う。そのため，次の保守日までは本番系の変更が待機系に入っていない期間がある。試験ではこの状態で切り替えたので，増設した端末が使えなかった。

本当の災害も保守日を待ってはくれない。リリースと関連文書は DC-B のファイルサーバに届いているので，業務再開フェーズの切替え前に，待機系に未実施の変更がないかを確かめ，あれば展開するかを判断して，必要なら展開する。

55字。解答例は「待機系システムに未実施の変更がある場合は，切替え前までに当該リリースの展開実施判断を行い，必要ならば展開する。」で53字。「確認→判断→展開」の順にし，「切替え前まで」と時点を書く。

本文の根拠

〔E 社のサービス要求管理プロセス〕

また，サービス要求の内容がバッチ処理作業依頼の場合は，F 社のオペレーションチームに転送して処理してもらう。

〔E 社のサービス要求管理プロセス〕

SD では，サービス要求への対応を行い，サービス利用者に対応結果を回答する。

バッチ処理の依頼は，SD がサービス利用者から受け付けて，オペレーションチームに転送する。オペレーションチームがバッチ処理を終えたら，その結果を利用者に返すのも SD の役目である。

オペレーションチームが直接利用者に連絡すると，SD が進み具合を把握できず，完了報告もできない。終わった旨は，依頼を回してきた SD に連絡する。

10字。解答例は「SD 又は サービスデスク」。本文では「SD」と略しているので，どちらで書いてもよい。

本文の根拠

〔E 社のサービス要求管理プロセス〕

SD では，サービス要求が受入基準を満たしているかどうかを判断し，基準を満たしていれば要求を受け付ける。このとき，決められた診断手順に従い，要求の優先度を判断する。

〔経理システムの統合〕

また，E 社の経理部は，現在は担当者が直接臨時バッチ処理を実行していることから，統合経理システムの利用に当たり，臨時バッチ処理を SD 経由ではなく，直接オペレーションチームに作業依頼したいとのことであった。

SD はサービス要求を「受入基準」で受け付けるか決め，「診断手順」で優先度を決める。統合経理システムの臨時バッチ処理は，これまで経理部が自分で実行していて，SD では扱ったことがない。

利用開始までに，臨時バッチ処理の依頼を受けるための受入基準や，優先度を判定できる診断手順，処理を見分けて回すための手順を SD に用意しておく必要がある。

30字。解答例は「要求内容の優先度が判定できる診断手順の作成」（21字）など3つ。どれも本文にある SD のプロセス（受入基準・診断手順）のうち，臨時バッチ処理の分が欠けていることを突いている。

採点講評（IPA）

設問1(2)は，単純な手順の整備や問合せ対応の体制を作るなどの一般的な解答が多く，正答率は低かった。サービスデスクで作業依頼を受け付けるために必要な準備作業について，サービス要求管理プロセスで必要としている作業内容に着目して正解を導き出してほしかった。

本文の根拠

表 2

③売上の当日集計値，経理部担当者の確認用（注2）。

表 1 注1）

通知は，警告と異常以外でシステムの運用に必要なメッセージを対象とする。

F 社の基準では，通知は「システムの運用に必要なメッセージ」に限る。表 2 の通知 3 つを見ていく。

①バッチの正常終了と②通信の正常接続は，運用で確かめるメッセージで基準に合う。③売上の当日集計値は，経理部の担当者が業務の数字を確かめるためのもので，システムの運用には関係しない。

答えは「③」。④は問われている項目なので除く。⑤⑥は異常で，F 社の基準の異常（正常に運用されていない状態）に合っている。

採点講評（IPA）

設問2(1)は，オペレータの負担を考えて正常なメッセージの出力を抑止するなど，運用管理システムの機能を利用しただけの解答が多く見られた。システムの受入れに当たり，運用監視基準に沿った運用ができることが重要であることを意識しておいてほしい。

本文の根拠

表 2 注2）

E 社では日次バッチ処理の結果を経理部担当者が確認している。業務で確認が必要な数値を出力して，担当者が確認している。

〔統合経理システムの監視〕

本番運用されている各システムが出力するメッセージは，運用管理システムに集約される。集約されたメッセージは，F 社の運用監視基準に従って種類分けされて，オペレータに通知される。

③は業務の担当者が数字を確かめるためのメッセージである。これまでは経理部の部門コンピュータで動いていたので，担当者の画面に出ればよかった。

統合後はメッセージがすべて運用管理システムに集まり，オペレータに届く。オペレータには要らない業務用の確認メッセージで，F 社の通知・警告・異常のどれにも当たらない。

30字。解答例は「顧客業務用の確認メッセージを出力しているから」（22字）と「出力すべきメッセージ種類のどれにも該当しないから」（24字）の2つ。

採点講評（IPA）

設問2(1)は，オペレータの負担を考えて正常なメッセージの出力を抑止するなど，運用管理システムの機能を利用しただけの解答が多く見られた。システムの受入れに当たり，運用監視基準に沿った運用ができることが重要であることを意識しておいてほしい。

本文の根拠

〔統合経理システムの監視〕

オペレータは通知されたメッセージを監視し，対応が必要な場合は，定められた対応を行う。

〔経理システムの統合〕

統合経理システムの機能要件は F 社開発チームのアプリケーション担当が，非機能要件はインフラ担当がそれぞれ設計を行う。

③の集計値は経理部の業務には必要なので，なくすわけにはいかない。問題は，それが運用監視のメッセージとしてオペレータに流れることである。

業務で使う数字は，アプリケーションの機能として経理部の担当者向けに出す（帳票や画面にする）。運用管理システムへの通知メッセージとしては出さない。こうすればオペレータの監視対象から外れる。

40字。解答例は「業務用メッセージはアプリケーションで作成し，通知メッセージは出力しない。」（35字）など2つ。「業務の数字を残す方法」と「通知から外す」の両方を書く。

採点講評（IPA）

設問2(1)は，オペレータの負担を考えて正常なメッセージの出力を抑止するなど，運用管理システムの機能を利用しただけの解答が多く見られた。システムの受入れに当たり，運用監視基準に沿った運用ができることが重要であることを意識しておいてほしい。

本文の根拠

〔経理システムの統合〕

インフラ担当は，メモリの使用状況などを分析し，オンライン業務に影響が及ぶことが想定される場合は，S 氏に連絡し，各社の経理部と臨時バッチ処理の使用制限について調整する。

〔統合経理システムの監視〕

警告のしきい値は，監視要件に基づいて設計・設定されている。統合システムの警告のしきい値については，F 社開発チームのインフラ担当が設計・設定を行う。

しきい値は，インフラ担当が監視要件に基づいて，オンライン業務に影響が出る前に気付けるように設計したものである。

オペレータの負担を減らすために緩めると，本当にオンラインに影響が出るときも警告が出なくなるおそれがある。今は「影響がない」と判断できているが，しきい値を変えるならその影響をもう一度評価し直さないと，安定稼働を保証できない。

40字。解答例は「しきい値変更に伴うオンラインへの影響を再評価する必要があるから」で30字。「オンラインへの影響」と「再評価」の2語を入れる。

本文の根拠

〔オペレーション業務の見直し〕

なお，障害などインシデントの発生に備えて，可能要員数に対する必要要員数の比率は常に 90％以下に抑える必要がある。

〔オペレーション業務の見直し〕

次に，統合データウェアハウスの運用方法について調べたところ，バッチ処理が多いことから，4 時から 8 時までの間，平均して 0.5 人の要員数が必要なことが分かった。

図 1

4 時〜6 時 3 人，6 時〜8 時 3.5 人

統合データウェアハウスが加わると，4 時〜8 時の必要要員数が 0.5 人増える。4 時〜8 時の可能要員数は 4 人である。

4 時〜6 時は 3 ＋ 0.5 ＝ 3.5 人で，3.5 ÷ 4 ＝ 87.5％，90％以下に収まる。6 時〜8 時は 3.5 ＋ 0.5 ＝ 4 人で，4 ÷ 4 ＝ 100％になり，90％を超える。

40字。解答例は「6時から8時の間は可能要員数に対する必要要員数の比率が90％を超えるから」で36字。時間帯と「90％を超える」ことを書く。6 時〜8 時が高いのは，バックアップの確認作業 1 人分がここに入っているからである。

採点講評（IPA）

設問3(1)は正答率が高く，運用作業負荷が集中する理由はおおむね理解されているようであった。一方，(2)の解決策については，新システム受入れのためだけにシフト勤務を見直すといった解答が多く見られた。与えられた制限を十分に理解して解答してほしかった。

本文の根拠

〔オペレーション業務の見直し〕

したがって，再処理時間を考慮し，早番の勤務時間帯でバックアップが取得できているかどうかを確認する必要がある。現在は，バックアップ処理完了後の 6 時から 8 時までの 2 時間で，この確認作業を平均して 1 人で行っている。

〔システムの運用体制〕

シフト時間帯は 6 時から 15 時までの早番，14 時から 23 時までの遅番，22 時から翌朝 7 時までの深夜番となっている。

図 1

8 時〜12 時 3 人，12 時〜16 時 4 人

バッチの時間は動かせないので，6 時〜8 時にあるバックアップの確認（2 時間，1 人）をずらす。確認は早番（6 時〜15 時）のうちに行う決まりがある。

8 時〜12 時は可能 3 人で，今の 2.5 人に 1 人足すと超える。12 時〜14 時は可能 4 人・必要 2.5 人で，1 人足しても 3.5 ÷ 4 ＝ 87.5％に収まる。移したあとの 6 時〜8 時は 3.5 − 1 ＋ 0.5 ＝ 3 人，3 ÷ 4 ＝ 75％になる。

40字。解答例は「バックアップ処理結果の確認作業の開始を12時からに変更する。」で29字。14 時からは遅番との引継ぎで早番の範囲を外れるので，12 時開始が早番内で収まる。