平成23年度 秋期 午後Ⅰ

本文の根拠

〔T システムのインシデント対応〕

特定の地域の会員に限って T システムにアクセスできないという連絡内容から，Y 氏は表 1 の T システムの優先度判定ルールを参照し，インシデントの優先度を“中”と判断した。

〔T システムのインシデント対応〕

本日は割引キャンペーンの実施日（以下，キャンペーン日という）であり，キャンペーン情報を掲載するので，迅速な回復をお願いしたい

〔その後の判明事項〕

このような業務特異日にインシデントが発生した場合は，通常日よりも 1 ランク高い優先度を設定し，対応することが，T 社と S 社で合意されていた。

その日はキャンペーン日で，業務特異日にあたる。業務特異日のインシデントは通常より 1 ランク上げる約束になっていた。特定の地域だけの障害なので表 1 では「中」だが，本当は「高」で対応すべきだった。

「高」なら目標復旧時間は 4 時間で，重大なインシデントとしてインシデント解決エキスパートにも通知される。Y 氏は「中」のまま 8 時間を目安に動いたので，回復に 5 時間掛かった。

30字。解答例は「業務特異日であるが優先度を1ランク上げなかった。」で23字。「業務特異日」の語を使い，何をしなかったかを書く。

本文の根拠

〔その後の判明事項〕

T 社は S 社に対して，前日までにキャンペーン日を通知していた。S 社では，当日がキャンペーン日であることを Y 氏に口頭で連絡していたが，Y 氏は障害回復において，キャンペーン日を考慮していなかった。

表 1 注記

項番の小さいものから順に参照し，最初に一致した優先度が適用される。

キャンペーン日であることは Y 氏に口頭で伝わっていた。それでも考慮されなかったのは，業務特異日なら優先度を上げるという取決めが，対応する人に周知されていなかったからである。Y 氏が見た表 1 の優先度判定ルールにも，業務特異日のことは書かれていない。

口頭で伝えるだけでは，今回のように抜け落ちる。誰が対応しても同じ判断になるよう，業務特異日の扱いを優先度判定ルールそのものに書き込む。

根本原因・再発防止策とも 30 字以内。解答例はそれぞれ「業務特異日の取扱いが周知されていなかったこと」（22字），「業務特異日の対応を優先度判定ルールの中に明記する。」（25字）。講評にあるとおり，根本原因に「キャンペーン日を考慮しなかった」と事象を書き写すだけでは原因にならない。

採点講評（IPA）

設問1(2)根本原因については，問題文の事象を転記しただけの解答が散見された。

本文の根拠

〔S 社のインシデント管理〕

⑤ 段階的取扱い（エスカレーション）　次のような場合，責任者は専門部署に回復策の検討を依頼する。・自らの知識・技能では回復策を見いだせない。・目標復旧時間内に，回復できないおそれがある。

〔T システムのインシデント対応〕

Y 氏は，この暫定対策を適用してよいかどうか，すぐには判断できなかった。

〔T システムのインシデント対応〕

Y 氏は別の回復策がないか，抽出された残りのインシデント情報を確認し，上記類似インシデントの原因と同様か，究明を続けた。

受付から 15 分で類似インシデントと暫定対策が見つかったが，Y 氏は使ってよいか判断できなかった。これは「自らの知識・技能では回復策を見いだせない」場合にあたり，専門部署に依頼すべき時点だった。

ところが Y 氏は自分で原因の究明を続け，専門部署に相談したのは 3 時間後に T 社から催促されてからだった。インシデント管理の目的は迅速な回復で，原因の究明は問題管理の仕事である。

30字。解答例は「問題の原因究明を続け，専門部署との連携が遅れた。」で23字。「原因究明を続けた」ことと「専門部署への依頼が遅れた」ことを並べる。

本文の根拠

〔S 社のインシデント管理〕

⑥ 解決　T 社によるサービスの回復確認をもって，インシデントの解決とする。

〔T システムのインシデント対応〕

