平成21年度 秋期 午後Ⅰ

本文の根拠

〔Web サイト運用サービスの概要〕

A 社と B 社は，Web サイト運用サービスの目標サービスレベルを取り決めて SLA として締結する予定である。SLA 締結に先立って，B 社では，表に示すサービスレベルの管理項目を，サービス開始時点から計測することにした。

表

B 社の目標値

表の値はまだ SLA ではなく「B 社の目標値」である。これから A 社と合意する目標値が妥当かどうかは，実際にどこまで達成できているかを見なければ決められない。

本文は「SLA 締結に先立って」「サービス開始時点から計測する」と書いている。締結前から測るのは，実績を材料にして目標値の達成度合いを確かめ，無理のない値で合意するためである。

30字。解答例は「サービス実績から目標値達成度合いを確認したいから」で24字。「実績」と「目標値の達成度合い」の2語を残せば伝わる。

採点講評（IPA）

設問1 (2)は，正答率が低かった。“予備機への切替えにはA社のシステム担当者の承認が必要”というルールがあるため，重大インシデントの回復時間には，B社だけでなくA社の判断プロセスも含まれている。サービス提供者側の回復プロセスを対象にサービスレベルの目標値設定を行うことに気づかない受験者が多く，ITサービスマネジメントの実務経験は少ないことが推察された。

本文の根拠

〔Web サイト運用サービスの概要〕

本番機から予備機への切替えに要する時間は 60 分間で，予備機から本番機への切戻しの際のサービス停止時間は 5 分間である。

〔Web サイト運用サービスの概要〕

予備機への切替えは，A 社のシステム担当者である K 部長又は L 課長の承認を得てから実施する。

表 項番3

B 社が重大インシデントを検知してから，障害が回復するまでの時間，90 分以内

回復時間の目標は検知から 90 分で，予備機への切替えそのものに 60 分掛かる。残りは 30 分しかない。その中に「A 社の K 部長か L 課長の承認を得る」時間が入る。2人とも連絡が付かなければ，B 社にはどうすることもできないまま目標を超えてしまう。

B 社が責任を持てるのは B 社の作業だけである。そこで，A 社側の事情で遅れる部分をルールで切り離す。取り方は2通りある。連絡が取れないときは B 社の判断で切り替えてよいとするか，承認待ちの時間を回復時間に数えないとするかである。

50字。解答例は「A社のシステム担当者と連絡が取れない場合は，B社の判断で予備機への切替えを行えること」で42字。どちらの案でも，「どういう場合に」「何を許す（除く）か」の2つを入れる。

採点講評（IPA）

設問1 (2)は，正答率が低かった。“予備機への切替えにはA社のシステム担当者の承認が必要”というルールがあるため，重大インシデントの回復時間には，B社だけでなくA社の判断プロセスも含まれている。サービス提供者側の回復プロセスを対象にサービスレベルの目標値設定を行うことに気づかない受験者が多く，ITサービスマネジメントの実務経験は少ないことが推察された。

本文の根拠

表 項番2

重大インシデント（注1）発生の連絡時間，B 社が重大インシデントを検知してから，A 社に連絡するまでの時間，15 分以内

表 注1）

Web サイトの閲覧が継続して 3 分以上不可能となるサーバ側の障害を，重大インシデントと定義する。

〔AP サーバの障害〕

Web サイトを閲覧できない状況が 3 分以上継続しており

下線（イ）の「閲覧できない状況が 3 分以上継続」は，表の注1）の重大インシデントの定義そのものである。つまりこの時点で重大インシデントと確定している。

重大インシデントには「検知から 15 分以内に A 社に連絡する」という目標がある。本文では T 氏が障害を診断し，復旧方法を決め，K 部長に電話したのはそのあとである。復旧方法の検討を始める前に，まず A 社へ発生を知らせないと 15 分を守れない。

30字。解答例は「重大インシデントが発生したことをA社に連絡する。」で24字。「重大インシデント」という語を使うと，表の項番2を踏まえていることがはっきりする。

本文の根拠

〔Web サイト運用サービスの概要〕

予備機から本番機への切戻しの際のサービス停止時間は 5 分間である。

〔Web サイト運用サービスの概要〕

B 社は，A 社からの問合せや故障の申告を受け付けるほかに，Web サイト上の“お知らせ”のコンテンツを更新して，Web サイトシステムの利用者への各種アナウンスも行う。

