応用情報技術者 2016年 春期 午後 問10

解答の論理構成

1. 不確実な事業計画
   • 【問題文】には「“取扱いチケットの種類の増加と新サービスの提供によって、2015年度（2015年4月1日から2016年3月31日まで）の売上を2012年度の2倍にする”という目標を立てた。中期事業計画どおりの売上の達成は不確実性を含んでいたが、…」とあります。
   • 達成が不確実であれば、初期投資を抑え、需要に応じて拡張できる構成が望ましいです。
   • よって「ア：事業計画どおりの売上の達成は不確実性を含んでいる。」が選択理由となります。
2. 余剰資源の抑制
   • 表2より
     • 案1：再構築前の3.5倍の処理能力／構築費用80百万円
     • 案2：初回構築2.0倍→追加構築3.5倍（計90百万円）
   • 案1は一括で3.5倍分を導入するため、需要が想定以下だった場合に資源が遊休化します。
   • 案2は「サーバ台数の追加で、サービスを停止することなく容量・処理能力の増強が可能」と段階的に拡張できるため、余剰資源を最小化できます。
   • したがって「オ：余剰資源を抑えることができる。」が選択理由です。
3. 他の選択肢が誤りとなる理由
   • イ：総工数は表2に示されておらず根拠不足。
   • ウ：総費用は80百万円（案1）＜90百万円（案2）であり、案2の方が小さいわけではない。
   • エ：表2の無停止増強は案2の特徴ですが、この機能は“余剰資源抑制”のための手段であって「案2を選んだ決め手」とまでは言えない。試験では目的（不確実性対応と余剰資源抑制）を問うています。

誤りやすいポイント

• 「構築費用が安いから案2」と早合点しやすい（実際は90百万円＞80百万円）。
• “無停止で増強可能”というキーワードに飛びつき「エ」を選んでしまう。これは導入後の運用メリットであって採択理由の本質ではない。
• 表2の処理能力倍率を読み違え、「案1＝2倍、案2＝3.5倍」と誤認すると判断を誤る。

FAQ

解答の論理構成

1. 事実確認
   • 2013年4月に「表1…3年間のデータ処理件数を見積もった」とあるように、初回キャパシティ計画は2013年度～2015年度分のみでした。
   • ところが実運用を始めると「2013年度の…データ処理件数は、見積りよりも15%程度上回っていた」「2014年度…データ処理件数は見積りを大きく上回る約2.1倍」と実績が急増しています。
2. 問題の発生
   • 実績値の増大を反映しないまま運用を続けた結果、「②アプリケーションサーバの CPU 使用率がしきい値を超え、警告メッセージが出るようになった」ことが記載されています。
3. 足りなかった活動の特定
   • ITIL などのキャパシティ管理では「定期的なキャパシティ計画の見直し」と「将来負荷の予測」が基本です。
   • 本文にも「(2) 分析…将来の予測を基に、資源の増強の要否や実施時期などを検討する」とあり、これを実施していれば警告発生前に増強できたはずです。
4. 結論
   • よって不足していたのは、初回構築後も継続的に実績を評価し、計画値を更新してデータ処理件数を再予測することです。

誤りやすいポイント

• 警告メッセージ＝監視強化と早合点し、「監視を強化する」とだけ書くと失点します。問題は監視結果を計画に反映しなかった点です。
• 「追加構築を早める」と答えるのも誤り。追加構築は結果であり、原因は見通しの欠如です。
• “CPU 使用率のしきい値設定”など運用設定の問題と考えがちですが、しきい値は既に正しく機能しており、そのアラートを予防できなかったのが本質です。

FAQ

解答の論理構成

• 【問題文】では監視活動について「しきい値を超えた場合などは、システム運用監視ツールで警告メッセージを出し、a 管理プロセスを通じて、適切に対処する。」と述べています。
  監視で発生するのは“警告メッセージ”という運用現場の出来事です。これは利用者からの“問い合わせ”や“要求”と同じく運用フェーズで扱うべき事象なので、ITIL では「インシデント管理」と「サービス要求管理」をまとめて扱うプロセスが該当します。解答群の「ア：インシデント及びサービス要求」がぴったり合致します。
• 実装に関して【問題文】は「変更を b 管理プロセスを通じて稼働環境に展開する。」と記載しています。
  キャパシティ増強という“変更”は、テスト済みのモジュールや設定を本番環境へ“リリース”し、“展開”する段階で完了します。ITIL ではこの一連を担当するのが「リリース及び展開管理プロセス」です。解答群の「カ：リリース及び展開」が該当します。
• 以上から
  a ＝ 「インシデント及びサービス要求」
  b ＝ 「リリース及び展開」
  となります。

誤りやすいポイント

• 「エ：変更」を [b] に選びたくなるが、変更管理は“承認・計画”までで、実際に環境へ入れるのはリリース及び展開管理である点を混同しがちです。
• 監視で発生するのは“問題”ではなく“インシデントやサービス要求”であるため、[a] に「オ：問題」を選ぶミスが多いです。問題管理は根本原因分析と恒久対策に焦点を当てます。
• 構成管理（イ）は“構成情報の正確性維持”が目的で、運用上のアラート対応プロセスとは役割が異なる点を押さえましょう。

