令和4年度 春期 午後Ⅰ

本文の根拠

〔サービスレベル目標の設定〕

Q 社では，今まで社内に提供するサービスについてはサービスレベル目標を定めていなかったが

〔サービスレベル目標の設定〕

主要なサービスレベル項目のサービスレベル目標について，営業部の要望を基にした目標値を作成した。

冒頭

再構築前の受注システムは，システム障害の発生によって，利用者がサービスを利用できない状況になることがあった。

仮の目標値がどう作られたかを見る。「営業部の要望を基にした目標値」である。つまり使う側の希望から出た数字で，提供する側が本当に守れるかどうかは，まだ誰も確かめていない。

しかもQ社は社内サービスの目標値をこれまで定めておらず，過去の実績もない。再構築前はサービスが使えなくなることもあった。この状態で正式な約束をすれば，守れない値を背負うことになりかねない。

そこで1か月動かして実績を測り，それを見てから正式な値を決める。「サービス提供者としてのシステム部の立場から」という条件は，ここを答えよという指定である。

30字。解答例は「現実的に達成可能なSLAを，営業部と合意するため」で24字。目標値を定めていなかったことや，決定までの期間を確保することは，この方式を選んだ背景であって目的ではない。

採点講評（IPA）

設問1(1)は，正答率がやや低かった。正式決定までの期間確保，現行でサービスレベル目標を定めていないなどを記述した誤答が多かった。サービスレベル目標の達成を確実にしていく観点から，目標値を仮設定してサービス提供の初期に達成状況を確認していく方式をとっていることについて，認識してほしい。

本文の根拠

表1

サービス時間が営業日の 7 時から 23 時まで（計画停止時間を除く），計画停止時間が 5 時間（第 1 土曜日の 18 時から 23 時まで），サービス稼働率が 99.3％以上。

〔サービスレベル目標の設定〕

合意した 1 か月間のサービス時間の目標値の合計（以下，計画サービス時間という）は

1日のサービス時間は7時から23時までなので16時間。営業日は27日と与えられている。

16 × 27 ＝ 432時間。

ここから計画停止時間を引く。表1のサービス時間が「（計画停止時間を除く）」と断っているからである。計画停止は第1土曜日の18時から23時までの5時間。

432 － 5 ＝ 427時間。

引き忘れると432となり，次の設問の稼働率までずれる。

本文の根拠

計算式

（計画サービス時間 － 計画外の停止時間の合計）÷ 計画サービス時間

表5

3 月 4 日は 150 分，3 月 10 日は 30 分，3 月 19 日は 20 分。

表1

サービス稼働率が 99.3％以上

計画外の停止時間の合計は 150 ＋ 30 ＋ 20 ＝ 200分。式は時間単位なので 200 ÷ 60 ＝ 3.333…時間に直す。分のまま計算すると答えが合わない。

（427 － 3.333…）÷ 427 ＝ 423.666… ÷ 427 ＝ 0.99219…

99.219…％を小数第2位で四捨五入して99.2％。

表1の目標は99.3％以上なので，未達成である。この1点が次の設問につながる。

本文の根拠

表1

保守性の種別では，計画外の停止時間がサービス停止 1 回当たり 2 時間以内。

表6

項番3の修理は，システム部は故障した磁気ディスク装置の部品交換を S 社に依頼した，S 社が保守部品を持参して Q 社に到着し交換を行った，所要時間 90 分。

表5

3 月 4 日は 150 分

まず，いくら縮めればよいかを出す。目標は1回当たり2時間，つまり120分以内。3月4日は150分だったので，30分以上縮める必要がある。

次に，どの手順なら30分縮められるかを見る。表6の所要時間は上から20分，20分，90分，10分，10分。項番1・2・4・5はもともと30分未満なので，仮にゼロにしても30分には届かない。1つの手順だけで足りるのは90分の項番3しかない。

30分縮めて120分にすると，稼働率のほうも直る。計画外の停止時間の合計が 120 ＋ 30 ＋ 20 ＝ 170分 ＝ 2.833…時間となり，（427 － 2.833…）÷ 427 ＝ 0.99336…で99.3％。表1の目標に届く。

25字。理由は「30分以上短縮できる可能性があるから」。「一番時間が掛かっているから」だけでは，なぜそれで目標に届くのかが言えていない。

採点講評（IPA）

設問3(1)の理由は，正答率がやや低かった。時間を要している点に留まった解答が多かった。サービスレベル目標を達成するための定量的な改善効果も踏まえて解答してほしい。

