令和7年度 春期 午後Ⅰ

本文の根拠

冒頭

インシデントの解決時間は最長で 7 時間 40 分も掛かっており，SLA の目標値達成が危ぶまれる状況になっている。

表1

インシデント解決時間について，重大インシデントは3時間以内，通常インシデントは8時間以内。

〔改善活動の実施〕

表2，表3及び表4の活動を可視化，分析し，インシデントを解決する活動の全体像を捉えて課題を発見し，改善することにした。

設問は「Kサービスの提供者の立場から」と断っている。利用者側の「早く使えるようになる」ではなく，提供者として何を守るために改善するのかを答える。

提供者が守るものは表1のSLAである。通常インシデントの目標は8時間以内なのに，先月の実績は最長7時間40分。残りは20分しかなく，本文も「SLAの目標値達成が危ぶまれる」と書いている。改善活動は，この目標を割らないために行っている。

20字に収める。解答例は「SLAの目標値を確実に達成するため」で16字。SLAという語を使わず「インシデントの解決時間を短縮するため」と書いてもよい。

本文の根拠

〔インシデント管理の概要〕

インシデント管理ファイルには，データ項目として，インシデント番号，活動番号，担当者の ID，対応日時（開始日時，終了日時），対応内容などがあり

表4 注記

問題管理ファイルには，データ項目として，問題番号，インシデント番号，活動番号，担当者の ID，対応日時（開始日時，終了日時），問題の内容，回避策，対応内容などがあり

表4 P11

エスカレーションされたインシデントとひも付けて問題管理ファイルに記録する。

2つのファイルのデータ項目を並べて，共通するものを探す。インシデント管理ファイルにも問題管理ファイルにも「インシデント番号」がある。

問題管理ファイルがインシデント番号を持っているのは，表4のP11で「エスカレーションされたインシデントとひも付けて」記録するからである。ひも付けのために置かれた項目なので，これが2つのファイルを結ぶ鍵になる。

「活動番号」「担当者のID」「対応日時」も両方のファイルにあるが，同じものを指していない（活動番号はI11とP11で体系が違い，担当者も別の人）。結び付けに使えるのは，1件のインシデントに1つだけ付く番号である。10字に収まる答えは「インシデント番号」で8字。

本文の根拠

冒頭

先月は，重大インシデントはなかったが，通常インシデントが 200 件発生した。

図1

I31 で回避策が見つからなかった場合は I41（30%）10分 → I71（30%）80分 へ進む。I71 で回避策が見つかった場合は I72（10%）10分を経て I52（30%）100分から I61 へ合流する。I71 で回避策が見つからなかった場合は P11（20%）5分

図1 凡例

（100%）は200件のインシデントに対する割合

図1の割合は，母数が200件のインシデントである。

aはエスカレーションを行った件数。エスカレーションは活動番号I41で，図1では30%。200×0.30＝60件。

bは開発課で回避策が見つからなかった件数。I71で回避策が見つからなかったときに進むのがP11で，図1では20%。200×0.20＝40件。

読み違いは検算で防げる。開発課に渡ったのはI71の30%で，そのうち回避策が見つかったのがI72の10%，見つからなかったのがP11の20%。10＋20＝30でI71と合う。合わなければ割合の拾い方を間違えている。

本文の根拠

表1

通常インシデントは8時間以内

図1

I11（100%）5分 → I21（100%）5分 → I31（100%）15分 と進み，回避策が見つかった場合は I51（70%）100分 → I61（100%）15分 → I62（100%）15分 で終了する。

図1

I71 で回避策が見つからなかった場合は P11（20%）5分 → P21（20%）140分 → P22（20%）15分を経て I52 へ合流する。

3つのパスについて，通る活動の平均実施時間を足す。

パス1（表2だけ）は 5＋5＋15＋100＋15＋15＝155分，2時間35分。

パス2（表2と表3）は 5＋5＋15＋10＋80＋10＋100＋15＋15＝255分，4時間15分。

パス3（表2と表3と表4）は 5＋5＋15＋10＋80＋5＋140＋15＋100＋15＋15＝405分，6時間45分。

