応用情報技術者 2011年 春期 午後 問11

解答の論理構成

1. a の選定
   • 原文: 「変更した確定版プログラムをaに格納し、本社内各部署及び全支店にリリース内容とリリース予定日をアナウンスした。」
   • ITIL では、リリース対象として確定したソフトウェアを保管する正式な保管庫を “Definitive Software Library” と呼びます。
   • 解答群で “DSL” を示すのは 「ウ：DSL」だけです。
     ⇒ a ＝ 「ウ：DSL」
2. b の選定
   • 原文: 「変更に関するインパクトとリソースの評価、及び変更の実施の認可を行う組織である b を設置する。」
   • ITIL でこの役割を担う組織は “Change Advisory Board” です。
   • 解答群で “CAB” を示すのは 「ア：CAB」だけです。
     ⇒ b ＝ 「ア：CAB」

誤りやすいポイント

• DSL を “DHS” と混同する
  “DHS” は正式名称が存在しないため distractor。確定版プログラムの保管庫＝DSL を押さえること。
• CAB と PMO の取り違え
  PMO はプロジェクト支援組織であり、変更評価・承認を行う CAB とは役割が異なる。
• リリース保管庫を SCM と誤解
  SCM は Software Configuration Management（構成管理手法）を指すことが多く、保管場所の名称ではない。

FAQ

解答の論理構成

1. 変更管理プロセスの対象範囲を問題文から確認
   • 「K社ではシステムの構成管理を徹底しており、情報システム部が本社と全支店のハードウェア及びソフトウェアを一元管理している」
   • 「ITサービスの構成情報を一元的に管理する構成管理データベース（CMDB）」
     ⇒ 変更管理で扱うのは “ハードウェア・ソフトウェアなどの構成アイテム（CI）の変更” であり、データ値や個人設定は対象外と読み取れます。
2. 各選択肢を CI か否かで仕分け
   • ア「競合店に対して優位に立つための戦略的なシステム変更」
     → システム機能そのものを改修する話であり、ソフトウェア CI の変更に該当。対象。
   • イ「支店独自で即時設定した目玉商品の売値」
     → 売値はマスタデータであり CI ではない。対象外。
   • ウ「支店の責任者が行う販売管理システムログインパスワードの変更内容」
     → 個人パスワードは運用上の設定値で CI 管理の対象外。
   • エ「支店の販売管理システム用PCのOSバージョンアップ」
     → OS はハードウェア／ソフトウェア構成の一部であり CI。対象。
3. よって「ア、エ」が変更管理プロセスの管理対象となります。

誤りやすいポイント

• “データの値” と “システム自体の変更” を混同しやすい
• パスワード変更も「システム設定だから対象」と誤解しがち
• ITIL系の用語になじみがなく、CI の概念があいまいだと判断を誤る

FAQ

解答の論理構成

• 【問題文】には、開発着手時に「構成アイテム属性の一つであるステータスが“本番稼働中”から“開発中”に自動更新された」とあります。
• 変更がリリースされると、構成アイテムは再び本番利用状態になります。
• 同じ段落で「①確定版プログラムが本番環境に反映された」と下線付きで示されており、これはリリース直後の処理を示します。
• リリースが完了した瞬間、構成管理側では“開発中”になっているステータスを“本番稼働中”に戻さないと、CMDB上の構成情報と実際の運用状態に不整合が生じます。
• したがって、①と同時に行われる構成管理の処理は「構成アイテム属性のステータスが“本番稼働中”に更新される」と導けます。

誤りやすいポイント

• CMDBへの「変更登録」や「構成アイテム追加」と混同し、ステータス更新を答え忘れる。
• “開発終了”や“リリース済み”など、原文にない表現で書いてしまう。
• ①はリリース作業だと気付きながら、構成管理との連動を意識できず「特になし」と回答する。

FAQ

解答の論理構成

1. 【問題文】では、L君が複数の変更要求を「受付順にA案件からシステム対応を行うことにした」と記載されています。
   → 変更要求間の“重要度”や“緊急度”を比較する仕組みがなく、単純な先着順で処理されています。
2. その結果、【問題文】の下線②「販売促進部のN部長からM課長にクレーム」が発生しました。クレームの理由は「B案件が、全社的に重要な変更要求であったにもかかわらず、今回リリースの対象外」になったためです。
   → 重要度が高い案件を後回しにしたことが問題の本質です。
3. 改善策として【問題文】は「変更管理マネージャは、変更の登録とフィルタリング、優先度の割当て、及びカテゴリ分けを行う。」と明示しています。
   → “優先度の割当て”という新ルールが導入されたことで、前述の欠点が補われました。