切戻しでは 5 分間サービスが止まる。障害ではなく B 社が計画して止めるのだから，いつ止めるかを顧客である A 社と決めてから行うべきである。

止める日時が決まったら，利用者にも前もって知らせる。B 社のサービスには「お知らせ」を更新して利用者にアナウンスする業務が含まれているので，それを使える。

40字。解答例は「サービス停止スケジュールをA社と調整して利用者にアナウンスする。」で31字。「A 社との調整」と「利用者への告知」の2つをそろえる。

本文の根拠

〔Web サイト運用サービスの概要〕

Web サイトシステムを構成するハードウェアの保守は，B 社がハードウェアベンダの C 社に委託する。ハードウェアに故障が発生した場合は，C 社が修理や交換を行う。

〔HDD の冗長化〕

A 社は B 社に対して，RAID 5 を構成する HDD に故障が発生した障害の場合でも，5 時間以内で復旧するように要求した。B 社は，A 社の要求にこたえるためには，ハードウェア故障の復旧において C 社から安定したサービスを受ける必要があると考え

A 社は B 社に「HDD 故障でも 5 時間以内に復旧」を求めた。しかし HDD を交換するのは B 社ではなく，保守を委託されている C 社である。C 社が何時間で来てくれるかが決まっていなければ，B 社は 5 時間を約束できない。

B 社から見ると C 社は供給者である。A 社と B 社の間で目標値を決めるのと同じように，B 社と C 社の間でも HDD 故障時の回復時間の目標を決めて合意しておく。

30字。解答例は「HDD故障時の回復時間の目標値を設定し，合意する。」で25字。「具体的に」とあるので，「HDD 故障時」「回復時間」まで書く。

採点講評（IPA）

設問3では，サービス提供者と供給者の関係を正しく認識していない解答が多く，正答率は低かった。B社はA社に対するサービス提供者であり，C社はB社に対する供給者である。ITサービスマネージャとして，サービスレベルの目標値設定にあわせて，サービスが確実に提供されるように，供給者管理が必要なことを理解してほしい。

本文の根拠

〔HDD の冗長化〕

RAID 5 を構成する HDD に故障が発生した障害の場合でも，5 時間以内で復旧するように要求した。

C 社との目標値は，B 社が A 社に約束する値を支えるためのものである。C 社の回復時間に，B 社の診断や連絡，リストア後の確認などの時間を足して，A 社が求める 5 時間に収まっていなければ意味がない。

したがって，C 社と取り決める目標値は，A 社から B 社への要求（5 時間以内）と整合しているかを確かめて決める。

40字。解答例は「B社とC社が設定する目標値はA社がB社に要求した回復時間と整合していること」で37字。どの目標値とどの要求の整合かを，社名を入れて書き分ける。

採点講評（IPA）

設問3では，サービス提供者と供給者の関係を正しく認識していない解答が多く，正答率は低かった。B社はA社に対するサービス提供者であり，C社はB社に対する供給者である。ITサービスマネージャとして，サービスレベルの目標値設定にあわせて，サービスが確実に提供されるように，供給者管理が必要なことを理解してほしい。

本文の根拠

〔Web サイト運用サービスの概要〕

A 社と B 社は，Web サイト運用サービスの目標サービスレベルを取り決めて SLA として締結する予定である。

〔Web サイト運用サービスの実施状況〕

B 社は SLA 締結に向けて必要なプロセスを実施するとともに，SLA 締結後も PDCA サイクルを実行して，継続的にサービスレベルの改善を行う方針とした。

今ある表の値は「B 社の目標値」で，B 社が自分で決めた値にすぎない。SLA はサービス提供者と顧客が合意した約束なので，締結するには，目標値を決めて A 社と B 社の双方が合意する段階が要る。

合意した値は，締結後の PDCA で継続的に管理していく。本文が締結後の改善まで触れているので，「合意したうえで管理する」までを1つの流れとして書く。

40字。解答例は「サービスレベルの目標値を設定し，A社とB社の双方が合意した上で管理する。」で36字。「双方の合意」が SLA の中心なので必ず入れる。

本文の根拠

〔キャパシティ管理の実施状況〕

表 2 に示す基準値を上限として管理している。基準値を超えると，パフォーマンスが急激に悪化するおそれがある。

〔キャパシティ管理の実施状況〕

表 2 に示すリソース管理項目ごとに設定されている警告値を超えると，運用管理システムから警告が出される。

