レベル: 中級 John Boyer (john.boyer@us.ibm.com), SOA Program Manager, IBM
Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM
Eoin Lane (eoinlane@us.ibm.com), Senior Solution Engineer, IBM
2008年 4月 17日 Web 2.0 技術を活用して、通常は HTML として静的に公開されるソフトウェア開発プロセスのコンテンツを拡張しましょう。この記事では、協調的な方法でメソッド・コンテンツを編集し、ある (ソフトウェア開発) メソッドのコンテキスト内にある最新の動的コンテンツにアクセスするための方法について説明します。
はじめに
IT 実務者は通常、IBM® RUP® (Rational® Unified Process) などのソフトウェア開発メソッドを使います。このようなメソッドは、さまざまなソフトウェア開発の分野やさまざまな業界に適用することができます。RUP や IBM RUP SOMA (Service-Oriented Modeling and Architecture) などのソフトウェア開発メソッドでは、HTML として公開される静的なプロセス・ガイダンスを提供します。IBM Rational Method Composer はプロセス・エンジニアがプロセスをカスタマイズするために使用するツールですが、その一方で新しいプロセスを単なる読み取り専用の Web ページとして公開することもできます。
ソフトウェア開発メソッドが真に有用なものであるためには、そのメソッドはコンテキスト特有のアセットによって強化されている必要があります。これらのアセットは通常、コンテンツやツール、そして人間です。コンテンツ・アセットには、文書やプレゼンテーション、モデル、ソーシャル・ブックマーク、その他さまざまなリソースが含まれます。例えば電話会社の特定顧客のビジネス・モデリングを補助するために、このようなメソッドを適用したとします。するとこのメソッドは、利用可能な特定のツールとコンテンツに関するガイダンスを提供するはずです。
メソッド・コンテンツは公開された後は凍結されるため、拡張することはできません。しかし Web 2.0 技術を利用すれば静的なコンテンツを補助的なウィキ・ページによって補強することができ、協調的な方法による編集と動的な Web フィードを実現することができます。こうしたページを、次のセクションでは拡張ポイントと呼ぶことにします。
では、なぜメソッドに拡張性がないと問題なのでしょう。その理由は次のとおりです。
- メソッド・コンテンツが古くなってしまいます。例えばガイダンスのための成果物 (テンプレートやアセット、ツール・メンターなど) が古くなってしまいます。
- メソッド・コンテンツをカスタマイズすることができず、特定のコンテキストのための詳細を持つことができません。例えば市販のメソッド・コンテンツは汎用的であるため、そのメソッド・コンテンツが適用される状況 (例えば組織や業界ドメイン、ロール、アクティビティー、アセット、ツールなど) に対してメソッド・コンテンツを適合させる必要があります。
- メソッド・コンテンツをカスタマイズした場合には再公開する必要があります。
- メソッド・コンテンツをユーザーや実務者が補強することはできないため、コミュニティーによるコンテンツ開発と機能強化に対するユーザーの貢献を利用することができません。その結果、ユーザー・コミュニティーによるフィードバックや協力の機会が失われがちです。
- メソッド・コンテンツは多様な媒体によるコンテンツ (ビデオやポッドキャスト、Flash によるデモなど) を活用することができません。こうしたコンテンツはすぐに古くなるからです。
- メソッド・コンテンツには、詳細な、そのまま使用できる商用ツール・ガイダンスがないことが多いものです。
- メソッド・コンテンツは、そのままの状態では組織のアセットやツールのためのガイダンスがありません。
もう 1 つの問題は、プロセス・エンジニアリング部門が、その分野に必要なすべてのメソッド・コンテンツを作成するための十分なリソースを持っていないことです。例えば、こうした部門は通常、同じツールのさまざまなバージョンに対するコンテンツを提供することができません。従ってメソッド・コンテンツは更新されることがないままとなり、その組織の実務者達は実際のフィールドで得た知識に基づいてコンテンツを改訂できるにもかかわらず、組織は実務者達の知識や理解を集約することができません。
注意: 一部のコンテンツは組織にとって優先課題であることが多いものです。その一例が、IBM のような会社に特有の IAA (Insurance Application Architecture) モデルです。
この、同じ問題を解決するために、他の手法が使われています。例えば次の例を考えてみてください。管理者またはプロセス・エンジニアは定期的に (例えば毎月、毎週、毎日など) 静的メソッドを再公開することができます。しかし、そのメソッドの中に実務者によるフィードバックや貢献を反映させるためのプロセスを確立しなければなりません。また、この問題を悪化させる事実として、このメソッドは IBM Rational Software Architect などのツールと一緒に公開されており、Rational Software Architect が更新されるまでメソッドを更新することができません。実務者は最新情報を持つ独自のページを構築しますが、こうしたページは分散されており、しかもメソッド・コンテンツやプロセス・コンテンツと統合されていません。
Web 2.0 を使って拡張可能なメソッド・コンテンツを作成する
理想的には、協調的な方法で構築される領域と、実務者がこのメソッドを利用する際に動的にデータが追加される領域とで構成される拡張ページを使って、ソフトウェア開発のプロセスとメソッドを拡張できるようにしたいものです。図 1 はこの様子を示しています。
図 1. 協調型で動的なメソッドの概要
この協調型で動的ななコンテンツには、いくつかのアクティビティーが関係しています。これらのアクティビティーを詳しく調べてみましょう。
拡張ポイントの識別
プロセス・エンジニアは拡張ポイントを静的メソッドで識別します。通常、これらの拡張ポイントは、新しい手法、または改善された手法、あるいはその両方を記述するメソッドの領域にあり、またコミュニティーの助けを借りてコンテンツを作成しないとコンテンツがすぐに古くなるような領域にあります。
拡張ページの作成
拡張ポイントが特定されると、プロセス・エンジニアはこの拡張ポイントに対する拡張ページを作成します。この拡張ページの目的は、静的メソッドのコンテンツに加え、最新のガイダンスを提供することです。この拡張ページには次の 2 つの領域が含まれます。
- 協調型ガイダンスのコンテンツ領域
- 動的コンテンツの領域
協調型ガイダンス領域
協調型ガイダンスのコンテンツ領域は、この拡張ポイント用のメソッドに対する最新ガイダンスを提供します。通常、この拡張ページの最初のコンテンツは、この特定の拡張ポイントについての専門知識を持った別のプロセス・エンジニアが作成します。この領域のコンテンツは、例えばツールやその入手方法に関する最新情報であり、この拡張ポイントをより効果的に実行するために使用することができます。またこの協調型の領域をユーザー (実務者またはアーキテクト) が編集することもできるため、フィールドから得られた教訓や入力を取り込むことができ、従ってこの拡張ポイントに関してユーザーが学んだベスト・プラクティスやフィールドでの教訓を最新の情報に保つことができます。この協調型ガイダンス領域を Web 2.0 で実装した一例がウィキです。
動的コンテンツ領域
動的コンテンツ領域は、この拡張ポイントによって記述されたタスクをユーザーや実務者が実行できるように、アセットや成果物を動的に提供します。こうした種類のアセットや成果物に含まれるものには、ソーシャル・ブックマークや、サブジェクトに関する専門的な情報 (インスタント・メッセージによる情報を含む)、文書、刊行物、プレゼンテーション、多様な媒体による配信コンテンツ (ポッドキャストやムービー)、教育資料 (ブログやオンライン・コースの資料、クラスを含む) などがあります。この領域の情報は動的であるため、システムは実務者が必ず最新の情報を得られるように、実務者がページを要求したときにコンテンツを構築します。この動的コンテンツ領域を Web 2.0 で実装した一例が集約型 Web フィードです。
静的メソッドのプロセス・エンジニアは、その静的メソッドの中で識別される各拡張ポイントに対して繰り返し拡張ページを作成します。
この手法をメソッドの作成に採用すると、ユーザーが特定のページを要求した時、そしてコア・メソッド・コンテンツ以外のさまざまなソースからの情報を含めた時に、自動的に動的コンテンツが構築されます。この動的コンテンツを、単にメソッドの作成者 (プロセス・エンジニア) が提供するだけではなく、実務者が提供することもできます。この動的コンテンツは作成したメソッドからアクセス可能であり、インターネットやイントラネットに分散されているわけではありません。
図 2 はメソッド・コンテンツが存在する場所を表しています (トポロジー・ビュー)。コメントを読む場合には、コンサルタントのローカル・マシン (Consultant’s local machine) から開始し、下から上に読むのが最適です。
図 2. 協調型で動的なメソッドの構造
こうした手法をソフトウェア・メソッドの開発に採用する利点は以下のとおりです。
- メソッド・コンテンツは特定バージョンのメソッドに付属しているものに制約されません。
- メソッド・コンテンツを常に最新の内容に保つことができます。
- プロセス・エンジニアだけではなく、実務者もメソッドに対するコンテンツを提供することができます。
- 実務者は凍結されているメソッドの新バージョンをダウンロードする必要がありません。
- コンテンツは、エンジニアリング部門に許された時間や予算、人員数の制約の中で作成されるもののみに制限されません。
- 多様な媒体による革新的なコンテンツ (例えば、あるトピックに関する専門家や、ポッドキャスト、Flash ムービーなどのリスト) を容易にメソッド・コンテンツの中に統合することができます。
- メソッドは、凍結された (静的な) コア・コンテンツと、組織やコミュニティーがコンテンツの拡張やカスタマイズを行える部分の両方を含むことができます。
- 実務者は対象のトピックに関する専門家を容易に見つけることができます。
この種のメソッドの実装では、
- 静的メソッドの中で、拡張可能なポイントを識別します。
- そうした拡張ポイントから、協調的な方法で構築される動的コンテンツへのリンクを提供します。
- 各リンクに対して、次の 2 つの領域を持つウィキ・ページを提供します。
- 最新の、編集可能なテキスト情報
- ソーシャル・ブックマークや人間、アクティビティー、ブログ、あるいはアセットなどに関する、動的に追加される Web フィード
この種のメソッドが、ある特定の SOA (Service-Oriented Architecture) 分析シナリオに対して、どのように動作し、実装されるかを以下に示します (図 3 を参照)。
図 3. 協調型で動的なメソッドの実装
このメソッドの使い方の例は次のとおりです。SOA プロジェクトのソフトウェア・アーキテクトが現在、ある SOA システムの分析に携わっています。SOA でのコア・アクティビティーの 1 つに、サービスの識別と呼ばれるアクティビティーがあります。SOA プロジェクトは元来非常に複雑であり、また現在は SOA とは何かが理解されつつある過程にあるため、SOA のアクティビティーと、そうしたアクティビティーをサポートするツールを完全に理解しているのは、ごく少数の実務者にすぎません。
静的メソッドが、こうしたアクティビティーのベスト・プラクティスに関して、さらにはこうしたアクティビティーを合理化できる可能性のあるツールに関して、最新のコンテンツを含む可能性は非常に低いと言えます。この問題に対応するためには、ベースとなるメソッドの中で拡張ポイントを識別します。静的メソッドが HTML で描画される場合、これらの拡張ポイントはこのメソッド内部のからのハイパーリンクです。この例では SOA アーキテクトがサービスの識別を行っています。この静的メソッドには、サービスの識別に関するガイダンスの概要と、サービスの識別に使われた特定のツールに対して協調的な方法で構築された動的コンテンツへのリンクが含まれています。このリンクによってアーキテクトを協調型の Web サイト (この拡張ポイント専用のウィキなど) に導くことができます。
ウィキの実装
ウィキのサイトには、次のような 2 つの領域が含まれます。
協調型コンテンツの領域
1 つ目の領域は、(アクティビティーを一貫性のある合理的なものにするために) サービス識別ツールによって提供される最新の情報を含んでいます。この領域は協調型の領域なので、SOA アーキテクトはこうした情報を編集して最新の状態を保つように求められ、また (ツールに関連した) フィールドでの経験に基づく開発に関する最新の考え方を提供するように求められます。
動的コンテンツの領域
ウィキ Web サイトの 2 つ目の領域は、この特定の拡張ポイントのアーキテクトに関係する動的コンテンツを Web フィードの形で提供します。サービス識別用の拡張の場合、この領域にはサービス識別に関する動的コンテンツが提供されます。この動的情報は、この特定の拡張ポイントに関連付けられた一連の固有のタグによってフィルタリングされます (例えば、サービスをモデリングするためのアクティビティー用のタグであれば、services modeling や service-modeling など)。そのように配信される動的コンテンツには、次のようなものが含まれます。
- ソーシャル・ブックマークや、サービス識別に関するサブジェクトの専門的な情報 (インスタント・メッセージによる情報を含む)
- アセット・リポジトリーから得られる再利用可能なアセット (ドキュメンテーション・パターンや、さらにはサービス識別のためのツールなど)
- 多様な媒体によるコンテンツ (技術的な内容のプレゼンテーション、ムービー、ポッドキャストなど)
- 教育コンテンツ (ブログ、コース資料、その他の読み物、IBM Redbooks® など)
- サービス識別に関する拡張ポイントを適切に完成するためにアーキテクトが従う必要のあるアクティビティー
これを実現するためには、こうしたすべての動的コンテンツを、RSS あるいは Atom のフォーマットで配信される Web フィードによってウィキに埋め込みます。上記の動的項目にはそれぞれ独自の Web フィードがあり、これらのフィードを集約することで、あらゆる動的コンテンツを提供することができます。これは既に可能であり、また例えば Web 2.0 技術とタグをベースに標準化することで、サービス識別に関連してアセット・リポジトリーの中にチェックインされるすべてのコンテンツは、サービスの識別と動的メソッドというキーワードを持つタグになります。ある項目が、これらのキーワードを使って Web フィード対応のアセット・リポジトリーにチェックインされると、アセット・リポジトリーが提供する Web フィードは自動的に更新されます。サービス識別の拡張ポイントに対する拡張ページが更新されると、更新されたコンテンツを、そのメソッドに関する実務者 (アーキテクト) が利用できるようになります。これは、他の動的フィードに対するすべてのコンテンツにも同様に行うことができます。
まとめ
この記事では、協調型で動的なメソッド・コンテンツを Web 2.0 技術を使って構築するための方法を説明しました。この方法は、ある (ソフトウェア開発) メソッドの拡張ポイント専用の一連のタグを利用して、コンテンツとコンテキストを動的にマッピングする、という考え方を活用しています。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | John Boyer は IBM Software Group の SOA プログラム・マネージャーです。彼は Java や J2EE、C++ などのシステムの設計や開発に幅広い経験を持っています。現在はソーシャル・ソフトウェアをソフトウェア開発と学習のアクティビティーに統合するための業務に従事しています。 |
| 
| | Bertrand Portier は IBM Software Group のSOA Advanced Technologies の IT アーキテクトです。彼は戦略的な SOA 変換プロジェクトの分野での経験を生かしながら IBM Software Group の開発チームと協力して業務を行っています。彼は J2EE や Web サービスに携わってきており、現在は ABD や MDD に深く関わっています。 |
| 
| | Eoin Lane 博士はシニア・ソリューション・エンジニアであり、またリーダーとして、IBM の SOA に関する重要プロジェクトからアプリケーション・パターンを取り出し、開発し、そしてこれらのパターンの採用を促進するために IBM のパターン・ガバナンス・プロセスを推進しています。彼は SOA 開発を実現するためのモデル駆動開発 (MDD: Model-Driven Development)、アセット・ベース開発、Reusable Asset Specification (RAS) の専門家でもあります。 |
記事の評価
| 