4. 以上より、不十分だった点は「変更要求に優先度を付けるプロセスが欠落していた」ことだと論理的に導けます。

誤りやすいポイント

• 先着順処理を「スケジュール管理の甘さ」と誤解しがちですが、本質は“優先度評価の欠如”です。
• 「カテゴリ分けがなかった」と答えると、クレームの直接原因（重要度の見極め不足）を示せず失点します。
• “緊急度”と“優先度”を混同する受験生が多いですが、問題はあくまで「優先度の割当て」の有無に言及しています。

FAQ

解答の論理構成

1. 現行ルールでは、変更の承認とリリースは“1か月に1回”の通常サイクルに乗せることが前提です。
2. ところが、C案件では「ビジネス上の緊急度が高く、早急なシステム対応が望まれている」と問題文にあるように、通常サイクルを待つと機会損失が発生します。
3. 緊急変更でも最低限守るべきは
   ・責任者の承認を受けること
   ・構築開始後に承認が確定するケースを許容すること
   です。
4. 解答群の選択肢を検討すると、
   ・イ「正規の承認手段とは別に、メールや電話で関連責任者に承認を得ることができるプロセス」
   → 対面会議を待たずに承認を取得でき、迅速性確保と統制の両立が図れます。
   ・エ「変更の実施の認可を待たずに変更の構築に着手し、後で認可を受けることができるプロセス」
   → 変更の着手と承認を並列化し、緊急度に応じたスピードを担保します。
   以上が緊急変更を可能にする実質的な仕組みです。
5. 他の選択肢は、
   ・ア：その場で権限代行者を決めると統制が曖昧になりかねず、恒常的なプロセスとは言い難い。
   ・ウ：結果確認を省略すると品質保証が欠落します。
   ・オ：スケジュール作成を省略すると影響範囲の共有ができません。
   したがって不適切です。
6. 以上より、緊急対応を可能にするプロセスは【イ、エ】となります。

誤りやすいポイント

• 「緊急＝何でも省略可」と早合点し、ウやオを選んでしまう。
• 承認経路を変えるのか、承認自体を省略するのかを混同する。
• 「その場で決める」や「担当者の判断」という曖昧な表現を、俊敏性と誤認する。

FAQ

解答の論理構成

• 変更を並行させる目的
  問題文では、ビジネス上の緊急度が高い「C案件」を1週間後にリリースしつつ、通常リリースサイクル分の変更も失わないようにするための手順が問われています。
  引用︓「通常リリースサイクル分の変更と C案件 の変更を間違いなく行うために、次の手順で作業を行うことを M課長 に報告し、承認を受けた。」
• Step(1) で一旦キャンセルする理由
  既に “開発中” の状態にあった通常リリースサイクル分の登録を取り消すことで、C案件 用に同じプログラムを安全に占有します。
  引用︓「通常リリースサイクル分の変更対象プログラムの変更作業登録をキャンセルする。」
• Step(2) は C案件 の登録
  キャンセルして空いた枠を C案件 が利用するため、まずは変更作業登録が必要です。
  ⇒ 解答群「イ：C案件の変更対象プログラムの変更作業登録を行う。」が適切。
• Step(3) は C案件 の構築・テスト
  登録後は速やかに開発作業へ進みます。
  ⇒ 解答群「ア：C案件の構築・テストを行う。」
• Step(4) は C案件 のリリース
  緊急案件を先に本番反映してビジネス機会を確保します。
  ⇒ 解答群「ウ：C案件のリリース承認を受け、リリース作業を行う。」
• Step(5) で通常リリースサイクル分を再登録
  C案件 が完了したので、もとの変更を CMDB に復帰させます。
  ⇒ 解答群「エ：通常リリースサイクル分の変更対象プログラムの変更作業登録を行う。」
• Step(6) で通常リリースサイクル分の作業を再開
  ここまでで一時退避していた変更が元通り進行可能になります。

誤りやすいポイント

• 「構築・テスト」と「変更作業登録」の順序を逆にしてしまう
  変更管理では必ず登録→構築・テスト→承認→リリースの順序を守ります。
• 通常リリースサイクル分を再登録する前に開発を再開してしまう
  CMDB に登録されていない構成アイテムを改修すると、トレーサビリティが失われます。
• 「リリース承認」と「リリース作業」を別工程と誤解
  本設問では一連の扱いとしてまとめられています（解答群「ウ」「カ」）。

FAQ