私は順応性のある人間であり、変化やチャレンジを好みます。しかし最近では、ハン・ソロのミレニアム・ファルコン号に乗って超空間を旅しているような気分です。

この10年間のITの進化を一覧にしてみたら、「良い知らせとともに、それを帳消しにする悪い知らせもある」というジョークのようになるでしょう。一元管理されるメインフレームをベースとした、緑色の文字が並んだトランザクション処理用のCICS画面は、恐竜と同じように消滅の運命を辿りましたが、この緑色の画面がハッキングされたことは一度もありませんでした。管理が一元化されたときには、サインオン画面が表示されないという電話がヘルプ・デスクに殺到しましたが、カスタマイズ可能なワークステーションを使用するユーザーは、画面の解像度を変更できると知って、苦情を言うのをやめました（もちろん、妥当な範囲を超えるほど拡大しました）。

環境の変化以外にも、従来は有線接続が必要であった機能を備える携帯型デバイスや、その他の「流行の技術」を利用した無線コンピューティングに対応しました。

メールはどうでしょうか。2年前は、ジョージ・ワシントン大学の学生は、口座をチェックするために必ずキオスクに立ち寄ってました。現在、メールはもはや時代遅れになり、ピア・ツー・ピアの分刻みのコミュニケーションには、IM（インスタント・メッセージ）、携帯電話向けテキスト・メッセージ、SNS（ソーシャル・ネットワーキング・サービス）、ブログが使用されるようになっています。新しい、優れたサービスが登場すると、当校のITスタッフがその存在を知るよりも早く、学生たちはそれを使いこなしています。大学がそのデバイスの使用を禁止することはできません。できることは、「サポート対象外」の一覧に加えることです。

複雑な環境の管理

当校が現在管理している環境では、従来は不可能だった方法でユーザーにサービスを提供できます。しかし、このように拡大されたサービスを提供するために必要な多くの新しいIT製品とユーティリティによって、管理すべき環境が非常に複雑化しています。

当校では、高等教育機関向けERPであるSunGard BannerスイートとOracle財務管理アプリケーションを実行しています。また、校内全域でEMC Documentum®スイートを導入しています。募集、入学、学資援助、履修登録、住居のあっせんといった当校のビジネス・サイクルや、政府機関への報告のための会計処理などを考えると、アップグレードのスケジュールを設定してテストを実施するだけでも複雑です。当校での最新の分析によると、理想的なアップグレードのタイミングは、うるう年の3月の第5木曜ということになります。

これが、ユーザーが利用しているシステムなのです。データベース、サーバ、オペレーティング・システム、ユーティリティ・システム、SAN、バックアップ・ソフトウェアには、それぞれ独自の更新サイクルがあります。当校では、本番サーバとアプリケーションごとにテスト環境と開発環境を維持しており、また、相互にサポートするデータ・センターを二重に管理してます。それでも、1つのコンポーネントを導入する際に、負担の少ない時間を確保するのは困難です。

また、ITはサービス指向アーキテクチャに移行していくと考えられます。それでもエンド・ユーザーが新しいソフトウェアの機能を理解し、当校がその機能のテストや構成に要する負担を考えると、すべての人が一層努力しなければなりません（私はむしろ、これ以上便利な暮らしを追求するのはやめてほしいと、どこかの部門が言ってくるのを待っているのですが）。しかし、IT業界の主要企業の中には、プラグ・アンド・プレイ方式のコンポーネントを開発しています。そのため、稼働中にインフラストラクチャを変更できるようになり、リスクの高い、持続不可能なレベルの関与をエンド・ユーザーに求めなくて済みます。

共同テストの重視

当校では、ERP機能のリリースやアップグレードを導入に、ユーザーとITスタッフの間で行う共同テストを重視したプロセスを開発し、さらに調整を進めています。

当校のITチームは、リリース内容を分析し、重要な変更や機能強化をリストアップする作業にプロジェクトの最初の3分の1を費やします。さらに、サーバとデータベースの調整、デスクトップ・クライアントのテスト、セキュリティの分析、エンド・ユーザーによるテスト用のスクリプトの準備など、多岐にわたる包括的なテストの準備を行います。準備に時間をかけるほど、より包括的な分析ができ、キャンパス運営への影響を軽減できます。

次に、ITスタッフは、重要なオフィスの「パワー・ユーザー」に対して新機能に関するトレーニングを行い、エンド・ユーザー向けのトレーニングを実施できるよう指導します。パワー・ユーザーは、ITスタッフが用意したテスト・スクリプト、運用に関する自身の知識、従来のバージョンのソフトウェアに関する知識を使用して、「改善された新しい」機能を分析し、その確かさを確認します。

異常があればすべて記録します。実際に問題となるものもありますが、考え違いや、テスト・スクリプトのミスということもあります。通常、報告される問題は、変更されたデータベース・エレメントを参照するレポート、不慣れな画面インターフェースまたは操作手順、従来了解されていた事項に関係する修正などに関連します。当校のプログラマが、ERPベンダーとともにすべての問題を調査します。問題は短期間で修正され、確認のためにユーザーに戻されます。

最終段階では、ユーザーの代表者がアップグレードを承認し、最高幹部レベルの執行委員会が「Go」サインを出します。最終的に技術的な課題があればそれをまとめ、ソフトウェアを本番環境に移行します。本番稼働計画（通常は30分単位まで詳細に作成）が開始され、特定の日時にシステムが本番稼働します。

このようなプロセスが必要な理由は、当校には数千人のユーザーが存在するためです。また、大規模なシステム変更を行える時間は限られており、導入に要する時間と労力はかなり大きくなるためです。比較的負担の少ないデータベース・アップグレードやセキュリティ・パッチの場合は、このプロセスを縮小し、必要な効率や安全性を考慮しながら、従来と同様にシステムが稼働することを確認します。

細部にまで気を配ることで、予想外の問題によって以前のバージョンへのロールバックが必要となることもなく、大規模なERPクラスのシステムを何度かアップグレードできました。しかし、それぞれのアップグレード計画には、最終段階で問題が発生した場合に必要となる日程が含まれています。そうした日程（通常は2週間以内）を設定することで、リスクに関係なく「やるしかない」という心理的なプレッシャーが軽減されます。また、意思決定者には、論理的かつ実践的な代替案を提示できます。プレッシャーを排除することで、現実的なリスク分析が得られます。

Bill Gates氏は「もしゼネラル・モーターズ社がコンピュータ業界のような絶え間ない技術開発競争にさらされていたら、私たちの車は1台25ドルになり、燃費は1ガロン1,000マイルになっていたでしょう」と発言したと言われています。しかし、もし自動車業界がIT業界と同じように仕様変更を頻繁に行っていたとしたら、1月には新しいタイヤへの交換のため、2月には新しいエアバッグを装備するため、3月には新開発のセラミック・ブレーキへの交換のためというように、頻繁に自動車を販売店に預けることになったでしょう。

1つの業界として、当校のIT環境の拡大において複雑さが緩和されることは決してないでしょう。しかし、変更を行うことで、エンド・ユーザーへの影響を軽減することはできます。私たちは皆、効率的に、そして効果的にエンド・ユーザーにサービスを提供することを望んでいます。プラスとなる変更を行う際に、意図しない不利益が生じないようにする必要があります。