レベル: 中級 Brian Byrne, Industry Models and Integration Architect, IBM
John Kling, Consulting and Services Architect, IBM
Dr. Guenter Sauter, Information Architect, IBM
Peter Worcester, Services Solution Marketing Manager, IBM
2008年 2月 14日
更新 2008年 10月 01日 重要なビジネス用語が引き起こす混乱、何を意味しているか (意味するべきか) で繰り返される議論、SOA やデータ統合プロジェクトの遅延や後からの変更、もしくは完全な失敗でお困りではありませんか？ 連載「情報の観点から考える SOA デザイン」の第 2 回は、このような誤解をなくすべく、ビジネス・グロッサリーの概念をご紹介します。SOA におけるビジネス・グロッサリーの価値を発見し、定義方法、使用方法を学習して、同僚とより明確なコミュニケーションがとれるようにしましょう。
はじめに
サービス指向アーキテクチャー (SOA) の構築やデータ統合の実施、そしてそれらが継続する期間中、プロセス、サービス、およびデータに関連した用語を定義した共通のビジネス・グロッサリーがないことがよくあります。ビジネス用語の共通定義は非常に重要で、これがないとあいまいさによって多くのデータ統合イニシアチブが複雑化します。「顧客」や「会員」などが何を意味するのか合意していないと、これらの概念に関係するサービスを正しく実装できないだけでなく、すべての関係者がその概念を構成しているデータについて合意している保証もできません。ビジネス・アナリストと技術部門との間で、意味体系、構造、データ構造のフォーマットを含め、プロセス、サービス、およびデータに関して使用される用語について共通の理解を持つことが重要です。
この記事では、SOA の世界におけるビジネス・グロッサリーの必要性に触れていきます。この便利なグロッサリーの定義および利用する方法について説明します。
動機付けと課題
残念なことに、同じ用語の解釈がビジネス専門家、IT 専門家、およびその他の部門間で異なることは非常によくあります。一見同じか似ているように見えるデータ要素の重複コピーが企業内で何度も作られますが、それが存在するデータ・ストアでしかそのコンテキストは有効ではありません。この要素が外部コンシューマーに公開されると、しばしば情報はコンテキストを失い、悪くすると誤解を招いたり無効になったりします。ビジネス・グロッサリーの基本的な価値はここにあります。ビジネス・グロッサリーは、コンテキストがこのデータを使用するすべてのコンシューマーにとって意味のあるものとなるように、データ要素の定義を揃える規約となるのです。
ビジネス・グロッサリーには、データ要素の合意された定義だけでなく、その要素に関連付けられたバリエーションや従属関係もすべて含まれている必要があります。これにより結果として、概念的で論理的なデータ・モデルの定義が推進されます。最終的には、SOA ソリューション内のコンポーネントおよび参加者が、コンテキスト内において調整された、整合性のあるビジネス情報の定義にたどりつくことができます。
サービスが複数のソースから情報を必要とするようなシナリオでは、重複するデータ要素が同じ名前や暗黙の定義を持つ場合があります。これらのデータ要素の定義やコンテキストはそれぞれ全く異なる場合があり、特定のデータ・ストア内、場合によっては関連プログラムによって取り出されたときのみ意味を持ちます。このようなケースにおいて、ビジネス・グロッサリーは、企業全体において 1 つの要素に対し 1 つの整合した共通のビジネス定義および従属関係を与えることにより、このような競合を特定し、解決するのに役立ちます。異なるセグメントのユーザーが「顧客」または「収益」について話す場合にも、それらが何を指しているのか誰もが正確にわかるようになります。
ビジネス・グロッサリーを指定しない場合、次のような潜在的な影響があると考えられます。
- ビジネスの基本的な情報要件が欠落するリスク
- 情報要件が十分に理解されていないプロジェクトを進めることによるコストの増加
- 明確でない要件や誤解されている要件のやり直しにかかる時間の増加
SOA の中では、これらの共通ビジネス定義を明らかにするのは、データ要素の意味構造についてだけでなく、複数のビジネス・ドメインを通じて最も再利用可能なデータをグループ化することについての議論を円滑にする鍵となります。例えば、複数の基幹業務から顧客の詳細情報にアクセスするサービスが必要である、という合意をとることは比較的容易ですが、非常に難しいのは、これらの基幹業務間でどのデータ要素がお客様というビジネス概念に関連するかについて合意を得ることです。もしできたとしても、これらのデータ要素のどれを再利用可能な顧客データ集合の構成要素にするかということや、後続のサービス呼び出しを通じてリトリーブされる補助要素の特定など、まだいくつもの課題があります。ビジネス・グロッサリーがないと、大抵これらの議論はネーミングやビジネス用語についての議論に巻き込まれてしまいます。しかもなお悪いことに、この種の議論は最初の段階で起こることはまずありません。ビジネス用語の精度不足によって、意見の不一致があるという事実が最初の段階では分からないのです。
マスター・データ管理 (MDM)でも、類似した問題が起こります。MDM リポジトリーにデータを提供している複数のソース・システムは、先述のような複数の基幹業務の役割を担っていますが、それぞれマスター・データの意味体系、構造、集約について個々の解釈があります。これらのデータ・セットの意味体系間の差異を明確に理解しないと、単一のマスター・データ・リポジトリーにマッピングすることが難しくなります。ここでも、ビジネス・グロッサリーはこのような状況下でのあいまいさをなくし、結果、複数のソース・システムに対し単一のビジネス定義を実現します。
同様のことがデータ・フェデレーションやデータ統合でも見られます。これらの場合も要件は全く同じ、ビジネス用語でデータの意味を理解する、ということです。これにより、結果として作成されるソリューションはプロジェクトの元々のビジネス目標を確実に満たすようになります。
ケース・スタディー
あるヘルスケア業界のお客様は、さまざまなところで発生する、ある問題に奮闘しています。ミーティングのたびに、必ずどの数字やレポートが正しいかで論争が起きるのです。問題はこの企業にデータウェアハウスが必要なことではありません。事実、データウェアハウスはいくつか既に存在します。しかし、その情報すべてがレポートの際、より大きな混乱を招くのです。例えば、経営幹部は、医療管理部門やセールス部門などのビジネス部門が提示する保健維持機構 (HMO) の会員数が一致するのを見たことがありません。
この企業は、問題の根本原因を解明し、改善方法を提案するのを支援してほしいと IBM に連絡をとりました。オペレーショナル・システムからのデータを集約するのにデータウェアハウスを使用していましたが、「会員」の意味について合意されたビジネス定義はありません。医療管理部門が定義する会員とは潜在的患者であり、医療サービスを受ける資格を持つ加入者とその扶養家族全員です。セールス部門にとっての会員とは、加入者と、契約更新対象である加入者の扶養家族全員です。死亡した加入者の扶養家族は除外されます。つまり、医療管理とセールスでは、ある計画 (地域の HMO など) では会員数が同じになりますが、別の計画では異なります。差異は年によっても異なり、決して同じになることがありません。経営幹部にとっては自分自身のレポートを信頼することができないので、苛立ちを感じることになります。
共通のビジネス・グロッサリーはこの問題に非常に効果的です。単一かつ共通に認められているビジネス上の意味を持つ用語を定義するためです。すべてのレポートで、合意された用語を一貫して使用できるようになります。
ビジネス・グロッサリーの概念
ビジネス・グロッサリーは「データ・ディクショナリー」と呼ばれることもあり、イニシアチブに関連した用語やデータを定義するものです。仕事の範囲や種類によってビジネス・グロッサリーの範囲は変わる可能性があり、(製品や部門ごとの) レポジトリーや情報ドメイン、または企業といった範囲内で用語を定義します。好ましいのは、企業全体の範囲でビジネス用語を定義することで、この場合すべてのプロジェクトでビジネス用語の一貫性を推進できます。
しかし、異なる部門や業務において、同じに見える用語に対し異なる意味体系をあてていることがあることがよくあります。例えば、「住所」という要素が流通部門にとって何を意味するか考えてみましょう。これは恐らく「出荷先」の住所です。一方、会計部門にとっては「請求先」の住所である可能性が高いでしょう。営業およびマーケティングにとっては、「訪問先」または「連絡先」の住所になります。これはかなり単純化した例で、通常は、名前の接頭辞を使用したり 3 つの異なる住所フィールドを使用したりして対処します。それでもやはり、扱っているのがどの種類の住所で、それぞれ何を意味しているのか文書化して特定する手段が必要です。
ビジネス・グロッサリーは、ビジネスの言語、ひいてはプロジェクトの言語を定義します。したがってビジネス・グロッサリーでは、的確な用語について、具体的かつ記述的に定義するよう注意しなければなりません。可能な限り、企業全体で適用される定義にすべきです。ある用語の使い方が部門で異なる場合は、それらの定義を取り込み、適切なコンテキスト (部門) と関連付ける必要があります。
組織が企業規模のビジネス・グロッサリーを構築する際、用語の意味論的定義と表記定義の両方が含まれる場合があります。意味論的定義 は、各用語の厳密な意味の作成に焦点を置きます。表記定義 は、整数、ストリング、日付形式 (データ・タイプを参照のこと) など、IT システムで各用語を表記する方法に焦点を置きます。ビジネス・グロッサリーは、組織において厳密な意味論的定義と表記定義を作成する道のりの一歩です。
どの SOA またはデータ統合イニシアチブにおいても、ビジネス・グロッサリーは、プロセス分解、再利用分析、既存資産の分析といった調査活動中に現われる用語を取り込みます。用語は、プロセス・アクティビティーに関連することもビジネス目標に関連することもあり、特定した個々のソースにおける定義のみで構成される場合もあります。
結果として出来上がるグロッサリー・モデルは、さまざまな構造化分析（ビジネス・モデル、データ・モデル、要件モデルなど）から見つかる成果物にマッピングしています。図 1 は、ビジネス・グロッサリーと他の成果物との関係を示しています。
図1. ビジネス・グロッサリーと他の成果物との関係
グロッサリーが組織に存在しない前提で話を進めると、問題はどうやって構築に着手するかです。実際は、グロッサリーが存在しない場合も、複数の断片的なグロッサリーが企業内に存在する場合も、パターンは非常に似ています。
誰がビジネス・グロッサリーを作成するか?
この問題は、適切なビジネス・グロッサリーを作成するのに必要なロールについての議論につながります。問題となるデータのビジネス定義を把握しているビジネス・アナリストが既にいる組織もあれば、非公式にデータを代々管理しているスチュワードがいる組織もあるでしょう。企業データの大半は、正式な定義や従属関係が関連付けられていないことがほとんどです。最近では、データ・スチュワードと呼ばれる新しいロールを設ける組織が増えてきました。 このロールは通常、ビジネス・グロッサリーの作成と保守を最も頻繁に管理します。
ビジネス・グロッサリーのオーナーは組織によって異なり、同じ組織であってもサイロによって異なります。理想としては、情報ドメインおよびそのオーナーシップは、企業データ/IT のガバナンス構造において定義されるべきです。それと同じ情報ドメインおよびオーナーシップの階層を、ビジネス・グロッサリーに適用できます。このようなガバナンス構造がまだ整備されていない場合は、プロジェクトの終了までに長期的な管理戦略を決定することを視野に入れつつ、SOA プロジェクトの期間中はデータ・アーキテクトがこのスチュワードのロールを担うことになります。すべてのプロジェクトにガバナンス・プロセスを取り入れるか使用することを強くお勧めします。このようなプロセスが企業内にまだない場合は、プロジェクトにガバナンス・プロセスの実装を含める必要があります。
通常、ビジネス・アナリストまたはデータ・スチュワードは情報ドメインごとに指定しますが、さらに細かくソリューションに関わるオペレーショナル・データ・ソースやドメイン、エンティティーごとに指定する場合もあります。同じ人が担当することもありますが、関連データを所有している LOB またはセグメントの人間が担当する場合もあります。1 つのソースに対し、特定の分野に関する専門知識を持つデータ・スチュワードを複数割り当てることも可能です。また、1 つの用語に対し複数のスチュワードを割り当てることが可能です。「顧客タイプ」という用語を例にとってみましょう。マーケティングまたは財務の顧客がいて、顧客関連データにはその部門や部署からデータ・スチュワードが割り当てられています。この例では、「住所」のカテゴリーを指定するために、修飾子を追加するかデータ構造を拡張しなければならない可能性があります。データ・アーキテクトは、必要とされる「住所」タイプを論理的に関連付け、特定する方法を提案してくれるでしょう。これが、用語の定義を推進するのに、さまざまなスキルをもつ人たちでチームを構成するもう 1 つの理由です。ビジネス・アナリストに一任されていると、結果として出てきた見解が後続フェーズにおいて従属するすべての下流工程のニーズと合わなくなる場合があります。
適切な対象分野の専門家 (SME) を見つけて、あらゆるソースまたはソースの一部に対し、データ・スチュワードのロールを割り当てる必要があります。 これを担当する人物は、プロジェクトに含まれる可能性のあるビジネス用語が、ビジネスでどのように使用されるか把握していなければなりません。ソース・データの量やそのデータに関する知識に応じて、複数の人を割り当てることもできます。また、スチュワードはすべての要素間の従属関係や関係について知っているか、またはそれを学習できるようにする必要があります。
データ・アーキテクトは通常は物理的制約やデータ・ソースの構造を把握しているので、彼らがこのプロセスに参加することは大きな助けとなります。データ間の関係や従属関係を決定する際にも助けが得られるでしょう。
SMA、ビジネス・アナリスト、およびデータ・スチュワードのロールの概念は正当ではありますが、これらの担当者は用語の実際のビジネス定義を知るビジネス・エキスパートを探し出し、その用語の最終定義に関与しているすべての人から合意を得るという骨の折れる作業を行わなければなりません。簡単に引き受けられる作業ではありませんし、達成するのに途方もない時間と労力がかかります。このプロジェクトは、単に核となる情報要件の定義を採用するだけではなく、企業全体の範囲にわたってこれらの用語を定義していくものです。すでに述べたとおり、ビジネス・グロッサリーは各要素や用語の現実的な定義に関する、企業全体で合意した契約となります。これにより、データのすべてのコンシューマーが拠り所とする共通の用語が確立されます。これを達成する方法は、企業またはプロジェクトによって異なります。
いつビジネス・グロッサリーを作成するか?
ビジネス・グロッサリーの作成はあまり早くからは開始できないこと、また、単に初期ディスカバリー・フェーズで開始される課題ではないことを忘れてはいけません。ビジネス・グロッサリーは、できるだけ早い段階、例えば要件収集やプロジェクト定義のフェーズで検討したほうがよいでしょう。ビジネス・グロッサリーの範囲は既存のデータ・ストアやデータベースに限定されません。SOA のビジネス・プロセスおよびサービスを記述する際に使用されるすべてのビジネス用語の定義も含みます。グロッサリーの開発をより早い時期にすればするほど、プロジェクトおよび企業全体の用語の一貫性を実現するための基盤が早く確立されます。
ビジネス・グロッサリーは、適用する方法論とは関係なく、初期の調査フェーズ中に確立、開発する必要があります。プロジェクトのフェーズが進む間、ビジネス・グロッサリーの更新は続き、改良されていきます。
どのようにビジネス・グロッサリーを作成するか?
ビジネス・グロッサリーの構築時に、次のステップを検討する必要があります。
- 情報ソースの収集
グロッサリーに入れるビジネス用語は、例えば業界標準や IBM の Industry Models など、さまざまなソースから取得する場合があります。その他一般的なソースとしては、要件に関する文書や既存のデータ辞書、レガシー・ソリューションなども含まれる場合があります。
1 つ以上のシステムを対象にした既存のビジネス・グロッサリーや、業界標準によって定義されたグロッサリーが存在する場合もあります。このようなグロッサリーは、再度検討を行ったうえで、共通ビジネス・グロッサリーに統合できます。
- ビジネス用語の抽出
ビジネス・グロッサリーの最も価値のある特徴は、最も難しいこと、つまり、ビジネス概念に合意に基づいた共通の定義を与えるということです。これは、促進セッションやアンケートを通じた対象分野の専門家へのインタビューから得ることができます。用語の使用範囲の幅を定めるのは、用語の意味を定めるのと同じくらい難しいものです。ビジネスの狭い範囲でしか使われない用語の場合、SME やビジネス・アナリストが既に合意した定義が存在するかもしれません。企業全体で使用される用語を定義する場合は、合意に達するまで多少困難を伴う可能性があります。まずは各人の持つ定義を収集し、次に SME が集まって用語の理解と定義の認識をすり合わせる必要があるかもしれません。この作業の結果、当初 1 つであった用語がすべてのコンテキストを満たすよう、複数の用語に細分化されることがよくあります。これは必ずしもグロッサリー内での懇願を表していません。同じ用語を複数のステークホルダーが全く異なる意味で採用していることがよくあります。明確なビジネス定義がない場合に発生するあいまいさのために問題が解決しないケースです。調査中に、同じ用語に対して複数の異なる要件が記述されているという事実が明らかになり、グロッサリーという形で詳細なビジネス定義を与えることは、これらの要件を区別するきっかけとなります。
ビジネス・グロッサリーの単純な特徴の 1 つは、用語の物理的特徴 (つまり、データ・タイプ定義、制約など)です。これはよく見過ごされがちですが、簡単に得られる情報です。用語によっては、物理構造は必ずしも収集しなければならないわけではなく、後でまたはデータ・モデルを開発する仕様フェーズでも定義できます。ただし、後日追加されるにしてもビジネス・グロッサリーでその情報を保守することには価値があります。これは、マニュアルでも、市場に出ている自動情報分析ツールを使用しても可能です。ツールは用語の物理的特徴を発見するのに役立ち、情報の現在の品質を診断する上でも大いに役立つ場合があります。
- グロッサリーの構築
グロッサリー内で整合性と正規化を維持することは重要です。グロッサリーを組織の自由に育ててしまうと、ビジネス用語がかなり重複する可能性があり、どの用語を削除すべきなのか、グロッサリーにさらなる混乱が引き起こされます。用語をビジネス・グロッサリーに追加する際は、既存用語との重複を判別するために用語をレビューし、それに従ってグロッサリー内の重複や競合を避けるよう調整する必要があります。ただし、これらの競合は、合意した用語の別名として保持しておくこともできます。その場合、ローカルまたは狭い範囲での使用法を追跡できよう、別名のコンテキストを記載しておく必要があります。これにより、ローカルでの使用を望むグループに対処する際に混乱が避けられます。
- 検証
ビジネス・グロッサリーの完成が近いことを示す基準は多数あります。例えば、用語の収束が見えてくると、追加ドメインを通じて指定される新しいビジネス定義がしだいに少なくなっていきます。2 つ目の指標は、すべての主要担当者がビジネス用語の定義に使用するソースが完全であること、さらにそれらの用語すべてがビジネスの概念別に正しく分類されていることを検証し終わった場合です。ビジネス定義の品質も重要なチェックポイントです。ビジネス・ステークホルダーが、用語がビジネスにおいて意味を持ち、正しく分類され、正しいコンテキストを持っていることを検証する必要があります。
適切に編成されたビジネス・グロッサリーは、標準データ・モデル内の要素や関係を確立するのに必要なコアとなる定義を提供するので、標準データ・モデリング・アクティビティーへの有益な情報源となります。ビジネス・グロッサリーが標準データ・モデリング・アクティビティーへの情報源となるにしても、ビジネス・グロッサリーが標準データ・モデルにとって代わるものではないことを認識しておくことは重要です。細分性、形式化、そしてもちろん構造の程度においてかなりの違いがあります。ビジネス・グロッサリーの役割は、明確なビジネス用語を提供することです。論理データ・モデルはその次のステップで、関係、サブタイプ、属性、包含など、データの詳細な構造を分析します。
ビジネス・グロッサリーの更新
ビジネス・グロッサリーは、一度に構築し、その後イニシアチブでの参考資料として使用される静的な文書ではありません。ビジネス・グロッサリーは、生きている反復成果物です。文書であれ、InfoSphere Business Glossary などのツールで保守されるグロッサリーであれ、絶えず改訂され、成熟し続ける成果物であることが求められています。
イニシアチブが初期調査フェーズから後のフェーズに進むにつれて、文書はより成熟し、しだいにビジネス用語の基準として認められるようになります。成果物の基本的な物理構造は、成果物が文書の形をとっていようとツールに取り込まれていようと変わりません。
例
下記は明確に定義されたビジネス・グロッサリーの例で、口座開設の手順を中心としたものです。既存定義の成熟度に応じて、 (例えば、識別フェーズの初期には) すべての用語の定義および価値が完全に定まっている場合もあればない場合もあります。プロジェクトがさまざまな方法論フェーズを通じて成熟するにつれて、グロッサリーも成熟します。ビジネス用語について学習すればするほど、ビジネス・グロッサリーで更新する必要のある情報が増えます。
図2. ビジネス・グロッサリーの例
まとめ
結論として、ビジネス・グロッサリーは、共通の語彙や用語の意味体系および関連する分類法を管理し、定義する最も信頼できる成果物です。データ統合および SOA イニシアチブの重要な開始点であり、単にどの用語がどれということではなく、組織全体でビジネスおよび IT のさまざまなロールの人が SOA の中でどの用語をまとめれば再利用可能な情報構造を形成できるかについて確実に理解を共有できるようにします。配布する情報やその情報の意味が不明瞭のままに、信頼できる情報を配布するようなイニシアチブは存在しません。
参考文献 学ぶために
- この記事で紹介されたトピックについてより詳しく知りたい場合は、この連載（US）の残りの記事をご覧ください。
製品や技術を入手するために
議論するために
著者について  | 
| | Brian Byrne は、分散システムの設計と開発の分野で 10 年以上の経験があり、業種を越えて Industry Models のアーキテクチャーを推進することに 7 年間を費やしました。Brian は現在、IBM の Information Management 組織でアーキテクトを務めています。 |
| | | John Kling は、IBM の Global Business Services 内の Information Services Practice でアーキテクトを務めています。
彼は、データ品質、データ統合、およびマスター・データ管理に重点を置く大規模なお客様との提携業務の指揮を担当しています。
現在は、フォーチュン 500 社の SAP 実装のデータ・チーム・リーダーです。
|
| 
| | Guenter Sauter は、IBM のソフトウェア・グループ内にある Information Platform & Solutions 部門のアーキテクトです。彼は、IBM のマスター・データ管理および情報プラットフォーム技術を越えてアーキテクチャー・パターンおよび使用法のシナリオを推進しています。彼は最近まで、Information as a Service のためのアーキテクチャー・アプローチ、パターン、およびベスト・プラクティスを開発するアーキテクト・チームのリーダーでした。彼は、 IBM の SOA Scenario on Information as a Service の技術上の共同責任者です。 |
| 
| | Peter は 3 年前に IBM に入社しました。その前はほぼ 25 年にわたってアメリカ国防総省、GE Corporate、Morgan Stanley などで働いてきました。彼はこれらの組織で、技術リーダーの立場にあり、Enterprise Architecture および Enterprise Data Integration で貴重な経験を得ました。彼は最初、Information as a Service のアーキテクト・チームの一員として Sr. IT Architect として IBM に入社しました。現在は、IPS Global Services 組織のソリューション・マーケティング・マネージャーとして、MDM ソリューションを専門にしています。 |
記事の評価
| 