通常インシデントの目標は8時間以内なので，パス3だけが残り1時間15分まで迫っている。パス1とパス2は倍近い余裕がある。優先して分析すべきなのはパス3である。

40字にはパス番号と「6時間45分」（または目標との近さ）を必ず入れる。「パス3が一番時間が掛かるから」では，目標値との関係が言えていない。

採点講評（IPA）

設問2(3)は，正答率が平均的であった。パス3に時間がかかっていることだけを記述した解答が多かった。SLAの目標値達成が危ぶまれる状況を踏まえ，インシデントの解決目標時間に対して，他のパスと比較してパス3を優先すべき具体的な理由を解答してほしい。

本文の根拠

〔インシデント管理の概要〕

活動番号 I41 でエスカレーションを行った場合，オペレーターは I41 の終了日時にエスカレーションの電子メールの発信日時を登録する。

表3 注1

活動を開始するときに担当者はインシデント管理システムを使ってエスカレーションされたインシデント番号を基にインシデント管理ファイルを検索し，“担当者の ID”に自らの社員番号を登録する。“担当者の ID”が登録されるとインシデント管理システムは“開始日時”を記録する。

〔インシデント対応の分析〕

それ以降の活動番号の実施時間は，一つ前に実施した活動番号の終了日時と当該活動番号の終了日時との時間差とした。

「作業待ち」とは，サービスデスクがエスカレーションしてから開発課が手を付けるまでの空き時間である。この2つの時刻はどちらもインシデント管理ファイルに入っている。

I41の終了日時が，エスカレーションの電子メールを出した時刻。I71の開始日時が，開発課の担当者が自分の社員番号を登録した時刻。この差が，送ってから着手するまでの待ち時間になる。

図1でI71が80分と長いのも，これで説明がつく。実施時間の数え方が「一つ前の活動の終了日時から当該活動の終了日時まで」なので，待っていた時間もI71に含まれてしまう。I71を調べるのに作業待ちを疑うのは，この数え方から来ている。

30字。解答例は「I41の終了日時とI71の開始日時の時間差の状況」で25字。「作業待ち時間を調べる」では，どのデータを見るのかが言えていない。

採点講評（IPA）

設問3(1)は，正答率がやや低かった。改善が必要な課題を正確に把握するため，作業待ちの発生状況をシステムで記録された定量的なデータから，何をどのように調査する必要があるのか具体的に解答してほしい。

本文の根拠

表2 I31

既知の誤りの調査（I31）は解決担当者が既知の誤りを調査して回避策を探し，見つかれば手順“解決”を，見つからなければ手順“エスカレーション”を行う。

表3 I71

インシデントの再調査（I71）はサービスデスクからエスカレーションされたインシデントを調査し，開発課又は運用チームの担当者は既知の誤りを調査して回避策を探す。

図1

I71 で回避策が見つかった場合は I72（10%）10分を経て

サービスデスクのI31と開発課のI71は，どちらも「既知の誤りを調査して回避策を探す」で，見ている問題管理ファイルも同じである。同じ作業を2回している。

差が出るのは結果のほうである。サービスデスクが見つけられずエスカレーションしたのは60件（30%）。そのうち開発課が見つけたのはI72の10%で20件。同じファイルを見ているのに，60件のうち20件は開発課でだけ見つかっている。

本来サービスデスクで解決できたはずの20件が，エスカレーションを経て余計な時間を使っている。これが課題である。

50字には件数を入れる。「サービスデスクと開発課が同じ活動をしている」だけでは，どれだけ無駄が出ているかが言えていない。

採点講評（IPA）

設問3(2)は，正答率が低かった。サービスデスクと開発課で同じ活動をしていることだけを指摘する解答が散見された。本来サービスデスクで発見すべき回避策が開発課で多く発見されているという状況から，具体的な改善の課題を解答してほしい。

本文の根拠

〔改善策の検討〕

M ツールは，開発課が問題管理ファイルへの回避策の登録・検索をする目的で開発したツールで，サービスデスクでも，そのツールを使用している。

〔改善策の検討〕

ベテランオペレーターは M ツールの高度な検索機能を使っていたが，新人オペレーターは検索機能を使いこなせていなかった。

冒頭