Y 氏は回復策による処置が正常に終了したことを確認し，当該インシデントの解決を管理システムに記録し

S 社のルールでは，インシデントの解決は「T 社によるサービスの回復確認」をもって決まる。

Y 氏は処置が正常に終わったことを自分で確かめただけで，解決と記録した。T 社はそのあと会員に確認すると答えている。つまり T 社の回復確認より前に解決にしてしまっている。

40字。解答例は「Y氏はサービス回復結果をT社に確認する前にインシデントが解決したと判断した。」で37字。ルールの「T 社による回復確認」との順序の食い違いを書く。

本文の根拠

〔S 社のインシデント管理〕

⑦ T 社とのコミュニケーション　インシデントに関する受付，障害回復処理の開始・完了を，T 社に通知する。また，障害回復処理の進捗状況について，T 社に最新情報を提供する。

〔T システムのインシデント対応〕

会員から障害回復などに関する問合せが何度もあったが，対応状況が分からず，返答に困った。報告が遅すぎるのではないか

S 社の説明

IT サービス部は，10 名で構成されている。

ルールでは T 社に進捗の最新情報を提供することになっている。しかし Y 氏は 1 人で調査と診断を抱え込み，T 社に状況を伝えられなかった。

調査・診断に集中する人と，T 社への連絡を受け持つ人を分ければよい。IT サービス部には 10 名いるので，Y 氏の他にもう 1 人割り当てられる。講評にあるとおり，「進展があったら報告する」では，進展がない間は何も伝わらず改善にならない。

50字。解答例は「Y氏の他にITサービス部員を割り当て，T社とのコミュニケーション対応と調査・診断の作業を分担する。」で48字。人を足すことと，役割をどう分けるかの両方を書く。

採点講評（IPA）

設問2(2)は，T社への報告タイミングや報告間隔に関して，“回復処理に進展があった時点で報告する。”のように改善策とならない解答が見受けられた。インシデントの影響を受けた顧客に対するコミュニケーションの重要性について理解しておいてもらいたい。

本文の根拠

〔障害に関する月次報告書の改善〕

最近，障害発生件数は減少しているが，同じような障害が何回も発生している。障害回復までに時間が掛かる上，根本的な対策が打たれているのかどうか疑問であり，不安である

図 1

(2) 障害回復：回復（暫定対応）方法と回復時間。

T 社の不安は「同じ障害が繰り返される」「根本的な対策が打たれているのか分からない」ことである。

今の報告書は障害の事象と，暫定対応による回復までしか書いていない。今回の通信プログラムの修正のように，根本原因と再発防止策がどう進んでいるかは載っていない。これを加えれば T 社の疑問に答えられる。

30字。解答例は「障害の根本原因を識別し，再発防止策の実施計画を報告する。」で27字。「具体的に」とあるので，「根本原因」と「再発防止策の計画」の両方を入れる。

採点講評（IPA）

設問3(1)は，正答率が高かった。T社への報告内容として，インシデント管理についてだけでなく，根本原因や再発防止策に関して追加する必要性について，おおむね理解されているようである。

本文の根拠

〔T システムのインシデント対応〕

インシデントの受付から 15 分後に，一部地域で発生した類似インシデントの存在を突き止めた。

〔その後の判明事項〕

今回のインシデントに対しては，システムを利用する側の PC の電源断／再投入によってサービスを回復できることが，S 社のサービスを利用している他社類似システムの暫定対策から分かった。

今回の障害は PC の電源を入れ直せば回復できた。しかしそれを知っていたのは S 社側で，会員から最初に連絡を受ける T 社は何もできずに待つしかなかった。

S 社はこうした暫定対策の知識を持っている。障害を早く回復させるための暫定対策をまとめて T 社に渡しておけば，T 社が会員に案内でき，回復が早まる。講評にあるとおり「PC の再起動を会員に試してもらう」は T 社の立場の対応で，S 社の提案にはなっていない。

30字。解答例は「障害回復を早期化させるための暫定対策を整備し，提示する。」で27字。S 社が T 社に「何を整えて渡すか」を書く。