本文の根拠

表4 項番2

項番2は，調査の結果，ハードウェアの部品交換が必要と判明した場合，部品交換の依頼から交換までを 90 分以内に行う。

表6

システム部は故障した磁気ディスク装置の部品交換を S 社に依頼した，S 社が保守部品を持参して Q 社に到着し交換を行った，所要時間 90 分。

表6の項番3が90分ちょうどなのは偶然ではない。表4の項番2で，S社との契約が「部品交換の依頼から交換までを90分以内」と決まっているからである。S社は契約どおりに動いており，落ち度はない。だから契約を変えないかぎり，この90分は縮まらない。

前問のとおり30分以上縮める必要があるので，90分以内を60分以内に改める。

30字。解答例は「表4の項番2の90分以内を60分以内に変更する。」で25字。

「S社との契約を見直す」で止めると，何をどう変えるのかが決まらない。どの契約事項の，どの数字を，いくつにするかまで書く。

採点講評（IPA）

設問3(2)は，正答率が平均的であった。変更対象となるサプライヤとの契約事項に関する解答が多く，契約の変更内容まで記述していない解答が散見された。サービスレベル目標値を達成可能とするためには，顧客とのSLAと整合するように，外部供給者との契約内容を具体的に調整することを心掛けてほしい。

本文の根拠

表6 項番1

項番1の検出は，システム部は営業部から“一部の利用者が新サービスを利用できない”という連絡を受けた，連絡から 15 分経過後に監視システムがアラートを検知して監視端末で警報を鳴らしシステム部はインシデントを記録した，所要時間 20 分。

表6 注1

監視システムは CPU 使用率，オンライン応答時間などを管理項目として常時監視し，管理項目がしきい値を超える事象が発生した場合アラートとして検知する。

項番1の中身を順に読むと，順番が逆になっていることに気づく。先に営業部から連絡が来て，監視システムのアラートはその15分後である。

監視システムは常時監視していて，しきい値を超えればアラートを出す仕組みになっている。それなのに人からの連絡のほうが15分も早かった。しきい値が実態に合っていない疑いがある。

検出が遅れれば，そのぶんだけ計画外の停止時間が伸びる。項番1の20分は，90分の項番3を除けば項番2と並んで最も長い。ここを詰めれば停止時間をさらに短くできる。

30字。解答例は「インシデントの検出に20分掛かったから」のほか，「アラート検知が営業部の連絡より15分遅いから」と，逆転している点を指してもよい。

本文の根拠

表1 業務サーバ

業務サーバは，必要なスループットを 15TPS（Transaction Per Second）と想定し，6 割の性能でそのスループットを確保できる能力を計画値とする。

「6割の性能で15TPSを確保できる能力」が計画値である。求める計画値をxとすると 0.6x ＝ 15 なので，x ＝ 15 ÷ 0.6 ＝ 25TPS。

15 × 0.6 ＝ 9 としないこと。計画値は必要量より大きくなければ余裕にならない。掛けるのか割るのかで迷ったら，答えが15より大きくなるかどうかで確かめられる。

本文の根拠

〔容量・能力計画と管理体制〕

購入実績情報：会員の商品購入の履歴であり，1 回の購入操作につき 1 レコードが作成される。

表1 ディスク装置

会員基本情報は 2M バイト／会員，購入実績情報は 1M バイト／レコード，商品基本情報は 250G バイト。

〔容量・能力計画の策定〕

2021 年 3 月末時点の会員数は 8,000 人

格納する3種類の情報について，容量が出せるかどうかを1つずつ確かめる。

会員基本情報は2Mバイト／会員で，会員数は表4にある。出せる。

商品基本情報は250Gバイト固定。出せる。

購入実績情報は1Mバイト／レコードだが，レコード数が分からない。「1回の購入操作につき1レコード」なので，会員数だけでは決まらず，会員が何回買うかが要る。

ここが足りない情報である。単位が「／会員」なら会員数で足りるが，「／レコード」なのでレコードの数を作る手がかりが別に要る，という読み方をする。

15字。解答例は「会員1人当たりの平均購入回数」で14字。

本文の根拠

〔販売ビッグデータ分析機能の開発〕

会員が E サービスを使って商品を検索するときに閲覧した Web ページを閲覧履歴情報として，E システムのディスク装置に記録する。なお，閲覧履歴情報は，閲覧した Web サイト 1 ページ当たり 0.1M バイトである。

