目次


Rational Method ComposerによるITILの実践

Comments

Rational Method Composer

Rational®のプロセスを少し使用した経験がある、もしくは、RUPをカスタマイズしようとしたことがあるのであれば、Rational Process Workbench(以下、RPW)には慣れていることでしょう。これは、Rational Extended Development Environment(以下、XDE)(モデリングおよび開発ツール)を基にしたプロセス管理ツールです。RPWは強力なツールである一方、多くの人が、使うのが難しいと感じていました。RPWから完全に脱却したRational Method Composer(以下、RMC)について見ていきましょう。

まず、RMCはRUPより広い範囲を扱います。RUPコンテンツ・ライブラリーが付属していますが、ユーザーはその中でプロセスを作成したり、カスタマイズすることができます。2番目に、数多くのIBM Rational新製品と同様に、Eclipseベースです。これは、業界標準のルック・アンド・フィールを備えていることを意味します。最後に、RMCは、モデリングの経験がないユーザーでも非常に簡単に利用できます。それでも分析スキルは必要であり、プロジェクト管理の経験があるにこしたことはありませんが、このツールを使用するのにUMLのエキスパートである必要はありません。

メソッド : RMCの基本

RMCについての詳細はこの記事では割愛しますが、基本概念について少し説明しましょう。[編集者注 : RMCの詳細については、同様に2005年12月に発行された記事「Rational Method Composer 入門 〜Key Concept編〜」を参照してください。

* 翻訳済み記事は以下URLリンク先を参照
Rational Method Composer 入門 〜Key Concept編〜

RMCはメソッドを扱います。メソッドは、実行する作業およびその作業の順序付けの定義です。メソッドを作成するには、メソッド・コンテンツ(誰、何、どのように)およびプロセス(いつ)を定義する必要がありますが、図1に示すように、これらは別個の要素です。ここで重要な考え方は、プロセスの実際の実装に目を向けると、プロジェクトと企業に共通するのは成果物および場合によってはロールであるという点です。共通しない点は、ロールが連携する方法またはロールが使用できる成果物です。

RMCは、この定義を使用して、再利用性とカスタマイズの容易さを最適化しようとします。ITILを実行可能にする場合は、まずはメソッド・コンテンツを定義して、次にプロセス要素を定義します。

図1:RMCの主要概念
図1
図1

RMCを使用すると、メソッド・コンテンツおよびそのプロセスを定義することによってメソッドを作成することができます。

RMCは、メソッドの拡張とカスタマイズを助けるためのメカニズムを提供します。
RPWが通常は、組織レベルで RUPを変更するために使用されたのに対して、RMCはプロジェクト・レベルの変更をサポートすることができ、さらにプロジェクト・レベルのプロセス管理を促進します。プロジェクト管理者と管理に関わる人にとって、これは非常に大きなことです。つまり、ワーク・ブレークダウン・ストラクチャーおよびプロセス定義がツールを使用して同期され、メソッド・ライブラリーから制御できるということなのです。

すべてを取り込む

これで、ITIL、実行可能プロセス、およびRMCとは何かについての基本的な考え方がおわかり頂けたでしょう。また、3文字略語が少なくとも10個はあなたの語彙に追加されたはずです。これは履歴書を作成するときに常に重要なことですね。次は、Noblestar社がRMCを使用してどのようにITILを実行可能にするのかを見ていきましょう。

私たちは、あるお客様がソフトウェア・エンジニアリングとIT運用の両方の分野をより厳密にすることができるよう支援しました。プロセス・エンジニアリングはこの取り組みで重要な役割を果たしており、この記事の大部分の基礎にもなっています。

私たちのワークフローでは、まず最初のステップとして、タスクの困難さを軽減するためにITILを分解する方法を決定することでした。当然の選択肢は、『ITILとは』のセクションで説明したITILの作業分野の方針に従って細分化することです。RUP の作業分野に分析と設計、実装、テストなどがあるのと同様に、ITILの作業分野には可用性管理、サービス・レベル管理などがあります。これらの作業分野は、RMCでのITILのメソッド・コンテンツのビルディング・ブロックになります。

私たちは、コンテンツを取り込むために反復型アプローチを採用し、お客様の要求に基づいて変更管理から始めました。1つ補足しておきたいことがあります。スタンドアロン・バージョンのITIL変更管理を作成した後、私たちのチームは、RUPの構成と変更管理をもっと活用できたように感じました。そして今、実際に2つを結合させるプラグインを作成する計画を開始しています。さて、これでパッケージにロール、ワーク・プロダクト、およびタスクを取り込む準備ができました。

メソッド・コンテンツ

この種の分析は、通常はロールの識別から始めて、次にシステム内でこれらのロールが機能する方法を記述するという点で、ユースケース分析ととてもよく似ています。私たちの場合は、ITILの資料を参照して、指定されたすべてのロールを取り出して、図2に示すように、定義できるだけの詳細をロール情報に取り込みました。この時点では、ロールの説明以外の情報は取り込んでいません。

図2:ITILの変更管理ロール
図2
図2

次にワーク・プロダクトが識別され、入力されました。さらに、これは主として、文書をレビューしてそこからアウトプットを引き出すことによって行われました。タスクを識別するというさらに骨の折れるアクティビティーは、大量の作業を探して表現しました。ロールと成果物を簡単に指定した場合は、タスクでは抽象化する必要があり、場合によってはITILの書籍の情報を拡張する必要がありました。表1は、派生したワーク・プロダクトおよびタスクのサンプルを示します。

表1:ITILのワーク・プロダクトとタスク)
ワーク・プロダクトタスク
変更要求(Request for Change)変更要求の承認
切り戻し計画(Backout Plan)変更管理委員会ミーティングの実施
RFC 変更スケジュール(RFC Change Schedule)影響分析の実行
実施計画(Implementation Plan)変更のスケジュール
RFC 状態レポート(RFC State Report)変更の実施

