目次


Rational Method ComposerによるITILの実践

Comments

ITILとは

「The Rational Edge」の以前からの読者であれば、Rational Unified Process(以下、RUP)、eXtreme Programming(以下、XP)、および Project Management Body of Knowledge(以下、PMBOK)に関する記事はよく目にしていることでしょう。それでは、ITILとは一体何なのでしょうか?

ITILは Information Technology Infrastructure Libraryの略であり、ITサービス・マネジメント(ITSM)のベスト・プラクティスのグローバル・スタンダード(国際標準)であると見なされています。RUPやXPなどのソフトウェア開発スタイルではソフトウェア開発という分野を対象としていますが、ITILはIT運用の分野を対象としています。これは、1980年半ばに、英国商務局(OGC)によってアプリケーションおよびインフラストラクチャーの管理に、厳密さと一貫性をもたらす方法として作成されました。

ITILは、以下の内容を対象とする7冊の書籍のセットとして提供されます。

  • サービス・サポート (Service Support)
  • サービス・デリバリー (Service Delivery)
  • サービス・マネジメント導入計画立案(Planning to Implement Service Management
  • ICTインフラストラクチャー管理(ICT Infrastructure Management)
  • アプリケーション管理(Applications Management
  • セキュリティー管理(Security Management)
  • ビジネスの観点(The Business Perspective)

すべての書籍には有益な洞察が含まれていますが、ITILを初めて使用する多くの企業は、サービス・デリバリーとサービス・サポートに重点を置く傾向があります。サービス・デリバリーは、以下の分野に分かれています。

  • 可用性管理
    アプリケーションおよびインフラストラクチャーのアップタイムと平均故障間隔を定義する方法を説明しています。ここでは、サービスの高可用性、回復可能性、および信頼性などの概念を扱います。
  • キャパシティー管理
    定義済みのサービス・レベルを基に十分かつ適切なリソースを使用できるようにする方法を説明しています。
  • 継続性管理
    災害時回復および停止を管理するためのプラクティスに関連しています。
  • 財務管理
    インフラストラクチャー・コストの計算方法およびコストの最適化を促進するプラクティスを対象としています。
  • サービス・レベル管理
    アップタイムとサポート・レベルの指定時にユーザーが使用するプラクティス、およびユーザーがサポート・コストとサービス・レベルのトレードオフを理解するのに役立つプラクティスの両方を扱います。

サービス・サポートには、次の分野があります。

  • 構成管理
    このコンテキストでは、資産または構成アイテム(以下、CI)のインフラストラクチャー・タイプの識別および制御を扱います。そのため、ソフトウェア構成管理でコードやモデル要素などの制御を処理する場合は、ITIL CIは、ハードウェア、ミドルウェア、エンド・ユーザー・アプリケーションなどになります。
  • 変更管理
    構成アイテムへの変更方法を説明しています。説明されているアクティビティーの大部分が、標準的なソフトウェア変更管理のアクティビティーと一致します。
  • インシデント管理
    通常のオペレーション・プロセスの一部ではないイベントの処理方法を詳述しています。対処方法を基に優先順位を設定するためのインシデントの種別が含まれます。
  • 問題管理
    多くの場合、問題、エラー、欠陥などがインシデントの原因であるという点で、インシデント管理に関連しています。問題管理では、これらのタイプのイベントを処理して、変更要求(RFC)によって解決する方法を説明しています。
  • リリース管理
    ソフトウェア・アイテムを運用環境に導入するためのプラクティスを説明しています。ここでは、実装アクティビティーと配布アクティビティーの両方について説明します。
  • サービス・デスク
    インシデントと問題を一元管理するためのプラクティスを説明しています。ここでは、インシデント解決のため、サービス・カタログや知識ベースのような重要なアイテムに焦点を当てます。

ITILのビジネス・ケース

一般的に、ITILは組織がビジネスに関して3つのニーズを認識した場合に適用すべきものです。

最初に、多くの組織は、インフラストラクチャー・コストの抑制につながるオペレーション効率を追求しています。一歩下がって、典型的なIT予算を評価すると、多くの場合、自由裁量の部分と非自由裁量の部分に分かれることがわかります。自由裁量の支出は、競争優位を促進するための新しい機能に割り振られる支出です。非自由裁量の予算は、「業務を続行する」ことを対象としています。Gartner の調査によると、平均的なIT部門が通常、予算の75%から80%を非自由裁量の支出に割り振っています。しかし実際には、運用組織が厳密なサービス管理プロセスを適用した場合に、非自由裁量のうちの10%から20%もの額が自由裁量の資金に変更できるといわれています。

第2に、多くの組織はまた、ビジネス継続性のリスクを軽減するためのITILプラクティスを求めています。最近、あるお客様が、大規模なアプリケーションの計画を外部委託業者から社内に戻しました。そのなかで、アプリケーション開発の複雑さの管理に役立つRUP およびRationalのツールを導入しました。移行アクティビティーの開始後まもなく、不適切な運用サポートが原因で、もう少しですべての努力が無駄になるような重大なリスクに直面したのです。それ以来、このお客様は、将来のこうしたリスクを軽減するための方法としてITILを採用しています。

第3に、私が仕事をした企業のうち数社では、IT部門が基本的なサービス・レベルを満たすことができなかったため、エンド・ユーザーがITILの適用を推進しました。正直なところ、IT部門は長い間、多くのビジネス・ユーザーから悪い評価を受けていました。必要なものを提供できなかったり、時間やコストがかかりすぎたり、提供したアプリケーションがパフォーマンスやサポートの面で期待を満たしていなかったりしました。複数のお客様のビジネス・コミュニティーが、こうした問題を解決するためにITILを採用しています。これは、ITILが一貫性のある一連のプラクティスを提供し、運用形態によってはこれまで想像もしなかった分野にまで及んでいるためです。

ITILの適用

ITILは、10年以上前にヨーロッパで絶大な支持を獲得しましたが、米国で支持され始めたのは、ごく最近になってのことです。2004年のGartnerの調査で、ITILの知名度が高まっているのにも関わらず、58%の回答者(CIO、IT運用のリーダー、およびデータ・センターの管理者)がITILに関する知識をほとんどもしくはまったく持っていないことが判明したことからもわかるように、米国では依然として、ITILはかなりの数のITプロフェッショナルにとって関心の対象外のままです。大手金融サービスのお客様と仕事をしているときに、私は初めて実質的にITILを知りました。私は、プロセスの適用を担当するチームのリーダーとして、RUP移行アクティビティーおよびITILリリース管理の調整を支援するよう依頼されました。ITILをうまく適用するうえでの根本的な阻害要因に気付いたのは、このときでした。

ITリーダーが市場においてさまざまなプロセスから価値を得られるように、私は適用可能なITビジネス・プロセスとそれを組織が適用する際の難易度を基にカテゴリー体系を考案しました。図1は、この分析のサンプルです。

図1:プロセス適用可能度のマトリックス
図1:プロセス適用可能度のマトリックス
図1:プロセス適用可能度のマトリックス

さらに、プロセスを以下の4つのカテゴリーのいずれかに細分化するカテゴリー体系を定義しました。

  • ベスト・プラクティス
    あるドメインの実行者が行う個々のタスクまたは実践すべきことの記述。ITIL、PMBOK、および CMMIがこのカテゴリーに当てはまります。
  • 評価、測定、および監査
    これらのプロセスは通常、あるドメインの組織を評価するための成熟度モデルまたは標準を提供します。多くの場合、この測定のコンテキストでベスト・プラクティスを記述します。この場合も CMMIは、プロジェクト・マネジメント協会(PMI)の組織的プロジェクト・マネジメント成熟度モデル(OPM3)と同様、このカテゴリーに当てはまります。
  • プロセス改善
    これらのアクティビティー・セットは、効率性を最適化する手段であるプロセスを分析する場合に役立ちます。例として、シックス・シグマとスリム化があります。
  • 実行可能プロセス
    このプロセスは、会社が取り組むべきプラクティスのタイプ、これを行う人、作成する内容、ワークフローと、ワークフローの依存関係を、時間軸上の目標を明記した特定のライフ・サイクル・モデルに沿った、完全な記述を提供します。実行可能プロセスの典型的な例はRUPです。

この記事では、他の3つのタイプのプロセスよりも実装が大幅に簡単であり、より大きな価値を組織に提供する実行可能プロセスに焦点を当てているため、これらの4つのタイプのプロセスを区別することがきわめて重要です。

これ以外にも、プロジェクト関連プロセスと運用プロセスを区別する必要があります。PMIによると、プロジェクトは目的ベースであり、明確な始点と終点を持ちます(私は決して終わりそうもないプロジェクトに関わっていますが、これはまた別の話です)。運用プロセスは無限に続くプロセスであり、通常は本質的に持続しています。RUPはプロジェクト関連プロセスの例で、ITILは運用プロセスの例です。これは重要な相違点です。既存の概念(例えば、RUP)とは別に、ライフ・サイクル・モデルに関する概念を開発しなければならないことを意味するためです。

組織がITILなどの一連のベスト・プラクティスを導入して適用するように指示すると、多くの課題に直面しますが、少なくともその課題は実行可能プロセスによって少しは軽減されます。非実行可能プロセスには、相当なレベルの解釈が必要となります。例えば、ワークフローが定義されていない場合は、プラクティス・セットからワークフローを導き出すのは適用者の責務です。これには、組織またはロールの依存関係、成果物の所有権、管理方法などを判別するためのプラクティスに関する広範な分析が要求されます。テンプレートとレポートの内容およびフォーマットに関して幅広い議論が行われることは珍しくありません。この種の分析が、数カ月ではないにせよ数週間を要するのに、満足のいかない結果に終わることがわかっています。また、プロセスの適用は組織的な変更を意味します。変更を成功させるための鍵は、新しいプロセスの影響を受ける人を明確に定義できるかどうかです。

  • その人が果たすロール
  • 期待されるスキルとコンピテンシー
  • ロールに対する各タスク
  • 担当する成果物、およびそれを担当する理由
  • 他の人とチームとして作業する方法
  • 自分たちの成功を認識する方法

実行可能プロセスは、これらの質問に答えるのに大いに役立ちます。RUPが、追加の重要な要素であるプロセスの調整に関するガイダンスを提供します。プロセスは、プロジェクトの複雑さやチームのスキル・レベルの変化に対処する柔軟性をもたずに、ひとまとめに適用されることが多すぎるのです。

実行可能なプロセス

プロセスを実行可能にするために必要なものは何でしょうか? まず、図2に示されているように、主要な要素が含まれている必要があります。

図2:RUP コンポーネント
図2
図2

図2は、RUPの基礎となるプロセス・メタモデルを示しています。
このモデルは、Object Management Group(OMG)が定義した Software Process Engineering Metamodel(SPEM)を基にしています。これは、Unified Modeling Language(UML)を使用するプロセスのさまざまな局面を完全に網羅しています。ITILを実行可能にするために、これらの要素を識別して文書化する必要があります。さらに、最終的にワーク・ブレークダウン・ストラクチャー(WBS)を生成できるように、関係と依存関係も決定する必要があります。

これを行うためのステップはかなり単純ですが、作業量は大変多くなります。ITILを文書化するために使用するワークフローは、次のとおりです。

  1. プロセスを最上位レベルで分割する。これにより、作業を編成して、依存関係を管理することができます。プロセスのこれらの「バケット」は、作業分野に変換されます。
  2. ロールおよびロール・グループを識別する。RUP を熟知していれば、例えば、分析者のロール・グループが、この場合はシステム分析者とユースケース定義者を含むロールを持っていることがわかります。
  3. 成果物またはワーク・プロダクトを識別する。これらは、プロセス実行の明確な入出力であり、文書からツールでの(電子的な)成果物まで、どんなものにでもなり得ます。
  4. タスクを識別する。ユースケース分析のような方法に従います。つまり、ロールによってタスクを検索してから、洗練する過程で、より一般化したタスクとして評価します。タスク(RUP アクティビティー)はステップに分かれており、一般的なガイドラインとして、1つのアクティビティーが10個を超えるステップを持たないように留意してください。
  5. 今までに導き出した要素間の関係を定義する。ロールを基本単位として使用して、最初にロールに関連するすべての関係を定義します。次に、ドメイン内で、要素間の関係(例えば、あるロールと他のロール、ある成果物と他の成果物など)を評価します。
  6. ワークフローを構成する。ワークフローはタスクの集合であり、順序付け、同期 (並行して実行できるタスクと実行できないタスク)、および依存関係を定義します。場合によっては、ステップ4の前にこのステップを実行できますが、Rationalのモデリング・プロセスの新しい方法を見ると、この位置で実行した方が多少うまく機能することがわかります。
  7. ガイドライン、チェックリスト、ツール・メンターなどを収集する。これらは、プロセスの適用、使用、および管理を容易にする要素です。
  8. 結果を外部に公開する。以前は、Rational Process Workbench(RPW)を使用してRUPへの変更を生成しました。代わりにRMCを使用します。次に、このツールについて詳しく見ていきましょう。

第2回 「Rational Method ComposerとITIL」

このページで紹介されている情報はレベル別にカテゴライズされています。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=312437
ArticleTitle=Rational Method ComposerによるITILの実践
publish-date=07262007