ITパスポート 令和8年度 問48：service_managementに関する問題

答えは c です。

この問題は3つの対応を区別します。

• 今困っているのをとりあえず何とかする＝インシデント管理（a）
• なぜ起きたか原因を調べて再発を防ぐ＝問題管理（b）
• 『仕組み自体をもっと良くする』＝サービスマネジメントシステムの改善（c）

cは『使用量を早めに把握して、容量不足の兆候に早く気づけるようにする』こと。これはチェックの仕組みそのものをレベルアップしています。

👉 覚え方：「改善＝仕組みを良くして次から困らないようにする」。

dの『すぐ増設手続き』はその場の対応(インシデント寄り)なので改善には含まれません。だから答えは c だけです。

なぜこれが正解か

正解は c。サービスマネジメントシステム（SMS）の改善とは、サービス提供の『仕組み・プロセスそのもの』を継続的に向上させる活動。選択肢cの『使用量をタイムリーに把握し、容量不足の兆候を早期検知できるようにする』は、監視・検知の仕組みを強化する改善活動であり、これに該当する。

各選択肢の解説

• a：使用量の大きいファイルを一時的に別ストレージへ移動→今の支障を解消するインシデント管理（暫定対応）。
• b：上限に達した原因を特定し再発防止策を検討→根本原因究明の問題管理。
• d：すぐに増設手続きを進める→当面の事象解消のための対応で、インシデント対応寄り。改善（仕組みの恒久的向上）とは性質が異なる。

覚え方・ひっかけ注意

3区分の判定基準：『今すぐ復旧＝インシデント管理』『原因究明＝問題管理』『仕組みを良くする＝SMSの改善』。dの『増設』を改善に入れたくなるが、これは個別事象への対処であって仕組み改善ではない。『早期検知できるようにする』というプロセス強化(c)だけが改善。

理論的背景

本問はITILのサービスマネジメントにおけるインシデント管理・問題管理・継続的サービス改善（CSI：Continual Service Improvement）の3プロセスの適用範囲を正確に識別することを問う。選択肢cのみが「サービスマネジメントシステムの改善」に該当するという判断根拠を詳細に解説する。

ITILv4では継続的改善を「PDCAサイクルの継続的な実施により、サービス・プロセス・実践の効率と有効性を改善するすること」と定義する。cの「共有ディスクの使用量をタイムリーに把握し、容量不足の兆候を早期に検知できるようにする」は、現行の月次チェックという監視プロセスをリアルタイム監視へと改善する提案であり、「管理プロセス自体の変革」を意味する。これが継続的改善（SMSの改善）の本質である。

aの「一時的別ストレージへの移動」はインシデント管理のワークアラウンド（暫定対処）であり、サービス継続のための即時対応。bの「根本原因特定と再発防止策の検討」は問題管理。dの「増設手続きの推進」はインシデント管理の恒久対処（サービス要求として変更管理へエスカレーション）または問題管理の解決策実施に近い。

実務での使われ方

クラウドストレージ管理の現代では、AWS S3・Azure Blob Storage・Google Cloud Storageのストレージ使用量はリアルタイムメトリクスとして監視ダッシュボードに表示され、閾値超過時には自動アラート（CloudWatch・Azure Monitor・Cloud Monitoring）が発動する仕組みが標準化されている。本問が描くような「月次チェック→手動対応」というプロセスは、現代の自動化されたクラウド管理では既に時代遅れの手法であり、「プロセス改善が必要」という問題設定の背景はDXの文脈として理解できる。

容量管理（Capacity Management）はITILの独立したプロセスとして存在し、現在の容量・近未来の需要予測・コスト最適化の3軸を管理する。キャパシティ計画はSLA達成の基盤であり、パフォーマンス管理と密接に連携する。

試験での位置づけ

本問のような「a〜d の記述を複数のITSMプロセスに分類する」タイプの問題はITパスポートで頻出する応用問題形式である。単純な定義暗記では対応できず、各プロセスの「目的（Why）・タイミング（When）・アクション（What）」を実践的に理解していることが求められる。識別の鍵は「何を変えているか」：サービス継続→インシデント管理、根本原因追求→問題管理、プロセス・仕組み自体の変革→SMSの改善。近年のシラバスv6（2022年改訂）ではDX推進文脈でのITSMプロセス適用事例の理解が強化されており、このような複合判断問題の出題が増加している。

選択肢の発展補足

選択肢dの「増設手続きの推進」は文脈によりインシデント管理の恒久対処または変更管理のどちらに分類するかが曖昧になりやすい。ITILでは「インシデント→問題管理で根本原因特定→変更管理で恒久対処を実施」という流れが標準プロセスであり、増設という変更作業はRFC（Request For Change）を経て変更管理プロセスで実施するのが正しい。SMSの改善との違いは「特定の問題の解決」か「管理プロセス自体の構造的変革」かにある。dは「この特定のインシデントを解決するための増設」であり、SMSの改善のように「今後同様の問題が起きないよう監視の仕組み自体を変える」とは本質的に異なる点を理解することが重要。