【ITパスポート練習問題 6.3対応】(1) サービスマネジメントシステムの概要 – 2

【解説】

正解: 3 サービスの稼働時間とパフォーマンスを最大化する

この問題は、ITサービスマネジメントにおける「可用性管理」の定義と、その活動が目指す中心的なゴールを理解しているかを確認するものです。

可用性管理とは、サービスが利用者の期待通りに「いつでも使える状態」を維持するための活動です。そのため、システムが停止する時間を極力減らし（稼働時間の最大化）、必要な処理能力を維持すること（パフォーマンスの維持）が主な目的となります。

選択肢1の「コスト削減」は財務管理の領域であり、選択肢2の「サポート対応の迅速化」はサービスデスクやインシデント管理の領域です。これらは可用性管理に関連する要素ではありますが、活動の直接的な目的ではありません。

【解説】

正解: 2 MTBF（平均故障間隔）

この問題は、システムの信頼性を客観的に測定するための代表的な指標（KPI）について、その意味と用途を理解しているかを問うものです。

可用性管理では、システムが故障せずにどれだけ長く動き続けられたかを評価するために、MTBF（平均故障間隔）という指標を用います。この数値が大きいほど、システムは安定しており、信頼性が高いと判断されます。

選択肢1の「ROI（投資対効果）」は投資に対する利益率を見るための財務指標です。選択肢3の「KPI（重要業績評価指標）」は指標全体を指す総称であり、可用性管理特有の具体的な測定項目ではありません。

【解説】

正解: 1 障害発生時のデータ復旧速度を向上させる

この問題は、可用性管理の役割の範囲と、他の管理プロセス（特にサービス継続管理やインシデント管理）との境界線を理解しているかを確認するものです。

可用性管理は、事前に障害を防ぎ「稼働し続けること」や、サービスの信頼性を設計・計画することに重点を置いています。障害が発生した後の具体的な「データ復旧作業の速度」そのものは、バックアップ計画やITサービス継続管理、あるいはインシデント管理の対応能力に依存するため、可用性管理の直接的な提供価値とは区別されます。

選択肢2の「予期せぬダウンタイムの減少」は可用性管理の核心的な価値であり、選択肢3の「評価指標の策定」も管理活動の一環として適切です。したがって、不適切なものは1となります。

【解説】

正解: 2 災害発生時に迅速にサービスを復旧するための計画を策定する

この問題は、「ITサービス継続管理（ITSCM）」の目的と、リスクに対する備えの重要性を理解しているかを問うものです。

ITサービス継続管理は、地震や火災などの重大な災害が発生した際に、ビジネスへの影響を最小限に抑え、決められた時間内にシステムを復旧させることを目的としています。そのために、事前の計画策定や訓練が最も重要な活動となります。

選択肢1の「ソフトウェアのバージョンアップ」は変更管理やリリース管理の活動です。選択肢3の「コスト削減施策」は財務管理などの活動であり、災害対応を主眼とする継続管理とは目的が異なります。

【解説】

正解: 2 ハードウェアの性能向上のための投資計画

この問題は、事業継続計画（BCP）に含めるべき内容と、通常のIT投資計画とを正しく区別できるかを確認するものです。

BCP（Business Continuity Plan）は、緊急事態において事業を止めない、あるいは早期に再開するための行動計画です。ハードウェアの性能向上による日常的な業務改善のための投資計画は、キャパシティ管理や事業戦略の範疇であり、緊急時の対応計画であるBCPには含まれません。

選択肢1の「業務の優先順位の設定」は、非常時にどの業務を優先して復旧させるかを決めるために必須です。選択肢3の「災害発生時の対応手順」も、混乱なく行動するためにBCPの中核となる項目です。

【解説】

正解: 1 データのバックアップ頻度

この問題は、災害復旧（DR：Disaster Recovery）計画において、技術的に何が最も復旧の成否を左右するかを理解しているかを問うものです。

災害などでシステムが全壊した場合、ハードウェアは買い直せますが、データはバックアップがなければ二度と戻りません。そのため、「いつの時点までデータを戻せるか（RPO：目標復旧時点）」を決定するバックアップの頻度は、DR計画において極めて重要な要素です。

