家に帰ってテレビを付けると、真っ先に聞こえて来るのは暗い話ばかりで、明日はわが身かと見ていても辛くなる今日この頃です。

 

 

 

 

 

 

開発から運用

 

変更管理

 

①変更の適用範囲が明確に定義され文書化されている

②事業利益をもたらす変更だけが認可される

③優先度及びリスクに基づき変更のスケジュールが立てられている

④変更実装時に構成に対する変更を検証できる

⑤変更を実装するための時間が監視され、必要な場合には改善される

⑥変更について次を行う方法を実証することができる

　・変更を定期、記録、分類する

　・サービス、顧客及びリリース計画に与えるインパクト、緊急度、コスト、利益、リスクに関して変更を評価

　・失敗した場合、元に戻すか修正する

　・文書化する

　・変更の種類、規模及びリスクによって変更許可委員が変更を認可または却下する

　・変更されるコンポーネントに責任を持つグループにおいて、指名されたオーナが変更を実装する

　・テスト、検証及び最終承認する

　・クローズしレビューする

　・スケジュールを立て、監視し、報告する

　・適切な場合はインシデント、問題、他の変更及び構成アイテムのレコードと関連付ける

法律的な表現でイメージしにくい感がありますが、概ね次のような表現になる。

 

予め変更するものが承認・計画化され、変更手順に基づきリハーサルを行い、変更内容の検証が行われる。
また、変更に失敗した場合には切り戻し手順に従いきり戻しが行える。
変更は変更の責任者が実施し検証を行い、変更作業が終了したらレビューを実施する。
変更作業と変更事項、また問題管理事項とリンクを取り、今後の変更作業時に役立てる。

となるが、どのくらいの情報部門がこの手順に沿って実践してるか、また、できるかは疑問だが、かなり簡略化した手順で実施してるのが実情だと思う。

何故苦手なのか、
問われてることはもっともなんですが、

開発・保守システムのリリースは別としても、保守が頻繁、トラブル時での緊急処置、復旧を優先、要員不足で別な変更管理専任者が置けない、多い例外条項の抜け道、テスト環境が十分でない、日常作業に追われ後回しでよいものが忘れて放置などが起因してるものと思いますが、そもそも環境も複雑になり変更するものも多く、どのような変更の時に何を変更し、他に何を同時に変更しなければならないのかが整理（リンク）されてないことが大きな原因だといえます。

ただ、変更作業内容によっては変更するものも異なることが多く、ケースを積み上げて地道にパターン化することが一番の近道だといえますが、まずは、変更ケースでの標準変更事項と、関連変更事項（選択）、変更事項一覧（選択）の申請・管理フォームを作り、関係者で変更作業承認・計画時に変更事項に漏れがないかの事前レビューができるものが必要で、その積み上げや分類により標準変更事項や関連変更作業の精度を上げることが大切ですが、問題は関係者の日ごろの意識や癖が何よりも重要になると思います。

 

この方法はかなり昔に私が実践してみましたが、変更事項に一通り目が通せるので、気付くことで漏れも少なくなり、スキルアップや品質向上にもかなり役立つものと思われます。