採点講評（IPA）

設問3(2)については，PCの再起動を会員に試してもらうなど，S社が行うべき提案内容としてふさわしくない解答が散見され，正答率は低かった。問題の趣意をよく理解して解答を導いてほしかった。

本文の根拠

表 2

PC 会員：1.0，0.9，0.8，0.7。携帯会員：0.5，1.2，1.9，2.6。

表 3

PC：1.0，携帯電話：1.2。

表 4

CPU 使用率（ピーク時）：Web サーバ（1 台当たり）しきい値 80，測定値 48。

Web サーバの負荷は，トランザクション数に 1 件当たりの CPU 使用時間の比率を掛けたものに比例する。現在は PC 1.0 × 1.0 ＋ 携帯 0.5 × 1.2 ＝ 1.6，1 年後は PC 0.9 × 1.0 ＋ 携帯 1.2 × 1.2 ＝ 2.34 である。

現在の 1.6 で CPU 使用率が 48％なので，1 年後は 48 × 2.34 ÷ 1.6 ＝ 70.2％。小数第 1 位を四捨五入して「70」。

講評では，表 3 の比率を使わずに計算した誤答が多かった。比率を掛けないと 48 × 2.1 ÷ 1.5 ≒ 67 になり，携帯会員が増える影響を少なく見積もってしまう。

採点講評（IPA）

設問1(1)の“WebサーバのCPU使用率”については，WebサーバのCPU使用時間の比率を使用せずに算出していると思われる解答が散見され，正答率が低かった。トランザクション数，CPU使用時間の比率及びCPU使用率の関係をよく理解して解答を導き出してほしかった。

本文の根拠

〔予約システムの構成〕

ディスクドライブは現在，10 台搭載されており，1 台当たりの容量は 300 GB である。

表 5

座席マスタファイル：200 GB，取扱い座席数の増加に伴い，現在の 1.2 倍になる。会員マスタファイル：300 GB，会員数の増加に伴い，現在の 1.4 倍になる。座席予約ファイル：700 GB，座席予約件数の増加に伴い，現在の 1.5 倍になる。

表 4

磁気ディスク使用率：磁気ディスク装置（全体）50，40。

1 年後の使用量は，200 × 1.2 ＋ 300 × 1.4 ＋ 700 × 1.5 ＝ 240 ＋ 420 ＋ 1,050 ＝ 1,710 GB。しきい値は 50％なので，容量は 1,710 ÷ 0.5 ＝ 3,420 GB 以上要る。

1 台 300 GB なので，3,420 ÷ 300 ＝ 11.4 台。台数は切り上げて 12 台。いま 10 台あるので，増設は「2」台。

検算：現在は 1,200 GB ÷ 3,000 GB ＝ 40％で，表 4 の測定値と一致する。12 台なら 1,710 ÷ 3,600 ≒ 47.5％，11 台だと 1,710 ÷ 3,300 ≒ 51.8％でしきい値を超える。

本文の根拠

〔新サービスに向けたテスト〕

本番環境と同じシステム構成で，過負荷用シミュレータを用いた性能テストを行い，良好な結果を得た。

〔新サービスに向けたテスト〕

大量の座席予約データを参照するので，CPU 負荷が高い。処理時間は，通常 5 分程度である。本番環境と同じシステム構成で，予約状況表示プログラムの機能テストを行い，良好な結果を得た。

〔応答遅延の発生〕

トランザクションのピーク時間帯に，AP サーバで予約状況表示プログラムが実行されていた

性能テストと，予約状況表示プログラムのテストは別々に行われていた。性能テストにはプログラムの負荷が入っておらず，プログラムのほうは機能テストしかしていない。

遅延は，ピーク時間帯に AP サーバでこのプログラムが動いたときに起きた。本番で起こりうる状態をそろえるなら，ピークを想定した性能テストの最中にプログラムを実行して，応答を確かめるべきだった。講評にあるとおり，プログラム単体の性能テストでは同時に動くときの影響が見えない。