基準値は「超えるとパフォーマンスが急激に悪化するおそれがある」上限である。警告を基準値ちょうどで出すと，気付いた時点ですでに悪化が始まっている。

警告値を低めに置けば，基準値に届く前に知らせが来る。そのあいだにチューニングやリソースの増強などの手を打てる。

30字。解答例は「パフォーマンスが悪化する前に是正処置がとれるから」で24字。「悪化する前に」「手を打てる」の2つがあればよい。

採点講評（IPA）

設問1 (3)は，正答率が低く，変更管理プロセスやキャパシティ管理プロセスそのものを記述した誤答が多かった。ITサービスマネージャとして，関連するサービスマネジメントプロセスの連携について理解しておいてほしい。

本文の根拠

〔キャパシティ計画〕

サービス面では，IT サービスのパフォーマンスを測定することによって，サービスレベルの要求水準を達成しているかどうかの記録・監視を行う。

〔キャパシティ計画〕

遵守率は，オンライン業務終了後に，販売管理システムのログファイルを分析して確認している。

〔キャパシティ管理の実施状況〕

リソース管理項目として，Web サーバと業務サーバの CPU 使用率及び磁気ディスク使用率を把握し，表 2 に示す基準値を上限として管理している。

警告の対象は CPU 使用率と磁気ディスク使用率だけである。一方，サービスレベルの要求水準はオンラインレスポンスで決まっている。レスポンスはそれ以外の原因でも悪化するので，リソースの値が正常でも要求水準を割ることがある。

しかもレスポンスの遵守率は，オンライン業務が終わってからログで確かめている。方針(2)では「要求水準を達成しているかどうかの記録・監視を行う」としているのに，業務中に監視していない。

35字。解答例は「サービスレベルの要求水準を達成するための監視になっていない。」で30字。どの方針に照らして足りないのかを，「サービスレベルの要求水準」という語で示す。

採点講評（IPA）

設問1 (3)は，正答率が低く，変更管理プロセスやキャパシティ管理プロセスそのものを記述した誤答が多かった。ITサービスマネージャとして，関連するサービスマネジメントプロセスの連携について理解しておいてほしい。

本文の根拠

〔キャパシティ管理の実施状況〕

インシデント管理及び変更管理などの，ほかのサービスマネジメントプロセスと，次の内容で連携して，キャパシティ管理を行っている。

〔キャパシティ管理の実施状況〕

パフォーマンス改善の変更要求を提案する。

〔障害に伴うオンラインレスポンスの悪化〕

変更管理プロセスを通して，機能性・可用性・保守性などの検証を行い，稼働中のサービスへの影響が最小となるようにリスクをコントロールする。

空欄 a は，変更管理との連携の2つめである。1つめの「改善の変更要求を提案する」は，キャパシティ管理から変更を起こす向き。もう1つは逆向きで，他から起きた変更がパフォーマンスにどう響くかを見る役目になる。

本文でも，運用変更（バッチ処理の切り出し）でレスポンスが悪化した。変更管理では機能性・可用性・保守性などを検証するとしているが，パフォーマンスへの影響を変更の計画段階で確かめることが，キャパシティ管理の持ち分である。

30字。解答例は「変更の計画段階でパフォーマンスへの影響を検証する。」で25字。変更管理プロセスの説明を書くのではなく，キャパシティ管理として行う作業を書く。

採点講評（IPA）

設問1 (3)は，正答率が低く，変更管理プロセスやキャパシティ管理プロセスそのものを記述した誤答が多かった。ITサービスマネージャとして，関連するサービスマネジメントプロセスの連携について理解しておいてほしい。

本文の根拠

販売管理システムの構成の説明

片寄せ運用の場合でも，2009 年度のピーク時トランザクション数の予測値を処理できるようにリソース設計されており

〔販売管理システムの運用変更〕

事前に通常の本番構成でピーク時の性能テストを実施した。

〔障害に伴うオンラインレスポンスの悪化〕

業務サーバ A のメモリ使用状況を分析したところ，片寄せ運用時には，オンライン業務の処理中にメモリ使用量がほぼ限界に達していた。

性能テストは「通常の本番構成」，つまり2台のサーバでしか行っていない。実際に悪化したのは，1台が故障して片寄せ運用になり，そこでバッチ処理が動いたときだった。

このシステムは片寄せ運用でもピーク時を処理できるように設計されている。運用を変えるなら，その前提がバッチ処理を足しても成り立つかを，片寄せ運用の状態で確かめる必要があった。

