エンタープライズアーキテクトとは

Mike Walker
2007 年 7 月

概要 : エンタープライズアーキテクトの役割は、きわめて流動的で多方面に及びます。IT 関連の問題だけでなく、ビジネスに関連した問題を常に把握することが要求されます。戦略的な構想に沿った作業を通じて、IT とビジネスの連携をできるだけ円滑な形で推し進めること、それがエンタープライズアーキテクトの仕事と言えるでしょう。

はじめに

エンタープライズアーキテクチャは、小規模な試験的設備の段階から成長を続け、企業の重要事案の 1 つとして認識されるまでになりました。コストの削減、機動性の向上、IT 環境の標準化などへの需要が高まる中、エンタープライズアーキテクチャに関連した活動の機会が急増しています。Gartner 社やマサチューセッツ工科大学などの研究機関によれば、プロセス、情報、ソフトウェア全般に見られる複雑化の傾向は、主要企業の CIO (最高情報責任者) が抱える 3 大懸念事項の 1 つと言われています。加えて、IT 管理改革法 (Clinger-Cohen Act、1996 年に制定) や FFIEC ガイダンスに見られるように、行政機関は、業界に対し法令への遵守をより一層強く求めています。これまでも、法令遵守は、エンタープライズアーキテクチャの枠組みを形成する触媒的な働きをしてきました。ここでは、エンタープライズアーキテクトが日々直面している課題についてご紹介します。この記事をお読みになれば、エンタープライズアーキテクトという、IT 業界で日増しに存在感を増している役割についての全体像を把握していただけるでしょう。

こうしたエンタープライズアーキテクトの役割について述べたうえで、IT 業界において、より広く知られている他の役割 (開発者の役割など) と比較します。エンタープライズアーキテクト (EA) の役割は複雑かつ流動的です。この記事を読み終える頃には、エンタープライズアーキテクチャの役割と、それを実践する人々が直面している課題について、より明確に理解していただけると思います。エンタープライズアーキテクトの方はもちろん、これから、エンタープライズアーキテクトを目指そうとしている方も、ぜひこの記事をお読みください。この記事の中のガイダンスは、中堅企業から大企業を想定して書かれています。企業規模によっては一部のガイダンスが該当しない場合もあることをご了承ください。エンタープライズアーキテクチャの戦略、ツール、およびガバナンスに関連した規範的なガイダンスについては、詳しく取り上げません。

"エンタープライズアーキテクチャ" という言葉には、実にさまざまな意味があり、そのすべての側面を把握することは非常に困難です。情報技術の専門家たちの間でさえ、エンタープライズアーキテクチャの捉え方が異なります。エンタープライズアーキテクチャを、さまざまな変動要因 (アーキテクチャ戦略、アーキテクチャパターン、原則、アーキテクチャ設計、ビジネスアーキテクチャ、IT ガバナンスなど) から成る、より体系化された活動と捉える IT プロフェッショナルもいれば、ビジネス、経営、戦略といった側面は無視して、単に技術的な側面のみに注目する IT プロフェッショナルもいます。通常は、エンタープライズアーキテクチャを IT のみの問題として捉えるのが一般的です。多くの場合、エンタープライズアーキテクチャに携わるスタッフは、ビジネスと IT の両方について話し合うことが重要となります。職務上、EA は中立的な立場を取る必要があります。

この記事の構成

この記事では、エンタープライズアーキテクトの日常を紹介します。そのために、この役割が持つ次の側面について簡単に触れておきます。

· EA の役割 – このセクションでは、エンタープライズアーキテクトとは何であるかについて説明します。具体的には、EA に求められるスキルや責任などについて取り上げます。

· 他のアーキテクトとの役割の違い – アーキテクチャにおける EA の存在意義をはっきりとイメージできるように各種の役割と比較します。

· 使用するツール – EA の職務に必要なツールを紹介します。適切なツールを有効活用することが EA にとっていかに重要かを示すシナリオも用意しました。

· 意思決定 – 複雑な意思決定に至るまでの EA の思考過程をたどります。

· 組織における位置付け – EA の組織における位置付けと、プロセスや意思決定に与える影響について説明します。

· 直面する課題 – このセクションでは、EA が日々直面する課題について取り上げます。

さらに、この記事を作成するにあたり、実際の現場で活躍する EA の声を取材してきました。世界の 2 大ソフトウェア企業 Microsoft と IBM の EA です。IBM も Microsoft も、この分野に対して高い関心を持っており、きわめて大きな影響力と経験を有しています。

エンタープライズアーキテクトの役割

EA の活動は日々刻々と形を変え、ときには劇的に変化します。この記事では、エンタープライズアーキテクチャ体系の構造的なモデルについては詳しく取り上げません。その代わり、エンタープライズアーキテクトの役割と責任を詳しく考察することにします。エンタープライズアーキテクトの役割を知ることで、EA が日々直面している課題をより深く理解していただけると思います。

図 1. Gartner 社によるエンタープライズアーキテクチャの定義 (図をクリックすると拡大画像が表示されます)

上の図は、Gartner 社によるエンタープライズアーキテクチャの定義です。残念ながら、この定義は、数ある定義の中の 1 つに過ぎません。エンタープライズアーキテクチャの一貫した定義というものは存在せず、そのことが、業界に混乱をもたらす原因となっています。この記事は、エンタープライズアーキテクチャという言葉を、Gartner 社の定義に基づいて解釈し、執筆しました。