選択肢2の「従業員の研修」や選択肢3の「プロセス見直し」も組織運営上は大切ですが、災害復旧という緊急時の技術的な復元力においては、データの保全（バックアップ）が最優先事項となります。

【解説】

正解: 2 関係者に対してサービスの状態や成果を説明する

この問題は、ITサービスマネジメントにおけるコミュニケーションの一環である「サービス報告」の意義を問うものです。

サービス報告の目的は、顧客や経営層などのステークホルダーに対し、サービスが合意したレベル（SLA）通りに提供されているか、どのような実績が出ているかを定期的かつ客観的に伝えることです。これにより、信頼関係の維持や透明性の確保を図ります。

選択肢1の「コスト分析」や選択肢3の「開発計画の立案」は、報告の作成過程や報告後のアクションとして行われることはありますが、報告プロセス自体の主目的（伝えること）とは異なります。

【解説】

正解: 3 従業員の福利厚生費用

この問題は、顧客向けのサービス報告書（SLAレポートなど）に記載すべき適切な指標と、内部管理情報を区別できるかを確認するものです。

サービス報告では、顧客に関係のある「サービスの品質」を示す指標が用いられます。稼働率や応答時間などはサービスの品質を直接表すため適切です。

一方、選択肢3の「従業員の福利厚生費用」は、サービス提供企業の内部的な人事・経理情報であり、顧客に対するサービスの品質や成果を示す指標ではないため、通常は報告対象に含まれません。

【解説】

正解: 3 サービス提供に必要な機器を調達する

この問題は、サービス報告プロセスの業務範囲と、他の運用業務（調達など）との違いを理解しているかを問うものです。

サービス報告プロセスの役割は、現状を測定・評価し、それを関係者に伝達することです。結果をもとに改善提案を行うことは含まれますが、実際の「機器の購入・調達」といった実務アクションは、購買部門や資産管理プロセスなどが担当します。

選択肢1の「目標達成状況の監視」や選択肢2の「改善提案」は、報告を作成し品質を維持するために必要な活動であり、プロセスの範囲内です。

【解説】

正解: 1 PDCAサイクル

この問題は、業務改善の基本的なフレームワークである「PDCA」について理解しているかを確認するものです。

継続的改善プロセスでは、Plan（計画）、Do（実行）、Check（評価）、Act（改善・処置）の4段階を繰り返す「PDCAサイクル」が基本モデルとして採用されています。これにより、一度きりの改善で終わらせず、スパイラルアップ（段階的な向上）を目指します。

選択肢2の「KGI」は目標達成指標という用語であり、サイクルではありません。選択肢3の「OODAループ」は意思決定のフレームワークであり、継続的な品質管理の文脈ではPDCAがより一般的です。

【解説】

正解: 2 既存サービスの停止手順の作成

この問題は、「改善」という活動に含まれる内容と、定型的な「運用手順作成」の違いを区別できるかを問うものです。

継続的改善（CSI）は、サービスの品質や効率をより良くするための活動です。現状を測定・評価し、改善策を計画することはCSIに含まれます。

一方、選択肢2の「サービスの停止手順の作成」は、日常的な運用操作マニュアルの作成にあたり、これは「サービスの設計」や「移行」の段階で行うべき作業です。「改善」そのものを目的とした活動ではないため、ここでは不適切となります。

【解説】

正解: 3 改善結果を標準化する

この問題は、PDCAサイクルの各フェーズの役割、特に最後の「Act（処置・改善）」で何を行うべきかを理解しているかを確認するものです。

Actの段階では、Check（評価）の結果を受けて次のアクションを決定します。うまくいった改善策は、今後も継続できるようにルール化・標準化して定着させます。逆にうまくいかなかった場合は、修正案を考えて次のPlanにつなげます。

選択肢1の「計画通りの実施」はDo（実行）、選択肢2の「効果の評価」はCheck（評価）の段階で行う活動です。

【解説】

正解: 3 目標や方針を設定し、計画を立てる

この問題は、PDCAサイクルの起点となる「Plan（計画）」フェーズの具体的な活動内容を理解しているかを問うものです。

Planの段階では、現状の問題点を把握した上で、「何をどこまで改善するか」という目標を設定し、それを達成するための具体的なスケジュールや方法を策定します。

