ITIL
本記事ではITILのサービスサポートにおける6つの運用プロセスの5つ目、「変更管理」をご紹介します。変更管理とはITサービスに対して変更を行う際、変更作業を効果的・効率的に行う運用プロセスです。
多くの事業との連携を必要とするプロジェクトでは、管理をスムーズに進めるために変更管理は欠かせないプロセスとなります。
しかし数多くの関係者との連携やスケジュール調整、プロジェクト内で大幅な変更が合った際の対応など、できることなら避けたいと思っている方も多いのではないでしょうか？
そこで、変更管理を運用することでプロジェクトの変更リクエストをスムーズに進めることができます。
特に複数のチームと連携して取り組むようなプロジェクトでは必須と言えるでしょう。
ここでは変更管理の基礎知識や目的、変更を行う際の手順からメリット・デメリットについてご紹介します。
まず初めに変更管理とはどういったものかご紹介します。
変更管理はプロジェクトや大規模な取り組みの中でITサービスを構成する要素に何らかの変更を加え、それを管理することを指します。
ITサービスを使用していれば、システムの更新や新しいシステムの導入・乗り換えなど、様々な変更を行うことがあります。
それらの変更や更新を円滑に行い、発生するリスクを最小限に抑えるためにも「変更管理」は必要といえます。
「変更」では、ITサービスを構成する要素に対する追加や変更、削除も含まれ、主にOSの更新やPCの変更、メンバースタッフの入れ替えなどが変更管理の対象となります。
変更管理なしでは、変更後に大きな問題に繋がるリスクがあるため注意が必要です。
変更管理では変更作業に伴うリスクを最小限に抑えることが求められます。これはシステムが持つリスクの1つに「変更作業によるインシデントの発生」があるからです。
ここで言う「変更」にはITサービスに影響を与える可能性のある変更をすべて含みます。OSの変更などはもちろんのこと、バッチジョブのスケジュール変更やソフトウェアへのパッチ適用なども含まれます。
変更管理ではRFC（Request For Change：変更要求書）という書類を作成します。これはCMBD（構成管理データベース）に登録されているCI（構成アイテム）を変更したい時に作成するものです。RFCを受け取るのは変更を管理する変更マネージャーですが、変更マネージャーだけでは判断できない場合があります。そのような場合はCAB（Change Advisory Board：変更諮問委員会）を招集することもあります。
本項目では変更管理の目的について紹介します。
変更管理の目的は、変更を行ったことで業務へ与えるマイナスな影響やリスクを最小限に抑えることをいいます。
予期せぬ事態や混乱が生じないよう、変更の正確な管理が必要です。
考えられるリスクとして、システムアップデートによるダウンタイムの発生、マニュアルやドキュメントなどの変更・統合・廃止による影響の発生、セキュリティ改善の導入による影響の発生などが挙げられます。
これらのリスクをなるべく抑えるために変更管理では次の3つが重要になっています。
これらの目的を念頭に、次のような活動を行います。
なぜ変更管理が必要なのかが確認できたところで、変更管理のメリットについてご紹介します。
変更管理はその過程で多くの人が関わります。
メールや口頭などでコミュニケーションを取り、進捗のすべてをExcelなどツールで管理するのは困難です。
しかし変更管理に対応したツールを活用することで業務管理の円滑化、プロジェクトの成果物や期日に関する効率化の向上につながるでしょう。
管理が行き届いていない変更がもたらす影響を考慮すると、変更管理は非常に重要です。
変更管理プロセスを正しく導入することで、変更管理に必要なフローや機能のテンプレートの活用などのワークマネジメントの目標も達成しやすくなるでしょう。
また変更管理プロセスの実施には次のようなメリットもあります。
一つずつ順番に解説していきます。
1つ目は仕事の生産性が向上することです。
変更管理を正しく行うことで、要件の不明確さやスケジュール管理の不備といったプロジェクトにおける成果物に関連した混乱を避けることができ業務の遂行がスムーズになります。
その結果、業務の生産性と効率化が見込まれるでしょう。
変更プロセスが導入されていない場合では、不要な業務に時間を取られ生産性が落ちてしまう可能性があり、仕事の期限が守られないといった事態になりかねません。
2つ目は効果的なコミュニケーションが取れることです。
変更プロセスを正確に記録することで、情報の伝達漏れやチームメンバー同士で連携が取れないといったコミュニケーションに関する問題を回避しやすくなるでしょう。
またプロジェクトやチームごとの目標が明確であれば、チーム内のコミュニケーションの活性化につながります。
しかし、変更管理のプロセス内におけるコミュニケーション問題がすべて解決するわけではないため注意が必要です。
効果的なコミュニケーションは変更管理において不可欠であり、プロジェクトの目標達成に大きく貢献するでしょう。
3つ目はチームワークとコラボレーションが改善されることです。
コミュニケーションがスムーズになるだけでもメリットではありますが、それに伴いチーム内の連携も改善されます。
コミュニケーションが明快になることで問題解決能力の向上や知識やスキルの共有、業務の効率化などにつながり、チーム内の連携がより簡単になります。
最初に周知から変更を正確に伝えることができれば、プロジェクトメンバーやその関係者は目標達成のために多くの時間を割くことができます。
しかしコミュニケーションが取れていなければ、メンバーへの変更内容の共有やすり合わせに時間を取られ、十分な力を発揮できません。
変更管理では、チームワークと連携作業はプロジェクトの成功とパフォーマンスに大きく影響するので、常にメンバー同士で意識しましょう。
上記では変更管理におけるメリットを紹介しましたが、変更にはデメリットも存在します。
変更管理はITサービスマネジメントにおいて重要なプロセスではありますが、次のようなデメリットから正確な変更管理が行えていない企業やプロジェクトも少なくありません。
変更管理のメリットは多くの方が認識されてますが、効果的な導入の妨げとなるデメリットもいくつか存在します。
それぞれ順番に解説していますので確認していきましょう。
1つ目は担当部門や関係が多く制御が大変なことです。
変更管理では、変更諮問委員会やリリース管理チーム、開発部門から外部の関連企業といった多数の関係者と連携を取る必要があります。
しかし、多くの関係者に迅速で正確な情報を伝えることは困難であり、正確に伝わらなかったことによる誤解や情報の伝達漏れなどが発生する可能性があります。
関係者が多いと変更リクエストの承認状況の確認や、変更に関する情報共有など細かいプロセスの調整に手間取ったり、それぞれの意見や主張が対立し、合意に時間がかかったりします。
2つ目は影響範囲の特定が難しいことです。
変更管理では、変更により受ける影響範囲や影響期間の確認及び、変更に必要なリソースの評価が事前に必要となります。
しかし変更の規模が大きいほど、関連するシステムやIT資産を特定することは困難です。
変更による影響範囲を正確に特定できないことで、想定外のトラブルや障害の発生、または変更箇所が他のプロセスやシステムに予期しない影響を与え、二次的影響を引き起こす可能性があります。
さらに影響範囲を正確に特定できないことでリスクが過小評価され適切なリスク管理がされず、問題が発生した際の対応が遅れることでよりリスクが拡大する恐れもあります。
3つ目はドキュメントのバージョン管理が煩雑になることです。
変更管理のプロセスには変更リクエストの記入をはじめ、ガントチャートを含めた様々なドキュメントが必要です。
さらに制作したドキュメントは関係者へ周知が必要であり、そのバージョン管理も重要になります。
しかしドキュメントが新しくなるにつれ、バージョンの管理や更新に時間とリソースが浪費されることもあります。
またドキュメントのバージョンが複数あると情報の一貫性が保たれにくくなるでしょう。
どれが最新でどれが古いバージョンなのか分かりづらくなり、誤ったバージョンでの使用や異なるバージョンの使用によるデータの整合性が保たれない可能性があります。
現場によって程度は違いますが、抱えている問題はどこも似通っています。これらの悩みを解決できる手段があればいいと思いませんか？
現場が抱えているさまざまな悩みを自動化し、システム運用担当者の手を介することなくある一定の処理まで行います。
今まで担当者が手動で行っていた業務の一部を自動化することで正確で確実な処理を実行し、担当者がより優先順位の高い業務に集中できる環境を整えていきます。
結果的に、システム運用が安定し、安定した運用が継続的に行えることでコストの低減も図っていくことが可能です。
SHERPA SUITEのSHERPA-IRとSHERPA-SMは、どちらも現場のシステム運用を支えるシステムで課題解決の手段の一つとなります。SHERPA-IR/SMともに、Redmineをベースに作られたソリューションで、Redmineの機能もそのまま使用できるのも魅力の一つです。プロジェクトとして、変更管理プロジェクトを作成し、前述の課題を管理し、インシデント管理や問題管理とも連携することが出来ます。
SHERPA-SMはインシデント管理から問合せ管理までを担当します。SHERPA-SMには3つのメリットがあります。
■管理業務を効率化しミスを防ぐ
インシデントの通知が来ると、SHERPA-SMはチケットとして自動登録します（アラートメールなどの集約はSHERPA-IRが行います）。人手による入力の手間を大幅に削減し、登録漏れやヒューマンエラーを未然に防ぐことができます。
■業務改善と生産性向上
チケットには独自のIDが割り振られるので、対応するスタッフが替わっても素早く応答することができます。すべての記録はSHERPA-SMに残るので、履歴やノウハウをチームで共有することができ、業務改善と生産性向上に活用することも可能です。
■お見合い遅延”防止
チケットには担当者情報が割り当てられ、担当者はリストボックスを設定することで自動で通知メールを送れます。これは、担当者間の“お見合い遅延”防止に効果を発揮します。アサインされた担当者は、通知メールに記載されたURLをクリックすればチケットにダイレクトに接続できます。チケットは一括で管理されるため、漏れも生じにくくなります。
他にも問合せ管理機能、インシデントの進捗状況を視覚化できるガントチャート、定期業務をチケットによって指示してくれる機能など、SHERPA-SMにはインシデント管理を効率化する機能が満載されています。
これまで変更管理の目的やメリット・デメリットについて紹介してきましたが、本項目では変更管理の手順について解説します。
変更管理プロセスには大きく5つのステップに分けられます。
変更リクエストの開始から実行までを基本ステップに則って実行することで、リクエストをスムーズに行い、不要な変更を回避することが可能です。
場合によっては、変更管理プロセスの流れをわかりやすく視覚的に表示することも可能です。
それでは変更管理プロセスをステップごとに紹介しておりますので順番に解説していきます。
変更リクエストが要求されると、まず変更管理プロセスの開始フェーズがスタートします。
多くの場合、変更リクエストを出すのはプロジェクトの関係者、あるいはプロジェクトのリーダーですが、変更の提案は誰でも行うことが可能です。
変更要求を出したいメンバーは、変更リクエストフォームからリクエストを提出します。
リクエストフォームに記入した次は、プロジェクト名、変更内容、日付や誰がリクエストしたのかといった必要情報の詳細を変更ログに記載します。
ログはあらゆる変更の記録であり、長期間行われる複数プロジェクトの管理にも役に立つため、プロジェクトマネージャーは変更ログを誰でも見れるよう、わかりやすい場所に保管しておくのがよいでしょう。
変更リクエストを提出し受け付けられたら、次はリクエスト内容の評価が行われます。
評価フェーズでは提出された変更内容の評価が行われますが、この段階で行うのは基本的な情報の確認のため必ずしも結論が出るわけではありません。
情報の評価はプロジェクトや部門のリーダーが行い、必要なリソース、ITサービスに与える影響、変更実施プラン、万が一問題が発生した際の復旧プランといった詳細情報を検討します。
変更リクエストがこの評価ケースを通過すると分析フェーズに移り、そこで具体的な結論が出されます。
分析フェーズではプロジェクトリーダーによって変更リクエストの承認か却下の最終判断が行われます。
変更リクエストを提出した人も決定に対し意見を述べることが可能ですが、その際は予めプロジェクトリーダーから正式な承認を得ておくのがよいでしょう。
変更リクエストが承認された場合はサインオフを行い、プロジェクトメンバーへ変更要請が承認されたことを伝え、変更プロセスの残りのフェーズへ移行します。
変更ログや変更内容をプロジェクトの共有スペースに記録し、関係者全員が変更内容を確認できるようにしましょう。
変更リクエストが承認されなかった場合も変更ログに記録しておきましょう。
承認されなかったリクエストをプロジェクトメンバーに伝える必要はありませんが、記録に残しておくことで連絡のないリクエストはどうなったのか確認がとれるため有効です。
変更リクエストが承認されれば、次は実装フェーズです。
このフェーズではプロジェクト関係者がリクエスト通りに変更を加えていきます。
変更の実装はプロジェクトによって異なりますが、通常はプロジェクトの進行に関するタイムラインや成果物の更新、プロジェクトチームへの連絡が主になります。
その上で作業の開始が可能です。
実装後にはプロジェクト範囲のレビューを行い、タイムライン変更によるプロジェクトの目標達成に大きな影響が出ないようにすることも重要です。
対策として、変更内容をプロジェクトの共有ワークスペースへ保管したり、変更ログで周知したりなどがあります。
変更の内容や根拠をまとめたビジネスケースを新たに作成したりするのもよいでしょう。
実装フェーズまで完了したらプロセスを終了できます。
終了に関して正式な手順がないプロジェクトチームもありますが、今後チームメンバーが誰でも情報を確認できるようにするためにも手順を決めておくことは有用です。
このフェーズでは変更リクエストで使用したすべての文書データ、変更ログ、話し合いの内容のまとめなどを今後もアクセス可能な共有スペースに保存します。
プロセス開始時の変更リクエストフォームや、プロセス中で作成した資料などがあれば一緒に保存しておきしましょう。
データの保存が完了したら残っているタスクをこなし、プロジェクト達成に向けて業務を継続します。
本記事では変更管理の目的やメリット・デメリット、変更管理を行う際のプロセスについて解説しました。
プロジェクトを進めていく上で変更の発生は避けては通れないものです。
しかし変更管理を正しく取り入れればプロジェクト進行の維持や明確で有効なコミュニケーションが可能になります。
変更が必要な場面でも適切な対応を知っていれば安心ですし、効果的な変更管理プロセスを導入・活用することで変更に伴うリスクを軽減でき、プロジェクトの進行を維持することができるでしょう。
