Roger Sessions

2006 年 4 月

適用対象 :
   アプリケーション アーキテクチャ
   分割と反復

概要 : Roger Sessions が、分割と反復、確率論の教訓に基づいたプロセス、および戦争の戦略を使用して、効率のよいエンタープライズ アーキテクチャを作成するためのガイドラインを紹介します (印刷版では 26 ページ)。

目次

はじめに
エンタープライズ アーキテクチャの定義
エンタープライズ アーキテクチャの歴史
公的機関のケース スタディ
民間部門のケース スタディ
複雑さ
複雑さのモデル化
分割
反復
分割と反復
既存のエンタープライズ アーキテクチャ フレームワーク
分割と反復の利点
成功するための鉄則
まとめ
用語集
参考資料

はじめに

エンタープライズ アーキテクチャは、効率よく機能している場合は、テクノロジをさらに活かす効果的な方法を見つけるうえで非常に貴重な資産となります。反対に、その効率が悪い場合は、組織の貴重なリソースを消耗させ、生産性を大きく低下させる可能性があります。残念なことに、逆効果になっているケースがあまりに多すぎるのが実情です。

しかし、エンタープライズ アーキテクチャが効率よく機能する場合に得られる利点を無視するわけにはいきません。利点には、コストの節減、収益の増加、プロセスの改善、ビジネス チャンスの拡大などがあります。同時に、エンタープライズ アーキテクチャの効率が悪く、悪循環に陥るリスクも無視できません。たとえば、巨額の経費、技術面での行き詰まり、役員に対する信頼の失墜などです。

しかし、あきらめないでください。これらの問題を回避しながらでも、上手に活用することは可能です。このペーパーで、その方法を説明します。確率論と戦争の戦略という関連性のない 2 つの分野から、エンタープライズ アーキテクチャに取り組む方法に関して、重要なヒントをいくつか解説します。

確率論からは、複雑さの性質について重要な教訓を学びます。これまでに多くの人たちが、エンタープライズ アーキテクチャを作成しようと、さまざまな努力を繰り返しては失敗してきましたが、その主な理由は複雑さを管理できないことにあります。エンタープライズ アーキテクチャの方法論はいくつかありますが、有意義な方法で複雑さの管理に取り組んでいるものは、ほとんどありません。しかも、今日の組織のアーキテクチャは、極度に複雑になっています。

それでは、複雑さはどのように管理すればよいのでしょうか。その答えは、"戦時における戦略" という意外な分野にあります。50 年前に空中戦を戦い抜いた戦闘機のパイロットが学んだ教訓に、今日の複雑なエンタープライズ アーキテクチャを構築するための重要な鍵が秘められているのです。

最後に、その内容を優れたエンタープライズ アーキテクチャを開発するための一連のガイドラインにまとめます。このようなエンタープライズ アーキテクチャは、組織にとって高コストの厄介な存在ではなく、重要な資産となります。

エンタープライズ アーキテクチャの定義

エンタープライズ アーキテクチャについて論じるにあたり、最初に "エンタープライズ アーキテクチャ" を定義しておきましょう。

カーネギー メロン大学 (この分野におけるリーダー集団の中心地です) によると、エンタープライズ アーキテクチャの定義は、次のとおりです。

ビジネス構造、およびビジネス構造を互いに結び付けるビジネス プロセスを記述するための手段。[CMU]

明瞭な定義ではありますが、エンタープライズ アーキテクチャの開発にありがちな高コストについても、このような過程を経るビジネス上の正当な理由についても触れていません。

Wikipedia は、さらに踏み込んで、次のように定義しています。

組織のプロセス/情報システム/人事や部門などの構造と機能を包括的かつ厳密な手法で記述する手法であり、それによって組織がその戦略的目的に沿って機能するように方向性を与えるものである。[Wiki]

Wikipedia の定義の方が、数多くの今日のエンタープライズ アーキテクチャ方法論の複雑さを、的確に表しています。全体をさらに的確に表しているのは、米国政府の Office of the CIO による定義です。

戦略的な情報資産の基盤。これにより、ビジネス、ビジネスの運営に必要な情報、ビジネスの運営をサポートするために必要な技術、および絶えず変化するビジネス ニーズに応じて新技術を実装するために必要な過渡的なプロセスが規定される。[Gov]

エンタープライズ アーキテクチャのコストが高い理由が、徐々にわかってきたでしょうか。記録すべき情報は大量にあります。

一般的なエンタープライズ アーキテクチャの構築費用は、主に次の 3 つの要素で占められています。

• 包括的な分析に必要な、膨大な時間
• プロセスに投入される、多数の内部の管理職スタッフ
• 複雑な方法論を導入するための、高額なコンサルタントたち

しかし、他の方法がないわけではありません。私の定義は、次のとおりです。プロセスを改善するためのヒントがいくつか含まれています。

エンタープライズ アーキテクチャとは、組織の目標、その目標をビジネス プロセスで実現する方法、およびこのビジネス プロセスを技術を通じて支援する方法を記述したものである。

多くの人が、私の定義では不十分だと思うことでしょう。しかし、それは誤解です。私の定義では、企業の目標は、あらゆるビジネス プロセス、ソフトウェア システム、および組織全体に存在するデータベース レコードを完全に記録することではありません。むしろ、私の定義ではもっと現実的な目標、つまりビジネス価値を高めるために技術を活用するチャンスを見つけ出すことを想定しています。

ビジネス価値を高めることが、エンタープライズ アーキテクチャの究極の目標でなければ、そのようなエンタープライズ アーキテクチャの作成に投入されるエネルギーは、大きな無駄となります。コストと時間のかかるプロセスを経ずにこの目標を達成できるなら、もちろん "それに越したことはありません"。

私のアプローチが他の人々のアプローチと違う点の 1 つは、"アーキテクチャ" という言葉で始まっていることです。アーキテクチャという言葉には、"青写真" の意味もあります。青写真には指示がすべて盛り込まれています。建物の屋根と壁のつながり具合から、配管のレイアウトや壁のコンセントの配置に至るまで、すべてが青写真で指定されます。エンタープライズ アーキテクチャの場合には、ここまで詳しくする必要はありませんし、適切でもありません。

技術を使用してビジネスの価値を高める方法を検討する際には、次の質問に答える必要があります。

• ビジネスの全体的な目標は何か。
• ビジネスにより自律的なプロセスを導入するには、どう組織化すればよいか。
• ビジネス プロセスは互いにどのように関連し合っているか。
• テクノロジにより改善を見込めるビジネス プロセス (またはプロセス間の関係) はどれか。
• これらの改善はどのように計画すればよいか。

このアプローチでは、"完成したエンタープライズ アーキテクチャ" などというものはないことに注意してください。むしろ、エンタープライズ アーキテクチャは、技術の活用法を導く、絶えず変化し続ける文書の集合なのです。そういう意味では、建物の青写真よりも都市計画に近いと考えられます。

エンタープライズ アーキテクチャを初めて都市計画にたとえたのは、Armour という人で、1999 年のことでした [Arm]。この比喩は、まさに今日の極度に複雑な組織の状況を表しています。

都市計画は、建物の青写真よりさまざまな問題に取り組んでいます。都市計画が取り組んでいる問題には、次のようなものがあります。

• 特定のゾーン (ビジネス街や住宅街など) に許可される建物の種類
• 建築物を都市のインフラに接続する方法 (配管や電気など)
• 建物がそれを取り巻く環境に及ぼす影響 (大気の汚染度や交通の流れなど)
• 建物の居住者を危険から守る基準 (耐火性や耐震性など)

都市に建設されるあらゆる建物の詳細な青写真が、都市計画にすべて盛り込まれたらどうなるかを想像してみてください。そのような計画は、あまりにコストがかかりすぎて実現できないでしょうし、仮に完成したとしても、柔軟性に欠け、息が詰まりそうです。考えてみると、私がこれまでに見てきたエンタープライズ アーキテクチャには、そのようなものもありました。

エンタープライズ アーキテクチャの歴史

エンタープライズ アーキテクチャという分野が誕生したのは、一般に 1987 年発行の『The IBM Systems Journal』の記事「A framework for information systems architecture」(J. A. ザックマン著) であるとされています [Zac]。後に、ザックマンは、自ら提唱した "情報システム" フレームワークという名称を "エンタープライズ アーキテクチャ" フレームワークに改めました。今日では、このフレームワークは単に "Zachman Framework" と呼ばれています。