FAQ

解答の論理構成

1. 【問題文】には、下線部 ③として
   “キャパシティ管理のプロセスを評価するための KPI を設定する”
   と記載されています。
   したがって選ぶべき指標は、キャパシティ不足の兆候や対応の適切さを数量化できるものです。
2. 選択肢を確認します。
   ア：インターネットの応答時間が遅いごとに起因するSLA違反の回数
   → 応答時間は利用者視点のサービス品質であり、SLA管理の指標に該当します。キャパシティ管理プロセスそのものの効果測定とはずれます。
   イ：設定した資源利用量のしきい値を超えた回数
   → 【問題文】の監視では“キャパシティの評価指標…しきい値を超えた場合などは、システム運用監視ツールで警告メッセージ”とあり、キャパシティ容量判定の直接的な指標です。プロセス評価に適しています。
   ウ：ソフトウェアの品質が低いことに起因するインシデントの発生回数
   → 品質保証やリリース管理の領域であり、キャパシティ管理プロセス評価とは直接関係しません。
   エ：不十分な資源割当てに起因するインシデントの発生回数
   → 資源計画やチューニングが適切に行われたかどうかを示す尺度で、キャパシティ管理プロセスの有効性に直結します。
3. よってキャパシティ管理プロセスを評価するKPIとして妥当なのは
   イ、エ となります。

誤りやすいポイント

• SLA違反回数（選択肢 ア）をキャパシティKPIと誤認する。SLA達成責任はサービスレベル管理であり、キャパシティ管理の狙いとは範囲が異なる点に注意。
• ソフトウェアの不具合（選択肢 ウ）によるインシデントは、構成管理やテストの問題であって、CPUやメモリなどリソース計画の善し悪しを示さない。
• しきい値超過回数（選択肢 イ）とインシデント回数（選択肢 エ）は目的が似て見えるが、前者は予兆、後者は結果という違いを押さえる。

FAQ

解答の論理構成

• 【問題文】には「アプリケーションサーバの CPU 使用率が一時的にしきい値を超え、応答時間が悪化することが懸念された」ことが示されています。
• 同時に「Z社イベントのチケット販売を優先するために…インターネットでの他のチケットの申込量を減らすことができれば、サービス全体に支障が出ない」と明記されています。
• つまり“他のチケット購入を 18～21 時から外す”需要シフトが核心です。
• 販売システムには「会員制度」を導入し、「購入実績に応じてポイントを受け取る特典」があると書かれています。ポイントは会員行動をコントロールできる既存機能です。
• 需要管理では価格・割引・ポイントなどのインセンティブでピーク負荷を平準化する施策が一般的です。
• そこで「ピーク時間帯以外に申し込む場合は付与ポイントを増額する」という対策が、(1)イベント優先、(2)既存機能活用、(3)利用者メリットの三拍子を満たし、需要管理方針を支援する最適解となります。

誤りやすいポイント

• 追加サーバ増設などキャパシティ拡張策を書いてしまう
  → 問題設定は「期間が必要なので当面はサービス要求と調整」と明示。
• 単に「時間帯を制限する」と回答し、ユーザーメリットを示さない
  → インセンティブがないと利用者は行動を変えにくい。
• 「Z社チケットの販売時間を変える」と書く
  → 優先すべきは“Z社イベント”であり、他チケット側を調整するのが条件。

FAQ

解答の論理構成

1. 【問題文】には、販売促進機能の前提として
   “これまで一定期間ごとに分散保存していた会員の購入記録を、一括して蓄積できるデータウェアハウスを構築する。”
   と記載されています。
2. さらに、同じ段落で
   “購入が見込める会員を迅速に選別して優先販売やキャンペーンの案内をする”
   とあり、販売促進機能では会員の購入記録を横断的に検索・抽出する処理が頻繁に走ることが読み取れます。
3. ⑤の下線部は、
   “将来見込まれる販売件数の増加をキャパシティ計画に反映し、処理能力を増強したり、ストレージの容量を増やしたりする必要がある。”
   と、計画通りに増強しない場合のリスクを問うています。
4. 会員購入記録の横断検索は CPU・I/O を大量に消費するため、処理能力が不足すると “応答時間の悪化” が顕在化しやすいことは、過去の本文事例
   “アプリケーションサーバの CPU 使用率がしきい値を超え、応答時間が悪化”
   からも示唆されます。
5. したがって「処理能力が十分でないときに発生するおそれがある事象」は
   “会員の購入記録を検索するときに応答時間が悪化する。”
   となります。

誤りやすいポイント

• “ストレージ不足でデータが保存できなくなる” と答えると、処理性能に関する問いからズレます。
• “販売促進機能全体が停止する” など大げさに書くと具体性が不足し減点対象です。
• “レスポンス遅延” とだけ書くと「何の処理で遅延するのか」が不明瞭になります。

FAQ