40字。解答例は「予約システムの性能テスト実施中に，予約状況表示プログラムを実行する。」で33字。2つを「同時に」行うことが要点になる。

採点講評（IPA）

設問2は，性能テスト方法に関する設問であるが，予約状況表示プログラム自体の性能テストを行うなどの誤った解答が散見された。本番時に想定される負荷条件をそろえて行う性能テストの意義と，性能テストに代表される非機能要件テストの重要性を理解しておいてもらいたい。

本文の根拠

〔予約システムの構成〕

なお，PC 会員及び携帯会員のトランザクションのピーク時間帯は，いずれも 10 時から 11 時までである。

〔新サービスに向けたテスト〕

このプログラムは，座席予約状況リストが必要になるたびに営業部が起動し，AP サーバ上で実行される。

予約状況表示プログラムは営業部が必要なときに起動する。CPU を多く使うので，10 時〜11 時のピーク時間帯に重なると応答が遅れる。

暫定的な回避策なので，システムの改修ではなく運用で避ける。営業部と調整して，ピーク時間帯にかかる時間には起動しないように決める。処理は 5 分程度なので，10 時の少し前から起動を控えることになる。

35字。解答例は「予約状況表示プログラムのピーク時間帯にかかる実行を禁止する。」で29字。「ピーク時間帯に実行しない」だけでなく「かかる」まで書くと，10 時直前の起動も含められる。

採点講評（IPA）

設問2は，性能テスト方法に関する設問であるが，予約状況表示プログラム自体の性能テストを行うなどの誤った解答が散見された。本番時に想定される負荷条件をそろえて行う性能テストの意義と，性能テストに代表される非機能要件テストの重要性を理解しておいてもらいたい。

本文の根拠

〔キャパシティ管理〕

安定したサービスを提供するために，予約システムの各サーバの CPU 使用率，メモリ使用率，磁気ディスク装置全体としての磁気ディスク使用率についてしきい値を設定して管理している。

〔応答遅延の発生〕

新サービスの試行を開始してから約 1 か月後，携帯会員から“応答が遅い”という苦情があった。

今の管理項目は CPU・メモリ・ディスクの使用率だけである。今回の問題は応答が遅いことで，それが分かったのは会員からの苦情だった。発生は 1 週間後から続いていたのに，システム部は気付いていなかった。

応答の遅れを直接見る項目がなければ，また苦情が来るまで分からない。応答時間を管理項目に加える。

字数の指定はない。解答例は「応答時間」。リソースの使用率がしきい値内でも応答は遅くなりうるので，サービス側の指標を別に持つ。

採点講評（IPA）

設問3(1)は，正答率が高かった。キャパシティ管理は，パフォーマンス及びキャパシティの全ての課題に対し中心となって取り組む必要のあることを理解しておいてもらいたい。

本文の根拠

〔キャパシティ管理〕

また，これらの使用率を定期的に測定し，この測定結果を基に，各リソースの増設要否を判断している。

(1)で応答時間を管理項目にした。予兆をつかんで手を打つには，測るだけでなく，どこまで遅くなったら対処するかの基準が要る。

CPU 使用率などと同じように，応答時間にもしきい値を設け，それを超えたかどうかで判断する。しきい値を苦情が出る水準より手前に置けば，悪化が目立つ前に対応できる。

30字。解答例は「応答時間のしきい値を判定条件として設定する。」で22字。「しきい値」と「判定条件」の2語で，予兆の検知として仕組み化することを示す。

本文の根拠

〔販売管理システムのアカウントの管理〕

C 氏は，毎月月末の ID 一覧表更新作業に合わせて，削除申請のあった利用者 ID をシステムから削除する。

削除の申請が来ても，実際に消すのは月末の一覧表の更新に合わせてである。月初に退職した人の ID は，1 か月近く使える状態で残る。

退職者の ID が残っていれば，本人や他人が不正に使うおそれがある。申請を受けたら，月末を待たずにすぐ削除する。