前の設問と同じ形である。閲覧履歴情報の単位は「1ページ当たり0.1Mバイト」なので，データ量は 0.1Mバイト × ページ数で決まる。

会員数は分かっているが，ページ数は分からない。だから必要なのは，会員がどれだけのページを見るかである。

30字。解答例は「会員が閲覧する1か月当たりの総ページ数」で19字。会員1人当たりの閲覧ページ数という形でもよいが，いずれにしてもページ数を数える手がかりであることを書く。バイト数や会員数を答えても，すでに分かっているものなので「必要な情報」にはならない。

採点講評（IPA）

設問3は，正答率がやや低かった。新たに取得する情報のデータ量の予測するために，どのようなデータを取得すべきかを理解して解答してほしい。

本文の根拠

表1 業務サーバ

計画値はスループットが空欄 a TPS，基準値は計画値の 80％。

表4

最大スループット（TPS）と対前年度増加率は，15.00／16.50（＋10％）／18.15（＋10％）／19.97（＋10％）。

〔新商品の販売計画〕

2022 年度から会員数が前年度に比べて 20％増加し，次年度以降も同様のペースで会員数が伸び続けると想定して会員数の見通しを修正した。

まず基準値を出す。計画値25TPSの80％で20TPSである。基準値を超えると容量・能力計画の変更を検討することになっている。

次に，増加率を10％から20％に置き換えて引き直す。起点は表4の2022年3月末の16.50TPS。

2023年3月末：16.50 × 1.2 ＝ 19.80TPS

2024年3月末：19.80 × 1.2 ＝ 23.76TPS

2023年3月末の19.80はまだ基準値20を下回るが，2024年3月末の23.76は超える。だから増強が必要になる。

40字。解答例は「2024年3月末までに最大スループットが基準値の20TPSを超えるから」で36字。いつ・何が・どの値を超えるのかを入れる。

なお23.76は計画値25TPSには届いていない。それでも増強するのは，基準値が「増強に必要な期間を考慮して」置かれた値だからである。計画値に達してから動いたのでは間に合わない。

採点講評（IPA）

設問4(1)は，正答率がやや高かった。業務サーバの能力増強が必要と考えた理由を，売上の増加に伴う計画値の見直しだけでなく，見直しに伴い基準値を超える見通しとなった旨を具体的に言及した解答が多かった。

本文の根拠

表1 注2

基準値とは容量・能力計画の変更を検討する契機となる指標のことである。基準値は，容量・能力を増強するときに必要となる期間を考慮して設定する。

表1 ディスク装置

計画値は容量 1T バイト，基準値は計画値の 70％。

〔新商品の販売計画〕

新商品の販売開始後の需要動向によっては，閲覧履歴情報の急増が予測されることから

設問が「容量の増強は除く」と断っているので，表1で触れる先は基準値しか残らない。

基準値は，注2のとおり「増強に必要な期間を考慮して」決める。基準値に達してから増強が終わるまでの間に容量が尽きないよう，余裕を見た値である。

閲覧履歴情報が急増すれば，使用率の上がり方も速くなる。70％のままだと，気づいてから増強を終えるまでに容量が足りなくなりかねない。速く増えるなら，もっと手前で気づけるようにしておく必要がある。

30字。解答例は「ディスク装置の基準値を現在の設定値より低い値に変更する。」で27字。上げるのではなく下げる。下げるほど早く検知できる。

採点講評（IPA）

設問4(2)は，正答率が低かった。情報量の急増が予測される中，ディスク装置の容量不足を早期に検知し，容量不足が発生する前に容量を増加するという観点から，ディスク装置の基準値設定に着目して正答を導き出してほしい。

本文の根拠

〔新商品の販売計画〕

商品カテゴリごとに顧客層が異なり，業務ピーク時のほかにも閲覧されやすい曜日や時間帯があって，それぞれが異なること。

〔新商品の販売計画〕

業務ピーク時以外の時間帯にタイムセールを開催すると，業務ピーク時からタイムセールの曜日，時間帯にトランザクション量がシフトする傾向にあること。

〔新商品の販売開始〕

G 氏は，営業部の方策は，タイムセールの開催頻度が増えるものの，会員にとって利便性を大きく損なわないことから

分析結果は3つ挙がっているが，この設問で使うのは1つ目と3つ目である。

3つ目だけを使うと「ピーク時以外にタイムセールをやる」で終わる。それでは移った先に今度は集中するし，会員が普段見ない曜日・時間帯に開催されて利便性も落ちる。