1994 年には、米国国防総省が Technical Architecture Framework for Information Management (TAFIM) を初めて導入しました [TAF]。TAFIM は、すべての防衛業務に対する新しいエンタープライズ アーキテクチャの基準となる、と布告されました。TAFIM は何度か繰り返された後に、最終的に 2000 年に廃止されました。

TAFIM は既に廃止されていますが、その一部は The Open Group Architectural Framework (TOGAF) に採用されました。TOGAF は The Open Group が管理する "オープン ソース" のフレームワークであり、現在のバージョンは 8.1 です。今日、民間部門で最も普及しているエンタープライズ アーキテクチャのフレームワークは、おそらく TOGAF であり、僅差で Zachman が 2 位となっています。

1996 年には、エンタープライズ アーキテクチャの分野が、米国の連邦議会から強力な後押しを得ました。同年、連邦議会は Clinger/Cohen 法を可決しました。この法律は Information Technology Management Reform Act (ITMRA) とも呼ばれています。この法律により、大統領府行政管理予算局 (OMB) に、"執行機関が情報システムのために行った大型の設備投資事例すべてのリスクと結果の分析、追跡、および評価" に関するさまざまな基準を規定するための幅広い権限が与えられました。[Cli]

Clinger/Cohen 法では、各執行機関に最高情報責任者の設置を義務付けていました。最高情報責任者は特に、"既存の情報技術の発展または維持、および新しい情報技術の獲得を行うための統合フレームワークを実現する手段の開発、維持、および推進" を担当します。この情報技術は、その執行機関の戦略上の目標、および情報資源の管理目標を達成するためのものです。[Cli]

不思議なことに、Clinger/Cohen 法は、エンタープライズ アーキテクチャの概念には触れていません。それでも、OMB はこの法律を、米国政府全体に適用される全般的なエンタープライズ アーキテクチャ フレームワークを実現するための公式の命令と解釈しました。このフレームワークは、Federal Enterprise Architectural Framework (FEAF) として知られるようになりました [FEA]。今日では、各執行機関 (法務省から国土安全保障省や農務省に至るまで) は、エンタープライズ アーキテクチャを開発し、そのアーキテクチャが FEAF とどのように整合するのかを示すよう、OMB から要求されています。

したがって、Clinger/Cohen 法の実質的な結果として、米国政府により、または米国政府のために行われる IT 関連作業はすべて、少なくとも理論上は、1 つの共通するエンタープライズ アーキテクチャの支援を受けて行われています。

公的機関のケース スタディ

Clinger/Cohen 法では、連邦政府のエンタープライズ アーキテクチャの使用が義務付けられた (または、少なくともそう解釈された) だけでなく、アーキテクチャの効果を定期的に監視して報告することが義務付けられました。その結果、大規模なエンタープライズ アーキテクチャが実際に稼働するようすを観察する貴重なチャンスを得ることができたのです。

これは実質的に、単独組織としてはおそらく世界で最も複雑な組織である米国政府による、全面的なエンタープライズ アーキテクチャ (FEAF) の使用という大規模なケース スタディとなります。さらに、FEAF は TOGAF と Zachman の両方の影響を色濃く受けているため、FEAF から学んだ教訓を、これら 2 つのエンタープライズ アーキテクチャ フレームワークにも当てはめることができます。

米国政府では、どんな効果が上がっているでしょうか。

明らかに、あまり効果はありませんでした。1 か月もたたないうちに、米国政府の独立監視機関である会計検査院 (GAO) が、少なくとも 1 つの機関の情報技術に関して、厳しく批判するレポートを発表しました。政府機関の重要度が高くなるほど、IT 分野で大きな失敗を犯す可能性が高くなるようです。

2005 年 11 月に、GAO は国税庁 (IRS) に関する以下の IT 問題に言及しました。

日々の意思決定に必要な、正確で有益な情報をタイムリーに生み出すことのできる適切な財務管理システムがないために、IRS の管理に深刻な課題が生じており、IRS の現在の財務管理システムが原因で、財務管理と運用上の問題に取り組む IRS の機能が阻害されている。この問題は、国家の徴税機関としての責任を果たす能力に悪影響を及ぼしている。[GAO1]

国防総省 (DOD) は繰り返し、批判にさらされています。たとえば、GAO は 2005 年 6 月に、以下のように述べるレポートを発表しました。

DOD の財務管理および業務管理上の大きな弱点により、監査可能な財務情報を生み出す能力だけでなく、幹部と連邦議会が情報を把握したうえで意思決定を行うための、正確で完結した情報をタイムリーに提供する能力も阻害されている。さらに、DOD の主要な業務領域全体に対し、説明責任が適切に問われていないため、財政上の制約が増しているにもかかわらず、年間数十億ドルもの資源が浪費されており、任務の遂行にマイナスの効果を与えている。[GAO2]

よく登場する国土安全保障省 (DHS) も、多くの問題を抱えています。2004 年 8 月のレポートで、GAO は以下のように述べています。

なぜHIPAAは、重要なのでしょうか？

DHS には、適切に定義されたアーキテクチャに当然あるべき重要な要素が、部分的または全体的にすべて欠落している。ビジネス プロセスの記述、そのプロセス間の情報の流れ、および情報の流れに関連するセキュリティ ルールは、それらの要素のいくつかにすぎない。さらに、初回バージョンには少なくとも部分的には重要な要素が存在したのだが、それについても、アーキテクチャ開発のベスト プラクティスに従った方法で入手していなかった。結果として、DHS にはいまだにアーキテクチャの青写真が存在しておらず、現在進行中の業務転換作業を効果的に遂行できず、情報技術資産の財政的支援に投資している数億ドルを抑制することができない。[GAO3]

このような例は、枚挙に暇がありません。FBI は仮想ケースファイリング システムを構築しようとして失敗し、5 億ドル以上を浪費したとして激しい批判にさらされています。FEMA は、あるシステムに 1 億ドル以上を費やしましたが、ハリケーン カトリーナにより効果がないことが証明されました。GAO からの批判の的となった連邦機関のグループとしては、これ以外に、国勢調査局、連邦航空局、NASA、HUD、保健社会福祉省、メディケア、メディケイドなどがあります。

おそらく究極の皮肉は、Clinger/Cohen 法を遵守していないとして批判された機関に、行政管理予算局が含まれていたことでしょう。行政管理予算局は、他の機関が Clinger/Cohen 法を遵守しているかどうかを監視する部局だからです。

連邦政府がエンタープライズ アーキテクチャの価値に関する最も包括的なケース スタディであるとすれば、この現場は悲惨な状態にあると言えます。

民間部門のケース スタディ

民間産業での失敗が大きく報道される可能性は低いのですが、民間部門も公的機関に劣らず、IT 分野で大失敗しています。エンタープライズ アーキテクチャの方法論を主な原因とする、民間部門の失敗としては、以下の例があります。

• マクドナルドは、レストラン事業全体を 1 つにまとめる統合業務管理システムを構築しようとして、失敗しました。そのコストは 1 億 7,000 万ドルです。[Mac]
• フォードは統合調達システムの構築に失敗しました。そのコストは 4 億ドルです。[For]
• KMart は最新鋭のサプライチェーン管理システムの構築に失敗しました。そのコストは 1 億 3,000 万ドルです。[Kma]

Nicholas G. Carr は、ニューヨーク タイムズの最近の記事で、以下の結論を述べています。

民間部門を見ると、ソフトウェアの大失敗が日常茶飯事になっていることがわかる。しかも、プロジェクトが野心的であればあるほど、期待外れに終わる可能性も高くなる。[Car]

IEEE Spectrum の最近の記事には、以下のような悲観的な評価が掲載されました。

ソフトウェアの新規プロジェクトに対する過去 5 年間のすべての投資 (政府系と民間系を含めて) を見てみると、プロジェクトの失敗による米国経済の損失額は少なくとも 250 億ドルであり、750 億ドルに達する可能性もあると思われる。もちろん、この 750 億ドルには、予算オーバーのプロジェクトは反映されていない (ほとんどのプロジェクトは予算オーバーである)。また、納期遅れのプロジェクトも反映されていない (大多数のプロジェクトは納期遅れである)。プロジェクトが中止になった後に最初からやり直さねばならない場合のコストも、何度も修正する必要があるバグだらけのシステムのコストも、この計算には含まれていない。[Cha]

公的機関と民間部門の両方に、ビジネス ニーズと技術ソリューションに対応できず、コストが高くついたエンタープライズ アーキテクチャの膨大な数の失敗例を見ることができます。入手できる証拠から判断する限り、エンタープライズ アーキテクチャは追求する価値がないか、またはエンタープライズ アーキテクチャの作成に採用している方法論に重大な欠陥がある、と結論せざるを得ません。