EA には、広範なスキルが要求されます。はっきりしていることは、技術に関する深い知識が必要であるということです。高度な技術的バックグラウンドがあれば理想的です。エンタープライズアーキテクトが手がける範囲は技術にとどまりませんが、絶えず技術的なスキルを磨いておくことは大切です。プロジェクトの細かな部分にまで関与することによって、新しい知識を身に付けることができます。

EA に要求されるのは、技術的なスキルだけではありません。それ以外にも、次のようなスキルが要求されます。

· 人のやる気を引き出す能力 : EA には人のやる気を引き出す能力が求められます。企業をあるべき姿に近づけていくために、人々に働きかけ、そして伝えることが、仕事の大部分を占めます。

· 交渉能力 : 意思決定が下される場で、目的を達成するために、EA の交渉能力が問われることがよくあります。通常、EA は一個人として組織に貢献するものであり、組織的な力は持ちません。

· 正確な判断力 : 迅速かつ慎重に判断する能力が求められます。

· 問題解決能力 : 複雑な問題や前例のない問題に直面する機会が多い EA には、こうした問題を分析し、解決する能力が求められます。

· 大局的な視野 : EA としての役割を果たすには、視野を広く持ち、問題をさまざまな角度から見て、自己の論理的根拠を裏付ける能力が求められます。

· ビジネスの実務的手腕 : 技術が実際のビジネスに及ぼす影響を理解するには、自分の従事する業界について詳しく知ることが必要です。ビジネスに精通することにより、EA に欠かすことのできない信頼を得ることができます。

· プロセス中心の考え方 : プロセスという観点から物事を考えることは、EA にとって不可欠な資質です。実施した作業の成果物はもちろん、その過程にいたるまで、反復可能で再利用可能なプロセスを構築します。

· 対人能力 : EA の仕事は、どうしても人と接する機会が多くなるため、対人スキルが欠如していると、トラブルが生じる可能性が高くなります。

以上、EA に求められるスキルを述べてきました。ここからもわかるように、EA が果たす役割は多方面に及びます。EA の最も一般的な職務は、大規模なプログラム開発を指揮することです。ここでいうプログラムとは、関連する複数のプロジェクトをパッケージとして表現したものと考えてください。通常、プログラムを管理するには、プロジェクトのさまざまな側面を同時に扱うことのできる人が必要です。

"エンタープライズアーキテクトを採用する際に私が望むのは、たぐいまれなコミュニケーション能力を持ち、人間関係を上手にこなすことができ、組織の大きな目標をまかせられる人材だ。強力なアーキテクチャ構築能力を持ち合わせていれば、私はその人物に仕事を委ね、後は状況を見守るだけだ"

- Kathy Watanabe 氏 (Microsoft チーフ IT アーキテクト)

EA の役割は、戦略に沿ったプログラムや大規模なプログラムの構築に限定されません。次に示すような性質の仕事に従事することもあります。

· ガバナンス委員会 : ビジネスパートナー向けにサポートするプロトコルなど、全社的に配備する必要のある組織的な標準や方針についての意思決定を行います。ビジネス、セキュリティ、およびテクノロジについてのきわめて明確な要件があれば、ガバナンス委員会は、それを基にして、反復可能なパターンや組織全体に採用すべきプロセスを判断します。

· アーキテクチャレビュー審議会 : アーキテクチャを承認するかどうかを審議するために別途設置される審議会です。アーキテクチャが組織にとって妥当なものであるかどうかが検討されます。

· テクノロジライフサイクル : 顧客獲得サービスを半年ごとに更新し、サポートする業務分野を毎年 2 つずつ増やしていくなど、個々の技術や標準がどのように変化し、バージョンを重ねていくかを決める職務です。技術や標準を組織内に残すか、段階的に排除していくかを決定する場合もあります。

· ポートフォリオ管理 : エンタープライズアーキテクトは、IT ポートフォリオに関与することはあっても、IT ポートフォリオのオーナーではありません。しかし、実際には、エンタープライズアーキテクトが、IT ポートフォリオの状態の一部または全体に対する説明責任を負うことも少なくありません。このような業務は資産ポートフォリオ管理 (APM) と呼ばれます。EA は、技術に関するきわめて重要な情報を提供し、それらを左右するライフサイクルの見通しを把握します。

· アーキテクチャ戦略 : IT 全般または IT の戦略的部分をカバーする活動です。通常は、現行の状態 ("今はどういう状態なのか")、移行中の状態 ("どのような段階を踏めば目標を達成できるか、そして、それはどのようなものか")、および、将来の状態 ("組織が目指すべき状態とは何か") を把握することが含まれます。

· 戦略的プロジェクトの支援 : 通常、EA は重要な戦略的プロジェクトに参加して、その設計プロセスを成功に導く役割を担います。

エンタープライズアーキテクトと、他の種類のアーキテクトを比較する有効な手段の 1 つは、"広さ" と "深さ" という観点から両者を見比べることです。これは、専門的知識の深さ (Windows インフラストラクチャアーキテクチャをどれだけ深く理解しているかなど) と、責任範囲の広さ (業務分野をどれだけ幅広く理解しているか) との関係を把握するのに役立ちます。

