ITパスポート 令和3年度 問37：サービスマネジメントに関する問題

答えは d「リリース及び展開管理」 です。

テストが終わった新しいサーバを、本番のシステムに"正式に入れて動かす"作業ですよね。この「新しいものを本番に出して使い始める」工程がリリース及び展開管理です。

スマホアプリでいうと、開発したアプリをアプリストアに"公開して使えるようにする"あの瞬間に近いです。

👉 覚え方：「リリース＝世に出して本番投入」。テスト済みのものを本番へ！

ほかの選択肢：a インシデント管理＝トラブルを早く直す／b 変更管理＝変えてよいか審査・承認する／c 問題管理＝トラブルの根本原因を調べる。

なぜこれが正解か

正解は d。リリース及び展開管理は、承認された変更（新しいサーバ・ソフトなど）を、テスト後に本番環境へ実際に導入・展開し、稼働させるプロセス。問題文の「動作テストが終わったサーバをシステムに組み入れて稼働させた」がまさにこれに該当する。

各選択肢の解説

• a インシデント管理：サービス中断や品質低下（インシデント）を、できるだけ早く復旧させる活動。
• b 変更管理：変更を行ってよいかを評価・承認し、リスクを管理する活動（"やってよいか"を決める段階）。
• c 問題管理：インシデントの根本原因を究明し、再発を防止する活動。

覚え方・ひっかけ注意

変更管理（b）と紛らわしいが、変更管理＝「変更を承認・計画する」、リリース及び展開管理＝「承認された変更を実際に本番へ展開する」という役割分担で区別する。本問は"稼働させた＝本番投入の実作業"なのでd。

ITILプロセスの連携フロー

ITIL v3（サービストランジション・フェーズ）における変更・リリース・構成管理の連携は以下の流れ。①変更管理：変更要求（RFC：Request for Change）を評価し、CAB（Change Advisory Board）で承認/却下を決定してリスクと優先度を管理。②リリース及び展開管理：承認済みの変更を対象に、ビルド（構築）・テスト環境での検証・本番展開（リリース）を計画・実行。③構成管理（SACM）：展開完了後にCMDB（構成管理データベース）を更新し、CI（構成アイテム：サーバ・ソフトウェア等）の現状を記録。本問はサーバ増設という変更が①で承認された後に②で本番投入される段階を問うている。

4プロセスの役割の精密な区別

• インシデント管理：SLA内での迅速な復旧が目的。原因究明より速度優先。暫定対処（ワークアラウンド）も認める。
• 問題管理：インシデントの根本原因（Root Cause Analysis・RCA）を特定し、Known Error（既知の誤り）として記録して恒久対策を打つ。再発防止が目的。
• 変更管理：変更の標準化・審査・承認による統制。未承認変更がインシデントの主要原因になるため予防的に機能する。
• リリース及び展開管理：承認済み変更の計画的な本番反映。テスト・ステージング・本番の環境管理とロールバック計画が重要。

近代的なリリース管理との接続

現代のDevOpsではCI/CD（継続的インテグレーション/継続的デリバリー）パイプライン（GitHub Actions・Jenkins・GitLab CI等）がリリース及び展開管理を自動化する。コードのプッシュから自動ビルド→テスト→本番デプロイまでが数分で完了し、デプロイ頻度が週1回から数十回/日に増加した。リスク低減技術としてブルーグリーンデプロイメント（新旧環境を並列維持してトラフィック切り替え）・カナリアリリース（一部ユーザーにのみ新バージョンを展開して様子見）・フィーチャーフラグ（コードを事前デプロイしてフラグで機能ON/OFF）が標準的に使われる。

上位資格への接続

基本情報技術者ではITILの4プロセスの役割識別・サービスデスク・SLA・PDCA（ITサービス改善）が頻出。応用情報以上ではITIL 4の概念（サービスバリューチェーン・34プラクティス・DevOpsとの統合）・ISO/IEC 20000との関係・CI/CDパイプライン設計まで踏み込む。

選択肢の発展補足

インシデント管理（選択肢a）では、重大インシデント（P1/P2等の高優先度）を専用チームで扱う「重大インシデント管理（Major Incident Management）」を別プロセスとして設けることが多い。問題管理（選択肢c）の成果物である「既知の誤り（Known Error）」と「ワークアラウンド」はナレッジベース（KEDB）に登録され、次回同じ症状のインシデントが発生した際にサービスデスクが迅速に参照・適用できる——インシデント管理と問題管理の間にある「一次解決率向上」という接点がITSM全体の品質向上に貢献する。