30字。解答例は「削除申請のあった利用者IDをすぐにシステムから削除する。」で27字。「問題の解決策」を問われているので，「すぐに」で問題点（削除が遅い）を裏返す。

採点講評（IPA）

設問1は，正答率が高かった。アカウント管理の基本的な考え方については理解されていると考えられる。

本文の根拠

〔販売管理システムのアカウントの管理〕

上長は，社員への利用者 ID 付与が必要と判断した場合，社員からの利用者 ID 付与申請書を承認した上で，システム部の利用者 ID 管理者である C 氏に送付する。

〔販売管理システムのアカウントの管理〕

A 社では社員の退職などによって利用者 ID が不要になった場合には，上長が，利用者 ID の削除を申請する。

削除は上長の申請で行う。上長が申請を忘れれば，要らない ID が残り続ける。申請の手続だけでは，そうした漏れは見つからない。

どの ID が今も必要かを分かっているのは部下を持つ上長である。C 氏がシステムに登録されている利用者 ID を全部抜き出し，各上長に登録内容が正しいか確かめてもらえば，漏れを補える。

40字。解答例は「システムに登録されている全ての利用者IDを抽出し，登録内容を確認すること」で35字。「上長に依頼する作業」なので，C 氏が一覧を出し，上長が確かめるという分担で書く。

採点講評（IPA）

設問1は，正答率が高かった。アカウント管理の基本的な考え方については理解されていると考えられる。

本文の根拠

〔販売管理システムのアカウントの管理〕

管理を簡素化するために，システム部全員で，一つの特権 ID を共用している。特権 ID を使用する場合は，個人の利用者 ID でサーバにログインし，切替コマンドで個人の利用者 ID から特権 ID に切り替える仕組みにしている。

〔セキュリティ要件〕

情報漏えいなどの問題が発生した場合に，アクセス元，アクセス者，アクセスされた情報などを調査するために，全てのサーバのアクセスログを 1 年間保存する。

特権 ID はシステム部全員で 1 つを共用している。特権 ID で直接ログインすると，誰が操作したのかがログから分からない。

先に個人の利用者 ID でログインしてから切り替えれば，その特権 ID を使ったのが誰かが記録に残る。問題があったときに，アクセス者を調べられる。

25字。解答例は「特権IDの利用者を特定できるようにしたいので」で22字。「共用」だから個人の特定が要る，という流れを押さえる。

採点講評（IPA）

設問1は，正答率が高かった。アカウント管理の基本的な考え方については理解されていると考えられる。

本文の根拠

〔注文受付システムの見直し〕

同一の a から複数の b へのログが短時間に大量に発生している場合，ポートスキャンの有無を調査する。

図 2

日時，発信元 IP アドレス，発信元ポート番号，宛先 IP アドレス，宛先ポート番号，プロトコル，アクション。

ポートスキャンは，1 つの攻撃元から，相手のポートを次々に試して，どのサービスが開いているかを探る手口である。

FW のログで言えば，同じ「発信元 IP アドレス」から，いくつもの「宛先ポート番号」への通信が短時間に並ぶ。FW は HTTPS 以外を遮断するので，これらはアクションが Drop や Reject のログとして残る。

項目は図 2 から選ぶ。a が「発信元 IP アドレス」，b が「宛先ポート番号」。発信元ポート番号は送る側が適当に選ぶ値なので，攻撃の目印にはならない。

採点講評（IPA）

設問2では，FWのログを取得し，外部からの攻撃の有無を調査する方法を取り上げている。ポートスキャンなど具体的な攻撃手段についても理解しておいてもらいたい。

本文の根拠

〔セキュリティ要件〕

アクセスログとして保存する項目のうち，顧客情報などの個人情報は，必要最小限にする。

〔注文受付システムの見直し〕

新たに DB アクセスログを作成して，利用者 ID，イベントタイプ，日時，成功／失敗，対象データのキー項目などを保存する。