他のアーキテクトとの役割の違い

図 3 に示したように、エンタープライズアーキテクトは、IT 全般に関する知識を持ちながら、ある程度、ビジネスに関する問題にも精通しています。その他の役割と見比べると、EA に求められる知識が他とは大きく異なっていることがわかります。

では、役割ごとの違いを、広さと深さという観点から見ていきましょう。

· エンタープライズ アーキテクト : エンタープライズアーキテクトの守備範囲は、業務分野と各種の IT ドメイン (セキュリティ、インフラストラクチャ、情報、開発など) 全般に及びます。

· ドメインアーキテクト : ドメインアーキテクトは、特定のドメインを中心に活動し、その分野に関する深い知識を持ちます。一般に、ドメインアーキテクトの守備範囲は特定の領域に限定されます。たとえば、ビジネスアーキテクト、セキュリティアーキテクト、情報アーキテクト、インフラストラクチャアーキテクト、コミュニケーションアーキテクトなどがあります。

· 開発者 : 開発者は特定のソリューションに集中して活動し、開発に関する深い知識を持ちます。

図 3. 広さと深さという観点から見たアーキテクチャ上の役割 (図をクリックすると拡大画像が表示されます)

図 3 は、エンタープライズアーキテクトと他のアーキテクトとを比較したものです。実際には、数多くのアーキテクチャ運用モデルが存在します。上に示した役割は、あくまで一例であり、それぞれの関係をわかりやすく示すために用いています。

図 4. 異なる組織構造の例 (図をクリックすると拡大画像が表示されます)

図 4 は、2 つの異なるアーキテクチャ構造モデルの例を左右に並べて示したものです。このような構造モデルは、本来、階層的に区別できるものではありません。むしろ、EA 以前の運用モデルへの対処を意識したものです。これがすべての場合において理想的であるとは言えませんが、組織内での摩擦を回避するために、変化を段階的に導入しなければならない場合もあります。EA の役割もそれによって変わる場合があり、また、組織上および経営上、まったく異なる課題を伴うこともあります。

当然、IT に関する意思決定は、1 つの条件によって左右されるわけではありません。意思決定はさまざまな視点を考慮して行われます。コスト、サポート人員の問題、IT 標準化など、組織的な側面を優先する関係から、技術上のメリットが犠牲になることも少なくありません。

エンタープライズアーキテクトが使用するツール

EA の役割は多方面に及ぶため、この記事では、いくつかの課題に焦点を絞って取り上げています。記事の目的は、エンタープライズアーキテクトの日常を紹介することなので、すべてのツールを網羅することはしません。

EA の役割において重要な問題の 1 つに、目標の達成にとって適切なツールを選択することがあります。開発者よりも高い視点で物事を俯瞰することになるため、EA が日常的に開発ツールを利用することはまずありません。代表的なツールとしては、モデリングツールやコミュニケーションツールが挙げられます。

EA のコンピュータを想像してください。きっと、Microsoft® Windows® のスタートメニューには、次のようなアプリケーションが並んでいることでしょう。

· Microsoft Word/Microsoft Excel ® : アーキテクチャに関する文書やレポートを作成するために使用します。

· モデリングツール (Microsoft Visio® など) : アーキテクチャのモデルを作成するために使用します。

· Microsoft PowerPoint ® : アーキテクチャについてプレゼンテーションを行うために使用します。

· 管理ツール : 社内アプリケーションやポートフォリオ管理ツールなどがあります。

その他のツールは、EA の役割によって異なります。社内で標準的に利用されている EA アプリケーションもあるでしょう。

図 5. 社内で利用されている EA ツール (Forrester Research 社の調査結果より) (図をクリックすると拡大画像が表示されます)

必要なツールが揃ったら、その機能を活かして最適なプロセスを構築する必要があります。プロセスや役割は組織によって異なる場合が多いため、ここではツールの用途に主眼を置いて説明します。

シナリオ : Microsoft ツールの利用とエンタープライズアーキテクチャ

既存のツールを活かす方法は数多く存在します。既存のツールをうまく利用すれば、無駄な労力やコストを減らし、EA としての生産性を大幅に高めることができます。図 6 は、文書化されたエンタープライズアーキテクチャに対するソリューションの例です。アーキテクチャを文書化するにあたっては、標準的な Microsoft Office ツールを利用しています。

図 6. Microsoft Office ツールをエンタープライズアーキテクチャに用いる例 (図をクリックすると拡大画像が表示されます)

このシナリオでは、エンタープライズアーキテクチャを構築する作業の一環として、全社的な取り組みやプロジェクトの現行の状態を収集します。Microsoft Word を使用すると、アーキテクチャに関する情報を収集するためのテンプレートを作成できます。テンプレートに要素を定義することによって、下流のプロセスで、その情報を利用したりワークフローを構築したりすることが可能となります。

データが利用しやすい形式になっていれば、そこからさまざまなプロセスを構築することができます。また、完成した文書の一貫性が保たれるため、IT に関連した意思決定を行う際には、その情報を容易にかつ最大限に活用できます。

情報を一元化することは、アーキテクチャに関するあらゆる情報のレポジトリを作成することにつながります。その結果、セキュリティ、ポリシー管理、情報管理、承認、通知など、企業統治に関連した業務が省力化されます。あらゆる情報が整然と分類されれば、下流の工程では、それをレポートや指標の作成に役立てることができます。