直感的には、エンタープライズ アーキテクチャは良いものに違いないと思われます。ここで、私が前に与えた定義を再検討してみましょう。

エンタープライズ アーキテクチャとは、組織の目標、その目標をビジネス プロセスで実現する方法、およびこのビジネス プロセスを技術を通じて支援する方法の説明である。

技術を駆使して組織の目標を達成するためのさらに優れた方法を探すという考え方には、議論の余地はありません。そこで、問題の原因は方法論ということになります。

複雑さ

エンタープライズ アーキテクチャのさまざまな方法論の失敗例を理解するためには、エンタープライズ アーキテクチャを作成しようとして失敗した実例すべてに共通する特性を理解する必要があります。国税庁の財務管理システム、国防総省の業務管理システム、国土安全保障省の災害管理システム、FBI の仮想ケースファイリング システム、マクドナルドの業務管理システム、フォードの調達システム、および KMart のサプライ チェーン管理システムという、実に多様なシステムに共通する特性は何でしょうか。

これらのシステムのすべてに共通する特性は 1 つしかありません。それは、"複雑さ" です。これらのシステムはどれも、あまりに複雑すぎます。FEAF、TOGAF、および Zachman の主な弱点は、システムの複雑さを管理できないことにある、と私は確信しています。

困ったことに、複雑さは一時的な気まぐれではありません。IT の未来について、自信を持って予言できることが 3 つあります。

• 複雑さは悪化の一途をたどる。
• 複雑さを管理するアプローチを見つけないと、失敗する運命にある。
• 既存のアプローチは有効ではない。

Richard Murch が InformIT の最近の記事で、簡潔にこう表現しています。

IT のインフラとアーキテクチャがますます複雑になっていくのを放置することは、容認できないことであり、無責任である。この問題の解決に、熟練度の高いプログラマやその他の人材を投入するだけでは、そのうちに必ず混乱状態に陥る。IT ベンダとユーザーの両方が複雑さという問題を解決するまでは、この問題が繰り返し発生し、IT 業界の悩みの種となるだろう。[Mur]

複雑さのモデル化

複雑さをうまく扱うには、まず複雑さを理解する必要があります。そして、複雑さをモデル化できるようになれば、理解において大きく前進したことになります。

複雑さについて私が知っている最善のモデルは、サイコロです。このモデルの利点は、直感的、視覚的、予測可能で、数学的根拠があることです。このモデルの基本原理を "複雑さに関する Sessions の法則" と呼ぶことにします。

システムの複雑さは、そのシステムに発生し得る状態の数の関数です。

サイコロを使って、この法則の重要性を理解しましょう。2 つの任意のシステム、システム A とシステム B の複雑さを比較します (図 1 参照)。システム A は、2 面のサイコロ (つまり "コイン") 1 個で構成されています。システム B は、6 面のサイコロ (つまり普通のサイコロ) 1 個で構成されています。

図 1. システム A とシステム B

システム A に発生し得る状態は、表と裏の 2 つです。システム B に発生し得る状態は、1、2、3、4、5、および 6 の 6 つです。複雑さに関する Sessions の法則によれば、6/2 で、システム B はシステム A より 3 倍も複雑です。数学が苦手でも、これは直感的に納得できます。

一般に、D 個のサイコロで構成されるシステムにおいて、各サイコロの面の数が S の場合、発生し得る状態の数は、S^D となります。この公式を使用すると、他のシステムの複雑さを計算できます。

今度は、システム B とシステム C を比較しましょう。システム B は前と同様に 6 面のサイコロ 1 個で構成されています。システム C は 6 面のサイコロ 3 個で構成されています (図 2 参照)

図 2. システム B とシステム C

B の状態の数は、6¹ = 6 です。C の状態の数は、6³ = 216 です。複雑さに関する Sessions の法則によれば、システム C はシステム B より、216/6 = 36 倍も複雑です。

システム C のサイコロすべてを 1 回投げたときの結果を予想する場合、正しく予想できる確率は 1/216 です。システム B のサイコロを 1 回投げたときの結果を予想する場合、正しく予想できる確率は 1/6 です。両方のシステムについて、繰り返し投げて結果を予想した場合、正しく予想できる確率は、システム C よりシステム B の方が平均 36 倍高くなります。システム B はシステム C ほど複雑ではないため、正しく予想しやすいのです。

分割

複雑さに関するこの基本モデルを使用すると、複雑なシステムを効率よく整理する方法を、ある程度見抜くことができます。

別の 2 つのシステム、システム C とシステム D を比較してみましょう。どちらも 6 面のサイコロ 3 個で構成されています。システム C では、サイコロは前の場合とまったく同じです。ところが、システム D では、サイコロが 3 つに分割されています。この 2 つのシステムを図 3 に示します。

図 3. システム C とシステム D

3 つの区画をそれぞれ独立して扱えると仮定しましょう。つまり、実質的には 3 つのサブシステムが存在し、それぞれがシステム B と同等になります。

システム C の複雑さが 216 になることは、既にわかっています。システム D 全体の複雑さは、(最初の区画の複雑さ) + (2 番目の区画の複雑さ) + (3 番目の区画の複雑さ) となります。各区画の複雑さは今回も、S^D の公式、つまり 6¹ = 6 で得られます。したがって、システム D 全体の複雑さは、6 + 6 + 6 = 18 となります。

この結果に納得がいかなければ、システム C とシステム D の正しさを調べることを想像してみてください。システム C の場合、216 とおりの状態について、正しさを調べる必要があります。システム D では、6 とおりの状態を調べて、最初の区画が正しいことを確認し、別の 6 とおりの状態を調べて、2 番目の区画が正しいことを確認し、さらに別の 6 とおりの状態を調べて、3 番目の区画が正しいことを確認する必要があります。

一般に、P 個の区画で構成されるシステムにおいて、各区画の複雑さの数が C の場合、システム全体の複雑さは、C x P となります。各区画に常にサイコロが 1 個存在する場合、この公式は S¹xD、つまり S x D となります。

それでは、これまで学んだ内容を、分割されたシステムと分割されていないシステム全般に当てはめてみましょう。簡単にするために、各区画に存在するサイコロの数は常に 1 個であると仮定します (システム D と同じ)。そうすると、非分割システム (例 : システム C) の複雑さは、常に S^D となり、分割システム (例 : システム D) の複雑さは、常に S x D となります。

そこで、結局、2 つの公式 (S x D) と (S^D) を比較した結果はどうなるかという問題にたどり着きます。S と D に具体的に値を代入したときの分割公式 (S x D) と非分割公式 (S^D) の計算結果を、表 1 に示します。

表 1. 分割時と非分割時の複雑さの比較

表 1 を使用すると、9 個のサイコロで構成される非分割システムは、同じサイコロの数の分割システムと比較して、はるかに複雑になることがわかります。その比率は 10,077,696 : 52 です。わかりやすく言えば、"複雑すぎる!" です。

表 1 の要点はおわかりでしょう。あるシステムの全体的な複雑さが増加するほど、分割することによってその複雑さが低下する度合いも大きくなるのです。

そこで、複雑さを扱う方法についてのヒントその 1 は、"分割" ということになります。

反復

分割というアプローチを用いて複雑さを低下させた後には、別の決定を下す必要があります。残っている複雑さをどのように分析すればよいでしょうか。選択肢は、"反復" (左から右に) と "再帰" (上から下に) の 2 つです。この 2 つのアプローチの違いは、サイコロが分割された場合の複雑さモデルを見直すとわかります (図 4)。

図 4. サイコロが分割された場合

反復法では、各区画を個別に分析します。たとえば、最初に区画 1 を徹底的に分析します。次に、区画 2 を分析します。こうして、すべての区画を同じように分析していきます。

再帰法では、各区画の水平層を分析します。たとえば、最初に、すべてのサイコロの目が 1 である場合について分析します。次に、最初のサイコロの目が 1 であり、残りすべてのサイコロの目が 2 である場合について分析します。すべての区画について、出る目を調べ尽くすまで、この作業を続けます。

優れているのはどちらのアプローチでしょうか。反復法でしょうか、それとも再帰法でしょうか。

その答えを知るには、空軍大佐ジョン ボイドが探究心を発揮した 1950 年にまでさかのぼる必要があります [Boy]。ボイドは、複雑な IT システムを構築する方法など考えていませんでした。おそらく、エンタープライズ アーキテクチャはおろか、IT システムの話すら聞いたことがなかったでしょう。彼が考えていたのは、空中戦で勝つ方法でした。