DB 更新ログはリカバリのためのログで，更新したデータの中身をそのまま持っている。顧客 DB の更新なら，顧客の個人情報がそっくり入る。

セキュリティ要件は，アクセスログに入れる個人情報を必要最小限にするとしている。DB 更新ログを 1 年間残すとこれに反するので，キー項目など調査に要る項目だけの DB アクセスログを別に作った。

30字。解答例は「多くの個人情報を含んでいてセキュリティ要件に反するので」で26字。「セキュリティ要件から」とあるので，要件に反することを書く。

本文の根拠

〔セキュリティ要件〕

全てのサーバのアクセスログを 1 年間保存する。

〔注文受付システムの見直し〕

ディスク容量の制約から 1 か月ごとに，アクセスログをログサーバのディスクに直近 1 か月分を残したまま，磁気テープに退避して保管する。

セキュリティ要件では，アクセスログを 1 年間保存しなければならない。一方でログサーバのディスクは容量に限りがあり，1 年分を置いておけない。

そこで直近 1 か月分だけをディスクに残し，それより古いものは磁気テープに移して保管する。テープへの退避は，容量が足りない中で 1 年間の保存を守るための手段である。

35字。解答例は「ディスク容量の制約がある中で，ログの1年間保存に対応するため」で29字。講評のとおり，テープへの退避を改ざん防止と答えるのは誤り。直近 1 か月分はディスクに残っているので改ざんは防げない。

採点講評（IPA）

設問3(2)は，正答率が低かった。アクセスログは1か月間ディスクに保管されているので，1か月ごとに磁気テープに退避することが，アクセスログの改ざんの防止対策にはならない。問題文中のセキュリティ要件とログの管理運用を照らし合わせて，解答を導き出してほしかった。

本文の根拠

図 1

LAN1：外部接続セグメント。LAN2：非武装セグメント。LAN3：内部セグメント。

〔セキュリティ要件〕

保存したアクセスログの改ざん・削除の防止対策を実施する。

〔Web サーバのコンテンツ改ざん〕

インターネットから Web サーバのセキュリティホールが攻撃可能な状態になっていたので，Web サーバに侵入され，コンテンツが改ざんされてしまった。

LAN2 は非武装セグメントで，インターネットから Web サーバにアクセスできる場所である。実際に Web サーバは侵入されて改ざんされている。

同じセグメントにログサーバを置けば，侵入者がそこからログサーバにも入り，ログを書き換えたり消したりできてしまう。侵入の証拠を消されれば調査もできない。セキュリティ要件の改ざん・削除の防止に反する。

40字。解答例は「外部から不正アクセスによって，ログを改ざん，削除されるおそれがある。」で33字。「外部から」と「改ざん・削除」の2つを入れる。

本文の根拠

〔注文受付システムの見直し〕

このとき，FW のパケットフィルタリング機能で，HTTPS のパケットだけを許可する。

〔Web サーバのコンテンツ改ざん〕

システム部で調査したところ，FW の設定は正しく行われていたが，HTTPS を利用して改ざんされていたことが判明した。

〔Web サーバのコンテンツ改ざん〕

ただし，解析処理に多くの CPU 資源を使用することから，ネットワークトラフィックが増加すると，侵入検知機能が停止してしまうおそれがあるので，IDS の設置場所と，その設置場所に応じた処理能力の検討が必要である。

攻撃は FW が許可している HTTPS で Web サーバに届いた。IDS で見るべきは，FW を通り抜けて Web サーバに向かう通信である。

LAN1 は FW の外側で，FW が捨てるはずの通信まで全部流れてくる。トラフィックが多く，IDS の処理が追い付かずに止まるおそれがある。LAN3 には Web サーバがなく，攻撃が届く場所ではない。LAN2 なら，FW が許可した通信だけを解析すればよい。

場所は「LAN2」。理由は 40 字以内で，解答例は「FWが許可するパケットだけを解析することで，IDSの負荷が軽減されるので」で36字。本文が処理能力に触れているので，負荷の観点から書く。

採点講評（IPA）