意思決定

エンタープライズアーキテクトが行う意思決定は、複雑なプロセスであり、複数の領域にまたがった判断が要求されます。あらゆる方向を見渡すと共に、どの程度まで関与するかを状況に応じて判断する必要があります。マクロ的な視点が求められる会議もあれば、ミクロ的な視点が求められる会議もあります。

アーキテクチャ上の意思決定を行う際には、それがプロジェクトレベルであろうと、全社レベルであろうと、意思決定プロセスにはさまざまな要因が関係してきます。より重要な事項を優先させるために、妥協点を模索さざるを得ない場合もあります。

図 7. アーキテクチャのトレードオフ (図をクリックすると拡大画像が表示されます)

図 7 に示したように、組織的な要因が、技術上の意思決定に大きく影響する場合もあります。

図 8 を見ると、EA に要求される意思決定が大きく 3 つに分類できることがわかります。組織構造によっては、これとは若干違ったものになる可能性もあります。ただし、いずれの項目も、EA が下す判断の拠り所として重要な意味を持ちます。

図 8. 意思決定の 3 大要素 (図をクリックすると拡大画像が表示されます)

組織的なポリシー

IT ガバナンスを促進する手段としては、しばしば組織全体のポリシーが用いられます。組織は一連のポリシーまたはルールを定義することにより、技術的な慣例として何が適切で何が適切でないかを見極めることができます。正式に評価する段階になっても、IT コミュニティは評価の基準を明確に把握することができます。

全社的に用いられる包括的なポリシーや標準を構築するための委員会に EA が参加し、意思決定を支援することもあります。長期的な戦略と、組織の IT 環境の両面から物事を考察できる EA の知識は、こうした場においても大いに発揮されます。

こうした取り組みは、組織に多大なメリットをもたらします。たとえば、次のような利点が挙げられます。

· IT コストの削減

· ベンダとの良好な関係の構築

· IT の積極的な活用

· アーキテクトや開発者への権限委譲

IT 戦略

戦略を構築することは、エンタープライズアーキテクトの主要な職務の 1 つです。基本的には、次の 3 つの活動があります。

· 将来の状態を定義する ("かくあるべき" アーキテクチャ) : 企業が目指すべき姿を提示します。移行状態のアーキテクチャは、将来の状態がわかってはじめて構築できます。

· 現状のアーキテクチャを把握する ("ありのままの" アーキテクチャ) : "今の姿" を明らかにする活動です。この活動を通じて、現状でうまく行っている部分や企業内で重複している部分を見極め、アーキテクチャがサポートしている主要なビジネスプロセスの状態を評価することができます。

· 移行状態のアーキテクチャを構築する : 移行状態のアーキテクチャとは、目指すべき将来像を具現化する反復的なロードマップを作成することによって、現行の状態と将来の状態との橋渡しをするプロセスです。

図 9 は、IT 戦略のライフサイクルを示しています。一連の活動には順序がない点に注意してください。

"エンタープライズアーキテクトにとって大事なことは、ビジネス上の戦略や目標とのバランスを取りながら技術的な戦略を管理し、実装することである"

- John Adams 氏 (IBM 上級アーキテクト)

変える必要のある事柄を把握するには、現状のアーキテクチャを知ることが欠かせません。ただし、現行の状態を最初の段階として捉えることは避けてください。一見、妥当な方法に見えますが、最終的な目的を見失い、細かな点にしばられてしまう可能性があります。

図 9 に示したように、IT 戦略のライフサイクルは反復的なものです。つまり、いったん現行の状態を把握したからといって、それで終わりというわけではありません。一度に消化できないほどの作業を詰め込むことのないように注意してください。消化可能な細かな単位に分けることが成功の秘訣です。

図 9. IT 戦略のライフサイクル (図をクリックすると拡大画像が表示されます)

将来のアーキテクチャを構築するときには、現行の状態を考慮することになります。将来像を表すモデルが完成すれば、そのモデルを、技術的な意思決定をする際のロードマップとして利用できるようになります。そうして初めて、組織におけるアーキテクチャの変化の状況と展望が明らかになります。その意味で、将来像のモデルは、アーキテクチャの思考過程と意思決定に不可欠なツールと言えます。

移行状態のアーキテクチャには、将来のモデルや計画を実現しやすくする働きがあります。急激な変化を抑え、消化しやすい形で少しずつ組織に変化をもたらします。あらゆる改革を一度に引き起こす "ビッグバン的手法" とは異なり、将来目指す方向へと段階的に移行してゆくことができます。

下流工程における利点としては、成功するかどうかに不安の残る新しいアイデアがあったときに、それをビジネスの中断や財務面の影響を最小限にして試験運用できるという点があります。

将来の状態は、ほとんどの場合、モデルとして文書化されます。図 10 に示すように、モデルとして文書化することによって、複雑なアーキテクチャをわかりやすく表現することができます。

図 10. 主要な Microsoft サーバーの将来のアーキテクチャを示すロードマップ (Gartner 社提供) (図をクリックすると拡大画像が表示されます)