空中戦とは、2 人の戦闘機パイロットによる 1 対 1 の戦闘です。互いに自分が撃たれる前に相手を倒そうとします。空軍大佐が勝つことに関心を持っていたのは、当然です。

航空作戦で戦闘機を飛ばすことは、非常に複雑な作業です。パイロットは、さまざまな情報源からの情報を考慮に入れる必要があるためです。これを敵のパイロットから狙われている間に瞬時に行わなければなりません。ボイドの部下であるパイロットが、どれほど複雑な状況に対処しなければならなかったのかは、ジェット機のコックピットを見るとわかります (図 5)。

図 5. ジェット機のコックピット

ボイドは単に空中戦に関心があっただけでなく、特に MiG-15 対 F-86 の空中戦に関心を持っていました。ボイドはパイロット出身の優れた航空機設計者だったので、どちらの戦闘機も熟知していました。彼は、MiG-15 の方が F-86 より優れていることを知っていたのです。MiG-15 は F-86 より速く上昇および旋回でき、距離的な視界も優れていました。

しかし、これらすべてに関して、問題点が 1 つだけありました。ボイドだけでなく、他の大半の航空機設計者も、MiG-15 の方が F-86 より優れていると考えていたのですが、パイロットたちは F-86 の方を好んだのです。その理由は単純です。F-86 は、MiG-15 との 1 対 1 の空中戦では、10 回中 9 回まで勝ったからです。

長い猫はどのように生きる

ボイドはこの問題に興味をそそられました。劣っている戦闘機が、優れている戦闘機に勝ち続けるのはなぜでしょうか。

この異例の事態を解決するためにボイドは、パイロットが空中戦で実際にどのように行動するのかを理解する必要がありました。ボイドはこの点で、有利な立場にありました。自身がパイロットであっただけでなく、史上最も優れたドッグファイターの 1 人だったからです。そのため、問題に関する知識をじかに得ることができたのです。

空中戦を戦うパイロットを考えてみましょう。このパイロットをピートと呼ぶことにします。ボイドは、ピートの空中戦を 4 つの段階に明確に区分することを提唱しました。第 1 段階では、ピートは自分の周囲 (敵の戦闘機も含まれます) の状態を観察します。第 2 段階では、その状態に関して局面を判断します。第 3 段階で、適切な行動を計画します。第 4 段階で、行動します。

つまり、ピートはまず観察し (Observe)、次に局面を判断してから (Orient)、計画し (Plan)、最後に行動するのです (Act)。ボイドは、この一連の流れを OOPA (Observe, Orient, Plan, Act) と呼びました。

(実際には、ボイドの研究に精通している読者なら、彼が自分のループを OODA (Observe, Orient, Deploy, Act) と呼んだことを思い出すかもしれません。しかし、私は 2 つの理由で Deploy を Plan に変更しました。まず、読者が技術分野の人の場合は、OODA をオブジェクト指向設計分析 (Object-Oriented Design and Analysis) と混同する可能性があるからです。第 2 に、ボイドの著作物を読んだところ、"Deploy" より IT 分野で使われる "Plan" の方が、ボイドが本来伝えたかった考えに近いという結論に達したからです。)

しかし、非常に重要な点は、ピートがこれを行うのは 1 回だけではないことです。何度も繰り返し行うのです。実際、彼は、この OOPA の一連の流れを、絶えず繰り返します。そして、もちろん、彼の敵もそうします。それでは、勝つのはどちらでしょうか。ピートでしょうか。それとも、敵でしょうか。ピートが F-86 を操縦していれば、勝つのはおそらく、彼です。しかし、なぜでしょうか。

MiG-15 を操縦しているピートの敵の方が、ピートより OOPA に優れているように思えます。敵の方がピートより視界が利くので、よく観察できるはずです。ピートより速く上昇し、旋回できるので、先に反応できるはずです。ところが、敵は負け、ピートが勝つのです。

ボイドは、空中戦で勝利を収めるための主要な決定要因は、観察、判断、計画、および行動において相手より優れていることではないと結論しました。空中戦で勝利を収めるための主要な決定要因は、観察、判断、計画、および行動において、相手に "先んずる" ことだったのです。つまり、どれほどすばやく繰り返すことができるかなのです。"反復の速度" は "反復の質" に勝ると、ボイドは提唱しました。

ボイドから次の質問は、"F-86 はなぜ、より速く反復できるのか" です。彼が結論として下したその理由は、だれも特に重要だとは思っていなかったことでした。それは、MiG-15 が手動の操縦桿を装備していたのに対して、F-86 は油圧式の操縦桿を装備していたという事実です。

MiG-15 の操縦桿は油圧式ではなかったため、F-86 の油圧式操縦桿を動かす場合より、わずかですが、より多くの物理エネルギーが必要でした。操縦桿を動かし始めた後は、MiG-15 の方が速く旋回 (または高く上昇) できますが、操縦桿を動かすのに必要なエネルギーの量は、MiG-15 のパイロットの方がわずかに多かったのです。

OOPA を 1 回繰り返すたびに、MiG-15 のパイロットは、F-86 のパイロットより疲れていきました。そして、疲れがたまるにつれ、OOPA ループを完結させるのに要する時間が延びていったのです。MiG-15 のパイロットは、戦闘で負けたのではなく、OOPA の繰り返しで負けたのです。

私は、ボイドの発見を "ボイドの反復の法則" と呼んでいます。

複雑さの分析においては、速く繰り返す方が詳細に分析するより、必ずと言ってよいほど良い結果を生みます。

分割と反復

これで、エンタープライズ アーキテクチャの複雑さを管理する方法について、2 つの教訓が得られました。サイコロの研究から、複雑さを "分割する" ことが、複雑さを "減らす" ための鍵の 1 つであることがわかりました。ボイドのジェット戦闘機の研究から、複雑さの区画を分析する最も良い方法は、区画を反復すること、そして反復する際には、完全性より速度を重視すべきであることがわかりました。

それでは、この 2 つの教訓を複雑なエンタープライズ アーキテクチャに適用する方法について考えてみましょう。マクドナルドが作成しようとして (失敗し)、1 億 7,000 万ドルを失ったときと同じような、大規模な業務管理システムを検討します。このシステムを LCBMS (Large, Complex, Business Management System) と呼ぶことにします。LCBMS に次の機能を搭載する必要があるとします。

• 国際人事
• 給与支払い
• 総勘定元帳
• 買掛勘定
• 売掛勘定
• 請求書発行
• 資産管理
• 会計
• 資金管理
• 従業員のポータル

LCBMS の分割方法については、この一覧から、直ちにヒントを得ることができます。LCBMS のために 1 つの巨大な設計を作成してはなりません。国際人事のアーキテクチャを 1 つ、給与支払いのアーキテクチャを 1 つ、という具合に作成していきます。つまり、すべてを 1 つにまとめた大規模で複雑なシステムを作らないということです。規模の小さい単純なシステムを数多く設計するのです。1 つを設計したら構築し、その後に次のシステムの構築を開始します。"分割する" ことにより、全体の複雑さが低下します。"反復する" ことにより、成功する確率が高まります。

アーキテクチャで失敗した上記の例 (たとえば、FBI が失敗した仮想ケースファイリング システムや、マクドナルドが失敗した BMS) はどれも、エンタープライズ アーキテクチャの標準的な方法論 (FEAP、TOGAF、Zachman など) に基づいていたと思われます。これらの方法論ではいずれも、反復は行われません。したがって、失敗したのも当然でしょう。また、失敗が高くついたのも当然です。

以下に示す段階が存在する必要があるという点では、すべてのエンタープライズ アーキテクチャの方法論の意見が一致しています。

• 業務面でのアーキテクチャの設計
• 技術面でのアーキテクチャの設計
• 実装
• テスト
• 展開

従来の方法論では、これらの段階を一度に 1 つずつ踏み、1 つを完成させてから次に進んでいました。そのようすを図 6 に示します。

図 6. 巨大設計のアプローチ

図 6 に示したとおり、従来の方法論は、最初に対象システム (たとえば仮の LCBMS) の詳細な業務アーキテクチャを構成します。次に、技術面でアーキテクチャを作成します。次に、実装します。次に、テストとデバッグ作業を開始します。次に、展開します。これを見ると、最終段階である展開が完了するまで、このプロジェクトには、ビジネス価値が何も関連付けられていないことに注目してください。

