令和7年度 秋期 ITサービスマネージャ 午後問題
練習用オリジナル問題です
本ページの設問・題材・模範解答は、IPA 試験本番の出題傾向を模して作成した練習用オリジナル問題であり、 実際の試験で出題された問題ではありません。AI 採点機能の動作確認用としてご活用ください。 本番形式の学習には、実際の IPA 過去問（午前問題）をご利用ください。
⚠️ 練習用オリジナル問題です。本ページに掲載している午後問題は、IPA過去問の形式を模して作成した練習用オリジナル問題であり、実際の試験で出題された問題ではありません。
AI採点は目安です。本試験の採点とは異なる可能性があります。 採点結果は学習の参考程度にご利用ください。
クラウドサービス利用環境におけるITサービスの可用性管理について
設問ア
0 / 800 字あなたが責任を担うITサービスの概要と、可用性管理を強化する契機となった背景について、800字以内で述べよ。
構成のポイント（ヒント）
- 冒頭2-3行で対象（業種／規模／自身の役割）を提示し、文脈を即座に把握できる構成にする
- 背景は3要素以上を挙げ、具体的な数値や事実を添える
- 設問イへの橋渡しとして、最終段落で次の論点に着地させる
- 「私は〜の立場で」と主語を明示し、当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私は、従業員数約1,000名の製造業A社において、情報システム部門のITサービスマネージャとして、基幹業務システム（以下、本システム）の運用・管理を担当している。本システムは、販売管理、生産管理、在庫管理、会計といった主要業務を支える、全社横断的な重要システムである。 本システムの可用性管理を強化する契機となったのは、2年前に発生した大規模なシステム障害である。当時、本システムはオンプレミス環境で稼働しており、ハードウェア故障とそれに伴うデータ破損が複合的に発生し、約12時間のシステム停止を余儀なくされた。この障害により、受注処理の遅延、生産ラインの一部停止、顧客からの問い合わせ殺到など、事業継続に甚大な影響が出た。特に、受注機会の損失や顧客信頼の低下は看過できないレベルであった。 この経験から、私は、従来の可用性管理体制では、現代のビジネス環境において求められるレベルのITサービス継続性を確保できないと強く認識した。特に、単一障害点のリスク、復旧時間の長期化、そして障害発生時の影響範囲特定と情報連携の遅延が課題であった。このため、経営層からの強い要請もあり、本システムをクラウドサービスへ移行し、可用性管理を抜本的に見直すプロジェクトを主導することになった。このプロジェクトでは、従来のオンプレミス環境では実現困難であった、高可用性、迅速な災害復旧、そして運用コストの最適化を目標とした。
採点の観点
【A評価相当】 - 対象事業／プロジェクトの概要（規模／自身の立場）が具体的に記述されている - 背景・前提が複数の論点から立体的に分析されている - 設問イ・ウへの伏線として論点の構造化が為されている 【B評価相当】 - 概要は記載されているが規模感や立場が曖昧 - 背景の記述が単発的で構造化が弱い 【C評価相当（要改善）】 - どの組織でも当てはまる一般論 - 背景・前提が当該事業／プロジェクトに紐付いていない
設問イ
0 / 800〜1600 字設問アで述べた背景を踏まえて、あなたが設計したクラウド利用環境下での可用性管理の内容と、設計上で重視した点を、800字以上1,600字以内で具体的に述べよ。
構成のポイント（ヒント）
- 全体像を冒頭で要約し、読み手に骨格を先に提示する（パラグラフ・ライティング）
- 「重視した点」は2〜3点に絞り、それぞれを独立した節として論述する
- 各重視点には『なぜそう判断したか』『代替案を取らなかった理由』を添える
- 設問アとの整合を1対1で対応させ、論理的整合性を見せる
- 数値（投資額／期間／顧客数／市場規模）を最低3箇所に織り込む
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問アで述べた背景を踏まえ、私は本システムのクラウド移行プロジェクトにおいて、可用性管理の設計を主導した。設計の基本的な考え方は、複数のクラウドサービスと外部委託先を組み合わせたハイブリッド環境において、エンドツーエンドの可用性を確保することである。 可用性目標は、通常の障害を対象に年間稼働率99.99%（365日で停止約52.6分以内）とした。これを超える広域災害についても停止を集計するが、別に復旧目標RTO4時間、データ復旧目標RPO1時間を設ける。RTOを満たしても年間可用性目標を満たすとは限らないため、両方の指標を事業部門と合意した。 次に、具体的な可用性管理の設計内容である。本システムは、主要な業務アプリケーションをパブリッククラウドA社（IaaS/PaaS）上に構築し、データバックアップと一部の非同期処理をパブリッククラウドB社（SaaS）に連携する構成とした。また、ネットワークインフラの一部と監視運用は専門の外部ベンダーC社に委託した。 設計上で最も重視した点は、責任分界点の明確化と、それを踏まえた冗長化・監視・復旧プロセスの統合設計である。 1. **多層的な冗長化と分散配置**: クラウドA社内では、アプリケーションサーバーを複数アベイラビリティゾーンに分散配置し、ロードバランサでトラフィックを分散した。データベースはマルチAZ構成とし、レプリケーションによるデータ同期を確保した。また、クラウドA社とクラウドB社間のデータ連携は、非同期レプリケーションを基本とし、片方のクラウドに障害が発生しても、もう一方で業務継続が可能な設計とした。 2. **エンドツーエンドの監視と通知設計**: 複数のクラウドサービスと外部ベンダーをまたぐため、統合監視ツールを導入し、各サービスの稼働状況、ネットワーク遅延、アプリケーション性能をリアルタイムで監視する仕組みを構築した。異常検知時には、自動的に担当者へ通知されるだけでなく、インシデント管理システムに連携され、関係者全員が状況を把握できる体制を整えた。特に、外部ベンダーC社とは、監視対象と通知ルールについて詳細なSLA（Service Level Agreement）を締結し、責任範囲を明確化した。 3. **障害発生時の影響範囲分析と復旧手順の確立**: 障害発生時に、どのクラウドサービス、どのコンポーネント、どの業務に影響が出ているかを迅速に特定できるよう、サービスマップと依存関係図を整備した。また、各障害シナリオに対する復旧手順書を詳細に作成し、定期的な訓練を実施することとした。この際、ISO/IEC 27001（情報セキュリティマネジメントシステム）の要求事項も考慮し、情報セキュリティと可用性の両面からリスクアセスメントを行った。 4. **SLAとサポート契約の整合性確保**: 各クラウド事業者および外部ベンダーC社とのSLAやサポート契約の内容を精査し、我々が設定した可用性目標と矛盾がないかを確認した。特に、障害発生時の連絡体制、エスカレーションパス、復旧目標時間について、各契約で定められた内容と自社の要求事項とのギャップを埋めるための交渉を行った。この交渉は困難を伴ったが、最終的には、主要なクラウド事業者とはプレミアムサポート契約を締結し、障害時の迅速な対応を確保した。 クラウド間の遅延とデータ整合性が課題となった。専用線で転送経路を安定させ、レプリケーション遅延を監視してRPO超過前に通知する設計とした。切替え時は旧側の更新を停止し、反映済み位置を確認する。分断時の二重更新を防ぎ、切戻し前も差分を照合する。
採点の観点
【A評価相当】 - 戦略／設計／計画／監査手続の内容が具体的に記述されている - 設問アの背景と論理的に対応している - 「重視した点」が3つ程度、それぞれに具体的判断と理由が明示されている - 数値（金額／期間／規模）が適切に織り込まれている 【B評価相当】 - 戦略／設計／計画は記述されているが、提供価値が一般論にとどまる - 重視点が単に列挙されているだけで判断理由が弱い - 設問アとの連携が弱く、戦略が独立して語られている 【C評価相当（要改善）】 - 標語の繰り返しで具体性に欠ける - 自身の役割が見えず、評論的記述に終始
設問ウ
0 / 600〜1200 字設問イで述べた可用性管理について、運用・改善上の工夫、関係者との合意形成、及び評価と今後の改善点を、600字以上1,200字以内で具体的に述べよ。
構成のポイント（ヒント）
- 経営層／関係者への説明と合意形成を、それぞれ独立段落で論じる
- 反対意見や困難の具体例を必ず1つ以上盛り込み、それへの対応を描く
- 評価点と改善点を明確に分け、改善点には今後への具体的アクションを添える
- 数値（期間／工数／合意までのステップ数）を散りばめて当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問イで設計した可用性管理は、運用開始後も継続的な改善と関係者との合意形成が重要である。私は以下の工夫と評価・改善を行った。 **運用・改善上の工夫** 半期ごとに事業部門と委託先を含む可用性レビューを開き、停止時間、未解決課題、改善策の進捗を確認した。年1回のDR訓練では、通信断や担当者不在も組み込み、復旧手順と連絡体制を見直した。 変更後の障害は、まず復旧し、原因分析を問題管理へ引き継いだ。ミドルウェア更新による障害を受け、変更管理に本番相当の事前試験と切戻し判定を追加した。 **関係者との合意形成** 複数の関係者を巻き込む可用性管理においては、合意形成が不可欠である。私は、定期的な情報共有会を設け、各関係者の役割と責任、SLAの遵守状況、改善活動の進捗を透明化することに努めた。特に、事業部門に対しては、可用性向上の投資対効果を具体的な数値で示し、理解と協力を得た。例えば、システム停止時間の短縮が、受注機会損失の低減にどのように寄与するかを説明した。 合意形成における困難な点として、外部ベンダーC社とのSLA改定交渉が挙げられる。当初、C社は監視対象の追加や通知レベルの厳格化に難色を示した。これに対し、私は、本システムの事業継続における重要性を繰り返し説明し、C社が提供するサービスの価値向上にも繋がることを強調した。最終的には、C社の技術担当者と共同で監視ツールの設定を見直し、より実効性の高いSLAに改定することで合意した。これにより、障害発生時の検知から通知までの時間が平均15分から5分に短縮された。 **評価と今後の改善点** 本番で利用者が影響を受けた停止時間は2年間で合計52.6分で、稼働率約99.995%となった。一方、災害訓練の復旧所要時間は従来8時間から2時間となり、RTO4時間以内を達成した。本番停止と訓練の時間を分けて集計し、訓練の成功だけで可用性を保証しないようにした。 今後の改善点としては、以下の2点を考えている。 第一に、閾値で捉えにくい劣化を検知するため、過去の障害前のメトリクスを分析する。誤報率と検知から対応までの時間も評価し、通知を増やすだけで終わらせない。 第二に、本番相当の検証環境で段階的に障害を注入し、代替経路や復旧手順の不足を確認する。本番で実施する場合は影響範囲、停止条件、切戻しを事前承認し、利用者への影響を管理する。
採点の観点
【A評価相当】 - 関係者への説明・合意形成の両方を具体的に記述 - 「評価」と「改善点」が両方明示され、改善点には次への学びがある - 反対意見・困難への対応プロセスが具体的に描かれている - 自身の関与と判断が明確 【B評価相当】 - 説明や合意形成は記述されているが、困難の描写が弱い - 評価のみで改善点が形式的、または逆 【C評価相当（要改善）】 - 「説明した」「合意を得た」と結果のみで過程が不明 - 改善点が当たり障りのない一般論