将来のモデルを構築するうえで重要なことは、完成したモデルは、あくまで将来の予測にすぎないという点です。ビジネスは業界の動向に応じて調整され、変化するものであり、予想外の方向に向かう可能性もあります。将来のアーキテクチャを見直しながら明確なライフサイクルを構築することによって、柔軟に対応することが大切です。

プログラムとプロジェクトの意思決定

EA がプロジェクトチームと連携しながら、プログラムレベルやプロジェクトレベルの意思決定を行おうとすると、偏った判断に陥ることがよくあります。特定の業務分野にのみ携わっているプロジェクトチームは、物事を狭い視点で見てしまう傾向があります。このことが、組織全体を総合的に見渡そうとする、EA の判断を鈍らせる原因となります。

しばしば、"このパッケージがどうしても必要なんだ" とか、"絶対うまくいくからいうことを聞いてくれないか" などという言葉が EA にぶつけられることがあります。IT の仕事の 75% はソリューションの保守作業と言われますが、その最たる原因は、意思決定の段階で視野を狭めてしまい、全体像を見据えた判断ができなかったことにあります。

このレベルで的確な意思決定をする秘訣は、作業を振り返りながら、組織のポリシーおよび IT 戦略に沿っているかを確認することです。トレーサビリティ (追跡可能性) を高める効果的な方法は、ポリシーや戦略を構成する 1 つ 1 つの要素を有機的につなげる手段を構築することです。そうすることで、次に示すようなさまざまな利点が生まれます。

· 全社を通じて一貫した IT の意思決定

· 反復可能なプロセスの作成

· 組織全体の戦略に対するトレーサビリティの向上

· 適切な意思決定を可能にするアーキテクトへの権限委譲

· 意思決定プロセスから利害の対立を排除

· 意思決定に対する監査の実現と責任の明確化

· ガバナンスの負担削減

このプロセスを正式なプロセスとするかどうかに関係なく、EA にとって大切なことは、一本の木だけをじっと見つめるのではなく、"森" を見ることです。つまり、一歩下がって全体を眺め、次のような問いを自問するようにします。

· 解決策は本当にそれだけなのか。既存の解決策を再利用することはできないか。

· この問題は "購入か構築か" のポリシーとどのように整合するのか。

· 特定のドメインのみが該当するのか、複数のドメインが該当するのか。

直面する課題

EA の仕事には、技術とは直接関係しない側面も数多く存在します。組織面での考慮事項や障壁が存在することも少なくありません。前述のように、EA が滞りなく仕事を遂行するには対人能力が不可欠です。技術に長けているだけでは十分ではありません。また、強力なコミュニケーションスキルを持ち、ビジネスに精通していること、そして、優れた意思決定能力を備えていることも必要です。

なぜ、それほどまでに組織的な障壁が多く存在するのでしょうか。

· 嗜好の違い : ここでいう嗜好とは、組織が何を支持し、何を支持したがらないかという意味です。たとえば、"ソフトウェアは構築するのではなく買う物である" という組織的な原則が存在するとき、ソリューションを構築しましょうと提案しても、それは、組織的な原則に反するため、支持は得られません。支持を得られるかどうかは、ソリューションを提案するときに必ず考慮しなければならないことの 1 つです。組織内の "政治" も考慮する必要があります。これも、嗜好の 1 つと言えます。

· 成熟度 : EA から出される提案は、高度な概念やアーキテクチャを取り入れた斬新なアイデアとなることが多くあります。しかし、組織内では、教育、インフラ、ソフトウェアの機能といった要因から、こうした新しいアイデアを受け入れるだけの準備が整っていない場合があります。EA は、組織の成熟度をよく見定めることによって、高度な概念やソリューションへと段階的に進化していく反復的な手法を提案できます。

· インセンティブ : 組織的な障壁の典型的な例として、"自分にとってのメリットは何か" という個人レベルまたはチームレベルでの局所的な関心事があります。通常、EA は一個人として組織に貢献するものであり、組織的な力は持ちません。独自の目標に基づいて行動しているチームと連携するとき、組織全体にまたがったアイデアを提案することは難しい場合があります。

複雑な意思決定に加えて、EA に組織的に抵抗しようとする勢力も存在します。こうした勢力が EA のグループに大きな影響を与え、認知度不足を招いたり、EA のグループが解体されたりすることもあります。

EA が直面する主要な組織的障壁としては、次の 3 つが存在します。

· 関係者の賛同 : 階層型の組織に限らず、人を説得することは容易ではありません。連携しようとする人員との間に組織管理上でのつながりがないとなると、目標を達成することはますます難しくなります。戦略やプロジェクトへの賛同を呼びかけたり、重要な活動への協力を得ることは、きわめて困難と言わざるをえません。

· リソース : 業務分野のマネージャが戦略に同意してくれたとしても、資金面や人員面で協力してくれるかどうかは、まったく別の問題です。多くの場合、EA は組織全体をまたいで活動するため、その部門の責任者だけでなく、複数の部門を相手にリソース面の協力を要請する必要があります。まとめると、EA に不足しているものは、大きく次の 2 つに大別できます。

· 予算 : 一般に、EA のグループには、正式な予算というものがありません。有能な EA になるためには、予算が必要になったときに、それを正当化できるだけの説得力が求められます。説得力があれば、ビジネス面や経営面からその正当性を訴えることができます。