この分析から、これらの組織が行うべきだったこともわかります。分割と反復のアプローチを採用すべきだったのです。

分割と反復は、まったく別のアプローチです。分割と反復を実施したようすを図 7 に示します。以前と同じ段階を踏んでいるのに、それが区画ごとに行われていることに注目してください。

図 7. 分割と反復

分割と反復を適用することにより、機能が絶えず先に進んでいきます。1 つの区画が完了しない限り、次の区画には進みません。組織が大規模で複雑な場合は、複数のプロジェクトが同時進行することは珍しくありません。それでも、その件数は最小限に抑えるべきです。初期の反復では、特にそうする必要があります。複数のプロジェクトを同時進行させると、その調整の必要性が増加します。

既存のエンタープライズ アーキテクチャ フレームワーク

標準的な既存のエンタープライズ アーキテクチャ フレームワーク (TOGAF、Zachman、FEAF など) は、どれも同じような過去を持っています。いずれも、オブジェクト指向設計分析 (OODA) の世界から多大な影響を受けています。

これらのフレームワークが OODA 世代にある、という事実は重要です。SOA (サービス指向アーキテクチャ) より古いことがわかるからです。今日の大規模なシステムのほとんどは、Web サービスの各種規格 (SOAP や WS-Security など) による自律アプリケーションの相互運用性の概念に基づいています。この概念は、サービス指向の世界に密接に結び付けられています。サービス指向の世界は、以前のアーキテクチャ フレームワークが作成されたころには、存在していませんでした。

オブジェクト技術の目的は、事業を設計することではなく、アプリケーションを実装することです。その最大の欠点は、複雑さを管理できないことです。

The Royal Academy of Engineering and the British Computer Society が、IT の複雑さに関する 2004 年の大規模な研究で述べたとおりです。

...現状のソフトウェア開発の方法と実践では、複雑化をたどる一方のグローバル分散システムを、理にかなったコストやプロジェクト リスクで管理することに対応できない。したがって、容赦なく進歩するコンピューティング技術と通信技術の能力に対処することが、ソフトウェア エンジニアリング上の大きな問題になっている。[Roy]

大規模で複雑なエンタープライズ アーキテクチャが取り組む必要がある問題には、アプリケーション自体の実装ではなく、アプリケーション間の連携が関係しています。大規模なシステムは、自律的なアプリケーション間の連携 (技術的にはこれが "分割" に相当します) で構成できるという考え方が成熟したのは、かなり後のオブジェクトの時代になってからでした。実際、これが、SOA の時代の決定的な特徴となりました。

SOA の使用は、技術的なレベルでの複雑さの管理に役立ちます。複雑さを管理しやすいレベルにまで下げるために、業務アーキテクチャを分割する必要があるのと同じように、技術面でのアーキテクチャも分割する必要があるのです。現時点では、SOA がこうした技術面での分割を行うための最善のアプローチです。

OODA のフレームワークは反復の概念をサポートしていると言われることがよくありますが、これは分割と反復の反復とは大きく異なります。OODA における反復の概念は、反復に関しては、"再帰" ほど明確ではありません (図 8 参照)。OODA では、簡単に処理できる部分の複雑さを対象とすることにより、システムの複雑さに取り組みます。これでは、システムの複雑さは減りません。一度に対処しなくてはならない複雑さの量を、最小限に抑えているだけです。

図 8. エンタープライズ アーキテクチャに取り組む OODA アプローチ

分割と反復は、2 つの重要な点で OODA アプローチとは異なります。最初に (そして最も重要なことに)、分割と反復では、再帰的処理で複雑さを管理しようとするのではなく、分割することで複雑さを減らします。しかし、第 2 に、分割と反復では、練りに練った計画を犠牲にしてでも、反復の速度を重視します。その理屈は、"計画" より "実践" から多くを学ぶということです。分割と反復のようすを図 9 に示します。

図 9. エンタープライズ アーキテクチャに対する分割と反復のアプローチ

分割は、OODA スタイルの再帰とは根本的に異なるアプローチであり、システムの複雑さに取り組みます。OODA では、複雑さを管理可能な量に分割して、取り組みます。分割と反復では、複雑さに真正面から挑みます。複雑さを管理しやすくする (これは、OODA アプローチ) のではなく、複雑さを全面的に排除することに努めます。サイコロの研究に見た数学的な原理 (機能を分割することによって複雑さを減らす) を適用するのです。

分割と反復の利点

分割と反復では、再帰的な OODA アプローチより、大幅に短期間で価値を手にすることができます。その理由は、システムをセグメント (区画) 単位で提供しているためです。各区画に測定可能なビジネス価値が含まれるように垂直なセグメントを設計している限り、"価値を生み出すまでの時間" (TTV: Time-to-Value) は、反復により短縮されます。

実業界では、TTV は重要な価値基準であり、"投資収益率" (ROI) よりはるかに重視されています。ROI は長期的な目標です。どんなプロジェクトでも、どれほど組織化が不十分で、予算オーバーであり、ビジネス要件から外れていても、立派な ROI を達成することは可能です。ただし、プロジェクトのコストがかなりの長期にわたって償却されるという条件があります。問題は、会社が倒産する前に収益を上げられるかどうかです。

TTV は ROI よりはるかに短期的です。TTV の定義は、人により異なります。私の定義は、"あるプロジェクトの予算承認が降りてから、そのプロジェクトが組織のビジネスに好影響を与えていると役員が感じるようになるまでの時間" です。言い換えると、出費が発生してから、認識できる価値がもたらされるまでの時間の長さです。ROI と TTV は、ほとんど無関係です。

たとえば、経営陣がカスタマ サポートを再編成するために 2 千万ドルの予算を承認するとしましょう。従来の再帰的な OODA アプローチを採用することもできます。その場合、2 千万ドルのプロジェクト全体が完成するまで (運が良ければ完成するでしょう)、認識できる価値は何も得られません。一方で、分割と反復を採用することもできます。その場合には、価値を含む垂直の区画にプロジェクトを分割します。

最初のセグメントは、顧客がオンラインでアクセスできる、使いやすくて有益な情報のライブラリであるとします。この垂直の区画は、残りのプロジェクトが完成するよりかなり前に、認識できる価値を生み出すことができます。ROI がプラスになる前に生み出すこともあり得るのです。たとえば、もし、最初の月のうちに、ライブラリのおかげでヘルプ デスク宛ての顧客の電話の長さが 20% 短縮されたことを示せるなら、それは "価値" を示していることになります。たとえプロジェクト全体の ROI がプラスになるのが、何年も先であったとしてもです。

中止される可能性が高いのは、どちらのプロジェクトでしょうか。明らかに認められる価値を数か月以内にもたらすプロジェクト (分割と反復) でしょうか。それとも、支出と努力を 2 年間注ぎ込んでも、認識できる価値を何ももたらさないプロジェクト (再帰的 OODA) でしょうか。

喫煙に関する最新の統計は、全国的に何ですか

プロジェクトを、常に経営陣の優先順位リストの先頭に置いておくには、短期間に価値を生み出せることが重要です。"去る者は日々に疎し" は、IT プロジェクトにも確かに当てはまる格言です。

分割と反復の 2 番目の利点は、プロジェクトが成功する全体的な確率が高くなることです。これは、これまでの反復作業で学んだ教訓を、今後の反復作業で起こる活動に応用することができるからです。

カスタマ コール センターに話を戻します。たとえば、当面の区画が新しいカスタマ ユーザー インターフェイスを完成しつつあり、今後の反復作業の 1 つにより、コール センターのユーザー インターフェイスが作成されるとしましょう。新しいカスタマ ユーザー インターフェイスを 6 人月で、新しいコール センター インターフェイスを 8 人月で完成できると想定していたとします。ところが、新しいカスタマ ユーザー インターフェイスが完成したところ、6 人月ではなく 9 人月かかったことがわかりました。ユーザー インターフェイスの作成に関係する仕事量の見積もりに問題があるのは明らかです。

これは、過ちから学ぶ良い機会となります。開発者の訓練に必要な時間を少なく見積もっていたことに問題があるとわかったとしましょう。コール センター インターフェイスに取り組むとき、経験豊かな開発者を確実に割り当てるようにすることができます。予想以上に開発ツールが複雑だったのであれば、別のツールに変更することを検討できます。予想以上にプロセスに時間がかかっただけなら、残りのプロジェクトのスケジュールを調整することができます。

