このコラムは、株式会社エル・ティー・エスのLTSコラムとして2018年10月に掲載されたものを移設したものです。
ライター
実は私もビジネスアーキテクトの一人なのですが、日本では普及した役割ではないため、情報がとれないことに悩んでいました。今回、2018年9月24日～26日にカナダのオタワで開催された「Business Architecture Innovation Summit」というカンファレンスに参加し、実際に欧米の民間企業で活躍しているビジネスアーキテクトの方のお話を伺うことが出来ました。このカンファレンスはビジネスアーキテクトのコミュニティ「Business Architecture Guild」が年に数回開催している会合の一つですが、今回のコラムではこのカンファレンスで得たことを元にビジネスアーキテクチャ、そしてビジネスアーキテクトについて紹介したいと思います。
参加者は全体で120～130人くらいに見えました。女性の出席者も多く、発表者の半分は女性でした。
ビジネスアーキテクチャとは何か
ビジネスアーキテクチャとはそのまま訳すと「事業構造」となりますが、その実態は事業体が戦略を着実に実行し、新しい姿に生まれ変わるための計画策定の手順や考え方をまとめた変革方法論です。
ビジネスアーキテクチャではまず業務や各業務のKPI、情報システム、情報、組織といった事業体が内包する構成要素を可視化します。そして長期的なビジョン（＝これが“戦略“です）を達成するために、その各要素のどこをどのように変えなくてはいけないのかを識別します。変化させなくてはいけない要素が見えたら、それらを作り変えるための活動（＝プロジェクト）を識別します。
この後の個々の変革プロジェクト※1の実行（=変革の実行）はプロジェクトマネジメントに託されますが、各プロジェクトの活動が戦略目標に対して適切に進んでいるのか、各プロジェクトの効果はしっかり出ているのかなどを全体俯瞰的な立場から管理しますし、プロジェクトにまたがっておきる課題の調整や計画途中で新たに必要となったプロジェクトの組成なども行いますので、計画を策定したら役割を終えるわけではありません。
なお近年の企業変革方法論においては、この変革のための個々の活動単位を「イニシアチブ」と呼ぶ傾向にあります。今回参加したビジネスアーキテクチャギルドだけでなく、業務分析の国際コミュニティIIBA（International Institute of Business Analysis）などでもこれらをイニシアチブと呼びます。 ただ、ここでは普段つかいなれた「プロジェクト」という言葉で話を進めます。
変革方法論というとプロジェクトマネジメント（PM）の方法論であるPMBOKや、ビジネスアナリシスの方法論であるBABOKを思い浮かべる方が多いと思いますが、このような方法論はもっぱら個別のプロジェクトを推進するための方法論です。一方でビジネスアーキテクチャは事業変革に必要なプロジェクトを識別し立ち上げるための方法論であり、プロジェクトマネジメントやビジネスアナリシスに先だって活用される方法論と言うことができます。またプロジェクトマネジメントやビジネスアナリシスは明確な期限を持った活動（＝プロジェクト）であるのに対して、ビジネスアーキテクチャはどちらかといえば定常業務（＝特に期限のない活動）に属するものです。
日本で言うと経営企画部などが行う中長期での組織変革計画の立案と管理などがそれにあたります。また、複数のプロジェクトを統合して管理することで戦略目標を達成するプログラムマネジメント※2と呼ばれているものにも通じる部分があります。
プログラムマネジメントは複数のプロジェクトを統合管理して大きな目標を達成するという点から多種多様な目標の達成の方法論として汎用性があります。一方で、ビジネスアーキテクチャはその名の通り、事業構造の可視化の考え方が重視されており、企業（組織）ないし事業の変革に特化した方法論と言えます。
ビジネスアーキテクチャ、そしてビジネスアーキテクトの役割
ここまでざっくりとビジネスアーキテクチャとは何かを説明してきました。このビジネスアーキテクチャ設計と管理を担う専門職がビジネスアーキテクトです。ここから先はビジネスアーキテクトの役割という形でより詳しく紹介したいと思います。
ビジネスアーキテクトの役割は細かく言えばたくさんありますが、主なものとしては「全体最適での変革活動計画」「個々の変革活動の投資管理」「ソリューションの全体最適化」という三つが挙げられます。これらを一つ一つ見ていきましょう。
1．全体最適での変革活動計画
企業が中長期で実現したいビジョン、つまり戦略を立案したとして、戦略実現のために行うべき変革活動はたくさんあります。そこにはいくつもの新サービスの立ち上げ、顧客等の基幹情報の統合、会計や人事といった管理業務の生産性向上などが含まれます。このような自らの意思で行う「攻め」の施策の他にも法令改訂対応やソフトウェアの老朽化対応といった、どちらかといえば外部環境変化のためにやらざるを得ない「守り」の施策も含まれます。
ビジネスアーキテクチャという概念が生まれる前は、このような戦略実現のための活動の立案は各部門に任される傾向にありました。しかし、一般的に企業の部門単位は全体最適で物事を進めるには細かすぎます。結果的に活動がうまく進まないことになります。
例えば、幾つかの製品事業部があったとして、それぞれの事業部が売る製品は異なっても、販売プロセスが同じものであれば同じビジネスプロセスや情報基盤を効率的に共有できるはずです。しかし各部門がそれぞれサービスを企画すると、当然異なるプロセス、異なる情報基盤となり、顧客から見てもチャネルが異なってしまうなど不都合が生じます。この結果、顧客価値とコストの両面でデメリットが生じます。
また事業部を横断して顧客情報を統合し管理すればお客様のニーズを迅速に把握し、よりお客様に沿った提案をできるようになるはずです。しかし、各事業部からすればそのような部門をまたいだ活動を担うのはその権限からみて簡単ではありません。仮に複数事業部が集まって「顧客情報統合ワークショップ」のようなものを開いても、各部門の利害が対立してなかなか進まないということは日常茶飯事です。
このように全社戦略に基づいた活動が遅々として進まない裏では、各部門が自部門の利益に基づいた活動、を推進するために限られた予算や人員の奪い合いをしていたりもします。しかし、そのような各部門の利害に基づいた活動が必ずしも全社の戦略上、優先順位が高い活動かというとそうでもないことがあります。
ビジネスアーキテクトはこのような部門最適（部分最適）が起きないよう事業体全体の視点から意味ある活動単位や、活動の順序、優先順位を設計します。この設計を元に最終判断は経営が行います。この例ですと、同じプロセス共有できる複数事業間のサービスについては同じ活動単位として切り出しますし、顧客情報統合はビジネスアーキテクトがファシリテーターの役割を果たしながら推進します。もちろん各部門が行いたいと主張する活動も全社戦略に照らして優先順位を決め、予算と人員を配分します。
ビジネスアーキテクチャの視点から見れば、「どの組織が担当か」というのは後付けの要素です。一般的に企業の活動は組織単位で区切られてしまうことが多いのですが、ビジネスアーキテクチャでは業務、情報、情報システムといった事業を構成する仕組みを中心に、戦略目標に基づいて意味ある活動単位を括りだします。このようにまず全体最適の活動単位を括りだしてから、誰がそこに巻き込まれるべきかを設定するのです。このように全体最適で変革活動を計画することがビジネスアーキテクトの役割の一つです。
計画が各プロジェクトに引き継がれた後は、進捗管理の役割に移ります。当初想定されなかった各プロジェクト間の役割の曖昧な部分が出てきたり、外部環境が変化して全体の計画を組み替えなくてはいけなくなったりと、ビジネスアーキテクトはその変革計画のライフサイクルに渡って計画の調整と関係者間のコミュニケーションに奔走します。
ここで一つ補足なのですが、一般的に戦略とは「自社にとっての重視すべき顧客は誰か」「顧客のニーズは何で、自社はどのようなサービスや製品を提供したいのか」「その製品やサービスに競争力はあるのか」「その結果、十分な投資効果（＝業績）は見込まれるのか」といったことが説明されます。総じて「どういう姿になりたいのか」「それはなぜか」ということが戦略の示すもので、「そのような姿になるためにどのような活動が、どういう計画に従って行われるのか」という実行に関することはあまり説明されません。少なくとも企業変革を語るコミュニティでは「どうありたいか」を示すのが企業戦略や事業戦略であり、「どのように実現するか」という実行計画に関しては戦略とは別の要素であるとされることが大半です。ですからビジネスアーキテクチャのコミュニティには“ビジネスアーキテクチャとは「戦略」と「変革実行」を間に入ってつなぐもの”という共通認識があるのです。
2．個々の変革活動の投資管理
切り出された各活動がしっかり効果を出しているのか、それを検証することがビジネスアーキテクトの役割です。これについては事例で説明したいのですが、世界最大級の航空会社の一つであるユナイテッド航空では2008年にビジネスアーキテクトが集う組織であるビジネスアーキテクチャチームが設置されました。これは当時のCIO（最高情報責任者）がたくさんのITプロジェクトが立ち上がる一方で、それらの効果がアプリケーション的な側面、つまり機能要求を満たしたとか、トラブルが起きていないといった観点からばかり説明されて、それが会社全体としての戦略目標に寄与しているものなのか説明がされないことに疑問を持ったためでした。
このような疑問を解消するためにビジネスアーキテクチャチームは自社の業務構造を「空港における顧客接点業務」や「貨物取扱業務」といったように細かく区分し、この業務区分ごと（この業務区分を「ケイパビリティ」と呼んでいます）に戦略目標に紐づく業務管理指標（KPI）を明確にしました。そしてITプロジェクトはそれらの業務管理指標にどのように貢献したかという観点で投資効果を説明しなくてはならないとする体系を作り上げたのです。
ビジネスアーキテクトが管理する変革活動とは本来はIT関連のプロジェクトだけにとどまりませんが、その投資規模からいってももっぱらIT投資の妥当さを事業側の側面から検証するためにビジネスアーキテクチャを導入することが多いようです。IT部門が構築した仕組みは、IT部門だけに説明責任を求めてもなかなか難しいことがほとんどです。ITを使う事業側がその事業に課された戦略目標に照らして、あくまでも「ビジネス」の側面から説明するというのがビジネスアーキテクトの役割です。
3．ソリューションの適切な選定
最後に説明する役割がソリューションの適切な選定です。ここで言うソリューションとは必ずしもITソリューションだけではありません。BPOのような人的ソリューションや、組織変更や業務ルールの改廃等、問題解決やあるべき姿を実現するための方策全体を指します。IT部門など技術側が中心となってソリューションを選定する場合、その視点が技術的な視点に偏ってしまうことがあります。またITに限らず特定のソリューションのスペシャリストは自分たちが専門とするソリューションができる範囲で問題を解決しようとしてしまうこともあります。
IT側がプロジェクトにおいて事前に特定のソリューションを適用することを決めてしまった上で、プロジェクト中の要件定義の段階ではじめて自社の事業とソリューションとのGAPが大きいことに気づき、あわてるケースは日本でも本当によく見かけます（どうやらこのような話は日本に限らないようですが）。このようなプロジェクトではソリューションの制約から業務上の要求事項を制限せざるを得ないという本末転倒な事態がおきます。ビジネスアーキテクトは、プロジェクトを組成する前段階でプロジェクトに適用する解決策（＝ソリューション）をしっかり吟味し、このようなことを防ぐ役割があります。
またプロセス変革の取り組みでは必ずしもソフトウェアソリューションを導入しただけでは効果を生まないことが多々あります。組織間の役割分担の見直しや、生産性向上の障壁となっているやっかいなルールを撤廃したりする活動も必要になるのですが、このような活動は本来、IT側（技術側）だけでは行うことが出来ません。このようなビジネス側との連携接点としても機能します。
このように技術側の観点が先行してソリューションを選定してしまうことを防ぎ、この時もあくまでもビジネス側の観点から技術側と連携して必要十分なソリューションを選定すると共に、選定したソリューションがしっかり力を発揮できるよう組織的な障壁を調整して解決の道筋をつけることもビジネスアーキテクトの役割です。
今回の前編ではビジネスアーキテクトの三つの役割を説明してきましたが、実際には企業によってビジネスアーキテクトの設置理由や役割は異なります。一般に「1．全体最適での変革活動計画」がビジネスアーキテクトとしての本領を発揮する部分ですが、「2．個々の変革活動の投資管理」を重点的に活動しているビジネスアーキテクトも多いようです。また「3．ソリューションの適切な選定」についてはITアーキテクトのような他の役割が担うこともありますから、ここで説明した役割は“最大公約数”的なものと理解頂ければ幸いです。
次回の後編では、ビジネスアーキテクトが属するビジネスアーキテクチャチームは企業のどこに属するのか、そしてITアーキテクチャやエンタープライズアーキテクチャとの違いを踏まえてビジネスアーキテクトの役割を深掘りしていきます。また、変革専門人材としてビジネスアナリストが思い浮かびます。この二者の役割は大きく見るとビジネス側の視点で組織を変革していく点で共通していますが、海外では異なる仕事とされています。この二者の役割の違いについても紹介していきます。