· 人員 : プロジェクトには、資金面でのリソースだけでなく、人的リソースが必要です。したがって、EA は、IT グループやビジネスグループに正当性を訴えながら、プロジェクトの人員確保を要請する必要もあります。

· 現行のプロジェクトや既存のプロジェクトへの働きかけ : プロジェクトの先頭に立つことと、既に動き始めたプロジェクトの方向性に影響を与えることは、まったく別の問題です。プロジェクトが既に進行している場合、アーキテクチャの変更に伴う時間的な制約や発生するコストから、チームメンバが EA の意見をなかなか聞き入れないことや、完全に無視してしまうことがよくあります。

図 11 は、エンタープライズアーキテクトが抱えるジレンマとして、Forrester Research 社が調査した結果を抜粋したものです。この図からも、これまで取り上げてきた基本的なテーマのいくつかが見て取れます。組織的な障壁がどのようなものか理解するのに役立つでしょう。

図 11. エンタープライズアーキテクトのジレンマ (Forrester 社の調査結果より) (図をクリックすると拡大画像が表示されます)

賛同の獲得

周囲の賛同を得ようとするときに重要なことは、テクノロジの価値ばかりを声高に訴えようとせず、相手に伝わりやすい言葉で話すことです。多くの場合、ビジネス分野の言葉で話すことになるでしょう。ビジネス分野の言葉で話をすることで、問題を具体化し、その正当性を定量的に立証できます。技術のための変化ではなく、ビジネス上の目標達成に必要な変化であると明確に示すことができます。

"エンタープライズアーキテクチャプログラムを成功に導くために、勤務時間の 50% を組織的な障壁を取り除くことに費やしている"

- Kathy Watanabe 氏 (Microsoft チーフ IT アーキテクト)

この問題を直接解決できるツールはほとんど存在しません。通常は、リソースとツールを組み合わせて使用することになります。その例を次に示します。

· プロジェクトダッシュボード

· IT 環境の状態管理と変更管理に関する統計

· ビジネス分析

· 現状のアーキテクチャの分析

関係者と互いに協力し合いながら正当性を訴えることが大切です。それが関係者の賛同を得ることにつながります。この場合、ポータルツールを使用すれば、戦略やそれに関する事実 (正当性の根拠や指標) を広く公開することができます。

Excel や PowerPoint などのツールも、プロジェクトの必要性を立証するうえで役立ちます。

リソースの確保

重役や統括責任者に "よいアイデアだ" と思わせることができたとしても、資金や人的リソースを確保できるとは限りません。そのリソースがなぜ必要なのかを説明することが、最も大きな課題です。他のだれかがリソースや優先順位、予算をシフトさせなければならない以上、EA は、その正当性を十分に説明できなければなりません。

資金や人員を要請する段階で、"話が違うじゃないか" という事態を避けるためにも、関係者の賛同を得るプロセスには十分な透明性が必要です。

現行のプロジェクトや既存のソリューションへの働きかけ

将来性のある新しいプロジェクトのために関係者の賛同を得たり、リソースを確保したりする業務と、既に始まっている既存のソリューションや既存のプロジェクトに働きかける業務は、まったく異なります。何よりも異なる点は、既にソフトウェア開発ライフサイクル (SDLC) の段階に入ったプロジェクトや、IT ポートフォリオに組み込まれているソリューションなど、既に動き始めた作業に影響を及ぼそうとしていることです。通常、関係者の賛同を得たりリソースを確保したりする業務は、リソース割り当てや資金調達がまだ確定していない計画段階で行います。この場合、作業は開始されている場合もあれば、既に完了していることもあります。ここで重要になってくるのが交渉スキルです。

"役に立つと思っていることでも、なかなかプロジェクトチームを説得できないことも多い。エンタープライズアーキテクチャの概念が浸透していない組織では、特にその傾向が強い"

- John Adams 氏 (IBM 上級アーキテクト)

まず、どうすれば、EA が現行のプロジェクトに割り込む形で、SDLC プロセスに働きかけることができるかを考えてみます。通常、SDLC 関連の用語は組織によって若干使い方が異なります。この記事では、用語の一貫性を保つために Microsoft の SDLC 用語を用いることにします。図 12 は、SDLC プロセス、および、プロセス内の潜在的な接点を示しています。繰り返しになりますが、フェーズごとの特定の名称は、環境によって異なる場合があります。

図 12. SDLC プロセスにおけるエンタープライズアーキテクチャの潜在的な接点 (図をクリックすると拡大画像が表示されます)

EA が SDLC のフェーズに関与できるポイントは複数存在しますが、必ずしもすべてのポイントで関与する必要はありません。EA が関与するポイントとして最も一般的なのは、構想 (Envision) フェーズの最後と、設計 (Design) フェーズの最初です。

それでは、各フェーズについて "EA ができること" を見ていくことにしましょう。

· 構想 (Envision) : 構想フェーズには、プロジェクトの方向性と、購入または開発すべきアプリケーション資産を決定付ける、いくつかの重要なプロセスが存在します。これらのプロセスで注視すべき点は、環境に対してどのようにソリューションを当てはめるか、どのように構築すべきか、および、ソリューションをどのように調達するか (組織内で構築するか、購入するか、あるいは、購入した上でカスタマイズするか) です。ベンダを選択する必要がある場合は、EA にとってきわめて重要な意味を持つ段階です。実際にベンダの選考プロセスが生じる前に、なんらかの助言をすることができます。

