RUP の拡張: 運用及びサポート作業分野

このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。

1. 概要

運用及びサポート作業分野の第 1 の目的は、稼動環境におけるソフトウェアを運用し、サポートすることです。運用では、ソフトウェアが適切に動いていること、ネットワークが利用可能で監視されていること、適切なデータが必要なときにバックアップ・リストアされていることの保証に重点をおきます。災害対策計画を立て、実際に災害が起きたときには、それを実行して主要システムを復旧します。サポートの主な仕事は、質問に答える、稼動システムで発生した問題を分析する、新しい機能の依頼を記録する、修正 (fix) を作成して提供するなどして、エンドユーザを支援することです。

運用及びサポート作業分野のワークフローを図1に示しています。EUP の他のフェーズや作業分野と同様、組織はこの作業分野に含まれる作業を自分の環境に合ったやり方で適用します。社内でシステムを開発・導入している組織の場合、店頭で市販するソフトウェアを作成している会社よりも、運用サポートの作業は多くなります。後者は、多様な有償顧客たちの満足度を上げるためにサポートの方に時間や工数を費やし、運用のための要員を置かないことがありますが、それに対して前者は、運用だけのために専任のチームを置いていることがあります。

図1. 運用とサポートの作業分野のワークフロー

2. 運用及びサポートの導入を計画する

この作業分野を成功させる上で欠かせないのが、システムを稼働環境に導入する計画を立てることです。この作業のために、導入作業分野には、システムを導入した後でどう運用・サポートするかの計画立案が追加されています。サポートマネージャは、システムを稼動環境に導入する前に、サポート計画を定義しなければなりません。システムのサポート計画では、以下の項目を検討します。

どのようにサポートを提供するか: サポートを行うには、電子メール、オンラインのチャット、人が対応するコールセンターなど、いくつかの方法があります。顧客(社内・社外)にどのようにサポート料金を支払ってもらうかを検討しなければなりません。特定の部署/団体 (cost center) に請求するのでしょうか、それともクレジットカードに請求するのでしょうか。また、有償・無償の顧客によってどのようにサポートの種類 ( レベル ) を変えるかも決めなければなりません。
システム担当の連絡先: 連絡先の情報を最新の状態にしておくことも重要です。リストが最新になっていなければ、夜中の 2 時の電話に誰も出ず、窮地に陥ってしまうかもしれません。連絡先リストには、誰に連絡するべきか、その担当者に連絡できる時間と連絡できない時間、その担当者に連絡するべき状況、その担当者への連絡方法 ( 電話、ポケットベルなど ) を含めておいてください。
不具合報告および拡張依頼のための戦略: 最初の連絡を受け、プロセスを通してエンドユーザに対応するのは、サポート担当者です。拡張依頼と重大度の低い不具合は、エンタープライズ変更管理審査会 (Enterprise Change Control Board: ECCB) に提出されます。これは、ポートフォリオ管理作業分野の作業に含まれます。
サポートのサービス品質保証 (Service-Level Agreement: SLA) : サポート SLA では、稼働環境におかれたシステムのサポートの問題に対応します。
不具合の優先順位付けおよび解決までの期間: 不具合 ( あるいは拡張 ) の重大度のレベルについてはサポート計画ですでに定義されていますが、SLA 要求を満たすために、重大度によってどのような制約 ( 時間、金銭、その他のリソース ) を課すかを決めなければなりません。
不具合エスカレーション基準: 重大度と合意された解決までの時間にもとづいて、適切なエスカレーション経路を定義します。
公式リリース以外で修正を稼働状態に導入する方法: システムごとに、リリーススケジュール ( 決まった日付または顧客ごとの予定 )、導入方法 ( 電子メール、Web、物理媒体、あるいはその組み合わせ )、修正を受け取る顧客の優先順位 ( あれば ) を決めなければなりません。