設問4では，侵入検知システムの導入を取り上げている。実効性を高めるためには，処理能力などの技術的な留意点を踏まえた検討が必要になることを理解しておいてもらいたい。

本文の根拠

〔バッチ処理の概要〕

ジョブ番号 1-2 又は 2-1 が異常終了したままでは，データに不整合が生じてオンラインを正常に開始できなくなる。不整合を解消するためには直前のバックアップからデータをリストアする必要がある。

〔バッチ処理の概要〕

いずれかのジョブが異常終了した場合は後続ジョブを自動的には起動させない。

〔バッチ処理の概要〕

したがって，日次バッチが異常終了した場合でも，次回のオンラインを開始するまでに正しい業務日付に更新しておく必要がある。

1-2（加工・集計）が異常終了すると，データが途中まで書き換わった不整合な状態になる。これを解消するには，直前のバックアップ（1-1 で取ったもの）から，リストアジョブでデータを戻す必要がある。

さらに，異常終了すると後続の 1-3（業務日付の更新）は自動では動かない。業務日付が古いままではオンラインを正しく始められないので，1-3 を手動で実行する。

①・②とも 20 字以内。解答例は①「リストアジョブを実行する。」（13字），②「ジョブ番号1-3を実行する。」（14字）。①はデータの不整合，②は業務日付と，本文で理由が別々に書かれている2点を拾う。

本文の根拠

表 3 項番3

メンテナンス作業は，オンライン時間帯及びバッチ処理中に行えないので，毎月 10 日の 3 時を開始時刻として，連続 7 時間のメンテナンス作業時間を確保し，セキュリティパッチの適用などを行う。

〔オンライン時間帯の拡大〕

販売管理システムのオンライン時間帯を 9 時から 23 時までに拡大することにした。販売管理システムのオペレーション管理を担当している N 氏は，メンテナンス作業の開始時刻を変更せず

メンテナンスは毎月 10 日の 3 時から連続 7 時間，つまり 10 時まで確保している。今まではオンラインが 11 時からだったので収まっていた。

6 月からオンラインは 9 時に始まる。メンテナンスの開始は 3 時のままなので，使えるのは 3 時〜9 時の 6 時間しかない。6 月 10 日，つまり 1 か月以内のメンテナンスで 7 時間を確保できなくなる。

30字。解答例は「システムのメンテナンス時間を連続6時間しか確保できない。」で27字。「1 か月以内に」とあるので，次の 10 日に起きることを，時間の数字で書く。

採点講評（IPA）

設問2(1)及び(2)は，正答率が高かった。システムの運用スケジュールを管理する場合は，日次以外の処理や，処理時間が増加傾向であるかについても着目する必要性があることを理解しておいてほしい。

本文の根拠

表 2

項番2：月次バッチ，毎月 1 日，3 時，4 時間。

〔バッチ処理の実行スケジュール〕

しかし，今後の売上拡大計画が達成された場合，1 年後にはデータ量が増加し，表 2 の処理時間枠に収まらなくなると見込んでいる。

表 3 項番2

リカバリの所要時間は，月次バッチが異常終了した場合に最大（1 時間 40 分）となる。

〔オンライン時間帯の拡大〕

バッチ処理の実行結果確認を 7 時に変更した上で

月次バッチは 1 日の 3 時から 4 時間枠で，7 時に終わる。実行結果の確認は 7 時に始めることにした。確認に 20 分，月次バッチのリカバリに最大 1 時間 40 分掛かり，足すと 7 時 ＋ 2 時間 ＝ 9 時で，オンライン開始にちょうど間に合う計算である。

ところが 1 年後はデータが増えて，月次バッチが 4 時間枠に収まらない。7 時に確認を始められず，異常終了していればリカバリが 9 時に間に合わない。講評にあるとおり，日次以外の処理や処理時間の伸びにも目を向ける設問である。

40字。解答例は「月次バッチ処理が異常終了した場合は，オンラインを定刻に開始できない。」（33字）と「バッチ処理の実行結果確認の開始時刻までに月次バッチが終了しない。」（31字）の2つ。