ここで重要な点は、プロセスを実行可能にすることは、単にプロセス管理ツールに置き換えることではないということです。実際には、特に、コンテンツの編成を簡単にするRMCのようなツールを使用すればかなり些細なことです。むしろ、時間のほとんどが、タスクおよび依存関係の分析を実施するために費やされます。

メソッド・コンテンツのもう1つの部分は、情報をどのようにカテゴリー化するべきかを定義することです。例えば、どのようにロールをまとめてロール・グループにするかということです。これは、最終的な表示におけるコンテンツの編成に影響を与えます。RMCは、一連の標準カテゴリーとカスタム・カテゴリーの両方を提供します。標準カテゴリーは、次のとおりです。

  • 作業分野
    私たちの場合は、ITILの作業分野を反映しています。
  • ドメイン
    ワーク・プロダクトのグループを含みます。これらのドメインを上位の問題ドメイン・パッケージとして扱います。これは、実行者が目的の類似性によって成果物のタイプを識別する場合に役立ちます。私たちのITILの分析では、ワーク・プロダクトの作業分野の分類でも行き詰まりますが、どこかの時点で最適な抽象化のために再編成できています。
  • ロール・セット
    上で述べたように、ロールのグループです。
  • ツール
    ツール・カテゴリー、正しくはツール自体を列挙していないという点で多少標準と離れています。私たちの場合は、これにTivoli Configuration Managerなどのツールを含めました。

カスタム・カテゴリーを作成には多くの理由がありますが、大抵は、メソッド・コンテンツの再使用可能なビューを構築するために作成されます。カスタム・カテゴリーを作成して、それにさまざまなメソッド要素を割り当てることによって、最後にレンダリングされた Webページで情報を表示する方法を構成することができます。

プロセス・オーサリング

プロセス・オーサリングの説明に移る前に、RMCでのタスクとアクティビティーの違いを指摘しなければなりません。

識別したメソッド・コンテンツ・アイテムの1つがタスクだったことを覚えておいででしょう。タスクは、個別のアクションであり、複数のステップに分解できます。これは、RMCで管理できる最も細かい作業単位です(1)。タスクは、複数のアクティビティーまたはプロセスで再利用可能です。

アクティビティーは通常、タスク、ワーク・プロダクト、ロール、およびガイドラインの順序化されたグループを表します。これは、タスクやその他のアクティビティーをワークフローにまとめるための抽象化メカニズムとして、プロセス・オーサリング中に作成されます。

メソッド・コンテンツを定義して、次にそこからプロセスと構成の構築を開始しました。これを行うために、ワーク・ブレークダウン・ストラクチャーを定義する RMCの機能を使用することで、もう1 つの大きな課題が明らかになりました。お客様との取り組みで ITILを検討していると、タスクの識別に役立つ大量の詳細情報を持つ分野があっても、多くの場合、タスクのWBSの作成に十分な詳細はないということがすぐにわかりました。「悪魔は細部に潜む」とはよく言ったものです。