サービスデスクは担当者（以下，オペレーターという）の離職率が高く，経験の浅いオペレーターも多い。

空欄cには，ツールについての根本的な対策で，かつ開発課に依頼できる内容が入る。

Mツールはもともと開発課が自分たちのために作ったもので，サービスデスクはそれを借りて使っている。作りが開発課向けなので，新人オペレーターには検索機能が使いこなせない。

ベテランは開発課要員とのやり取りの中で，たまたま使い方を覚えた。だがサービスデスクは離職率が高く経験の浅い人が多いので，この偶然に任せたままでは人が入れ替わるたびに元へ戻る。だから開発課に頼んで，仕組みとして手当てする。

30字。オペレーター向けに検索しやすいツールを作ってもらう（解答例1）か，開発課からMツールの使い方を教える場を設けてもらう（解答例2）のどちらでもよい。

本文の根拠

表1 項番8

8 稼働しているアプリケーションプログラムの不具合の改修は開発課／S チーム。

〔Tサービスの開発と運用における課題〕

T6 サービスは，今後も反復アプローチに基づいた開発が継続する状況にあり，開発課は機能追加の開発に専念する必要がある。

表1のT6サービスの列を上から見ると，Sチームが担うのは項番4〜9である。監視・障害対応，運用改善，リリースと展開，インフラ運用，信頼性向上への取組——ここまでは運用の仕事で，運用経験があれば足りる。

1つだけ違うのが項番8「稼働しているアプリケーションプログラムの不具合の改修」で，これはプログラムを直す仕事である。T1〜T5サービスでは開発課が担っているが，T6サービスでは開発課が機能追加に専念するため，Sチームに回ってくる。だから開発の業務経験が要る。

30字。解答例は「アプリケーションプログラムの不具合の改修を実施するから」で26字。表1を指して「表1項番8の業務内容を行う必要があるから」と書いてもよい。「開発から運用までのライフサイクル全般に関わるから」では，開発経験が要る仕事を名指しできていない。

採点講評（IPA）

設問1は，正答率がやや低かった。Sチームが開発から運用までのライフサイクル全般に関わる点だけに着目した解答も多かった。T6サービスに着目して，U社SREチームの要員には，運用だけではなく開発の業務経験も必要な理由を解答してほしい。

本文の根拠

表3 項番2

2 EB が 3 分以下となった場合，S チームと開発課で協議を行って，翌日から稼働環境へのリリース作業を凍結し，信頼性回復のための改善活動を開始する。

表1 注1

リリースには機能追加に対応して行う定期リリースと不具合修正を行う緊急リリースがあり

表3の項番2は「リリース作業を凍結」としか書いていない。ところが表1の注1のとおり，リリースには定期リリースと緊急リリースの2種類があり，緊急リリースは不具合を直すためのものである。

このまま全部を止めると，EBがひっ迫している最中に障害が起きても直せなくなる。信頼性を守るために凍結したのに，かえって信頼性を下げてしまう。だから緊急リリースだけは凍結の対象から外す，という例外が要る。

30字。解答例は「故障対応などの緊急リリースを行う必要があるから」で22字。

本文の根拠

〔試行運用の開始〕

当日の EB の回復とは“過去に発生したサービス停止事象が対象日（当日）を含む過去 30 日間から外れたので，EB に追加する当該事象のサービス停止時間のこと”である。

表4

4月2日は99.998％，14分，1分，機能追加に伴う定期リリース作業として T6 サービスの停止及び起動を行った。

表4

5月1日は99.970％，2分，0分，無し。

EBは「前日のEB − 当日の消費 ＋ 当日の回復」で決まる。5月2日は停止が0分なので消費は無い。回復があるかどうかを見る。

対象期間は「対象日を含む過去30日間」である。5月1日の対象期間は4月2日〜5月1日，5月2日の対象期間は4月3日〜5月2日。つまり5月2日になると，4月2日の事象が対象期間から外れる。その停止時間1分がEBに戻ってくる。

2 − 0 ＋ 1 ＝ 3分。

稼働率でも確かめられる。EBが3分ならサービス停止時間の合計は 15 − 3 ＝ 12分で，（43,200 − 12）÷ 43,200 ＝ 0.999722…，小数第4位を四捨五入して99.972％。表4の値と一致する。