重要な点は分割と反復を使用して、問題を早期に、つまり問題がプロジェクト全体に広がる前に見つけ出すことです。しかも、問題を解決できないとしても、少なくともプロジェクトが遅れていることを知って、経営陣が驚く前に、問題を特定することはできます。経営陣というものは、プロジェクトの遅れを喜びませんが、驚かされることはもっと嫌がります。

ほとんどのプロジェクトでは、期待に効果的に対処する� �とが重要な要素です。分割と反復を使うことによって、潜在的な問題に、より容易に対応することができます。そして、現実的に期待できそうなことを、より効果的に役員チームに伝えることができます。

分割と反復の 3 番目の利点は、最高レベルの非常に重要な (そして最も給与の高い) スタッフの拘束時間がはるかに少ないことです。これは、各区画の設計について意見の一致を必要とするのが、その区画に直接関係しているスタッフに限定されるからです。再帰的な OODA アプローチでは、スタッフの大半が設計の決定の大部分に関係しています。しかも、表面上は単純に見える設計の決定なのに、結論に至るまでに骨が折れることもよくあります。

分割と反復の 4 番目の利点は、SOA に自然に対応する設計を得ることができることです。SOA は、OODA アプローチによく見られるような巨大なモンスターではなく、むしろ小さい自律的なサービスで構成されています。この小さい自律的な相互運用サービスは、再利用、コラボレーション、相互運用性、機敏さ、および自動化されたワークフローの点で、OODA の場合よりはるかに柔軟です。

そして最後に、分割と反復では、機能クリープ (当初の計画になかった機能が後からいくつも追加されていく事態) に対して、OODA アプローチよりはるかに優れたソリューションを得ることができます。機能クリープに対処する点で、分割と反復に有利に働く要素が 3 つあります。

• 区画の数は OODA アプローチより分割と反復の方が、はるかに多くなります。その結果、ある特定の区画が自分個人のものであり、スタッフが個人的に、自分が望む機能を組み込める場所はここしかないと思い込む可能性は低くなります。
• 各区画の設計に関与するスタッフの人数は、OODA アプローチより少なくなります。つまり、どの反復作業でも、新機能について意見を求められる人の人数が少ないのです。
• 分割と反復では、OODA の大切な子供とも呼ぶべき投資収益率 (ROI) ではなく "価値を生み出すまでの時間" (TTV) が重視されます。大半の人々は、機能が豊富であれば、ROI がプラスになると考えます。機能が多いということは、それだけ多くの人がそのアプリケーションを使用できることにつながるからです。そのアプリケーションの使用者数が増えれば増えるほど、もたらされる "収益" も増えます。ROI がこのように過度に重要視されているために、必然的に機能クリープに陥ってしまうのです。

しかし、分割と反復の中心である TTV では、結果をすぐに得られることが重視されます。結果をすぐに得るには、期限を設定 (time boxing) する必要があることを、だれもが理解しています。"期限を設定する (time boxing)" とは、機能を重要かつ所定の時間枠内で供給できるものだけに限定することを意味します。その結果、要求される機能を厳しく検討し、本当に必要でなければカットすることをいとわないという気迫が組織内に広がります。

おわかりのように、OODA のエンタープライズ アーキテクチャ方法論から、分割と反復の方法論に切り替えることにより、組織は数多くの大きな利点を得られます。それらを次に示します。

• 数量化できるビジネス価値を、より早く得ることができる。
• プロジェクトが成功して完了する可能性が高まる。
• 以前の成功と失敗から学ぶ機会が増える。
• プロジェクト計画の精度が向上する。
• 技術面でのサービス指向アーキテクチャとの整合性が向上する。
• 機能クリープを予防できる。

このような重要なメリットについて聞けば、アーキテクチャに投入した労力から本当の価値を見いだすことを望む組織は、興味をそそられるはずです。

成功するための鉄則

ここまでに、エンタープライズ アーキテクチャに関する分割と反復の理論と実践の背景について説明したので、今度はこのアプローチでいっそうの成功を収めるために役立つと思われるルールをご紹介しましょう。

ルール 1 : 解決できそうな課題から始める

第 1 段階を踏み出してプロジェクトまたは区画を特定したら、最初にどれに取り組むべきかを決める必要があります。専門家の多くは、リスクの高い方のプロジェクトから始めるように勧めます。その論理は、問題が発生した場合に早期に発見できることです。私は、このアプローチには反対です。

エンタープライズ アーキテクチャの開発において、最初に実行したいことは、成功を見せることです。そうすれば、より大きい目標に向かって弾みがつきます。これは、OODA の方法論でエンタープライズ アーキテクチャを構築しようとして過去に失敗した組織では、とりわけ重要です。

まず、早期の反復作業において最も重要な目標は、信頼を確立することです。信頼を確立する最善の方法は、組織内の皆が理解できる、はっきりと見える成功実績をいくつか示すことです。

区画に優先順位を付ける際に最も重要な要素、各区画の最善の分析方法、および各区画が全体の優先順位に及ぼす影響の概要を、表 2 に示します。

表 2. 区画の優先順位決定の要素

区画に優先順位を付けるための良い方法は、優先順位目標を使うことです (図 10)。優先順位目標では、表 2 に挙げた優先順位に関する考慮事項の 1 つが、1 つの軸に対応します。それぞれの軸には、中心に近ければプラスの測定値が、周辺部に近ければマイナスの測定値が与えられます。

図 10. 優先順位目標

優先順位目標を作成したら、軸ごとに "ショット" をいくつか撮ります。たとえば、この区画の危険度が "中" なら、目標の黄色の領域内で危険軸の上に丸を 1 つ置いてください。完了すると、どの候補プロジェクト (区画) に最初に取り組むべきであるのかを、視覚的に確認できるようになります。

たとえば、2 つのプロジェクトを特定したとしましょう。最初のプロジェクトは、顧客がアクセスできる知識ベースの開発です。2 番目のプロジェクトは、シングルサインオンの手順を作成して、セキュリティを強化することです。この 2 つの区画の優先順位目標を作成します。結果は、図 11 のようになります。2 つのプロジェクトのどちらが "解決できそうな課題" にふさわしいかは、一目瞭然です。

図 11. 2 つの優先順位目標の比較

ルール 2 : 小規模の経済を活用する

エンタープライズ アーキテクチャによくある誤解は、大規模に行うと節約できるという考え方 ("規模の経済") です。この理論によると、十分な数の人々が十分に大きい 1 件のプロジェクトに携わった場合は、必然的に、冗長な部分が多く発生します。このような冗長な部分を排除すると、開発費と維持費が低減します。プロジェクトの規模が大きくなれば、冗長な部分も増えます。冗長な部分が増えれば増えるほど、冗長性を排除するためのチャンスも増えます。冗長性を排除すればするほど、プロジェクト全体のコストは低減されます。

残念ながら、この理論は、プロジェクト管理のもっと基本的な法則、つまり、リソース リターン逓減の法則を無視しています。プロジェクトに関与する人が増えるほど、プロジェクト全体の効率は低下していきます。リソース リターン逓減の法則は、有名なブルックスの法則の必然的な帰結です。フレッド ブルックスは、ソフトウェア開発が遅れている場合にリソースを追加投入すると、プロジェクトがさらに遅れることを、30 年以上前に発見しました [Bro]。この発見や他の知見により、彼は 1999 年にチューリング賞を受賞しました。

事業の適切に定義された区画に取り組んでいるグループの規模が比較的小さい場合は、妥当な時間枠で妥当な仕事をすることができます。区切られていない事業に取り組んでいるグループの規模が大きい場合は、確かに冗長な部分が出てくることでしょう。しかし、このような冗長な部分を見つけ出すためのコスト、それらを排除するための最善の方法について論じるためのコスト、および統一されたアプローチを実現するための設計について合意に達しようと努めるためのコストは、ほとんど例外なく、冗長な部分自体のコストを上回ります。

節約が規模で達成されるのは、事実です。しかし、本物の節約は、大規模ではなく、小規模の場合に達成されるのです。

ルール 3 : 相互運用性は一元化し、実装は分散する

多くの組織では、過度に一元化されたエンタープライズ アーキテクチャを構築しています。よくあるのは、エンタープライズ アーキテクチャのオフィスを作り、広範囲の決定事項に関する権限を与えることです。このように一元化しすぎると、窮屈な形式主義に陥り、プロジェクトが行き詰まることがあります。

エンタープライズ アーキテクチャの組織を一元化することは、確かに必要です。しかし、その中央組織は該当する問題に集中する必要があり、関係のない問題に大きく時間を割くべきではありません。