40字。解答例は「片寄せ運用でオンライン業務中にバッチ処理を実行した場合のピーク時の性能検証」で36字。「片寄せ運用」「オンライン業務中のバッチ処理」「ピーク時」の3条件がそろってはじめて今回の事象を再現できる。

本文の根拠

〔障害に伴うオンラインレスポンスの悪化〕

そこにバッチ処理が起動されると，バッチ処理用のメモリ領域を確保するために，ページングが多発していることが判明した。

表 2

Web サーバ CPU 使用率：基準値 80％，警告値 60％。業務サーバ CPU 使用率：基準値 80％，警告値 60％。磁気ディスク使用率：基準値 50％，警告値 40％。

原因はメモリ不足によるページングだった。ところが表 2 の管理項目は CPU 使用率と磁気ディスク使用率だけで，メモリは見ていない。これでは日常の監視で気付けない。

本格対応でもメモリ所要量を設計し直して実メモリを増設するとしているので，増設後も含めて実メモリの使用状況を管理項目に加える。

20字。解答例は「サーバの実メモリ使用状況」で12字。「メモリ使用率」でも意味は同じだが，ページングは実メモリが足りないときに起きるので「実メモリ」と書くと正確になる。

本文の根拠

〔販売管理システムの運用変更〕

現状では，バッチ業務の終了から翌日のオンライン業務開始までの空き時間が少なく，単純にバッチ業務の開始時間を遅らせた場合には，バッチ業務でのトラブルなどの発生時にオンライン業務の開始が遅れてしまうリスクが生じる。

〔障害に伴うオンラインレスポンスの悪化〕

この本格対応実施までの暫定対応として，片寄せ運用になった場合は，オンライン業務中はバッチ処理を実行しないように変更する。

暫定対応では，片寄せ運用中は切り出したバッチ処理を昼に動かさない。動かさない分は夜間のバッチ業務に戻すことになる。

そもそもバッチ処理を切り出したのは，夜間の空き時間が少なく，トラブルがあると翌朝のオンライン開始が遅れるからだった。夜間に戻せば，本文に書かれたこのリスクがそのまま戻ってくる。

35字。解答例は「バッチ業務でのトラブル発生時にオンライン業務開始が遅れる。」で28字。本文の言い回しを使えば，運用変更の理由と結び付けていることが伝わる。

本文の根拠

〔キャパシティ計画〕

この予測は，2009 年度のピーク時トランザクション数を基準（1.0）とした指標で，2012 年度までを予測している。

〔販売キャンペーンの実施計画〕

販売キャンペーン実施に伴い，キャンペーン期間中の業務量が 2 割程度増加すると見込まれていた。

キャパシティ計画の土台は表 1 のピーク時トランザクション数の予測である。キャンペーンで業務量が 2 割増えるなら，その期間のピーク時トランザクション数も予測より増える。

まずキャンペーンを織り込んだピーク時トランザクション数を計算し直し，今の予測値とどれだけ離れるかを把握する。影響の大きさはそこから判断できる。

40字。解答例は「ピーク時トランザクション数を算出して現状の予測値との乖離を把握する。」で34字。「何を算出するか」と「何と比べるか」を書く。

採点講評（IPA）

設問3は，業務量の需要予測に基づいてピーク時トランザクション件数を算出し，現状の予測値との乖離を把握した上でキャパシティ計画を見直すという内容を取り上げている。ITサービスマネージャとして，キャパシティ管理に関するサービスマネジメントの計画立案と導入について，よく理解しておいてほしい。

本文の根拠

〔キャパシティ計画〕

ビジネス面では，IT サービスに対するビジネス要件を検討し，キャパシティを確保するのに必要なリソースを適切なタイミングで実装する。

〔販売キャンペーンの実施計画〕

企画部門では，販売計画の中で，販売キャンペーン実施を前提に，今後 3 年間の需要予測をしている。

企画部門はキャンペーンを前提に3年間の需要予測を立て直している。一方，IT サービス部の表 1 はキャンペーンを考えていない。このまま運用すると，2010 年度以降の 6 月と 12 月にリソースが足りなくなるおそれがある。

方針(1)はビジネス要件に合わせて必要なリソースを適切なタイミングで実装するとしている。したがって，販売計画の需要予測を基にキャパシティ計画そのものを見直す。

