2011年 春期 応用情報技術者試験 問11
システムの変更管理
【改善前の変更管理の状況】
K社は、地方都市に30店舗を有する中堅スーパーマーケットであり、自社で販売管理システムの運用・保守を行っている。K社ではシステムの構成管理を徹底しており、情報システム部が本社と全支店のハードウェア及びソフトウェアを一元管理している。
システム変更要求の受付担当である情報システム部のL君は、商品開発部からシステム変更要求(以下、A条件という)を受け付けた。その翌日に、支店の取りまとめ部署である販売促進部から別のシステム変更要求(以下、B条件という)を受け付けたが、A、B二つの条件を同時に対応する余裕はなかった。L君は、受付順にA条件からシステム対応を行うことにした。
L君は、情報システム部のM課長にA条件の実施の承認を受け、変更のスケジュールを作成し、変更作業に着手した。ITサービスの構成情報を一元的に管理する構成管理データベース(CMDB)に対して、変更対象プログラムの変更作業登録を行うと、構成アイテム属性の一つであるステータスが"本番稼働中"から"開発中"に自動更新された。L君は、変更の構築・テストを完了し、リリース確認会議の場で正式なリリース承認を受けた。その後、変更した確定版プログラムをaに格納し、本社内各部署及び全支店にリリース内容とリリース予定日をアナウンスした。リリース日に、①確定版プログラムが本番環境に反映された。K社の変更管理、構成管理、及びリリース管理の関係を、図1に示す。
②その後、販売促進部のN部長からM課長にクレームが届いた。販売促進部から受け付けたB条件が、全社的に重要な変更要求であったにもかかわらず、今回リリース
【変更管理プロセスの改善】
L君はB条件のシステム対応を速やかに行ったので、今回は大事には至らなかった。変更要求の取扱いに関しては、これまでも見直しを要請されていた。そこで、M課長は社内システムの変更管理プロセスの改善を検討し、図2に示す新たな変更管理プロセスを作成した。
(ア)変更の登録とフィルタリング | (オ)変更の実施の認可 |
(イ)優先度の割当て | (カ)変更のスケジュール作成 |
(ウ)カテゴリ分け | (キ)変更の構築・テスト |
(エ)インパクトとリソースの評価 | (ク)変更の結果の確認とリリース承認 |
新たな変更管理プロセスの中で、次のルールを定めた。
・変更管理マネージャを設置し、M課長が務める。変更管理マネージャは、変更の登録とフィルタリング、優先度の割当て、及びカテゴリ分けを行う。
・変更に関するインパクトとリソースの評価、及び変更の実施の認可を行う組織であるbを設置する。変更管理マネージャのM課長が、議長を務める。
また、この変更管理プロセスを実施するに当たって、bの通常開催サイクル、及び販売管理システムの通常リリースサイクルを、"1か月に1回"と設定した。
【変更管理プロセスの例外処理】
数か月後、ある地域の競合店が目玉りで目玉商品のタイムセールを実施し、K社の既存顧客が大量に競合店に流れていく事態が発生した。これに対抗するために、競合店の売値を見た上で支店独自の売値を即時設定できるシステム変更要求(以下、C条件という)が情報システム部に届いた。M課長は、L君にC条件の変更調査を指示すると、変更対象プログラムは1本で、プログラムの変更とテストは数日間で対応できるという報告を受けた。しかし、通常リリースサイクルでの次回のリリース予定日は3週間後であり、それを待っていると大きな機会損失につながってしまう。
ビジネス上の緊急度が高く、早急なシステム対応が望まれていることを把握した情報システム部のT部長は、通常リリースサイクルの変更と並行してC条件のシステム対応を行い、1週間後にC条件だけを先にリリースするという、例外的な変更の実施を認めることにした。
T部長及びM課長の指示を受けたL君は、C条件の変更対象プログラムの構成アイテム属性を調べた。ステータスは"開発中"になっており、次回通常リリースサイクル分として、既に変更実施中であることが分かった。L君は、通常リリースサイクル分の変更とC条件の変更を間違いなく行うために、次の手順で作業を行うことをM課長に報告し、承認を受けた。
(1) 通常リリースサイクル分の変更対象プログラムの変更作業登録をキャンセルする。 (2) c (3) d (4) e (5) f (6) 通常リリースサイクル分の変更対象プログラムの変更作業を再開する。