🚀応用情報技術者試験・変更管理の解き方|RFC・CAB・PIRの重要ポイントを徹底網羅
ITサービスマネジメント(ITSM)の核心である「変更管理」について、試験のポイントと実務での応用を網羅的に解説します。
📝演習問題:物流システムの変更管理改善
【ケーススタディ:B社(中堅物流企業)】
事業拡大に伴い、物流管理サービスへの変更要求(RFC)が急増。現在、システム部ではリリース遅延や優先順位の不明確さが深刻な問題となっている。
● 現在顕在化している主な問題点
- 個人的な要望の混入: 部署長の承認なしにメール一本でRFCが提出されている。
- 優先順位の形骸化: 法規制対応以外は受付順であり、重要なRFCが実施希望日を過ぎてしまう。
- 展開作業の失敗: 切り戻し計画(バックアウト計画)が不十分で、サービス開始を遅延させている。
- 不透明なコスト配分: 開発費用が「人数割り」で全社配分されており、受益者負担になっていない。
● 改善に向けた「手順案」の重要ポイント
| プロセス | 新ルールの要点 |
|---|---|
| RFCの提出 | 自部署の部長承認を必須とし、内容を精査する。 |
| RFCの評価 | CAB(変更諮問委員会)を設置。受益者部署の代表を参加させる。 |
| 意思決定 | 優先度「低」の案件は、変更管理マネージャへ権限委譲する。 |
| 評価指標 | 失敗した展開作業数や変更起因のインシデント数をKPIとする。 |
📌この記事のまとめ(要点)
- RFC(変更要求): 正式な依頼書。上司承認により「個人的な要望」をフィルタリングする。
- CAB(変更諮問委員会): 利害関係者による評価。ROIだけでなく法規制対応も重視。
- 権限委譲: 優先度の低い変更はマネージャに任せ、意思決定を迅速化。
- 切り戻し計画: サービス停止遅延を防ぐための「撤退プラン」。
- 受益者負担制: 公平性を保つため、利益を得る部署がコストを負担する。
- PIR(実装後レビュー): 変更の効果を確認し、KPIでプロセスを継続改善。
1. 変更の入り口:RFC(変更要求)の統制
📝RFC (Request for Change) とは?
ITシステムに対する変更を正式に依頼するための文書です。問題文では「依頼者の個人的な見解に基づくRFC」が課題となっていました。
- 対策: 提出前に「自部署の部長承認」を必須とする。
- 効果: 組織として優先順位が低い、または不要な変更を入口でカット(撲滅)できる。
2. 評価と承認:CABと優先順位
👥CAB (Change Advisory Board) の役割
変更によるリスク、コスト、影響範囲を多角的に評価する会議体です。
| 評価項目 | 詳細解説 |
|---|---|
| ROI (投資対効果) | 売上向上やコスト削減にどれだけ寄与するか。 |
| 法規制対応 | 重要! ROIだけで判断してはいけない。法令遵守のため必須。 |
| 実現可能性 | 技術的・時間的に実行可能か。 |
3. 迅速な意思決定:権限委譲の仕組み
⚡実務での使用状況:ボトルネックの解消
部長がすべての変更を承認していると、数が増えた際に判断が遅れます。そこで、優先度「低」の変更については、変更管理マネージャ(課長級)に決定権限を委譲します。これにより、部長は経営判断が必要な優先度「高」の案件に集中できます。
4. リリースと展開:失敗に備える「切り戻し」
🔄切り戻し計画 (Back-out Plan)
「予定時間内に作業が終わらない」「本番環境で予期せぬエラーが出た」場合に、システムを変更前の正常な状態に戻すための手順です。
- 目的: サービス開始時刻の遅延(SLA違反)を絶対に防ぐ。
- 必須要素: どの時点で継続を断念し、切り戻しを開始するかという「判断基準」と「時刻」。
5. コスト管理:受益者負担の原則
💰費用の配賦方法の変更
- 旧:人数割り配賦(全社員で均等負担)→ 不公平感がある。
- 新:受益者負担(利益を受ける部署が負担)→ コスト意識が高まり、無駄なRFCが減る。
⚠️この場合、CABには「費用を負担する部署の代表者」を参加させる必要があります。
6. 継続的改善:KPI(重要業績評価指標)
| KPI指標 | 測定の狙い |
|---|---|
| 失敗した展開作業数の削減率 | 事前テストや計画の精度の向上を確認する。 |
| 変更起因のインシデント数 | 変更作業そのものの品質を評価する。 |
| 実施希望日遵守率の増加率 | リソース逼迫の解消と、ユーザー満足度の向上を測る。 |
7. 具体的な使用状況のイメージ
シーン:物流システムの消費税率変更対応
- 経理部長がRFCを提出(法規制対応のためROI無視で承認)。
- CABを開催。システム部、営業部、経理部の代表が参加。
- 変更スケジュールを作成。サービス停止時間を日曜22:00〜翌4:00に設定。
- 作業中、予期せぬデータ破損が発生。午前3時の「Go/No-Go判断」で切り戻しを決断。
- 翌週、再トライして成功。数週間後にPIRを実施し、KPIを確認。
💡 試験攻略のあとがき:変更管理の「本質」を掴む
今回のB社の事例、いかがでしたでしょうか?応用情報技術者試験の午後問題では、単に「用語(RFCやCAB)」を知っているだけでなく、「なぜそのルールが必要なのか?」というビジネス的な背景を問う問題が非常に増えています。
- ITIL® 4へのシフト: 近年の試験では、従来のプロセス管理に加え、今回のKPIやROIのように「ビジネス価値」との連動を意識した出題がトレンドです。
- アジャイルとの対比: 厳格な変更管理(今回のようなウォーターフォール型)と、スピード重視のアジャイル開発での変更管理の違いを問われる可能性もあります。
- 構成管理との連携: 変更の影響範囲を特定するために、構成管理データベース(CMDB)を参照するという文脈はセットで覚えておきましょう。
合格への近道は、自分がシステム部の「D課長」になったつもりで問題文を読むことです。現場で起きている「要員のひっ迫」や「利用者からのクレーム」を、ITILのフレームワークを使ってどうスマートに解決するか。その視点を持つだけで、記述式の解答精度は格段に上がります。
あなたの試験合格と、実務でのスムーズなリリース管理を応援しています! 🚀
🎯記述で狙われる!試験直前「定型文」リスト
午後問題の「〜はなぜか?」「〜の狙いは何か?」に対する、そのまま使える解答パターンです。
| 問われる用語 | 記述解答の定型フレーズ |
|---|---|
| RFCの部長承認 | 「依頼者の個人的な見解に基づく不要な変更を排除(撲滅)するため。」 |
| 切り戻し計画 | 「展開作業の失敗時に、システムを変更前の正常な状態に復旧させ、サービス開始の遅延を防ぐため。」 |
| 権限委譲 | 「定型的な変更の承認を委譲することで、意思決定の迅速化を図り、上位者のボトルネックを解消するため。」 |
| PIRの実施 | 「変更の実施結果をレビューし、当初の目的(ROI等)の達成度や、新たな問題の有無を確認するため。」 |
| 受益者負担 | 「変更によって利益を受ける部署に費用を負担させ、コスト意識を向上させるとともに、配賦の公平性を担保するため。」 |
解答を記述する際は、問題文にある「具体的な課題(例:サービス停止が長引いている)」を主語に据えて、「〜することで、〜を解決するため」という構成にすると部分点をもらいやすくなります!
🎴ホバーで確認!重要用語フラッシュカード(20選)
カードに触れると裏面の「暗記必須ポイント」が表示されます。
🌟 全て正解できましたか? 繰り返し練習して、記述問題のボキャブラリーを増やしましょう!
⚠️【ひっかけ注意】一問一答チェックテスト
クリック・タップで「正解」と「ひっかけの理由」が表示されます。
応用情報の午後問題では、「役割の境界線」がよく狙われます。「誰が判断するのか(権限)」「何が目的か(コンプライアンスか利益か)」を常に意識して問題文を読みましょう。
📚用語集:変更管理・サービスマネジメント完全網羅マニュアル
問題文の文脈に基づき、試験合格に必要な周辺知識まで網羅的に解説します。
変更の理由、詳細、コスト、リスクを記載した正式な依頼文書。試験では「個人的な見解に基づく依頼」を防ぐ統制手段として「上司承認」とセットで頻出します。
変更プロセスの実行責任者。RFCの受付、優先順位の割り当て、CABの招集などを管理します。本問ではD課長が担当し、低リスク案件の権限委譲先となります。
変更の影響を多角的に評価し、助言を行う会議体。開発・運用だけでなく「受益部署(ユーザー)」を参加させることで、ビジネス面の影響を正しく評価します。
重大な障害対応など、通常のプロセスを待てない緊急変更を迅速に承認するための縮小版CAB。事後の記録(RFC化)は必須です。
変更実施後に、当初の目的(ROIなど)が達成されたか、新たな障害が発生していないかを確認する評価活動。承認時に実施時期を決めるのがベストプラクティスです。
展開作業の失敗時に、システムを変更前の正常な状態に復旧させる手順。サービス開始時刻を遵守するための「撤退基準時刻(Go/No-Go判断)」を含めます。
承認された変更の実施予定日をまとめたカレンダー。リソースの競合を避け、サービス停止時間帯(メンテナンスウィンドウ)への割り当てを可視化します。
「影響度」と「緊急度」に基づいて、RFCの対応順序を客観的に決めるための基準表。受付順による「重要な案件の遅延」を防ぐために使用します。
投資費用に対する利益の割合。適応保守(売上改善など)の承認可否を決める指標ですが、法規制対応などこれに縛られない案件との区別が必要です。
法令遵守。これに基づく変更は「実施希望日」が施行日に直結するため、ROIに関わらず最優先でリソースを割り当てる必要があります。
変更で利益を得る部署がコストを払う仕組み。人数割りのような全社均等配分よりもコスト意識が向上し、安易なRFCの抑制に繋がります。
上位決定者(部長等)の承認権限を実務担当者へ譲ること。優先度の低い「標準的な変更」を迅速に処理し、上位者の意思決定ボトルネックを解消します。
プロセスの有効性を測る指標。本問では「失敗した展開数」「変更起因のインシデント数」「実施希望日遵守率」などが設定されました。
外部環境の変化(法改正、OS更新、クラウド仕様変更など)に合わせてシステムを調整する活動。
システムで見つかったバグや障害を修正し、仕様通りの正常な状態に復旧させる活動。
承認された変更をパッケージ化し、実際に本番環境へ導入・公開する実作業プロセス。変更管理は「何をやるか」を決め、リリース管理が「どう入れるか」を担います。
サービス中断を最短時間で復旧させるプロセス。変更の失敗(リリース直後の不具合)を迅速に検知し、エスカレーションする重要な連携先です。
サービスの品質に関する利用者との合意。本問での「サービス開始の遅延」は、合意されたサービス稼働率の低下を招く重大な契約不履行リスクとなります。
IT資産の情報を管理する台帳。CABでの評価時に「このサーバを変更すると、どのアプリに影響が出るか」を確認するために不可欠なツールです。
手順が確立されており、過去に何度も成功している低リスクな変更。都度のCAB評価を省略し、事前承認済みの手順として迅速に実行されます。
📌 学習の仕上げ:
応用情報の午後問題では、「役割(誰が)」「判断材料(何を元に)」「目的(何のために)」の3つが揃うように解答を構成してください。例えば「受益部署の代表者(誰が)が、費用負担に合意する(何を)ために、CABに参加する(目的)」といった具合です。
この記事へのコメント