本文の根拠

表3 項番2

EB が 3 分以下となった場合，S チームと開発課で協議を行って，翌日から稼働環境へのリリース作業を凍結し，信頼性回復のための改善活動を開始する。

表4

4月25日は99.970％，2分で，停止時間1分の機能追加に伴う定期リリース作業と，停止時間2分の定期リリース作業後に改修の一部が正しく行われていないことが判明したリリース戻し作業の二つの事象がある。

表3の項番2は「EBが3分以下となった場合」「翌日から」と，条件と時期の両方を決めている。表4で条件に当たる日を探す。

4月25日は，定期リリースで1分，リリース戻しで2分の合計3分を消費し，EBが5分から2分になった。3分以下に当たるのはここである。

ルールが「翌日から」なので，開始は4月26日になる。

25字。解答例は「4月25日にEBが3分を下回ったから」で18字。日付と「3分」の両方を入れる。「EBがひっ迫したから」だけでは，なぜ26日なのかが言えていない。

採点講評（IPA）

設問3(2)は，正答率は平均的であった。4月25日にEB（エラーバジェット）が3分を下回った点について解答してほしかったが，部分的な解答も多かった。

本文の根拠

〔Sチームの目標設定〕

定期リリースや緊急リリースの展開に伴って発生する稼働停止の時間及びエラー対処に要した時間を EB から消費させていく運用を行う

表2

SLI は稼働率（％），SLO は 99.965％，算出式は（サービス稼働予定時間 − サービス停止時間）÷ サービス稼働予定時間

「SLOの観点から」と条件が付いているので，稼働率99.965％を守る話に落とす。

表4でEBが減った原因を並べると，W社のクラウド障害（4月17日の5分）を除いて，残りはすべて自分たちのリリース作業に伴う停止である。4月2日，4月4日，4月9日，4月16日，4月25日——1〜2分ずつだが積み上がって，1か月でEBを15分から2分まで減らした。

停止せずにリリースできれば，この消費が無くなる。サービス停止時間が減れば算出式の分子が大きくなって稼働率が上がり，SLOに余裕ができる。

30字。解答例は「リリース作業でのEB消費を防止できるから」のほか，稼働率の低下を防ぐ，障害復旧時間を短縮できる，といった書き方でもよい。

本文の根拠

表3 項番2

S チームと開発課で協議を行って，翌日から稼働環境へのリリース作業を凍結し

表3 項番3

3 リリース作業の凍結解除については，S チームと開発課で協議を行い判断する。

空欄bには「開発課と実施判断について議論したもの」が入る。表3で，Sチームと開発課が協議して決めると書いてあるものを探す。

項番2の凍結も項番3の凍結解除も，判断の対象は稼働環境へのリリース作業をやるかどうかである。EBの残りという数字を見ながら，止めるか再開するかを決められた——これが「EBを使って効果的な議論を行い，信頼性低下のリスクを抑えることができた」の中身になる。

15字。解答例は「稼働環境へのリリース作業」で12字。信頼性回復の改善活動は，Sチームと開発課が主体的に取り組むものであって，やるかどうかを協議するものではない。

採点講評（IPA）

設問4(1)は，正答率がやや低かった。EBを使って効果的な議論を行った点に着目し，稼働環境へのリリース作業について解答してほしかったが，信頼性回復の改善活動といった解答も多かった。

本文の根拠

〔試行運用の振り返り〕

調査したところ，プログラムでエラーが発生していて，リクエストが失敗となっていた。稼働時間を基に算出する稼働率の SLI だけでは，十分でないように感じる。

表2

算出式は（サービス稼働予定時間 − サービス停止時間）÷ サービス稼働予定時間

4月11日に起きたのは，サービスが止まったことではない。動いてはいたが，個々のリクエストがエラーで失敗していた。

表2の稼働率は，稼働していた時間の割合で測る。動いてさえいれば中でリクエストが失敗していても数字に表れない。だから「稼働率のSLIだけでは十分でない」と言っている。

利用者にとっては，リクエストが通ったかどうかが使えたかどうかである。そこで総リクエスト数のうち何件が通ったかを見る。