本文の根拠

表 1

月次バッチ：2-1 加工・集計（販売データ），2-2 バックアップの取得（在庫データ，販売データ，業務日付データ）。

表 1

1-4 バックアップの取得（在庫データ，販売データ，業務日付データ）。

表 1 注記1

各ジョブの処理時間は，処理対象データ量に比例する。

月次バッチの 2-1 が書き換えるのは販売データだけである。それなのに 2-2 では在庫データと業務日付データまでバックアップしている。

月次バッチは日次バッチのあとに動き，日次の 1-4 で3種類ともバックアップ済みである。在庫と業務日付は 2-1 で変わらないので，2-2 で取り直す必要はない。2-2 を販売データだけにすれば，処理時間はデータ量に比例して短くなる。

30字。解答例は「ジョブ番号2-2のバックアップ対象を販売データだけにする。」で28字。講評のとおり，開始時刻を早める案は所要時間の短縮にならない。

採点講評（IPA）

設問2(3)は，月次バッチの所要時間の短縮方法に関する設問であるが，月次バッチの開始時刻を早めるなどの誤った解答が多かった。このような問題には，バックアップの内容がバックアップの目的に合わせて正しく取得されているか，不要に取得されている内容はないかといった実務的視点から対策を立ててもらいたい。

本文の根拠

図 1

シフト A は 7 時から 12 時まで勤務，12 時から 13 時まで休憩，13 時から 15 時まで勤務。シフト B は 11 時から 16 時まで勤務，16 時から 17 時まで休憩，17 時から 19 時まで勤務。シフト C は 15 時から 17 時まで勤務，17 時から 18 時まで休憩，18 時から 23 時まで勤務。

〔オペレーション体制の見直し〕

7 時から 23 時までの時間帯に，休憩中のオペレータを除いても常時，2 名以上がオペレーションできる状態で勤務する体制を，U 部長に提案した。

7 時〜11 時はシフト A しか勤務していないので，A は 2 名要る。19 時〜23 時は C しかいないので，C も 2 名要る。

11 時〜15 時は A の 2 名がいるが，どちらかが休憩すると 1 名になる。休憩は必ずシフト内で取るので，その間を埋める人が要り，B が 1 名必要になる。B の休憩は，A か C が 2 名とも勤務している時間にずらせばよい。15 時〜19 時は C の 2 名と B の 1 名で，同じように休憩をずらせる。

答えは A「2」，B「1」，C「2」。B を 0 にすると 11 時〜15 時の A の休憩中が 1 名になり，条件を満たせない。

本文の根拠

〔バッチ処理の機能変更〕

N 氏は，ジョブ管理製品のバージョンアップを急いでいたので，オペレーション手順書の更新は後日行うことにした。

〔トラブルの発生〕

X 氏は，販売管理システムのオペレーション手順書を見ながら作業を行った。ところが，操作端末の表示画面は，オペレーション手順書の記載と異なっており，X 氏は N 氏に電話で確認しながら作業を進めざるを得なかった。

バージョンアップで画面が変わったのに，手順書の更新は後回しにされた。担当のオペレータは慣れていたので困らなかったが，別の担当の X 氏は手順書どおりに操作できず，時間が掛かった。

手順書を製品と一緒に変わる対象として扱い，本番にリリースするときは手順書も必ず最新にしてから出す。リリースのたびに手順書を更新することを，プロセスに組み込む。

40字。解答例は「本番リリースを行う際には，オペレーション手順書を常に最新の内容に更新する。」で36字。講評のとおり，手順書などの文書も変更対象の構成品目として管理する，という考え方に立って書く。

採点講評（IPA）

設問3(2)は，システムの変更を本番リリースするプロセスの改善について取り上げている。ITサービスマネージャは，システム運用オペレーションが正確に実施されるために，オペレーション手順書などの文書も変更対象の構成品目として管理することの重要性を，是非知っておいてもらいたい。