シンプルになったITサービス管理 part2

社内IT部門では、社内における顧客＝ユーザーである従業員や他部門に影響を及ぼすシステム変更を実施する場合があります。しかし、いつでも好き勝手なタイミングで変更を開始し、何か問題が起こったら慌てて火消しに走るようなやり方では問題があります。アプリケーション、インフラストラクチャ、プロセス、ツールのチェンジマネジメントに不備があれば、長時間に及ぶ予定外の業務中断、プロジェクト進行の遅れ、関係者全員のイライラといった結果を招きかねません。チェンジマネジメントの成功率がどうも思わしくない、あるいは、成功率など特に考えたこともない、といった課題の、対処に役立つヒントをお教えします。

プロセスの定義

変更管理を成功させるには、関係者全員の同一の認識を共有して臨む必要があります。サービスの責任者、ビジネスリレーションシップ管理者、そしてIT部門の当事者を集めてミーティングを開き、変更を行う場合のプロセス、ステークホルダー、必要な通知、問題が起こった場合の通知先について合意を得ておきます。緊急の変更に該当する条件も決め、承認や通知の適切な手順について同意を取り付けます。

変更の種類によっては、サービスに影響がないものもありますが、このようなケースでも、やはり提案された変更を記録する必要があります。このような場合は、事前承認にすると良いでしょう。変更を事前承認するための条件について、当時者と同意し、記録を残しておけば、予想外の波及作用があった場合にも、ずっと簡単に原因を洗い出すことができます。社外のベンダーがメンテナンスを担当するソフトウェアに依存している場合は、そのベンダーにも、変更プロセスを正式に了承させます。たとえば、営業時間中に変更が未承認だったにもかかわらず、ベンダーが先走ってしまい、変更が行われてネットワークの重要部分（銀行の金融ソフトウェアなど）がダウンするような事態が起こったらーーー窓口係が融資を承認できなくなったり、渡すべきでない現金を渡してしまった場合の修羅場を想像してみてください。

スケジュールへの配慮

まず初回のミーティングで、定期メンテナンスの時間帯について関係者内での合意をとりましょう。個別の変更依頼について日付と時刻を設定するときは、必要なスタッフや、すでに予定が決まっている他の変更との兼ね合いで支障がないかどうかを確認します。変更承認プロセスに関係者のグループが参加し、変更依頼を評価したうえで、別の依頼との衝突やリスクを基準に、変更を承認するか却下すると効果的です。同時刻にネットワーク全体の停止が予定されていると分かっていれば、プロジェクトチームがソフトウェアの更新は回避できます。変更のテストや、結果が思わしくなかった場合に必要となるロールバックのための余分な時間も、忘れずに見込んでおきましょう。

通知

システム変更の予定は、社内のユーザーが常に最新の情報にアクセスできるように、Zendeskのアナウンス専用のフォーラムで通知しましょう。日付と時刻、変更によって影響がある対象、変更の目的について情報を提供します。ユーザーにとって分かりやすい言葉を使い、無駄に専門的すぎる説明は避けましょう。

すべての指示を盛り込む

変更、テスト、そして変更が失敗した場合のロールバックについて、詳しい指示を変更依頼に記載しましょう。疑問やトラブルが生じた場合のエスカレーション方法も、明確にしておきます。指示の抜け漏れがあると、変更を担当する現場のスタッフが困惑し、待機のために余分なコストが生じたり、業務の中断につながるおそれがあります。今後も定期的な変更を予定しているなら、定型文を作成すると、毎回同様の変更依頼を作成する手間と時間を節約できます。

問題が起こったら

手順の実行中に何か問題が起こって、予定時間の枠内で問題が解消されそうもないと判断した場合は、同意済みのプロセスに従って通知を行います。影響を受ける顧客、遭遇する可能性のある現象、信憑性のある復旧予定時刻を顧客に知らせます。最初のアナウンス投稿を通じて定期的に最新情報を提供し、プロセスに関する定義済みの合意事項に従って、知らせるべきすべての人に知らせます。午前9時に財務チームが必要な日次レポートを実行できそうもない場合、イライラするのは仕方がないとしても、その問題に高い優先度が設定され、しかも明記された時間内に解決される可能性が高いことが分かれば、状況を前向きに捉えるでしょう。

変更に成功した場合

変更を反映して、該当する文書や資産明細をすべて更新します。TPSレポートをプリントアウトするための新しい手法を初めて導入したにもかかわらず、文書に記載されている手順の更新をうっかり忘れると、その分だけサポートに時間がかかり、ナレッジベースが停滞することになります。

レビュー

変更プロセスをそのつど見直して、プロセスの途中で問題が発生しなかったかどうかを確認します。手続き上の問題や、技術的な問題が発生していた場合は、その問題に対処し、関係者を交えて変更管理プロセスの修正について話し合います。緊急の変更が占める割合や、インシデントが起こらず最初の1回で変更に成功する率（FTRすなわちFirst Time Right）などのトレンドに注意を払うと、成功を証明し、プロセスに潜んでいる不具合に対処することが可能になります。

明確な変更管理プロセスは、成功率を高める鍵になります。変更管理プロセスに欠かせないのが、明瞭で分かりやすいコミュニケーションであり、これは顧客中心型のITサービスにするうえで中心的な役割を果たします。決定に際して、社内顧客に重要な役割を演じてもらうことで、すべての人が確実に輪の中に加わり、見込み違いが生じる余地がなくなります。

この記事は、シンプルで強力なITサービス管理を達成するためのZendeskのアプローチをテーマとするシリーズのパート2です。
パート3：顧客満足度とパート4：インシデントと問題についても併せてご覧ください。