40字。解答例は「販売計画の需要予測に基づいてキャパシティ計画を見直す。」で26字。見直しの根拠（販売計画の需要予測）を添えると，(1)の結果を使うことがはっきりする。

採点講評（IPA）

設問3は，業務量の需要予測に基づいてピーク時トランザクション件数を算出し，現状の予測値との乖離を把握した上でキャパシティ計画を見直すという内容を取り上げている。ITサービスマネージャとして，キャパシティ管理に関するサービスマネジメントの計画立案と導入について，よく理解しておいてほしい。

本文の根拠

〔販売管理システムの 1 日の運用スケジュールとオペレーション体制〕

1 シフトは 8 時間で，7 時から 15 時，15 時から 23 時，23 時から 7 時の 3 シフトで 1 日の運用を行っている。

〔販売管理システムの 1 日の運用スケジュールとオペレーション体制〕

各チームの人数は同一とし，運用オペレータの休暇取得やピーク時の応援などのために，常に 1 チーム当たり 1 人分の余裕を見込んだ体制としている。

図 1

9 時〜20 時：オンライン処理，バッチ処理（2）。20 時〜21 時：バックアップ（2）。21 時〜6 時：バッチ処理（1）。6 時〜9 時：予備時間（0）。

まず 1 チームの人数を決める。図 1 で必要人数が最も多いのは 2 人（9 時〜21 時）である。7 時〜15 時と 15 時〜23 時のシフトはどちらもこの時間帯を含むので 2 人要る。チームの人数は同じにそろえ，さらに 1 人の余裕を持たせるので，1 チーム 3 人になる。

次にチームの数である。1 日 3 シフトを 1 チームずつ受け持つので，毎日 3 チームが勤務する。これで 365 日を回しながら，週に 1 日以上の非番を作るには，休みに回るチームがもう 1 つ要る。4 チームあれば，4 日に 1 日は休める。

3 人 × 4 チーム ＝ 12 人。答えは「12」。休憩時間は考えなくてよいという条件なので，1 シフトの 8 時間をそのまま使って構わない。

採点講評（IPA）

設問１は，正答率が低かった。図１と本文記述をよく読めば，解答は容易に導き出せた。

本文の根拠

〔オンラインサービス提供時間の拡大〕

X 社の納品データは毎日 22 時ごろに到着するので，ジョブ J1 の終了後，常に 40 分程度の待ち時間があることが分かった。

〔オンラインサービス提供時間の拡大〕

ジョブ J2 は，ジョブ J1 の終了とファイル“X01”の作成完了の両方が満たされた時点で自動的に起動される。ジョブ J2 の処理時間は 1 時間であるが，そのうち，ジョブステップ S23 の処理時間は 30 分である。

図 3

S23 には F23 のほかに，X 社から送られるファイル X01 も入力される。

図 3 を見ると，X01 を使うのは J2 の最後のステップ S23 だけである。S21 と S22 は J1 が作った F14 から F23 を作るだけで，X01 を待つ必要がない。それなのに J2 全体が「J1 終了と X01 到着の両方」を条件に起動されるので，J1 が終わってから 40 分ほど何もせずに待っている。

そこで，X01 が要らない S21・S22 を J2 から外し，J1 が終わったらすぐ動くようにする。J2 を分けて S22 までを別ジョブにし J1 の終了で起動する方法と，S21・S22 を J1 の S13 のあとに移す方法の，どちらでもよい。

60字。解答例は「ジョブJ2を分割して，ジョブステップS22以前を別ジョブとして分離し，別ジョブをジョブJ1終了時に起動させる。」で53字。「どこで分けるか」と「分けたものを何を合図に動かすか」を必ず書く。

採点講評（IPA）

設問2は，(1)，(2)ともに正答率は高く，ジョブ構成に関する理解度は高いと思われる。

本文の根拠

〔販売管理システムの 1 日の運用スケジュールとオペレーション体制〕

21 時からは夜間バッチ処理を実行する。夜間バッチ処理は 6 時に終了し，その後の 3 時間は，システム変更やバッチ処理のトラブルなどへの対応のための予備時間としている。

〔オンラインサービス提供時間の拡大〕

システム運用部では，3 時間の予備時間は確保した上で，オンラインサービス開始時刻を早めるために，夜間のバッチ処理時間の短縮を検討することとし

X01 は 22 時ごろ届き，J1 はその 40 分前，21 時 20 分ごろに終わっている。今は J2 が 22 時に始まり 1 時間，23 時に終わる。