同様に、運用管理者はプロジェクトチームと密接に協力し、運用計画を作成します。システム運用計画では、稼動状態にある間、システムをどう運用するかを定義します。

3. ユーザをサポートする

サポートのための戦略には、大きく分けて 2 つのものがあります。エスカレーション戦略 (escalation strategy) と窓口固定戦略 (touch-and-hold strategy) です。エスカレーション戦略は、ほとんどのサポート要求はきわめて基本的で、簡単に処理ができるけれども、ごく一部の要求は複雑で、より知識の深いメンバーに受け継ぐ必要がある、という考え方がもとになっています。この方法の場合、規模を拡大するのは簡単ですが、サポートを受ける側からすると、サポート担当者間の引継ぎがいらだたしく感じられることがあります。窓口固定戦略では、最初にサポート要求を受けたメンバーが最後まで面倒をみます ( ただしその過程で他のメンバーの協力を仰がなければならない可能性はあります )。窓口固定戦略では、サポートを受ける側は 1 人のサポート担当者とだけやり取りすればよいため、概して顧客満足度は高くなります。しかし、そのためにはよりスキルの高いサポート要員が必要であり、そのようなメンバーを雇って引き止めておくのは難しいため、規模を拡大するのは困難です。インシデント管理、問題報告、サービスデスクに関する詳しい情報は、それぞれ関連する ITIL Fact Sheet を参照してください。

4. システムを運用する

この作業(図2を参照)の目的は、稼働環境においてシステムを運用することです。この作業には主に2つの役割が関与します。

運用担当者: システムを安定稼動させること、システムの運用計画および要求にもとづいてデータをバックアップ・リストアすること、問題が発生したらそれに対応すること、定期的なクリーンアップを行うこと、細かい調整やシステムの再構成を行うこと、システムを監視すること、必要に応じてシステムを導入し直すことを担当します。運用サポートはたいてい 24 時間休みなしの作業なので、引継ぎ手続きを定義し、シフトをまたがる問題が起きたらそれに従って引き継ぎを行う必要がありますし、シフトが始まる前および終わる前に各チームが何を終わらせておかなければならないかも定義しておく必要があります。
サポート開発者: ホット・フィックス(サービスパック、パッチともいいます)によってシステムの修正を導入することに責任を持ちます。たいていは開発チームのメンバーです。開発を行う場合と同じように、プログラムやシステムの細かい調整や再構成を行う場合には、稼働環境に導入する前に必ずテスト環境でテストを行ってください。また、重大な問題が起きたときのために復元計画 (back-out plan) を準備しておく必要もあります。

図2. 「システムを運用する」ワークフローの詳細

5. 災害に備える

災害復旧計画を作成して、大災害が発生したときに基幹システムを復旧し、稼動させるための手順を定めます。この場合の大災害には、暴風や竜巻がやってきて会社のネットワーク運用センターが破壊されてしまったというような自然災害が含まれます。また、2003年の秋にアメリカ北東部を襲った停電のような人災も含まれます。IT サービス継続性管理に関する詳しい情報は、関連する ITIL Fact Sheetを参照してください。

6. 災害から復旧する

組織が最終的に災害復旧計画を実施しなければならない場合があります。災害復旧計画は、必ずハードコピーとして印刷し、複数の人が見ることのできる複数の場所に保管してください。災害発生時には電子ファイルにアクセスできないことがあるからです。運用管理者は災害復旧計画を実施する責任があり、必要ならさまざまなプロジェクトチームと協力してシステムを復旧しなければなりません。最終的に災害からの復旧が成功したといえるのは、計画に従って非常時用プラットフォーム上でシステムが動いている状態になったときです。運用管理者は、復旧作業を再検討して、そこでの教訓を明らかにし、それにもとづいて行動する責任もあります。

本ページの原文 ( 改訂されている可能性あり ): www.enterpriseunifiedprocess.com/essays/operationsAndSupport.html

元ページ更新日: 2004/11/25
日本語訳最終更新日: 2008/6/24