15字。解答例は「成功したリクエスト数」で10字。「リクエスト数に着目して」という条件があるので，件数で答える。

本文の根拠

冒頭

毎日 0 時時点で損害調査システム及び契約管理システムのストレージのデータを 24 時間間隔でフルバックアップしている

冒頭

フルバックアップは DC 内のバックアップ専用の別ストレージに保存し，災害に備えてクラウド事業者 S 社のサービス（以下，S クラウドという）のストレージサービスにも転送して保存している。

〔現在のITサービス継続計画〕

被災によって更新ログが使用不能な場合は，バックアップ時点から被災発生時点までの更新内容は，自動車保険部による再入力が必要となる。

RPO（目標復旧時点）は，どの時点のデータまで戻せるかである。Sクラウドに何が置いてあるかを確かめる。

Sクラウドへ転送しているのはフルバックアップだけで，更新ログは送っていない。しかも下線（ア）の状況はDCのバックアップが被災して使えない場合なので，DCにある更新ログも当てにできない。使えるのはフルバックアップ1本だけである。

そのフルバックアップは毎日0時時点のもの。したがって戻せるのは被災当日の0時までで，そこから被災までの更新は自動車保険部が再入力することになる。

10字。解答例は「被災当日の0時」で7字。「0時」だけでは，いつの0時かが言えていない。

本文の根拠

〔現在のITサービス継続計画〕

復旧作業を行う場合に必要な復旧手順書の最新版は，DC の文書管理システムに文書ファイル（以下，F ファイルという）として保存していて，情報システム部の要員は，F ファイルに基づいて復旧作業を行う。

冒頭

毎日 0 時時点で損害調査システム及び契約管理システムのストレージのデータを 24 時間間隔でフルバックアップしている

バックアップの対象を読み直すと，「損害調査システム及び契約管理システム」とだけ書いてある。文書管理システムは入っていない。ここが見落としやすい。

一方で復旧手順書（Fファイル）は，その文書管理システムの中にしか無い。文書管理システムもDCにあるので，DCが被災すれば復旧手順書ごと失われる。手順書が無ければ復旧作業そのものが始められない，というのが「支障」の中身である。

対策は，被災しても手順書が読める状態を作ることになる。Fファイルもバックアップの対象に加えてSクラウドへ転送しておくか，印刷して使用する拠点に置いておくかである。

50字。どちらの案でも，「何を」「どこに置いて」「被災時に使える」の3点をそろえる。

本文の根拠

冒頭

情報システム部では災害に備えたバックアップの方針として，フルバックアップを遠隔地にも保管することとしている。

冒頭

S クラウドは，Q 社本社の遠隔地となる関西の S 社データセンターで稼働しており，サービス対象データのバックアップを常に取り，S 社データセンターに保存している。

レビューの指摘は「情報システム部のバックアップ方針に関連して」と言っている。方針は「フルバックアップを遠隔地にも保管する」である。

ところがS社のバックアップは，S社データセンターに保存している。Sクラウドが動いているのと同じ場所である。待機系システムをSクラウドで動かすと，その待機系のバックアップは待機系と同じ拠点にあることになり，S社データセンターが被災すれば両方まとめて失う。自社の方針を満たしていない。

だから確認すべきは，S社のバックアップが遠隔地にも保管されているかどうかである。

20字。解答例は「バックアップの遠隔地保管の有無」で15字。S社側の復旧の早さ・戻せる時点という観点から「SクラウドのRPO及びRTO」と書いてもよい。

採点講評（IPA）

設問2（1）は正解率が低かった。クラウドサービスを活用する際は，災害に備えた自社の方針とクラウドサービスの対応内容が整合していることの確認が重要であると認識してほしい。

本文の根拠

〔ITサービス継続計画の見直し〕

“目標復旧時間（以下，RTO という）は，障害発生から 10 時間以内”とする。

〔サービス継続措置の検討〕

データ回復から業務復旧確認までは 6 時間であり，RTO を達成見込である。ただし，データ回復作業の一部で，S クラウドの S 社担当者と連携して作業を進める必要がある。

RTO 10時間は，BCPを変えたときに「こうしたい」と置いた値で，達成できるかどうかは分からないまま決まっている。