変更後は，S21・S22（J2 の 1 時間のうち S23 以外の 30 分）を 21 時 20 分から先に済ませておく。22 時に X01 が届いたら S23 の 30 分だけを動かせばよく，22 時 30 分に終わる。30 分早くなるので，夜間バッチの終了は 6 時から 5 時 30 分になる。

3 時間の予備時間は減らさないので，5 時 30 分 ＋ 3 時間 ＝ 8 時 30 分。答えは「8 時 30 分」。取込み処理の間は他の処理が動かないという条件があるので，縮めた 30 分がそのまま全体に効く。

採点講評（IPA）

設問2は，(1)，(2)ともに正答率は高く，ジョブ構成に関する理解度は高いと思われる。

本文の根拠

表

計：19,431，18,694，705，15，17。1 人 1 件当たりの平均対応時間（分）：対応なし 1，連絡だけ 3，ジョブ制御 60，臨時処理 30。

今の対応工数を求める。件数 × 1 件当たりの時間で，対応なし 18,694 × 1 ＝ 18,694 分，連絡だけ 705 × 3 ＝ 2,115 分，ジョブ制御 15 × 60 ＝ 900 分，臨時処理 17 × 30 ＝ 510 分。合計 22,219 分である。

半分にするには 22,219 ÷ 2 ＝ 11,109.5 分減らす。これを対応なしだけで減らすので，1 分の対応を 11,109.5 件減らすことになる。対応なしは 18,694 件なので，11,109.5 ÷ 18,694 ≒ 59.4％。

小数第 1 位を切り上げて「60」％。切り上げなのは，59％では半分に届かないからである。表の「計」の行をそのまま使えば，種類ごとに足し直さなくて済む。

採点講評（IPA）

設問3は，(1)の正答率は低く，単純な計算ミスもあったと思われる。

本文の根拠

〔販売管理システムの運用方法〕

現在のしきい値は，1 年前の，運用管理システム導入時に設定した値となっていて，その後は変更されていない。

〔出力メッセージ対応業務の効率向上〕

しきい値超過で対応方法が“連絡だけ”となった出力メッセージのほとんどは，運用管理システムから出力される，CPU 使用率のしきい値超過による警告メッセージであった。

連絡だけのメッセージは 705 件で，そのうち 652 件がしきい値超過，しかもほとんどが CPU 使用率の警告である。運用管理者に連絡しても，毎回「対応不要」と言われている。

対応不要な警告がこれほど出るのは，しきい値が今の稼働状況に合っていない疑いが強い。しきい値は 1 年前の導入時のまま変えていない。まず，今の CPU 使用率のしきい値が妥当かを調べる。

30字。解答例は「現在設定しているCPU使用率のしきい値の妥当性」で23字。「CPU 使用率」まで絞る。メッセージ全般のしきい値と書くと，何を調べるかがぼやける。

採点講評（IPA）

設問3は，(1)の正答率は低く，単純な計算ミスもあったと思われる。

本文の根拠

〔販売管理システムの 1 日の運用スケジュールとオペレーション体制〕

バックアップは，磁気ディスク上に取得する方が処理時間は早く済むが，災害に備えて遠隔地保管を行うために，磁気テープに取得する。

〔販売管理システムの 1 日の運用スケジュールとオペレーション体制〕

バックアップ取得時は，ジョブ起動コマンド投入オペレーションと磁気テープ装置オペレーションとの連携が必要である。1 人で実行すると 2 時間が必要であり，1 時間以内で終わらせるためには 2 人の運用オペレータが必要である。

〔販売管理システムの 1 日の運用スケジュールとオペレーション体制〕

取得した磁気テープは，宅配業者に委託して，毎翌朝 9 時発で遠隔地に配送している。

2 人が要る時間帯はオンライン処理中とバックアップ中である。オンライン側は設問 3 で扱ったので，残るのはバックアップになる。バックアップが 2 人要るのは，磁気テープ装置の操作とジョブの起動を同時に行うからである。

そこで，磁気ディスクへのバックアップと，テープへのコピーを分ける。ディスクへの取得は速く，テープ装置の操作も要らない。テープへのコピーは 6 時〜9 時の予備時間に回す。テープの配送は翌朝 9 時発なので，それまでにコピーできていれば遠隔地保管は変わらない。機器の増設は要らない。

50字。解答例は「バックアップは磁気ディスクに取得し，予備時間帯にバックアップファイルを磁気テープにコピーする。」で46字。「ディスクに取る」「テープへのコピーを予備時間帯に回す」の2つをそろえる。