1つ目と組み合わせると形が変わる。商品カテゴリごとに顧客層が違い，閲覧されやすい曜日や時間帯も違うのだから，カテゴリごとにその時間帯へタイムセールを割り振ればよい。トランザクションは複数の曜日・時間帯へ散り，しかも会員は自分が見やすいときに買えるので利便性も落ちない。

G氏が「開催頻度が増えるものの，会員にとって利便性を大きく損なわない」と評したのは，カテゴリごとに分けて何度も開くことを指している。この一文が，答えがカテゴリ別の分散であることの裏付けになる。

40字。解答例は「商品カテゴリごとにタイムセールの曜日や時間帯を分散させる。」で28字。

採点講評（IPA）

設問5は，正答率が平均的であった。トランザクションの分散の手段として，単にタイムセールをピーク時間帯以外に実施するという解答が多かった。データ分析の結果を踏まえて解答してほしい。

本文の根拠

表1 注1

計画停止とは機器の保守などを行うためのサービス停止のことで，15 日前までに A 社の Web サイトを使って利用者に案内する。

表4

サービス可用性は，サービス時間が 24 時間 365 日（計画停止を除く），サービス稼働率が 99.99％以上。

表1と表4のサービス時間はどちらも「24時間365日（計画停止を除く）」で，文言は同じである。違うのは，計画停止を決めるのがA社からB社に移る点である。

A社は表1の注1で，計画停止を15日前までに利用者へ案内すると約束している。ところがB社がいつA社へ知らせてくれるかは，サービスカタログのどこにも書いていない。B社の連絡が10日前なら，A社は15日前の案内ができない。

表4の数字そのものは表1を上回っているのに達成できなくなる，というのがここでの懸念である。だから何日前に案内が来るのかを確かめる。

40字。解答例は「B社が計画停止を実施する何日前に，B社からA社に計画停止の案内を行うか。」で36字。

採点講評（IPA）

設問1(1)は，正答率がやや高かった。販売サービスの計画停止を利用者に周知する必要性は，正しく理解されているようであった。

本文の根拠

表1

保守性は，インシデント発生時のサービス回復時間が 4 時間以内。

表4

保守性は，インシデント発生時のサービス回復時間が 4 時間以内，インシデント発生時及び解決時の連絡は指定された緊急連絡先にメール及び電話で連絡。

〔インシデント管理プロセスについての検討〕

PaaS に障害が発生した場合，障害の解決処理は B 社が行う。

表1も表4も「4時間以内」で，数字は同じである。同じなら達成できそうに見えるが，何から何までの4時間かが違う。

表4の4時間は，B社のPaaSが回復するまでである。PaaSが直っても，その上で動く販売アプリが正常に使えるかはA社が確かめなければならない。その確認の時間は，B社の4時間の外にある。

つまりA社の回復時間は「B社の4時間 ＋ A社の確認時間」になり，表1の4時間を超える。同じ数字を並べただけでは足りない，というのがこの設問の要点である。

40字。解答例は「B社のPaaSが復旧した後の販売アプリの稼働確認時間が確保できないから」で35字。

採点講評（IPA）

設問1(2)は，正答率がやや低かった。PaaSに障害が発生して回復したときに，販売サービスが正常に利用できることを確認するなど，A社による作業時間の確保が必要なことに気付いていないようであった。

本文の根拠

〔(2) データセンタ内のバックアップデータの取得方法〕

この事例では，バックアップデータの取得場所を本番データと同一の機器としていたので，バックアップデータの消失事象が発生した。

表4 注2

過去 1 週間のデータを復元できるよう，PaaS を運用するデータセンタ内において日次でバックアップデータを取得している。

表4の注2は「データセンタ内において」としか書いていない。同じデータセンタの中でも，本番データと同じ機器に取っているのか，別の機器に取っているのかは分からない。

同じ機器だと，その機器が1台壊れただけで本番データとバックアップデータの両方を失う。他社で起きたのがまさにこれである。

バックアップは，本番が失われたときに使うためのものである。同時に失われるなら持っている意味がない。だから取得場所を確かめる。

40字。解答例は「本番データとバックアップデータが同時に利用できなくなる可能性があるから」で34字。「同時に」が肝で，これが抜けると，なぜ場所を聞くのかが伝わらない。

本文の根拠

〔(3) 解約時のデータの取扱い〕