テストをして初めて，データ回復から業務復旧確認まで6時間という実測が出る。この結果を見てから合意すれば，守れない数字を約束することも，逆に余裕を見すぎた数字を置くこともない。

20字。解答例は「実現可能なRTOとするため」で12字。「テスト結果を目標値に反映するため」では，何のために反映するのかが言えていない。実現できる目標にそろえる，というところまで書く。

採点講評（IPA）

設問2（2）は正解率がやや低かった。テスト結果を目標値へ反映することに留まった解答が散見された。実現可能な目標を設定するために，テスト結果評価後に合意形成していくプロセスを認識してほしい。

本文の根拠

冒頭

情報システム部では，“事故受付リクエスト全件の 95％に対して応答時間を 5 秒以内とする”ことを，事故対応サービスのサービスレベル目標としている。

〔サービス継続措置の検討〕

S クラウドのサーバサービスの制約から，待機系システムでは，事故受付リクエスト全件の 95％が応答時間 10 秒以内に収まる結果となった。

RLO（目標復旧レベル）は，復旧した状態でどこまでのサービス水準を出すかである。

平時の目標は「95％が5秒以内」だが，待機系システムのテスト結果は「95％が10秒以内」だった。R氏は能力を上げようと相談したが，部長は先にRLOを協議せよと指示している。つまり代替運用の間は平時と同じ水準でなくてよいかもしれない，まずどの水準で合意するかを決めよ，ということである。

したがってRLOはテスト結果そのもの，「事故受付リクエスト全件の95％が10秒以内」になる。

30字。解答例は27字。95％という条件を落とすと，平時の目標と対になる形にならない。

本文の根拠

〔現在のITサービス継続計画〕

障害復旧後のシステムの正常稼働については，情報システム部のシステム担当が自動車保険部へ業務面の確認をして判断している。

図1

自動車保険部 BCP 対策本部には「事故対応サービス担当」もあり，損害サービス拠点及び本社との間で業務影響確認・業務復旧の確認を行う。

表1 項番1

1 損害調査システムは，事故受付，損害金見積り，事故進捗管理，保険金支払いを処理する機能を提供し，損害サービス拠点と本社で利用する。

システム担当は，システムが動いただけでは正常稼働と判断できない。業務として使えるかどうかを自動車保険部に確かめてもらったうえで判断する，と本文に書いてある。

確かめる相手は，図1のとおり事故対応サービス担当である。この担当は損害サービス拠点と本社に対して業務影響と業務復旧を確認する役回りをもっている。そして損害調査システムを使うのは，表1のとおりその損害サービス拠点と本社である。

したがって依頼するのは，損害サービス拠点と本社で業務が復旧したかどうかの確認になる。

25字。解答例は「損害サービス拠点及び本社での業務面の復旧確認」で21字。確認する場所を落として「業務の復旧確認」だけにすると，誰にどこを見てもらうのかが決まらない。

採点講評（IPA）

設問4（1）は正解率がやや低かった。システムを利用した業務影響及び業務再開可否を，サービス利用者側で確認する際には，サービス利用者側と事前に役割を合意して計画に組み込むことが重要である。

本文の根拠

〔サービス継続措置の検討〕

ただし，データ回復作業の一部で，S クラウドの S 社担当者と連携して作業を進める必要がある。

〔緊急事態発動時の体制整備〕

今まで IT サービス継続計画に基づいた緊急事態対応訓練を年 1 回実施することで，IT サービス継続計画の評価を行い，緊急時の連絡を含む確認を行ってきた。

見直し後の復旧は，データ回復の一部をS社担当者と一緒に進めることになる。自社の要員だけでは暫定復旧が終わらない。

ところが訓練はこれまで情報システム部だけで行ってきた。S社が入らない訓練では，本番で連携できるかどうかを確かめられないし，S社側に人が出せるかも分からない。「体制面の内容を追加し」とあるのはここを指している。

20字。解答例は「S社担当者の緊急事態対応訓練への参加」で18字。訓練への参加ではなく，復旧作業に人を出せる体制の確保という形で「データ回復作業を行うS社体制の確保」と書いてもよい。