採点講評（IPA）

設問4の運用オペレータの省人化を目指した対策としては，設問３のオンライン処理の対策のほかに，バックアップ処理の対策が必要になる。“メッセージ対応処理を標準化する”や“対応マニュアルを作る”といった誤答が多く，実効性の高い業務効率化の対策を解答してほしかった。

本文の根拠

〔電子証明書を利用した認証〕

電子証明書の有効期限は 2〜3 年の間で任意に設定できるが，M 社では，申請日のちょうど 2 年後を有効期限としている。

〔認証システムの運用状況〕

情報システム部では，発行済の電子証明書の有効期限が近づいた場合，利用者に対して，電子証明書の更新を行うように，有効期限の 20 日前に自動的に電子メールで通知している。しかし，更新を忘れる利用者が多く

今の運用では，有効期限の 20 日前にメールを1回送るだけである。いつまでに更新を申し込むかという期限も決めておらず，申し込まない人に催促もしない。

更新の手続は申込書・管理者の承認・情報システム部での発行と何段階もあり，日数が掛かる。更新期限を決めずメール1通で済ませていれば，忘れた人から順に失効していく。

40字。解答例は「電子証明書の更新期限を決めておらず，未更新者への督促も行っていない。」で33字。「期限を決めていない」「督促していない」の2つを並べる。

採点講評（IPA）

設問1では，ITサービスマネージャとして，情報セキュリティを維持しサービスを安定的に稼働させるとともに，システム運用における作業負荷の低減に着目してほしかった。

本文の根拠

〔電子証明書の発行ルール〕

電子証明書の発行作業は手順化されていて，一度に複数の電子証明書の発行が可能であるが，情報システム部では申請される都度，発行作業を行っている。

〔電子証明書を利用した認証〕

電子証明書の有効期限は 2〜3 年の間で任意に設定できるが，M 社では，申請日のちょうど 2 年後を有効期限としている。

有効期限を「申請日のちょうど 2 年後」にしているので，期限は人ごとにばらばらになる。更新も毎日のように少しずつ発生し，情報システム部はそのたびに作業を中断している。

一方で，発行は一度に複数まとめてでき，有効期限も 2〜3 年の間で自由に決められる。期限をたとえば月末や年度末にそろえれば，更新をまとめて1回で処理でき，作業の回数が減る。

40字。解答例は「有効期限をそろえて電子証明書の更新作業回数を減らす。」で26字。「期限をそろえる」ことと，それで「回数が減る」ことの両方を書く。

採点講評（IPA）

設問1では，ITサービスマネージャとして，情報セキュリティを維持しサービスを安定的に稼働させるとともに，システム運用における作業負荷の低減に着目してほしかった。

本文の根拠

〔販売システムの概要〕

社員が利用するモバイル PC と PC のブラウザは，最新のセキュリティパッチが適用されているかどうかが自動的にチェックされ，常に最新版にバージョンアップされる運用としている。

〔認証システムのトラブル発生事例〕

数日前に，あるブラウザに大幅なバージョンアップがあり，最新版のブラウザと電子証明書との組合せが原因となって問題が発生していたことが分かった。

原因は，最新版のブラウザと電子証明書の組合せだった。ブラウザは自動で常に最新版にされる運用なので，販売システムで使えるかどうかを誰も確かめないまま，社員の PC に入ってしまった。

セキュリティパッチを急いで当てる考え方自体は正しい。問題は，業務システムとの動作を事前に検証する段階がないことである。

30字。解答例は「事前検証せずにブラウザを自動更新させている。」で22字。「自動更新」そのものではなく「事前検証なしに」を問題として書く。

採点講評（IPA）

設問2は，正答率が高かった。障害の切分けについては，おおむね理解されているようであった。

本文の根拠

〔電子証明書を利用した認証〕

認証結果はすべて認証ログに記録される。

図 2

日時，利用者 ID，認証可否，接続元 IP アドレス，要求先 URL，ブラウザ情報（注1）。注1）ブラウザの種類とバージョンが記録される。

〔認証システムのトラブル発生事例〕

ある日，前日までは正常に認証できていた PC の一部で販売システムへのログインができなくなるというトラブルが発生し始めた。

「前日までは正常に認証できていた PC」が対象である。認証ログは結果をすべて残しており，項目にはブラウザの種類とバージョンがある。