一般的な経験則は、"相互運用性" に影響を与える決定を一元化すべきであることです。"実装" に影響を与える決定は、分散させるべきです。どの決定がどちらに該当するかがわからないということは、エンタープライズ アーキテクチャの各分野でよく見られる誤りです。

エンタープライズ アーキテクチャで生じる一般的な誤りをいくつか見てみましょう。

• プラットフォーム - ソフトウェアの標準のプラットフォームを定義しようと試みる組織は少なくありませんが、Microsoft .NET、IBM の WebSphere、BEA の WebLogic などの間で意見が割れ、なかなか決着が付かないことがよくあります。これは、努力の対象が間違っています。プラットフォームは実現手段に関する決定にすぎず、それらのプラットフォーム上でのアプリケーションの連携方法には影響しません。プラットフォームが組織の相互運用性の要件を満たす限り、アプリケーション チームには、アプリケーションのニーズのために最善のプラットフォームを選択する自由が与えられるべきです
• データ - 1 つのデータ層を定義し、組織で使用されているすべてのアプリケーションに共有させようと試みる組織が少なくありません。この努力は高くつくことが多く、成功することはほとんどありません。データの格納法は、アプリケーションの実装の細部として取り扱うべきです。
• ビジネス インテリジェンス – ほとんどの組織では、データとビジネス インテリジェンスを、同様に機能するものとして扱っています。データ (顧客をデータベースに格納する方法など) が、実装の細部であるのに対して、インテリジェンス (所定の顧客に対して行ってきたビジネスの内容など) は、組織の資産です。このようなインテリジェンスを共有する方法を決定することは、適切です。インテリジェンスを供給するデータをアプリケーションが追跡する方法を、企業レベルで決定することは、適切ではありません。
• コードの共有 - 多くの組織では、コードを共有することによってリサイクルが達成されると考えています。達成できなかった事例が過去数十年の間にいくつもあるのに、このように考える組織が多いのには驚かされます。所定のプロジェクトが必要とするコードの量を減らす最善の方法は、コードの共有ではなく、機能の委任です (Web サービスのケースなど)。
• Web サービス API - 多くの組織で、相互運用性の実現には Web サービスの使用が不可欠であると考えられていますが、これ自体は正しい考え方です。また、アプリケーションが Web サービス API を使用する方法を標準化すべきであると考える組織も少なくありません。ところが、実際には、Web サービス API は、アプリケーションに関係のあるレベルをはるかに下回っています。アプリケーションは一般に、ベンダ固有のバッファリング層を利用します。たとえば、Microsoft .NET プラットフォームによって提供される Windows Communications Framework 層です。この層の目的は、Web サービス API の複雑さをアプリケーションが理解しなくても済むようにすることです。このバッファリング層は、プラットフォームに固有です。そのため、アプリケーション実装の細部の一部です。

要するに、"エンタープライズ" アーキテクチャは、"アプリケーション" アーキテクチャとは異なるものなのです。アプリケーション アーキテクチャが関係しているのは、"アプリケーション" の設計です。この設計は、そのアプリケーションを所有するグループの責任とすべきです。これは、前述の小規模の経済を達成する方法の 1 つです (「ルール 2 : 小規模の経済を活用する」を参照)。エンタープライズ アーキテクチャ設計者は、それらのアプリケーションが連携し、その結果として組織にさらに優れた価値をもたらす方法について、気を配るべきです。

まとめ

組織が技術を使用して、重要なビジネス プロセスを支援するためのより優れた方法を見つけるのに役立つという点で、エンタープライズ アーキテクチャは、重要なリソースになり得ます。ところが、困ったことに、エンタープライズ アーキテクチャを作成しようとして莫大な資金を投入したのに、限られた、または場合によっては、マイナスの価値しか得ることができない組織が少なくありません。公的機関と民間部門の両方で、数億ドルの損失を出す失敗が頻繁に起こっています。

このように高くつく失敗が頻繁に発生することには、3 つの主な理由があります。第 1 の理由は、再帰的なオブジェクト指向設計分析 (OODA) によるアーキテクチャの方法論に、過度に依存することです。第 2 の理由は、エンタープライズ アーキテクチャを作成するには、組織全体の詳細な青写真を作成しなければならないという誤った考えです。そして、第 3 の理由は、複雑な構造をより小さい、より管理しやすいプロジェクトに分割できないことです。

OODA 方法論が複雑さを管理する能力は、再帰的なアプローチすべてと同様に、限られています。複雑さこそが、今日の極度に変化しやすい組織が直面する課題なのです。

この記事では、エンタープライズ アーキテクチャの構築に対する別のアプローチを提案します。このアプローチは、組織のプロセスを垂直に分割し、それらのプロセスを改善する必要性に優先順位を付けた後に、"価値を生み出すまでの時間" (TTV) に重点を置きつつ、それらのプロセスを反復することに基づきます。このアプローチは、"分割と反復" と呼ばれます。再帰的な方法論とは異なり、分割と反復は複雑さに真正面から挑みます。

この記事では、分割と反復の戦略における 3 つのルールを説明します。それは、次のとおりです。

1. 解決できそうな課題から始めて、"価値を生み出すまでの時間" を短縮することに集中する。
2. 小規模の経済を活用し、プロセスの速さを意識する。
3. 相互運用性を一元化しつつ、実装を分散させ、分割して複雑さを減らす。同時に、機敏に対処してよりすばやく反復することに集中する。

分割と反復に基づくエンタープライズ アーキテクチャへのアプローチには、再帰法に基づくアプローチより多くの利点があります。それらを次に示します。

• 差し迫ったビジネス上の問題を解決するために、技術をより巧みに活用する。
• 複雑なシステムを構築するコストを劇的に削減する。
• ビジネスへの貢献度の高いプロジェクトの技術的な成果を、より早く得ることができる。
• システムの総コストを制御できる。
• 納期の予測の精度が向上する。
• システム全体の成功率が大幅に向上する。

分割と反復は、最もコスト効率に優れたアプローチであり、組織の目標設定、目標のビジネス プロセスでの具体化、およびビジネス プロセスへの技術的な支援を実現します。

つまり、分割と反復を使用すると、ビジネス価値の高い技術面でのソリューションを、できる限り早く、かつ最低のコストで得ることができます。高い価値。最短の時間。最低のコスト。これこそまさに、分割と反復の核心です。

用語集

.NET - Microsoft の製品ファミリー (Web サービスのインフラストラクチャを含む) を表現する包括的な用語。

機敏さ – エンティティ (企業など) が持つ、急激に変化する環境条件にすばやく対応する能力の評価基準。

ボイドの反復の法則 - 複雑さの分析においては、速く繰り返す方が詳細に分析するより、必ずと言ってよいほど良い結果を生む、という法則。ジョン ボイド大佐にちなんで名付けられました。

ブルックスの法則 - ソフトウェア開発が遅れている場合にリソースを追加投入すると、プロジェクトがさらに遅れること。フレデリック ブルックスが提唱したとされます。

Clinger/Cohen 法 - 「Information Technology Management Reform Act」を参照。

コラボレーション – 複数の企業で使用される 2 つのアプリケーションを、プログラムで連携できるようにするプロセス。"相互運用性" の対立概念です。

エンタープライズ アーキテクチャ - 組織の目標、その目標をビジネス プロセスで実現する方法、およびこのビジネス プロセスを技術を通じて支援する方法を記述したもの。

エンタープライズ アーキテクチャ フレームワーク - "エンタープライズ アーキテクチャ" を作成するための方法論。

FEAF - 「Federal Enterprise Architectural Framework」を参照。

Federal Enterprise Architectural Framework (FEAF) - 米国連邦政府が、さまざまな政府機関とその各種 IT システムが互いに関連し合う方法を記述するために使用したエンタープライズ アーキテクチャ フレームワーク。

FEMA - Federal Emergency Management Agency の頭字語。災害対応を担当する米国政府の部門です。

GAO - 「General Accountability Office」を参照。

General Accountability Office - 米国政府内のさまざまな組織の有効性の監視を担当する部門。

Information Technology Management Reform Act - 米国議会が 1996 年に可決した法律で、効果的な戦略とフレームワークを使用して、IT リソースの開発と保守を行うことをすべての政府組織に要求します。

相互運用性 – 1 つの企業で使用される複数のアプリケーションを、プログラムで連携できるようにするプロセス。"コラボレーション" の対立概念です。

IT - 情報技術 (Information Technology)。

反復 – 全体を、より小さくて簡単に処理できる部分の集まりと見なして取り組むプロセス。

反復アーキテクチャ - システムを構築するためのアプローチであり、大規模で複雑なシステムを段階的に設計、構築、および展開します。

