解説

• 下線①はRFCの提出に関する手順であり、「自部署の部長の承認を得た後，変更管理マネージャに提出する」というものです。
  
  〔変更管理の現状〕(1)に「RFCの依頼者は，依頼部署の上司を写し受信者として，電子メールで提出すればよいので，依頼者の個人的な見解に基づくRFCもある」と記載されているように、現状では上長の承認を得ずに変更依頼者の判断でRFCを提出できる仕組みになっているために、不必要なRFCが提出され、変更管理の負担が増大している様子が読み取れます。こうした、言ってみれば"非公式"なRFCが変更マネージャの元に届くことを防ぐため、RFCの提出には部長の承認を必要とする仕組みに変更したと考えられます。
  
  以上より、本施策の狙いは「依頼者の個人的な見解に基づくRFCをなくすこと」であると判断できます。
  
  ∴依頼者の個人的な見解に基づくRFCの撲滅
  
  
• 〔aについて〕
  空欄aを含む一文を確認すると「システム部は，RFCの優先度と実施希望日を考慮して，RFCの承認に必要となるaを作成する」と記述されています。これより、「RFCの優先度」と「実施希望日」が関係する字句を選択肢から選べば良いことがわかります。選択肢の中で上記要件を満たすのは「エ：変更スケジュール」だけです。
  
  サービスを新たに導入したり、サービスに大きな変更を加えたりする際には、変更要求に加えて変更の概要を説明する「変更提案」という文書が必要となります。変更提案には、変更の必要性、得られる事業上の成果、費用対効果、変更スケジュール等が記載されます。
  
  なお、他の選択肢は以下の理由で不適切です。
  • エスカレーションフローは、インシデントが発生してから上長や問題解決を図る部署に指示を仰ぐフローを指す単語です。
  • サービスカタログは、現在提供中のサービス及び承認済で今後導入予定のサービスを一覧化したものでです。
  • トレーニングに使用する資料の作成は、RFCの優先度や実施希望日とは関係ないので不適切です。
  ∴a＝エ：変更スケジュール

解説

• 下線②を含む一文を確認すると「適応保守の中には，ROIと実現可能性だけで判断すべきではないRFCもあるので，…」と記述されています。これは、表1のRFCの承認の手順にある「RFCの承認及び差戻しの判断基準には，ROIと実現可能性を考慮する」に対する問題提起となっています。
  〔変更管理の現状〕の冒頭部で「適応保守には，売上げや利益を改善するための修正や法規制対応などが含まれる」と記載されているように、適応保守には2種類があります。このうち法規制に対応するための変更は、ROIや実現可能性にかかわらず、法令遵守の観点から期日までに必ず実施する必要があります。法規制対応のRFCがROIや実現可能性で判断されてしまうのは不適切であるため、C部長はこの点を指摘したと判断できます。したがって、C部長の指摘に該当するRFCは「法規制対応のRFC」です。
  
  ∴法規制対応のRFC
  
  
• 〔費用負担方法について〕
  変更の費用負担についての現状は「変更管理部署であるシステム部が一旦負担し，その費用をB社の全部署に人数割りで配賦している」とあるように、変更に関係のない部署も変更費用を負担する不公平な仕組みでした。下線③の前文に「経営層からの指示に基づき」とあるので、〔変更管理の現状〕(4)のbを見ると「変更の費用は，変更の実施によって利益を受ける受益者が負担すること」という指示を経営者から受けていることがわかります。これが変更後の仕組みです。
  
  変更前と変更後の方法を整理すると以下のようになります。
  • 変更前 … 全部署に人数割りで配賦
  • 変更後 … 変更による受益者が負担
  これをまとめると「全部署に人数割りで配賦していたのを、変更による受益者が負担するように変更する」旨の解答となります。
  
  ∴全部署への人数割り配賦を，利益を受ける受益者負担に変更する
  
  〔bについて〕
  空欄bを含む一文を確認すると「経営層からの指示に基づき，変更の費用の費用負担方法を変更すること。これに伴い，CAB要員として必ずbを参加させること。」と記述されています。既に確認した通り、費用負担方法の変更により、変更の費用は「利益を受ける受益者」が負担することになります。この仕組みに変更した場合、「関係する部署でRFCを協議して，費用の取扱いを決定すること」という経営者からの指示があるので、費用負担に関係する部署をCABに参加させる必要があります。解答群の中でこの条件に合致する人物は「ウ：変更の実施によって利益を受ける部署の代表者」です。
  
  ∴b＝ウ：変更の実施によって利益を受ける部署の代表者
  
  
• 下線④を含む一文を確認すると「サービス開始を遅延させないための展開作業時に実施する可能性のある作業を計画すること」と記載されています。サービス開始の遅延については〔変更管理の現状〕(3)に「展開作業が予定時間に完了しない場合を想定しておらず，終了予定時刻を超過しても展開作業を継続し，サービス開始を遅延させてしまうことがある」という問題が生じていることがわかります。C部長は上記問題を解決する作業を変更管理プロセスの手順に含めるように指摘しています。
  
  一般的に、展開作業（=本番への変更適用作業）はその過程で想定外の作業やトラブルが発生する可能性があり、変更が失敗したり変更適用が時間内に完了しないであろうときは、切り戻し（=変更前の状態に戻すこと）作業を実施します。切り戻し作業を実施すれば、変更作業中にトラブルがあった場合でもサービス開始を遅延させることはありません。失敗したときに適切に切り戻し作業を実施するためには、事前に、変更前の状態に回復させるための対処方法を計画としてまとめておく必要があります。
  
  したがって、「展開作業時に実施する可能性のある作業」とは切り戻し作業、そのための計画なので「切り戻し計画の作成」が適切な解答となります。
  
  ITILでは修復計画という用語で定義されているので、こちらでもOKでしょう。
  
  ∴切り戻し計画の作成
  
  
• 下線⑤を含む一文を確認すると「変更実施後のレビュー(以下，PIRという)を行い，変更の有効性をレビューすること」と記述されています。また、経営層からの指示について確認すると、〔変更管理の現状〕(4)のcに「変更実施後の実現効果を利害関係者と確認し，必要に応じて利害関係者と合意した処置をとること」と記述されています。これらの記述がそのまま回答根拠になります。すなわち、変更実施後のレビュー（PIR：Post Implementation Review）の目的は、変更実施後の実現効果を利害関係者と確認することにあると言えます。解答群のうちこれに該当する記述は「ア」です。
  
  ∴ア：変更による実現効果を利害関係者と確認するため

解説