PaaS の利用を終了した場合にデータが消去されることを確認した。B 社がデータを消去する前の取扱いについて

〔サービス移行の検討〕

A 社では，事業構造改革に伴うシステム統廃合を 2027 年度末までに完遂させる予定があるので，更改後の販売システムのライフサイクルを 5 年間とした。

本文が「消去する前の取扱いについて」と限っている。消去されること自体はすでに確認済みなので，消し方を聞く設問ではない。

販売システムは5年で終わるが，そのデータまで不要になるわけではない。A社は2027年度末までにシステムを統廃合する予定で，販売のデータは移った先で引き続き使う。消される前にA社が受け取らなければ，データごと失う。

だから確認するのは，データを返してもらえるか，そしてどういう形式で返るか（そのまま使える形かどうか）である。

35字。解答例は「A社にデータが適切な形で戻されることを確認しておく。」で25字。完全に消去してほしいと答えると，設問が指定した「消去する前」の話から外れる。

採点講評（IPA）

設問1(4)は，正答率がやや低かった。情報セキュリティ管理の観点からデータを完全に消去することを求める誤答が多かった。データの取扱いについて解答してほしい。

本文の根拠

表3

年間費用（百万円）は，336／336／696／696／696。一時費用（百万円）は，500／—／200／—／—。

年間費用と一時費用を全部足すだけである。

年間費用：336 ＋ 336 ＋ 696 ＋ 696 ＋ 696 ＝ 2,760

一時費用：500 ＋ 200 ＝ 700

合計 3,460百万円。

一時費用を忘れやすい。表3では年間費用と別の行になっており，しかも2023年度と2025年度にしか無い。注1・注2のとおり移行と容量・能力強化に伴うもので，どちらも5年間の中で実際に出ていく費用なので合算する。

本文の根拠

表2

ピーク時間帯の 1 時間当たりの処理件数は，1,200／1,700／2,200／2,700／3,200。

表5

1,500 未満は年間費用 240 百万円，1,500 以上 2,000 未満は 336 百万円，2,000 以上 2,500 未満は 432 百万円，2,500 以上 3,000 未満は 504 百万円，3,000 以上は 600 百万円。

〔(3) 解約時のデータの取扱い〕

サービス利用に先立って，移行の費用も含めて一時費用として 100 百万円が必要になる。

表2の処理件数を，年度ごとに表5の区分へ当てはめる。

2023年度 1,200件 → 1,500未満 → 240

2024年度 1,700件 → 1,500以上2,000未満 → 336

2025年度 2,200件 → 2,000以上2,500未満 → 432

2026年度 2,700件 → 2,500以上3,000未満 → 504

2027年度 3,200件 → 3,000以上 → 600

年間費用の合計は 240 ＋ 336 ＋ 432 ＋ 504 ＋ 600 ＝ 2,112。これに一時費用100を足して2,212百万円。

オンプレミス案の3,460と比べて1,248百万円安い。これが「5年間の総費用を抑えられるのはPaaS案の方であった」の中身である。

本文の根拠

表4

インシデント発生時及び解決時の連絡は指定された緊急連絡先にメール及び電話で連絡。

〔インシデント管理プロセスについての検討〕

インシデントの解決に時間が掛かる場合は，インシデントの解決に向けた進捗状況について経過連絡を行う。

〔インシデント管理プロセスについての検討〕

PaaS の障害がサービス利用者に影響するインシデントの場合，情報システム部は営業部に対してインシデントの解決についての説明責任をもつ。

A社が営業部にしている連絡は，発生連絡・解決連絡・経過連絡の3つである。これと表4のB社の約束を突き合わせる。

B社が約束しているのは「発生時及び解決時」の2つだけで，途中経過の連絡が無い。

障害を直すのはB社なので，A社は自力で進捗を知る手立てを持たない。経過連絡が来なければ，解決に時間が掛かっているときに営業部へ何も言えず，説明責任を果たせない。そもそも経過連絡は，過去に長時間を要したことを契機に始めた運用である。

だからB社と，経過連絡をどうやって・どの間隔で行うかを決める。

30字。解答例は「PaaS障害対応状況の経過連絡に関する方法とタイミング」で26字。「経過連絡をしてもらう」だけでなく，方法とタイミングまで詰める。

採点講評（IPA）

設問3は，正答率が平均的であった。解決に時間が掛かる障害の場合，顧客とのコミュニケーション手段として経過連絡が必要で，その方法とタイミングが重要となることについては理解されているようであった。