反復プロセス – ソフトウェア開発において設計、実装、および再評価の工程をすばやく繰り返す "アジャイル ソフトウェア開発" のアプローチ。結果として、変化するビジネス条件により密接に対応できるシステムを得ることができます (できるとされています)。"ウォーターフォール プロセス" の対立概念です。

ITMRA - 「Information Technology Management Reform Act」を参照。

複雑さに関する法則 - システムの複雑さは、そのシステムに発生し得る状態の数の関数である、という法則。1 つのシステムを構築する際に、2 つの異なるアプローチの複雑さを比較するためによく使用されます。

解決できそうな課題 – 予測した最低のコストで、認識できる最大の価値をもたらす選択肢の部分集合を表す用語。

オブジェクト指向設計分析 - オブジェクト指向の再帰的な分析に基づく、アーキテクチャのフレームワーク。

OODA - 「オブジェクト指向設計分析」を参照。

OOPA - Observe (観察)、Orient (局面判断)、Plan (計画)、Act (行動)。ジェット戦闘機に関連して、ジョン ボイド大佐が初めて提唱したループ プロセスです。ただし、ボイドは自分のループを "Observe, Orient, Deploy, Act" と表現しました。ボイドの説明によると、Observe (観察)、Orient (局面判断)、Plan (計画)、および Act (行動) で構成されるこのループは、反復的に行われ、より速く反復できるエンティティが、より徹底的に反復するエンティティに勝ちます。

分割と反復 - エンタープライズ アーキテクチャを構築するアプローチ。企業は、最初に一連の自律的な垂直セグメントに分割され、次に反復的に分析され、最後に (適切である場合は) さらに優れたビジネス プロセスと技術プロセスを使用して改善されます。

優先順位目標 – 提案された達成目標を、目標として視覚的に表現したもの。目標の中心から放射状に延びた直線が、優先順位を付ける要素を表し、各軸に沿って配置された "ショット" が、この達成目標に対するその要素の相対的な重要度を示します。ショットは各軸上に配置され、目標の中心に近いほど、プラスの影響力が強いことを示します。

Rational Unified Process (RUP) – IBM の Rational ツール スイートの基盤となる、ソフトウェア開発プロセス。

再帰 – 分析において、1 つのシステムが複数のサブシステムで構成されているものとして分析され、さらに、各サブシステムが複数のサブシステムで構成されているものとして分析され、この分析が、論理的にそれ以上分割できない最終システムのセットが特定されるまで繰り返されるプロセス。

冗長性 - 複数のシステム間で機能が重複していること。

投資収益率 – プロジェクトのビジネス価値の評価基準 (パーセント単位)。収益の増加分 (収入の増加または支出の減少のいずれかによる) を、プロジェクトのコストで除算して求めます。たとえば、あるプロジェクトのコストが 10 万ドルで、収益の増加分が 20 万ドルの場合、ROI は 200% です。

ROI - 「投資収益率」を参照。

SOA - 「サービス指向アーキテクチャ」を参照。

サーベンス オクスリー法 – 米国議会が 2002 に可決した法律で、企業による不正な会計処理を禁じています。この法律により、財務データの厳密な監査と、これを遵守しない場合に財務担当者が個人的に責任をとることが要求されます。

サービス - 「Web サービス」を参照。

サービス指向アーキテクチャ - Web サービスの各種技術に基づいて構築された自律システム間の相互運用性を実現するアーキテクチャ。

SOX - 「サーベンス オクスリー法」を参照。

TAFIM (Technical Architecture Framework for Information Management) - 国防総省が開発したアーキテクチャ フレームワーク。2000 年に正式に廃止されました。

期限の設定 (time boxing) – 1 つのシステムに複数の新機能を追加し続けたい衝動を抑えるために、概ね短い納入サイクルを厳格に設定すること。

価値を生み出すまでの時間 - あるプロジェクトの予算承認が降りてから、そのプロジェクトが組織のビジネスに好影響を与えている、と役員が感じるようになるまでの時間。

TOGAF (The Open Group Architectural Framework) 8.1 - The Open Group が管理するアーキテクチャ フレームワーク。

TTV - 「価値を生み出すまでの時間」を参照。

Web サービス - 汎用のメッセージ形式と転送プロトコルによる、他の独立したソフトウェア システムからの要求に応答できる自律的なソフトウェア システム。通常のメッセージ形式は SOAP です。

ワークフロー – レベルの高い作業が完了するにつれ、業務が組織内を流れていくこと (保険金請求の処理など)。

エンタープライズ アーキテクチャの Zachman Framework – 1 つの企業が 30 個のセルとしてモデル化されるアーキテクチャ フレームワーク。各セルは 1 つの考え方と 1 つの抽象的概念の交点です。

参考資料

Arm—『A big-picture look at enterprise architectures』 Armour, F.J. Kaisler, S.H.; Liu, S.Y. in IT Professional Volume 1, Issue 1, Jan/Feb 1999 Page(s):35–42

Bro—『The Mythical Man-Month; Essays on Software Engineering』 Frederick Phillips Brooks.Addison-Wesley, 20th anniversary edition published 1995

Boy— John Boyd については、次の誌面を参照してください。『Genghis John』 U. S. Naval Institute July 1997, pp. 42–47 By Franklin C. Spinney

Car—『Does Not Compute』 Nicholas G. Carr, New York Times, January 22, 2006

Cha—『Why Software Fails』 Robert N. Charette in IEEE Spectrum Sept 2005

Cli— 情報技術マネジメント改革法 (Information Technology Management Reform Act)、第 104 回連邦議会第 2 セッションより

CMU—カーネギー メロン大学 (www.sei.cmu.edu/architecture/glossary.html)

Gov—本引用は多くの文書から参照可能です (www.cio.gov/documents/FINAL_White_Paper_on_EA_v62.doc など)

Fea—FEAF については、多くの文書で言及されています (『A Practical Guide to Federal Enterprise Architecture』( など)

GAO1—『Financial Audit. IRS's Fiscal Years 2002 and 2001 Financial Statements, GAO Report to the Secretary of the Treasury』(2004 年 11 月)

GAO2—『Testimony Before the Subcommittee on Government Management, Finance, and Accountability, Committee on Government Reform, House of Representatives; DOD BUSINESS TRANSFORMATION - Sustained Leadership Needed to Address Long-standing Financial and Business Management Problems』(2005 年 6 月)

GAO3—下院政府改革委員会の技術、情報ポリシー、政府間関係、および国勢調査に関する小委員会に提出された GAO レポート『August 2004 HOMELAND SECURITY Efforts Under Way to Develop Enterprise Architecture, but Much Work Remains』

For—『Oops!Ford and Oracle mega-software project crumbles』 Patricia Keefe in ADTMag, November 11, 2004

Kma—『Code Blue』 David F. Carr and Edward Cone in Baseline, November/December 2001

Mac—『McDonald's: McBusted』 Larry Barrett and Sean Gallagher in Baseline, July 2, 2003

Mur—『Managing Complexity in IT, Part 1: The Problem』 Richard Murch in InformIT, Oct 1, 2004

Roy—『The Challenges of Complex IT Projects』英国王立工学アカデミーと英国コンピュータ学会の作業部会レポート。2004 年 4 月

TAF—米国国防総省『Technical Architecture Framework For Information Management (TAFIM) Volumes 1』–8, Version 2.0.Reston, VA: DISA Center for Architecture, 1994

TOG—TOGAF (The Open Group Architectural Framework) Version 8.1 "Enterprise Edition" は、www.opengroup.org で入手できます

Wiki—Wikipedia (

Zac—『A framework for information systems architecture,』 J.A.Zachman in The IBM Systems Journal, 1987, volume 26, number 3, pages 276–292

著者について

Roger Sessions は ObjectWatch Inc. の CTO であり、これまでに 6 冊の書籍と多数の記事や白書を執筆しました。International Association of Software Architects (www.iasahome.org) の取締役会の一員です。世界各地で開催される数多くのイベントで基調講演者を務め、アーキテクトのコミュニティでセミナーと研修会を開催しています。エンタープライズ アーキテクトと IT マネージャ向けの月刊ニュースレター Architect Technology Advisory (ATA) を書いています。ObjectWatch は、あらゆる規模の組織がエンタープライズ アーキテクチャから最大限の価値を実現できるように、コンサルティングと研修を提供して支援することに特化した企業です。Roger Sessions と ObjectWatch の詳細については、www.objectwatch.com にアクセスしてください。