· 設計 (Design) : 通常、ミクロレベルの詳細な部分については、ドメインアーキテクトや開発者に頼ることになります。ただし、EA は、あらゆる要素を全社的な構図に当てはめて考え、完成したら全体を俯瞰してアーキテクチャを再確認する必要があります。

· 構築 (Build) : このアプリケーションコーディングフェーズでは、はっきりとした理由がない限り、EA が介入すべきではありません。

· 安定化 (Stabilize) : テストサイクルでは、必ず、アプリケーションになんらかの変更が必要になります。アーキテクチャに大きな変更が生じた場合、EA は十分な正当性をもって、その変更をレビューし、プロジェクトチームに手をさしのべ、正しい方向に導くことができます。

· 展開 (Deploy) : ソフトウェアを環境に展開する段階や、変更管理を導入する段階では、はっきりとした理由がない限り、EA が介入すべきではありません。

· 実稼働 (Production) : このフェーズでは、アプリケーションのメンテナンスを担当するポストプロダクション (開発後の工程) のリソースに対して働きかけることができます。サービスのエンドポイント、または、エンドポイントの管理になんらかの余地があれば、その後のライフサイクルの IT ポートフォリオにどのようにしてテクノロジを組み入れ、バージョンアップを図るか、また、既に確定したアーキテクチャをどのように拡張させていくかなどを検討できます。

既に実稼働環境へと展開された既存のソリューションを変更することは、非常に難しいことです。"壊れてもいないのに、なぜ直すのか"、あるいは、"ちゃんと動いているのに、あえてコストをかけてカスタマイズする理由はない" という声が上がってくるはずです。もっともな意見ですが、それでも説得しなければなりません。

アプリケーションのライフサイクルで言えば、ポストプロダクションフェーズであり、当然、そこには既に完成したシステムが存在しています。EA がそこに介入しようとする場合、重視すべき領域がいくつかあります。図 13 を見ると、考慮しなければならない点がたくさん存在することがわかります。

図 13. ポストプロダクション段階における EA の課題 (図をクリックすると拡大画像が表示されます)

影響はさまざまな領域に及び、それぞれ異なる問題が表面化してくることになります。考慮する必要のある主な領域には、次の 3 つがあります。

· 実稼働プロセス : ソフトウェアを実稼働環境に導入し、変更管理を行い、既に運用段階に入ったソリューションをサポートするプロセスです。

· 実稼働システム : 実稼働環境のシステムは、もはや隔離された状態ではありません。既に、さまざまな依存関係や制約を持った環境に合わせて展開、構成されています。

· 実稼働チーム : ソリューションのサポートと展開を担当するチームには、固有のプロセスと実施手順が与えられています。この点については、プロセス面と体制面の両方の視点が必要です。

実稼働プロセス

実稼働プロセスに介入する場合は、慎重な対応が要求されます。ソフトウェアのコストや品質、障害からの回復能力などに影響するためです。次の主要な実稼働プロセスに関与することによって、このプロセスにプラスの影響を与えることが可能です。

· 構成管理 : アーキテクチャの設計面だけでなく、それ以外の組織面にも働きかけることによって (構成管理プロセスを標準化するなど)、構成管理プロセスを最適化できます。

· 変更管理 : 通常、このプロセスに EA が関与することはありません。ただし、ソリューションに与える影響には敏感になる必要があります。他のソリューションと複雑に関係し合っていることも考えられます。また、ソリューションに変更を加えることによって、下流工程にしわ寄せが来る可能性もあります。

· インシデント管理 : このプロセスも、EA が関与することはほとんどありません。ただし、インシデント管理データが大きな価値を持つ場合もあるため、注意深く観察する必要があります。EA は、ここで収集されたデータを他のデータと相互に関連付けることによって、アーキテクチャのコストを正確に評価できます。

実稼働システム

EA の活動では、既存の実稼働システムに関与する機会が多くなります。次のような活動に参加したり、自ら指揮をとったりしながら、結果的に、複数の役割を兼ねることになります。

· 将来のアーキテクチャ : ビジネス上の一連の問題に対して方向性を決めると、ソリューションのロードマップとアーキテクチャの構想が浮かび上がってきます。

· 現在の状態のレビュー : 前述のように、EA は通常、他のアーキテクトよりもソリューションのアーキテクチャを深く理解しています。このプロセスでは、EA が業務分野の責任者またはポストプロダクションのメンテナンスチームと連携します。

· 戦略的な構想 : 正式な計画プロセス以外でも、なんらかのきっかけで、現行のソリューションアーキテクチャを評価する機会があれば、EA は戦略的な構想をまとめることができます。

ソリューションをレビューして、再構築しようとするとき、EA は技術的な側面と運用上の側面の両方の問題に遭遇します。単にソフトウェアに関連した問題だけとは限りません。ハードウェア、通信、ソフトウェアなど、あらゆる要因が混在していると考えてください。こうした問題は、企業全体にかかわるさまざまな機能が原因で発生します。たとえば、次のような要因が挙げられます。

· 共有サービス : EA は特定のソリューションで共有サービスを使用するかどうかを検討します。

