ITサービス管理をよりシンプルに – 第2部

IT部門には、社内のカスタマーやさまざまな部門や部署に影響を及ぼす「変化」がつきものです。変更を実施するには、有効な方法とうまくいかない方法があります。うまくいかない方法とは、時を選ばずに変更作業を実施し、変更に伴う問題を引き起こすことです。アプリケーションやインフラ、プロセス、ツールの変更管理（チェンジ・マネジメント）が適切に行われていない場合、すべての関係者に、長期間にわたる予期せぬ混乱、プロジェクト展開の遅延、不満をもたらすことになります。少し長めの記事になりますが、環境変化のマネジメント の成功率が低い場合、あるいは、そもそも成功率とは何かがわからない場合は、ここでシェアするヒントをぜひ役立ててください。

<< プロセスの定義 >>

チェンジ・マネジメントを適切に行うには、関係者全員が共通の認識をもっていることが必要です。変更のステークホルダー（利害関係者）となる、サービスのオーナーやビジネスリレーションシップマネージャーと話し合い、承認の方法や必要な通知、問題が起きた場合の連絡先など、通常の変更作業のプロセスについてあらかじめ合意しておきます。緊急時の変更要件も決定し、適切な通知経路などについて認識を一致させておきます。サービスに直接影響することのないような、一般的な変更については、事前に承認を受け記録に残しておきましょう。記録しておくことで、変更による予期せぬ連鎖反応をより簡単に追跡できるようになります。社外で管理されているソフトウェアを利用している場合は、そのベンダーからも変更プロセスについて合意を取り付けます。銀行の金融ソフトウェアのようなネットワークの基幹部分を、営業時間中にベンダーが中断させて、未承認の変更を行うことになっては最悪の事態です。銀行の窓口で融資の承認や現金の受け渡しができなくなるような混乱した状態を想像したくありませんね。

<< 変更の実施計画 >>

変更を実施するタイミングについては、利害関係者との最初の打ち合わせの際に、定期メンテナンスの実施に最適な時間帯を決めておきます。変更リクエストごとに個々の実施日を設定する場合は、作業の人員や時間帯が、すでに予定されている変更作業や時間枠と重ならないようにしてください。効果的に変更の承認プロセスを進めるにはステークホルダー（利害関係者）グループを巻き込み、変更要求の評価、そして競合する他の要求やリスクに基づいて承認または却下の判断を行います。同じ夜にネットワーク全体の停止がすでに計画されている場合に、ソフトウェアアップデートのロールアウトする プロジェクトが実行されることはありません。変更をテストしたり、うまくいかない場合にロールバックできるように、十分な時間を確保することを忘れないでください。

<< 通知 >>

予定されている変更を社内のカスタマーに周知するには、Zendeskに専用のフォーラムを設けて案内用の掲示版として使用するとよいでしょう。その掲示板で、変更の実施日時、変更中に予想される影響、目的とする成果について案内します。カスタマーが理解できる言葉を使用し、過度に技術的な説明は避けるようにします。

<< すべての指示を含める >>

変更要求に、変更の実施とテストの手順、失敗した場合のロールバックの手順を詳細に記載します。質問や問題が発生した場合のエスカレーションパスも明確にしておきます。指示がなかったり指示に不備があった場合、変更作業に当たる人員を混乱させ、余計なオンコールコストとトラブルを発生させることになります。定期的な変更を行う場合、同じ変更要求に対して再利用できるマクロを作っておくと、時間を大幅に節約できます。

<< うまくいかない場合 >>

変更作業中に何かがうまくいかず、予定時間内に変更を完了できないおそれがでてきた場合は、あらかじめ合意してある通知プロセスに従います。影響を受けるカスタマーが誰で、どのような事態が起こりうるか、修正のための現実的なETA（完了予定時刻）などをカスタマーに説明します。最初の通知で定期アップデートについて案内し、合意済みのプロセスに従って、失敗した場合に知らせる必要のあるカスタマーに通知します。例えば、財務チームが通常午前9時に送るべき必須レポートをその事態によって実行できないという場合、不満が募ることは確かですが、その問題の処理が最優先事項とされていて、説明された時間内に解決される見通しであることがわかれば納得するでしょう。

<< うまくいった場合 >>

マニュアルや資産管理台帳などへの記録が必要な場合は、実施した変更内容を直ちに記載して更新します。TPS（Testing Procedure Specification）レポートを印刷するための新しい方法をロールアウトしたのに、マニュアルの手順を更新していない場合、サポートが遅くなり、ナレッジベース内のサポート情報にも最新情報が反映されません。

<< 再確認 >>

作業中に生じた問題に対処するごとに、変更プロセスを見直しします。発生した手続き上の問題や技術的な問題に対処したうえで、変更管理プロセスの見直しに関わる議論にはステークホルダー（利害関係者）を参加させます。緊急変更の発生頻度やFTR率（first time right – はじめからうまくいき、変更後に問題が生じなかった場合）などのトレンドに注目することで、成功を証明し、プロセスで生じる可能性のある欠陥に取り組むことができるようになります。

成功率を向上させるには、変更管理プロセスを明確にすることが重要です。明確なコミュニケーションはその肝心な部分であり、カスタマー指向のITサービスにおいては中心的な役割を果たします。意思決定において社内カスタマーに重要な役割を与えることで、すべての関係者がループ内に含まれるようになり、寝耳に水といった事態にならないことが保証されます。

これは、強力でシンプルなITサービス管理を実現するためのZendeskのアプローチに焦点を当てたシリーズの第2部です。第1部「社内IT部門のヘルプデスク： ユーザー = カスタマー」と、今後投稿予定の第3部「カスタマーの満足度」も併せてお読みください。