選択肢1の「標準化」はAct（処置）、選択肢2の「活動の実施」はDo（実行）の段階で行う活動です。

【解説】

正解: 1 計画した活動を評価し、結果を分析する

この問題は、PDCAサイクルの「Check（評価）」フェーズで行うべき分析・検証活動について理解しているかを確認するものです。

Checkの段階では、Doで実行した内容が、最初にPlanで立てた目標に対してどの程度の成果を上げたかを測定し、ギャップや原因を分析します。この評価がなければ、次の改善につなげることができません。

選択肢2の「標準業務として定着させる」はAct（処置）、選択肢3の「具体的な行動」はDo（実行）またはAct（処置）に該当します。

【解説】

正解: 2 業務プロセスの継続的な改善を図るため

この問題は、なぜPDCAサイクルを回すのかという根本的な目的を理解しているかを問うものです。

PDCAサイクルの最大の特徴は「サイクル（循環）」であることです。一度計画して実行して終わりではなく、評価と処置を経て次の計画へとつなげることで、業務プロセスやサービス品質を時間をかけて継続的に向上させることが目的です。

選択肢1の「短期間での成果」や選択肢3の「計画変更を減らすこと」は、状況によっては結果として現れることもありますが、PDCAを適用する本来の目的ではありません。

【解説】

正解: 1 ユーザーに提供するサービス内容を明確にする

この問題は、ITサービスマネジメントにおける「サービスカタログ」の役割と目的を理解しているかを確認するものです。

サービスカタログは、IT部門が提供しているサービスのメニュー表のようなものです。ユーザーに対して「どのようなサービスが利用可能か」「申し込み方法は何か」といった情報を明確に提示し、理解してもらうことを目的としています。

選択肢2の「コスト削減の指針」や選択肢3の「開発計画の管理」は、内部向けの管理資料の役割であり、ユーザーへの提示を目的とするサービスカタログとは異なります。

【解説】

正解: 3 提供される各サービスの詳細な説明

この問題は、サービスカタログに具体的にどのような情報を記載すべきかを問うものです。

ユーザーがサービスを選んで利用するためには、サービスの名前だけでなく、具体的な内容、利用条件、料金（社内課金の場合）、サポート受付時間などの詳細な説明が必要です。

選択肢1の「提供者の給与情報」や選択肢2の「個人情報管理手順」といった内部的な管理情報は、利用者がサービスを選択・利用する上で直接必要としない情報であり、カタログには記載しません。

【解説】

正解: 2 ユーザーが利用できるサービスの透明性が向上する

この問題は、サービスカタログを導入することで得られるメリットを理解しているかを確認するものです。

サービスカタログがあることで、ユーザーは「IT部門が何をしてくれるのか」を一目で把握できるようになります。これにより、サービスのブラックボックス化を防ぎ、透明性が向上します。また、ユーザーとIT部門の認識のズレを減らす効果もあります。

選択肢1の「サービスレベル管理が不要になる」は誤りです。カタログの内容を守るために管理はより重要になります。選択肢3の「すべて無料になる」というのも、カタログの有無とは無関係な課金ポリシーの話です。

【解説】

正解: 2 上位の専門知識や権限が必要な問題を迅速に解決するため

この問題は、サポート業務における「エスカレーション（階層化対応）」の概念と目的を理解しているかを問うものです。

現場の担当者では解決できない難しい技術的な問題や、権限を超える判断が必要なクレームが発生した場合、より詳しい専門家や上司に担当を引き継ぐことをエスカレーションと呼びます。これにより、組織として迅速かつ適切な解決を目指します。

選択肢1の「同じ担当者で解決」はエスカレーションの逆です。選択肢3の「苦情を軽視」も誤りであり、むしろ苦情を重視して上位者が対応するために行います。

【解説】

正解: 2 日常的な問い合わせで、特に問題がない場合

この問題は、エスカレーションを行うべきタイミングと、行う必要がない通常の対応を区別できるかを確認するものです。

エスカレーションは「通常の手順では解決できない場合」に行う例外的な処理です。マニュアル通りに対応できる日常的な問い合わせであれば、担当者がそのまま完了させるべきであり、エスカレーションの必要はありません。