同じ端末について，正常に認証できていたときのログと，失敗したときのログを並べれば，何が変わったかが分かる。ここではブラウザのバージョンが変わっていたことが見つかる。

30字。解答例は「該当端末で正常に認証が行われたときとの違いを確認する。」で26字。「ブラウザのバージョンを見る」と結論だけ書くより，比べて違いを探すという調べ方を書く。

採点講評（IPA）

設問2は，正答率が高かった。障害の切分けについては，おおむね理解されているようであった。

本文の根拠

〔電子証明書を利用した認証〕

さらに，認証サーバに保存されている利用者 ID ごとの利用可能業務と比較し，認証可否の判定を行う。

図 2

接続元 IP アドレス

〔セキュリティ事故の発生事例〕

配送センタ勤務時に保管していた電子証明書のバックアップデータと利用者 PW を利用して，本来，営業担当者は行わない配送先の変更を行っていたことが分かった。

S 氏は自宅からインターネット経由で入り，配送センタでしか行わない配送先の変更をしていた。今の認証は利用者 ID ごとに業務を絞るだけで，どこから接続しているかは見ていない。

社外からの接続は VPN 装置を通るので，接続元で社内か社外かを見分けられる。社外からは参照業務だけ，というように接続元ごとに使える業務を制限すれば，今回の変更はできなかった。

25字。解答例は「接続元ごとに利用可能業務を制限する。」で18字。「機能」を問われているので，運用ルールではなくシステムで制限する形で書く。

採点講評（IPA）

設問3 (1)は，正答率が低かった。ITサービスマネージャとして，情報セキュリティ維持のためには，情報へのアクセスを許可された人だけが情報を使うことができるようにする機密性の観点での対策が重要であることを理解してほしい。

本文の根拠

〔電子証明書の発行ルール〕

新しく PC を利用する場合や，使用中の電子証明書の有効期限が近づいた場合は，利用者本人が申込書に記入し，所属部署の管理者の承認を得た上で情報システム部に送付し，情報システム部の担当者が新しい電子証明書を発行する。

〔電子証明書の発行ルール〕

M 社では，PC の故障時に備えて，発行済の電子証明書を外部記憶媒体にバックアップし，利用者の責任で鍵付きロッカーに保管しておく取決めになっている。

バックアップは PC が故障したときの備えだった。禁止すると，故障時は一から発行し直すしかない。

今の発行手順は，申込書の記入，管理者の承認，情報システム部の審査，発行用 PW の郵送と手渡しと，日数の掛かる段階が続く。その間，利用者は販売システムを使えず，業務が止まる。

45字。解答例は「PCが故障した場合の電子証明書再発行処理に時間が掛かり，販売システムが利用できない。」で41字。「時間が掛かる」だけで止めず，その結果「販売システムが使えない」まで書く。

採点講評（IPA）

設問3 (1)は，正答率が低かった。ITサービスマネージャとして，情報セキュリティ維持のためには，情報へのアクセスを許可された人だけが情報を使うことができるようにする機密性の観点での対策が重要であることを理解してほしい。

本文の根拠

〔電子証明書の発行ルール〕

利用者本人が申込書に記入し，所属部署の管理者の承認を得た上で情報システム部に送付し

〔電子証明書の発行ルール〕

発行用 ID は電子メールで利用者あてに送付し，発行用 PW は所属部署の管理者あてに郵送する。

〔セキュリティ事故の発生事例〕

利用者本人が直接，情報システム部に電子メールで申請を行い，情報システム部では，申請の電子メールの返信に添付して，新しい電子証明書を本人に送付する手順へ変更することを考えた。

N 課長の案では，申請も受け取りもメールだけで済む。通常の発行では必ず入る所属部署の管理者の承認がない。

また，通常は発行用 ID をメールで，発行用 PW を管理者経由で渡し，2つの経路に分けて本人にしか揃わないようにしている。メールの返信に証明書を付けるだけでは，メールを送ってきたのが本人かどうかを確かめられない。

30字。解答例は「所属部署の管理者の承認を得ていない。」（17字）と「確実に本人確認を行うプロセスになっていない。」（22字）の2つがあり，どちらかを書けばよい。

採点講評（IPA）

設問3 (1)は，正答率が低かった。ITサービスマネージャとして，情報セキュリティ維持のためには，情報へのアクセスを許可された人だけが情報を使うことができるようにする機密性の観点での対策が重要であることを理解してほしい。