なります。経験によると、不十分な要件 把握、適切なテストとユーザ受け入れの 欠如でも変更の実施がうまくいかない場 合があるようです。
オーストラリアのある大手銀行がその 電気通信ネットワークの管理をサービ ス・プロバイダにアウトソーシングして いました。銀行が新たな拠点を追加しな ければならなくなり、その拠点に対して 電気通信ネットワークの拡張を実施する ことになりました。これは同銀行にとっ ては成長計画に則った標準的な変更でし た。電気通信サービス・プロバイダでは 標準的な運用手順が整備されていまし た。不運なことに現場のセキュリティ・
エンジニアがあるステップを実施し損な ったため、新拠点の立ち上げ日に間に合 わなくなりました。何がまずかったのか を探ることに数人日が割かれました。
同様のケースですが、北米のある大手 ケーブル・サービス・プロバイダが、ア カウント更新のビジネス・プロセスを設 計し直すことになりました。ビジネス・
プロセスの設計が承認され、IT サービ ス会社が本番環境に IT 変更を展開する ことになりました。期日が迫っているこ とから、重大で緊急の展開として扱われ、
変更諮問委員会の承認は省かれました。
展開は、多くのアカウント更新がある営 業日に行われました。その結果、本番環 境で障害が発生し、6 時間にわたってシ ステムが停止しました。
技術
組織はそれぞれ広範囲の構成アイテ ムをサポートしており、これらの相互 依存性も変更を成功させる鍵となりま す。特に、他から切り離して行われる アップグレードはしばしば問題の発生 につながります。さまざまなベンダが 提供するハードウェアも、アルゴリズ ムの変更に加えて、アプリケーション がもたらす変更にもうまく対応できな
いことがあります。
CPU、メモリ、およびディスクに限ら ずネットワーク・キャパシティなどを含 む環境のサイジングも、帯域幅や遅延の 面で見落とされることが多くあります。
変更は既存のサービス・ラインに持ち込 まれるため、ネットワークのキャパシテ ィには定常的なモニタリングとアップグ レードが必要です。アーキテクチャの整 合不良、技術的な不一致、第三の構成ア イテムが技術ロードマップに整合してい ないという落とし穴も、変更の失敗につ ながることがあります。
英国の最大手電気通信サービス・プロ バイダの 1 社が、欧州で運営している関 連会社の 1 社でオンライン・プラット フォームのアップグレードを行わせまし た。この変更の結果、誤って機密資料が 公開されたしまったことが明らかにな り、標準的な技術的変更を展開から数分 のうちに切り戻さなければならなくなり ました。このトラブルの主な理由は、新 プラットフォームと旧プラットフォーム の間でセキュリティ・モジュールの互換 性がなかったことでした。
成功率を高めるには どうすればよいしょうか？
以下に、大企業の IT 組織内で不備が よく見られる領域を幾つか示します。こ れらの領域に正しく対応すれば、変更の 成功率を大幅に高められるでしょう。
1. 総合的品質保証：
どのような大規模な変更においても、
エンド・ユーザ教育および標準運用手順
（SOP）を伴った徹底的なユーザ受け入れ テストの実施が重要です。SOP はプロセ スを標準化し、タスクを一貫した方法で 行える段階的な操作指示を提示します。
文書化された SOP とチェックリストが非 常に有用ですが、ピア・レビューの仕組
みを利用すれば堅牢性を強化できます。
リリース計画を整備し、これに変更展開 指針（ラン・ブック）と切り戻し手順を 盛り込むべきでしょう。
前述のオーストラリアの銀行の例で電 気通信プロバイダが標準運用手順にピ ア・レビューの仕組みを組み込んでいれ ば、変更の失敗を避けられたかもしれま せん。
2. コミュニケーションと再コミュ ニケーション：
さまざまな利害関係者の期待が裏切ら れないようにするため、展開しようとし ている変更を前もってコミュニケーショ ンすれば、人々が心構えをするのに役立 ちます。変更についてコミュニケーショ ンし、テストし、展開する。そして変更 が実施されたことを再びコミュニケーシ ョンすることにより、適度な利害関係者 の関与が得られます。
3. 測定基準と測定：
測定基準の収集と分析を実施すること が重要です。四半期ごと、月次、および 年次データに基づく経時的な分析で、変 更の失敗にパターンが見つかることがあ ります。分析により、技術、事業、地域、
およびアプリケーション、ネットワーク、
チームなどのさまざまな領域にまで掘り 下げることができます。運用上の測定基 準としては例えば次のものがあります。
・サービス・ライン別、地域別、事業部 門別の毎月の変更失敗件数
・変更の失敗により発生したインシデン トまたは問題の件数
・不十分なインパクト分析、許可の欠如、
またはプロセスを遵守しないことによ る変更の失敗
4. ガバナンスの確立と遵守：
変更諮問委員会を構成するさまざまな 役割（アプリケーション・オーナ、ハー
SPRING 2014 SERVICE TALK
IT 変更の失敗を避ける方法
ドウェア / ネットワーク専門家、事業オ ーナなど）を考慮したガバナンス体制を 構築しなければなりません。これにより、
各オーナにそれぞれの領域に集中させ、
しかもどのような変更でも全体的な運用 には影響が及ばないようにすることがで きます。また、利害関係者全員が関与す るため、機能性、サービスレベル、パフ ォーマンス、キャパシティ、およびコス トに対する望ましくない副作用が抑制さ れます。変更管理は、あらゆるレベルの サービス・サポート・チームにできるだ け前もって情報を提供し、実施される変 更に基づいて適切なスタッフの配置を手 配しなければなりません。
5. 継続的プロセス改善：
昨日はうまくいったからといって、明 日もそうだとは限りません。変更プロセ スには継続的改善を適用し、ストレス・
テスト後は短期のうちに成熟度が上がる ようにする必要があります。当初設定 した達成目標が満たされたか確認するた め、実施後のレビューを行わなければな りません。
6. 実施後のレビュー：
プロジェクト管理のベスト・プラク ティスの幾つか、例えば教訓、うまく いったこととうまくいかなかったこと の記録なども、変更管理に適用できま す。RISC モ デ ル（Review（ レ ビ ュ ー）、 Investigate（調査）、Survey（サーベイ）、 Consult（コンサルティング））は、実施 後レビューの非常に有効なツールです。
・レビュー：週ごと、月ごと、年ごとの 変更失敗件数、変更の失敗による平均 停止時間、復旧までの時間などの統計 を集めます。
・調査：変更の失敗 1 件によりどれだけ のインシデントが記録されたか、どれ だけ SLA に違反したかなど、コストを 計算します。
・サーベイ：最も重要なサービスについ
て総意を得ます。
・コンサルティング：専門家に改善の領 域をレビューしてもらいます。事業マ ネージャおよび技術マネージャとブレ インストーミングを行うことにより、
課題を識別します。このようなセッシ ョンの目的は、ユーザ、顧客、および 各利害関係者が結果に満足すること で、そうでない場合はさまざまな不備 について話し合い、将来はそれらを回 避できるようにすることです。
これまで述べた指針に関連し、変更の 展開の成功率を大きく向上させたプラク ティスを次に紹介しましょう。
ヒント 1：複雑性に基づく変更の分類：
契約上、変更の失敗はペナルティを伴 うため、マルチベンダ環境では責任者を 明確にするうえで分類が重要です。大組 織では、基本的なソフトウェア・ビルド を担当する技術パートナに加え、何社か のハードウェア・プロバイダ、複数のシ ステム・インテグレータ、および多数の 外部契約者を抱えているのが普通です。
そのため、変更が失敗した場合にその責 任がどこにあるのかを確認することが重 要です。また、全体的なプロセス・コン トロールに単一のオーナシップがないの で、変更失敗の原因が何だったのかを精 査することに貴重な時間の多くが失われ
ます。
ある大手電気通信プロバイダでの事例 で、変更を複雑、中程度、単純に分類す る重要性が明らかになりました。この組 織は、新規の法人顧客を獲得するため、
百万ドル規模の新規ポータル立ち上げに 取り組みました。このポータルはトライ アルに選ばれた顧客 1 社とともに立ち上 げられましたが、その顧客は 1 ヵ月もし ないうちに製品品質の悪さが不満で撤退 したのです。立ち上げが切り戻されるこ とはありませんでしたが、多大な収益の 損失が生じました。問題を解決するた め、追加資金も投入しなければなりませ んでした。これは変更の失敗と分類して よいでしょうか？ この展開には、切り 戻しを除くと、変更の失敗の属性すべて が備わっています。失敗の主な理由は、
設計時に採られた戦略のまずさにありま した。短期での市場投入を達成するた め、すぐに使えるシステムの実装と統合 に主な焦点が置かれました。多様なシス テムにまたがって入り組んだワークフロ ーが導入され、カスタマイゼーションも 最小限に止められました。IT システム というものは、LEGO ブロックとは異なり、
信頼性を実現するためには設計、開発、
テスト、展開の厳しさをくぐる必要があ るのだということが忘れ去られていたの です。