私たちの場合は、ギャップを埋めるためにサービス管理の経験を持つ社内リソースを割り当てる余裕がありました。そのうえ、ワーク・ブレークダウン・ストラクチャーを作成するためにお客様と一緒に作業していたのです。

RMC内のプロセス定義は、ケーパビリティー・パターンとデリバリー・プロセスに分類されます。デリバリー・プロセスでは、与えられたプロジェクト・タイプに対して完全なライフ・サイクルを記述します。RMCベータに付属のデリバリー・プロセスの例には、小規模、中規模、および大規模のプロジェクト用のRUPのインスタンスがあります。特筆すべき機能の1つは、デリバリー・プロセスを Rational Portfolio Managerにエクスポートする機能です。ケーパビリティー・パターンの内容はデリバリー・プロセスと似ていますが、通常はより小さい再使用可能コンポーネントです。RUPの例には、ユースケース分析や単体テストがあります。

ITILの変更管理の作業分野から、次のような4つのコア・ワークフローを導き出しました。

  • 変更要求の管理(Manage Request For Change)
  • 変更スケジュールの管理(Manage Change Schedule)
  • 構成アイテムの変更の管理(Manage Change to Configuration Items)
  • ITSM プロセスの評価および管理(Evaluate and Manage ITSM Processes)

最初の2つは、明らかに「ITIL変更管理」の分野に属していますが、他の2つは「構成管理」と「プロセス改善」の分野の方がうまく当てはまります。これらすべてをRMCケーパビリティー・パターンにすることを選択しました。

ケーパビリティー・パターンには、タスクやワーク・プロダクトなどを構成ビューから適切なブレークダウン・スケジュールにドラッグすることで作成されるアクティビティーが取り込まれます。

これは私のお気に入りのRMC機能の1つです。RUPを熟知しているのであれば、ワークフローを記述するアクティビティー図に慣れていることでしょう。私はプロセス・モデリングが大好きで、特にアクティビティー図を使用してワークフローを記述することが気に入っています。というのも、利用者が取り組んでいるコンテキストを理解するのに役立つからです。以前(RPWを使用していた頃)は、RoseまたはXDEでこれらのダイアグラムを作成して、イメージとして管理していました。あまり変更しなければ問題ありませんでしたが、そうでなければ保守が大変でした。RMCでは、ダイアグラムはスケジュールと同期されます。プロセス・ワークフローをモデリングしたい場合は、ツールで作業を行って、単にワーク・ブレークダウン・ビューに切り替えるだけです。

図3はアクティビティー図の例を示し、図4は、関連するワーク・ブレークダウン・ソリューションを示します。

図3:プロセスのアクティビティー図
図3
図3
図4:ワーク・ブレークダウン・ストラクチャー
図4
図4

定義された反復について、デリバリー・プロセスを独立して提供できるように、最終的にすべての作業分野が含められる基本のITILデリバリー・プロセスおよびITIL変更管理のデリバリー・プロセスを識別しました。

公開前の最後のステップは、プロセスのビューを定義することです。私たちの場合は、RUPと同じような方法で、つまりチームに焦点を当ててビューを定義しました。

最終的な結果を公開することは、単に出力を生成することに過ぎません。

これで、実行可能プロセスが作成されました。ここからはどうすればよいのでしょうか?

実行可能プロセスを作成したら、面倒なことはすべて終わりで、大切な人と何年間も計画していた長期休暇を取ることができます、と言いたいところですが、それ程簡単ではありません。プロセスの文書化は、最初のステップに過ぎません。プロセスから本当に価値を得るには、人々にそのプロセスを繰り返し使用してもらう必要があります。新しいスタッフは仕事を始める前にプロセスのトレーニングを受けるべきだ、と誰もが主張するようになるくらい、プロセスを社内に十分に浸透させる必要があります。この結果、組織的な変更管理が必要になります。しかし、これもまた別の記事で扱うことにしましょう。

ITILは、IT運用およびサポート組織に大きな価値を提供しますが、一連のベスト・プラクティスの文書としては、適用を容易にし、その価値を最大限に発揮させるための重要なコンポーネントが欠けています。RMCは、その足りない部分を補完するだけでなく、拡張と保守を単純かつ容易にする環境を提供します。


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


関連トピック


コメント

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

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