前回まで、アーキテクチャの5つの柱を解説しました。今回からはアーキテクチャの専門領域に踏み込みます。ITABoKには次の4つの専門領域が定義されています。
ビジネス・アーキテクチャの専門領域
インフォメーション・アーキテクチャの専門領域
インフラストラクチャ・アーキテクチャの専門領域
ソフトウェア・アーキテクチャの専門領域
これらの専門領域で求められるスキルの多くは、5つの柱をさらに深化または拡大したものとなります。今回は、ビジネス・アーキテクチャの専門領域を取り上げ、そこで求められるケイパビリティについて解説したいと思います。
ビジネス・アーキテクトの役割とは何でしょうか。ITABoKには以下の記載があります。
「ビジネス・アーキテクトは、特定のビジネス・ゴールを達成するためのビジネス戦略の作成に参加する事で、テクノロジー戦略を通じてビジネス・イニシアティブにおいてリーダーシップを発揮します。ビジネス・アーキテクトは、事業部内でのイノベーションと機会の特定を可能にします」（註1）。
また、その活動に関しては「ビジネス・アーキテクトは困難なビジネス関連プロジェクトの領域内で、ソリューション・アーキテクトとしての役割を果たす場合もあれば、現在の企業内での一般的なロールで活動する一員として活動する場合もあります。しかし、ビジネス・アーキテクトの主たる責務はビジネスシステムそのものにあり、それはデリバリー関連の職務機能ではありません」としています（註2）。ここから伺えることは、ビジネス・アーキテクトの役割はビジネス活動そのものを変革することに焦点があてられているということです。そのためのビジネス・ゴールやビジネス戦略の策定に深く関与し、その策定においてはステークホルダーや他の専門領域のアーキテクトと協調しながら、変革活動を主導することが期待されていると言えそうです。
次に、ビジネス・アーキテクチャについて見ていきましょう。ITABoKが述べているのは、ビジネス・アーキテクトというロールのスキル要件とその役割です。
ですので、ここではBusiness Architecture Guildが公開するBIZBOK®ガイド(A Guide to the Business Architecture Body of Knowledge®)からビジネス・アーキテクチャの定義を引用します。
BIZBOK®ガイドでは「ビジネス・アーキテクチャとは、ケイパビリティ、エンド・ツー・エンドでの価値提供の流れ、情報、および組織構造に関する包括的で多次元的なビジネス・ビューおよび、これらのビジネス・ビューと戦略、製品、ポリシー、イニシアチブ、ステークホルダーとの関係をあらわしたもの（註3）」と定義しています。下図をご覧ください。
この図は、ビジネス・アーキテクチャを構成する個々のドメイン（個別の領域知識）をあらわしています。企業はビジネス・ゴールを達成するために、これらのドメインに着目して変革のための活動を推進していくことが求められます。「ビジネス・アーキテクチャは、戦略を実行可能なイニシアチブに変換するための効果的なコミュニケーションおよび分析フレームワークとしての価値を提供する」と述べられています（註4）。
さて、ここでITABoKに戻ってケイパビリティを見ていきたいと思います。
最初にあげられるケイパビリティは「ビジネス・マネジメント」です。ITABoKによると、アーキテクトがよく直面する主な課題の１つは「テクノロジー」と「ビジネス」の不一致であり、従って、アーキテクトは組織の概要、特にそのビジョン、ミッション、ゴール、目的に関する深い理解をする必要があるとしています。加えて、ビジネスプロセス・マネジメント（BPM）に対する幅広い知識が極めて必要であることを強調しています。注意しなければいけないのは、ここでいうBPMとは戦略を実現するためのあるべきビジネスプロセスの姿が対象となり、日本で一般的にイメージされる現場レベルの詳細な業務フローが中心課題ではありません。ビジネス・アーキテクトは、組織の目的を高め達成するために、いかに組織のプロセスを変更できるかにフォーカスすることが求められます（註5）。 続くケイパビリティは「ビジネス戦略」です。戦略とは、不確定な状況の下で１つまたは複数のゴールを達成するための高いレベルの計画を指します。ビジネス戦略は、戦略的マネジメントフレームワークや、戦略マップ等の形で表現される場合があります。ここでビジネス・アーキテクトが担う最も重要な役割は、組織への投資の価値を実現するためにビジネス戦略で規定された、テクノロジー投資からビジネスの成果までのトレーサビリティのマトリクスを作成することであると述べられています（註6）。世界的なプロジェクトマネジメント組織であるPMI（Project Management Institute）によると、組織におけるすべての変革はプロジェクトやプログラムを通じて実現されます。Iasaもこうした考え方を支持しているようです。「ポートフォリオとプログラム・マネジメント」を3つ目のケイパビリティに含めている点は、非常に好感が持てます。
ビジネス・アーキテクトは、ビジネスが直接引き起こす潜在的な変化が、財務パフォーマンス指標とどのように関連するかを理解することが求められます。また同時に、ビジネスの変化全般を評価して、それを支援するために必要なIT投資を特定することができる独自の立場にいます（註7）。こうした理由から、ビジネス・アーキテクチャにおいては「財務的手法」「テクノロジー投資」に関わるケイパビリティが必要となります。 ビジネス・アーキテクトは「テクノロジーの戦略とイノベーション」に関する動向へのチャネルや技術的知見を有していることが期待されます。本来、アーキテクトが得意とするIT技術の目利き力を発揮できる領域ですね。これらに関連する特定のスキルや知識の活用し、ビジネスや組織のゴールと目標を達成することで、ITやビジネスの価値に貢献することができます（註8）。言うまでもなくビジネス・アーキテクチャは、関係する全てのステークホルダーに理解されなければなりません。そこで求められるケイパビリティが「ビジネスのビューとモデル」です。モデリングすべきビューを決定する際に、ビジネス・アーキテクトの知性と経験が活かされます。例えばITABoKでは、主に以下のビューをあげています（註9）。
戦略
価値
サービス
ケイパビリティ
プロセス
財務
BIZBOK®ガイドのモデルとは異なるビューもあります。このようにフレームワーク間で必ずしも整合性が取られているわけではありませんが、重要な点はビジネス・アーキテクトがそのイニシアチブにとって、どんなビューが必要か決定できることにあると思います。
最後に、ビジネス・アーキテクトは「ガバナンス、リスク、コンプライアンス」のケイパビリティを発揮しながら「組織の変化を先導」していくことが求められます。
先述したように、アーキテクトが解決しなければならない主な課題の１つが「テクノロジー」と「ビジネス」の不一致です。ビジネス・アーキテクトはその不一致を解消する任務を担っています。彼らは変化にとって重要なエージェントであり、現在のアーキテクチャ、移行中のアーキテクチャ、及び、「目標とされる」アーキテクチャを創出するべく（内部および外部の）全ステークホルダーと緊密に活動しながら、組織変化の成功に不可欠な存在であらねばならないのです（註10）。今回は、ビジネス・アーキテクチャの専門領域のケイパビリティを解説しました。ビジネス・アーキテクトという名称は、国内ではまだ馴染みのないものかもしれません。一方で、その活動内容を考えた時、皆さんの組織においてもビジネス・アーキテクトに相当する人材がおられるかもしれません。そうした人材は、何という名称で呼ばれ、どのようなケイパビリティを発揮されているのでしょうか。ビジネス・アーキテクトの活動において、今回解説したケイパビリティがどう位置付けられるか、私の理解を図にしてみました。
皆さんはどうお感じになられたでしょうか。Iasa日本支部では、皆さんが考えるビジネス・アーキテクト像について意見交換を重ね、理解を深めていきたいと思います。ご意見お聞かせくだされば幸いです。
註）
ITABoK Version2 日本語訳版、「3.3 ロールの記述」P.398
ITABoK Version2 日本語訳版、「3.3 ロールの記述」P.398
BIZBOK®ガイド Version7 、「What is Business Architecture?」P.2
BIZBOK®ガイド Version7 、「What is Business Architecture?」P.3
ITABoK Version2 日本語訳版、「2.2.1.1 ビジネス・マネジメント」P.220
ITABoK Version2 日本語訳版、「2.2.1.2 ビジネス戦略」P.225
ITABoK Version2 日本語訳版、「2.2.1.4 財務的手法」P.236
ITABoK Version2 日本語訳版、 「2.2.1.6テクノロジーの戦略とイノベーション」P.245
ITABoK Version2 日本語訳版、「2.2.1.8 ビジネスのビューとモデル」P.260
ITABoK Version2 日本語訳版、「2.2.1.9 組織の変化を先導する」P.263