選択肢1の「自分の権限では解決できない場合」や選択肢3の「重大な障害報告」は、まさにエスカレーションが必要な典型的なシチュエーションです。

【解説】

正解: 1 問題発生時の詳細な状況と現在の対応状況

この問題は、スムーズなエスカレーションを行うために必要な情報共有（引継ぎ）の質について問うものです。

上位者や専門家に引き継ぐ際、最も重要なのは「何が起きたか（事実）」と「今まで何をしたか（経緯）」の正確な情報です。これらが不足していると、引継ぎ先が最初から調査し直すことになり、解決が遅れます。

選択肢2の「顧客の個人的意見」や選択肢3の「担当者の感想」は、参考にはなるかもしれませんが、問題解決に向けた客観的な事実情報と比べると重要度は低くなります。

【解説】

正解: 3 新しいシステムにスムーズに切り替えて中断を最小限に抑えるため

この問題は、システムライフサイクルにおける「サービス移行（トランジション）」段階の目的を理解しているかを確認するものです。

開発されたシステムを本番環境へ導入したり、古いシステムから切り替えたりする際、予期せぬトラブルで業務が止まるリスクがあります。サービス移行の目的は、このリスクを管理し、スムーズに切り替えを行い、ビジネスへの悪影響（中断など）を最小限にすることです。

選択肢1の「完全廃止」は移行の一部ではありますが、目的全体ではありません。選択肢2の「無料提供」は移行とは関係のないポリシーの話です。

【解説】

正解: 2 顧客のクレーム対応のガイドライン

この問題は、システム移行計画に含めるべき技術的・管理的な要素と、日常的な運用ルールを区別できるかを問うものです。

移行計画には、失敗した場合のリスク対策や、データを新システムに移すための手順、バックアップなどが不可欠です。

一方、選択肢2の「クレーム対応のガイドライン」は、移行後の「日常運用（サービスオペレーション）」で使用するマニュアル類であり、移行そのものを実行するための計画書には通常含まれません。

【解説】

正解: 1 システムのダウンタイムを最小限に抑える

この問題は、移行作業中における最優先事項を理解しているかを確認するものです。

システムの切り替え作業中は、一時的にサービスが使えなくなる可能性があります。ビジネスへの影響を減らすため、この停止時間（ダウンタイム）を可能な限り短くすること、あるいは業務時間外に行うことなどが重要視されます。

選択肢2の「新機能の追加」は開発段階の話であり、移行中は機能追加よりも安定稼働が優先されます。選択肢3の「データ削除」も、移行完了後の整理作業であり、移行中の最重要事項ではありません。

【解説】

正解: 2 新サービスが品質基準を満たしていることを確認する

この問題は、システムリリースの直前に行われる「サービス受入れ（アクセプタンス）」の目的を理解しているかを問うものです。

サービス受入れ基準は、開発されたシステムが、実際の業務に耐えうる品質や機能を備えているかを判断するためのゴールラインです。この基準をクリアすることを確認して初めて、本番環境への導入が許可されます。

選択肢1の「コスト削減」や選択肢3の「フィードバック収集」は、受入れ判定の直接的な目的ではありません。

【解説】

正解: 1 サービスの機能的要件やセキュリティ要件

この問題は、サービス受入れテストで具体的に何をチェックするのか、その評価項目を理解しているかを確認するものです。

受入れ基準には、要件定義で決められた「機能が正しく動くか」だけでなく、情報の安全性に関わる「セキュリティ要件」や、処理速度などの「非機能要件」が含まれます。これらがすべて満たされているかをチェックします。

選択肢2の「サポート担当者の満足度」や選択肢3の「ユーザーの意見」といった主観的な要素は、客観的な受入れ基準（合格/不合格の判定）としては不適切です。

【解説】

正解: 3 不適合箇所を修正し再テストする

この問題は、受入れ基準を満たせなかった場合の正しいプロセス対応を理解しているかを問うものです。

もし基準を満たさない項目（バグや性能不足など）が見つかった場合、そのまま見切り発車で導入するのはリスクが高すぎます。必ず問題箇所を修正し、再度テストを行って基準をクリアしたことを確認する必要があります。

選択肢1の「基準を緩和」することや、選択肢2の「即座にキャンセル」することは適切な対応ではありません。まずは修正による解決を目指します。