【変更管理⓪】変更管理とは
QMS（ISO 9001）などにも定義されているため、知っている人もいらっしゃると思いますが、「モノを作る」仕事において、作ったら作りっぱなしという選択は、どの業界でもまずNGになっているのではないかと思います。
仮に、売り切りの商品であったとしても、量産しているのであれば、その為の設計書、設計図や、手順、ルール、機材、その他もろもろ、色々なものが残っていると思います。それがなければ、まったく同じものを量産することができませんものね。
ですが、一度作ったモノは、一切の欠陥が無く、これ以上手を加えることがないほど完璧なものになっている…と言うケースは非常に珍しく、たいていの場合は、時を経るごとに何かしら変わっていくようになっています。
そんな時、変更前と変更後において具体的に「何が」「どのように」変わったのか、管理しておかなければならないケースがあります。改版、改訂、改編、etc.…呼び方は色々ありますが、そうやって改められ、さらにバージョンやバージョン名なんてついていようものなら、まず間違いなく
「変更管理」
が行われているはずです。と言うか、普通は必ず実施するものです。ＩＴ業界では、ほぼ必須と言われていますね。ＩＴ製品、ＩＴサービスへの変更を、変更作業に伴うリスクを最小限に抑えながら、効果的かつ効率的に実現するためのＩＴ運用管理プロセス（支援プロセスともいう）です。ＩＴ運用管理プロセスの中では、最も重要なプロセスの１つとされています。
変更管理を行う目的は主に以下に示す３つです。
①変更履歴を残すため（トレーサビリティの確保）
②利用者への影響を必要最小限に抑えるため
③既に適切に導入されているコントロールを維持するため
ここで言う「変更」とはＩＴサービスの運用に影響を与える可能性のある変更の全てを指します。たとえば、具体的な変更で言えば、「バッチジョブのスケジュール変更」や、「アクセス権限の変更」、「OSの変更」、「ソフトウェアへのパッチ適用」、「ハードウェア設定などの変更」が含まれます。一般的に、業界の中で言う"仕様変更"も含みますが、その仕様変更の結果として、上記のような変更結果を検討しなければならなくなるわけです。
変更管理の定義
ひとくちに「変更管理」と言っていますが、「何を」はとりあえず置いておいて、「どんな変更」を管理していく必要があるのか、ここで簡単に定義しておきますと、大別して２つ存在します。
①変更管理
“意図的（事前）に”設計や製造工程において変えたことによって生じるトラブルの変化（要因）を、管理グラフや管理図などで察知し、‘未然防止対策 を実行するための管理を指します。
例）
・コストダウンや機能向上、生産計画の変更などによる設計変更
（機構、構造、寸法、重量、機能、レイアウト、材料（強度）など）
・環境または設備治工具の変化または更新
・リソース変更、作業方法（編成、工法、工程など）の変更
・情報および管理の変更 等
②変化点管理
"突発的（偶発的）に"状況が変わって（変えたくないのに変わった)、結果的に何かの変化（要因）で生じるトラブル、およびそのトラブルの変化（要因）を察知し、未然防止対策を行うための管理を指す。
例）
・休暇（退職、療養、家庭の事情など）者の代行
・環境・設備治工具のトラブル
・異常時対応の作業者の変更
・情報および管理のミス 等
「変更」そのものを人の意思によって行うのか、人の意思に関係なく行わざるを得ない状態で行うのかの違いですね。ですが、どちらも「変更する」と言う結果自体は変わりません。エンジニア目線で言えば、①を仕様変更やリスケ、調整、②はバグ対応やリスク対策と呼んでいたりするでしょうか。
押さえるべきポイント
「変更管理」の導入では、以下の点についてプロジェクト特性を考慮しながらルール化を進めていくことが必要になります。
アセスメント（評価）はどうするのか？
承認はどうするのか？
実装はどうするのか？
レビューはどうするのか？
緊急事態における変更はどうするのか？
一般的に、変更管理は
依頼する
↓
アセスメントする
↓
承認する
↓
対策（実装）する
↓
対策内容が妥当であることを確認する
と言う流れで進んでいきます。何か一つでも漏れていると、場合によっては「誤った変更を実施する」「変更した結果、影響を受ける機能や処理の対策が漏れている」「変更する作業にかかった費用が請求できない」と言った事故を起こしてしまいかねません。
当然ながら、当初の計画にはなかった作業をするからこその「変更」ですので、スケジュールの圧迫やコストの発生は覚悟しなければなりません。仮に立った１日で終わる作業だったとしても、単価100万のエンジニアが活動するのであれば、１日で50,000円も費用を消費することになってしまうわけです。そういった事情すべてを考慮に入れて、それでも「変更すべき」と承認したものだけが実施可能となるのです。
リリース管理とは異なる
変更管理の先には、当然製品リリースへの影響もあることでしょう。ですが、変更管理とリリース管理は厳密には違うものです。
変更管理が、作業・活動の安全性を保証するために「製品やサービスに影響をあたえる可能性のある全ての変更」を対象としているのに対し、リリース管理では、製品やサービスそのものの安全性を保障するために「ソフトウェア（およびそれに伴うハードウェアは付属品などについて）の本番環境への移行」を対象としています。
つまり、どのような場合でも製品やサービスへ何らかの変更を加える場合には、まずは開発環境上のリソースに対して「変更管理」にもとづく変更の承認を受け、対策し、テスト等によって確認、保証する必要がありますが、さらにこの変更結果が、本番環境への適用を伴う場合については、その具体的な進め方について「リリース管理」に基づく準備作業や移行作業、文書化作業などを行う必要があるというわけです。
主に管理すべき変更管理対象
変更依頼は、次の理由により、「ソフトウェア」、手順や説明を記述した「文書類」など、リリースするために必要となるすべてのリソースが管理されたリポジトリ（フォルダ等）に登録されている構成アイテム（Configuration Item）を変更したい時に実施します。
・レビューまたはテストの実施によって発見した不良、不具合など
によって必要性が生じ、変更するケース
・プロジェクト管理上、計画の見直しが必要と判断し、変更するケース
・顧客の要求事項の追加、変更または削除等により、変更するケース
要するに、変更管理のトリガーは３種類あると言うことです。これらの理由によって「変更したい」「変更しなければならない」と言う声が上がった時から、変更管理を始めなければならないと言うことです。
変更管理を行うために必要なもの
いきなり「変更管理よろしく」と言われても、おそらく開発現場サイドで即対応できるチームやマネージャーは多くないと思います。
まずは、次のものが用意できるか確認してみてください。
・変更管理の業務フローまたは手順
・変更依頼を管理できる個票、または一覧表。あるいはその両方
・変更依頼を承認するための基準、ルール
・変更依頼を承認する人またはチーム
です。ここで特にお話しておきたいのは「変更依頼を承認する人またはチーム（変更管理委員会）」の存在です。当たり前ですが、専属で置く必要はありません。
・コストおよびスケジュールに対して、決定／決裁権を持っている
・マネジメント調整を実施する権限がある
・技術的支援が可能なスキルレベルにある
これらの条件を満たせる個人…と言うのはおそらくいないので、人をかき集めて、必要に応じて検討してもらえるようなチームになっていれば問題ありません。たいていの場合は「プロジェクトマネージャー」「社内でプロジェクト規模に比して承認できる管理職」「顧客側の決裁権を持つ人」そして、「状況や変更難易度にあわせて技術的判断ができる技術有識者」の４～５名がいればいいでしょう。
このチームが機能しないと、変更管理業務そのものの品質を担保することは難しくなると思っておくと良いでしょう。
いずれ、各フロー等についても説明したいと思います。
いいなと思ったら応援しよう！