· ソリューションの依存関係 : あるソリューションが、より多くの機能を実現するために、他のソリューションと連携している場合が少なくありません。現状のアーキテクチャと他のアーキテクチャとの依存関係がすべて明確に定義されていない限り、全社的な視点で見ると、気が遠くなるほどの相互依存性が存在します。

· 環境 : 通常、EA はプラットフォーム環境 (Windows 2003 など) の統合と管理の一元化を検討します。

· 制約 : EA は、さまざまな理由から、アーキテクチャに関する制限や制約を受け入れる必要性に遭遇します。たとえば、既製のソフトウェアをベースにしたソリューションで API の利用が限られていたり、独自開発のソリューションでも拡張性を考慮して構築されているとは限りません。

実稼働チーム

SDLC プロセスで作成された設計ドキュメントはすぐに古くなってしまうため、既存のアーキテクチャに対するほとんどの作業は、ポストプロダクションの各メンテナンスチームが行います。ポストプロダクションライフサイクルで、アーキテクチャ全体を網羅した詳細なドキュメントが作成されない限り、EA としては、こうした実稼働システムの担当チームに頼らざるを得ません。たとえば、次のようなチームと連携することになるでしょう。

· メンテナンスチーム

· 運用チーム

· ユーザーサポートチーム

アーキテクチャ上の意思決定を行う際は、こうしたチームと連携することで、さまざまな考慮事項に対する知見を広めることができます。

ガバナンスへの取り組み

ガバナンスによってもたらされる利点は、一連のプロセスと運用モデルを使用してポリシーを確立することによって、企業における秩序だったソフトウェア開発が促進されることです。ガバナンスでは、ソフトウェアをどのように構築すべきかのプロセスが定義されます。ポリシーの確立には、ビジネス要因、業界の動向、競合他社の影響、企業戦略、IT 戦略などに由来する、さまざまな側面があります。この記事では、こうした話題について深く追求することは避け、エンタープライズアーキテクトの日常にかかわる部分に的を絞って説明することにします。

ガバナンスモデルは、EA がポリシーと標準を確立した後、それを全社的な観点から確認し始めたときに表面化します。組織の文化が大きくかかわってくるため、ガバナンスプロセスは決して取り組みやすい問題とは言えません。さらに、組織ごとに独自のモデルが採用されている場合もあります。図 14 (TOGAF のアーキテクチャガバナンスフレームワーク) を見てください。この図は、アーキテクチャガバナンス構想に求められる主要な構造要素を示しています。

図 14. TOGAF アーキテクチャガバナンスフレームワークの組織構造 (図をクリックすると拡大画像が表示されます)

ガバナンスモデルは、組織の文化と成熟度に大きく依存します。これは決して悪いことではありません。実際には、多くの理由からこれは非常に良いことなのです。たとえば、次のような理由が挙げられます。

· 組織の文化に適応させることができる。

· 組織内の意識を変革することができる。

· 組織内の人材の教育水準を高めることができる。

IT ガバナンスは、EA が定期的に従事する活動の 1 つです。日々のガバナンス活動が、長期的な利益という点で、組織の全体的な成功に微妙な影響を及ぼすことに注意してください。

正式のガバナンスモデルとは別に、通常、EA はいくつかのガバナンス活動に関与します。たとえば、次のような活動を挙げることができます。

· アーキテクチャレビュー : 委員会を設置し、そこでアーキテクチャを評価するという形態が一般的です。ここで、EA は技術の標準準拠に取り組むことができます。

· ポリシーと標準の確立 : 通常、ポリシーや標準の確立にあたっては、主要部門の代表者で構成される委員会を設置します。

· デザインパターンの作成 : アーキテクチャの概念を伝えるには、ポリシーや標準の採用方法を文書化する必要があります。それが、開発コミュニティに対し、ポリシーや標準に準拠したアーキテクチャを構築するための前提条件を提供することにもつながります。

安易に命令や強制といった行為に走ることは避けます。こうしろと単に命令するよりも、チームとの共同作業を推進する方が効果的です。EA が一方的に変化を強制しても、"机上の空論" と見られて、信頼を失うことになります。EA はコミュニティが適切な判断を下せるようにし、また、そうしやすいような環境作りをする必要があります。個人の裁量権を尊重することで、信頼と支持を集めることができます。

最終的な目標は、ソリューションを実装する際に、アーキテクチャ上の意思決定に注意を払うように開発者の意識を喚起することです。

まとめ

エンタープライズアーキテクトの役割は、きわめて流動的で多方面に及びます。IT 関連の問題だけでなく、ビジネスに関連した問題を常に把握することが要求されます。戦略的な構想に沿った作業を通じて、IT とビジネスの連携をできるだけ円滑な形で推し進めること、それがエンタープライズアーキテクトの仕事と言えるでしょう。

ビジネスグループやテクノロジグループとのつながりのない一個人として組織に貢献することになるため、EA には、技術的なスキルよりも、むしろ交渉スキルが要求されます。EA はその能力を存分に発揮して、組織を正しい方向へと導く必要があります。

意思決定のための再利用可能なフレームワークと反復可能なプロセスを確立し、基幹業務系プロジェクトへの助言を提供することによってコミュニティを活性化すること、それがエンタープライズアーキテクチャの中心となる考え方です。

参考資料

MSDN エンタープライズアーキテクチャセンター (http://msdn.microsoft.com/architecture/EA)

目次