企業の変革を全体最適で進める役割 「ビジネスアーキテクト」とは(後編)のサムネイル
プロセス変革・業務改革

企業の変革を全体最適で進める役割 「ビジネスアーキテクト」とは(後編)

このコラムは、株式会社エル・ティー・エスのLTSコラムとして2018年11月に掲載されたものを移設したものです。

ライター

山本 政樹(LTS 執行役員)

アクセンチュア、フリーコンサルタントを経てLTSに入社。ビジネスプロセス変革案件を手掛け、ビジネスプロセスマネジメント及びビジネスアナリシスの手法や人材育成に関する啓蒙活動に注力している。近年、組織能力「ビジネスアジリティ」の研究家としても活動している。(2021年6月時点)  ⇒プロフィールの詳細はこちら

こんにちは、LTSの山本政樹です。皆さんは「ビジネスアーキテクチャ」という方法論、そしてこれを担う「ビジネスアーキテクト」という役割をご存じでしょうか。前回の前編では、ビジネスアーキテクトの役割として「1.全体最適での変革活動計画」「2.個々の変革活動の投資管理」「3.ソリューションの適切な選定」の3つを紹介しました。しかし、実際には企業によってビジネスアーキテクトの設置理由や役割は異なります。

今回の後編では、ビジネスアーキテクトが属するビジネスアーキテクチャチームは企業のどこに属するのか、そしてITアーキテクチャやエンタープライズアーキテクチャとの違いを踏まえてビジネスアーキテクトの役割を深掘りしていきます。また、ビジネスアーキテクトと同じ変革専門人材として思い浮かぶ役割にビジネスアナリストがありますが、海外では異なる仕事とされています。この二者の違いについても紹介していきます。

ビジネスアーキテクトはどこに所属するのか

ビジネスアーキテクトの全社における影響力は大きく、アーキテクトが所属するビジネスアーキテクチャチームは多くの場合、経営直轄のチームです。大きく分けてCSO(最高戦略責任者)やCOO(最高執行責任者)という事業側の責任者の管轄であるケースと、CIO(最高情報責任者)のようなIT側の責任者の管轄であるケースの二つの傾向がありますが、専門家※1によると近年はよりビジネス側の管轄となる傾向にあるとのことでした。

※1
参加したカンファレンスのチェアマンであったWhynde Kuehn氏に回答頂きました。氏はビジネスアーキテクチャの方法論「BizBOK」を展開している団体「Business Architecture Guild」の主催者の一人で、ビジネスアーキテクチャ領域の第一人者の一人です。

ビジネスアーキテクトがIT側に所属するケースでも「ビジネスアーキテクト」の役割名の通り、その目線はあくまでもビジネス側に立つことが求められます。前編でご紹介したあのユナイテッド航空のビジネスアーキテクトの方にお話を伺ったのですが、当初チームはCIO直轄のチームとして立ち上がったそうです。しかし組織図上IT機能に所属してはいますが、現実的にはビジネス部門横断で調整を行う「部門横断チーム(クロスファンクショナルチーム)」であり、一概に「IT側」とは言いきれないそうです。その後CIOがデジタルビジネス全般に責任を持つCDO(最高デジタル責任者)となったため、その点からも純粋にIT側とも言い切れないということでした。

また世界最大級の運輸会社であるフェデックスのビジネスアーキテクトの方のお話を伺ったところ、フェデックスではマーケティング機能に属するそうです。日本ではマーケティングというと「広告・宣伝・イベント」と狭く捉えられがちですが、本来マーケティングとは顧客理解から自社の製品やサービスの在り方を考え、それらを市場に発信するという製品&サービスのライフサイクル管理全体を担う考え方です。フェデックスのプロダクト開発チーム(Product Development Team・・・※2)には、戦略で示された新サービスの導入や既存のサービスの改善・改革の方針をサービスプロセスに反映していくためにビジネスアーキテクトが所属しているとのことでした。

※2
プロダクトは一般に「製品」と訳されますが、英語の「Product」は広義では物理的な製品だけでなく人が行うサービスや知的財産も含まれます。厳密にモノとしての製品(商品)だけを指す場合は「Goods」と言われる傾向にあります。

このようにビジネスアーキテクチャチームの所属はいろいろな考え方があります。この種の変革方法論はITが引き金となって導入されるケースが多く、その成立過程においてはIT機能の管轄からはじまることが多い一方で、機能が成熟すればするほど本来の意図に沿ってビジネス(事業)側との接点が濃くなるというのが傾向のようです。

ITアーキテクチャやエンタープライズアーキテクチャとは何が違うのか

ビジネスアーキテクチャとビジネスアーキテクトの話を聞くと、これらはITアーキテクチャ(ITアーキテクト)やエンタープライズアーキテクチャ(エンタープライズアーキテクト)とは何が違うのかという疑問を持つかもしれません。まずITアーキテクチャとの違いに関しては、ビジネスアーキテクチャはビジネスの視点からITに求める要求を提示しますのでビジネスアーキテクチャは要求の送り手であり、ITアーキテクチャは要求の受け手であるという違いがあります。ビジネスアーキテクチャはITのアプリケーション構成や基盤構成を最適化する手法はほとんど触れられていません。これらのITを全体最適で運営する構成は、ビジネスアーキテクチャからの要求を受けてITアーキテクチャ側(ITアーキテクト側)で実施します。

さて問題はエンタープライズアーキテクチャです。エンタープライズアーキテクチャの構成要素には一般的にビジネスアーキテクチャ、アプリケーションアーキテクチャ、データアーキテクチャ、そしてテクニカルアーキテクチャの四つです。ビジネスアーキテクチャを除く後者三つをまとめたものがITアーキテクチャですから、エンタープライズアーキテクチャとはざっくり「ビジネスアーキテクチャ+ITアーキテクチャ」なのです。

だったらエンタープライズアーキテクチャ一つあれば良いではないかと思われるでしょう。エンタープライズアーキテクチャという方法論がその言葉通り、ビジネス側もIT側も全ての観点を必要十分に満たしているのであれば確かにそれで良いのですが、実際にはそうとも言えません。

エンタープライズアーキテクチャがカバーする範囲は極めて広く、コンテンツのボリュームは膨大です。実際、エンタープライズアーキテクチャの世界標準であるTOGAF※3の本編は電話帳のような厚さの書籍であり、中には哲学的とも思える難解な考察も含まれるようなものです。しかし、そのボリュームにも関わらずTOGAFですらその内容は未だビジネス側よりもIT側の記述の方が圧倒的に多く、ビジネス側でアーキテクチャ管理を行う人から見れば方法論として十分な内容ではありません。エンタープライズアーキテクチャは歴史的な経緯から未だIT関連の議論中心です。そのためビジネスアーキテクチャに関心を持つ人々はビジネスアーキテクチャを中心に議論するコミュニティを別に立ち上げているのです。このような人々が中心となって記述したビジネスアーキテクチャのノウハウ書がBusiness Architecture Guildが提供している“BIZBOK”です。

※3 TOGAF
The Open Groupが提供しているエンタープライズアーキテクチャのノウハウ集であり、これに基づいた資格制度も存在しています。私(山本)もTOGAF9の資格保持者です。

TOGAFとBIZBOKは決して違う方向を向いているわけではなく、双方に同じ研究者が入って連携が図られています。最近刊行されたTOGAFバージョン9.2ではBIZBOKの基本的な考え方がTOGAFに組み入れられています。これによりエンタープライズアーキテクチャの全体像を学ぶならTOGAF、その中でもビジネスアーキテクチャをより詳しく推進するのであればBIZBOKという連携が出来るようになりました。このほかにもアーキテクチャ関連の方法論は多々あるのですが、世界のアーキテクチャコミュニティでは、それぞれの領域の専門家がそれぞれの問題意識に基づきながら時に連携しつつ、時に差異化しながら日々、研究をつづけています。

ビジネスアナリストとビジネスアーキテクトは何が違うのか

企業の変革をビジネス側から進める変革専門人材というとビジネスアーキテクト以外にビジネスアナリストが思い浮かびます。私たちLTSでもこれまで企業のビジネス変革を担う役割としてビジネスアナリストを何度も紹介してきました。この二つの役割は大きく見るとビジネス側の視点で組織を変革していく仲間です。この種の考え方に慣れていない日本のコミュニティから見ればほぼ同じ役割に見えるかもしれません。

ただ海外の組織内においては二つの役割は異なる仕事とされています。さながら変革プログラム全体の指揮をとるビジネスアーキテクトと、もっぱら個別の変革プロジェクトの実行を担うビジネスアナリストの関係は、組織全体を率いて部門に指示を出す経営と個々の部門を率いて業績を生み出す管理職のような関係に近いものとして捉えられていると感じます。誰も経営者と管理職を「同じ役割」とは言わないですからね。この他にも冒頭に説明したように期限を持ったプロジェクトに属するビジネスアナリストに対して、ビジネスアーキテクトはもっぱら定常組織の中で活動するという違いもあります。

ただ、ビジネスアナリストのコミュニティでは近年、ビジネスアーキテクチャやビジネスアーキテクトとの関係性に関する議論が大変盛んです。個別のプロジェクトを効果的に進める上ではビジネスアナリストにもビジネスアーキテクチャへの理解は必須となりますし、全社的な影響力を持つ規模の大きいプロジェクトだと役割の境目は曖昧になってしまいます。実際、全社の基幹業務改革(=基幹システム導入)のような大規模なプロジェクトではビジネスアナリストチームのリーダーが実質的にビジネスアーキテクトとして振る舞うこともあり、この役割の間にはある程度、重なる部分もあります。

またビジネスアナリストとしてのキャリアを積み、より大きな変革を初期工程から主導したいと思えば必然的にビジネスアーキテクトとして振る舞う必要が出てきますから、ビジネスアーキテクトはビジネスアナリストのキャリアアップ先の選択肢の一つとしてもとても意識する存在なのです。

そのような中で、一部ではビジネスアナリストとビジネスアーキテクトは前述のような「大きく見れば仲間」とするような主張や、同じとは言わないまでも極めて近い隣接した仕事という主張も聞くようになってきました。実際ビジネスアナリシスのノウハウ集であるBABOKのバージョン3ではビジネスアナリストの職務を遂行することがある職種の例としてビジネスアーキテクトが紹介されていますし、またビジネスアナリシスを遂行する上で持つべき専門視点としてもビジネスアーキテクチャが紹介されています。

これらの動きはどちらかといえばビジネスアナリストコミュニティがその役割の範囲とキャリアの選択肢を広げようとする中で仕掛けている動きのように見えます。現状のビジネスアーキテクトのコミュニティはエンタープライズアーキテクトコミュニティ出身の人たちが多く、そのような人から見るとビジネスアナリストとビジネスアーキテクトは明確に違う役割であり、むしろエンタープライズアーキテクトやITアーキテクトとビジネスアーキテクトの境目の方が曖昧という認識のようです。

その役割が同じなのか、違うのかという議論は諸説ありますが、私(山本)のキャリアはビジネスアナリストとして個別プロジェクトの業務分析を担う役割からはじまり、最近ではビジネスアーキテクトとして企業に必要な変革活動全体を議論する役割を担うことが増えました。個々のプロジェクト経験を積みながら、徐々に視野を広げて経営的な視点から事業変革全体の管理を担う流れは一つのキャリアとして、私は成り立つと考えています。日本ではまだビジネスアナリストですら確立された役割とは言えませんが、将来的にそのどちらの役割も皆さんのキャリアの選択肢として加わることを願っています。

日本企業にもビジネスアーキテクトが必要なのではないか?

さてここまで紹介してきたビジネスアーキテクトですが、日本での知名度は皆無といって等しいかと思います。これがエンタープライズアーキテクトやITアーキテクトであれば数少ないとはいえそのような肩書で活躍されている方に会うことはできます。しかしビジネスアーキテクトという肩書で活動されている方はそれらよりもはるかに少ないのです。

もちろんビジネスアーキテクトは新しい役割です。IT導入の一般化に伴い、エンタープライズアーキテクトは1980~1990年代くらいから、ビジネスアナリストも2000年代くらいから普及しはじめた役割なのに対して、ビジネスアーキテクトは2010年前後に普及しはじめた役割です。これは2000年前後に言われた「IT革命」の結果として乱立したIT導入プロジェクトの整合性や効果への疑問からビジネスアーキテクトが設置されたという経緯があるためです。前述のユナイテッド航空のケース(2008年に設置)はかなり早い例のようで、カンファレンスで発表される事例を聞いていると2010年代前半(2011年~2013年あたり)に設置されているケースが多いようです。そう考えると、ビジネスアーキテクトはまだ海外でも普及途上にある役割なのです。

ただ、ここまで紹介してきたビジネスアーキテクトの役割を読めば、それがとても必然性のある大切な役割であることが分かるかと思います。私が関わる多くの日本企業でビジネスアーキテクトのような全社視点でプロジェクト組成時に適切なスコーピングと体制構築がされていないが故の失敗をたくさん見ています。

そのようなことが起きてしまう原因は多々ありますが、私はその中でも企業内の組織単位の在り方が大きな原因の一つだと考えています。企業の組織は多くの場合階層型で、各組織の権限と業務知識の及ぶ範囲は限定されています。大抵の企業は戦略を立案した後に、その実行は担当組織が割り当てられ、その組織が推進します。しかし既に書いたように企業が本当に多くの変革を効果的に進めていくためには組織単位ではなく意味ある業務(ないし製品やサービス)やシステムの単位で変革を進め、企業内の各組織の壁を超えた連携が必要になります。

このような組織を越えて連携する必要性が合意されていないままスタートしてしまった変革プロジェクトはほぼ間違いなく壁にぶちあたります。場合によっては中止や失敗となることすらあります。ですから、事前にその取り組みの意味ある単位と影響範囲を吟味し、必要な関係者と意思決定の在り方を考慮した適切なプロジェクトの組成を行う必要があるのです。多くの会社ではこのような検討を行う変革人材(ビジネスアーキテクト)を育てられていませんし、検討のためのアーキテクチャの可視化(例:プロセスマップやシステム構成図)も不十分なのが現状ですが、このような人材と仕組みの整備を経営直轄で行う必要があります。

日本企業においては変革人材全般(エンジニア、ビジネスアナリスト、プロジェクトマネージャー・・・)が不足しており、上位職ともいえるビジネスアーキテクトの育成はその次のフェーズなのかもしれませんが、このような人材の育成には大変時間がかかります。是非、ビジネスアーキテクトという役割を一つ、念頭において今後の企業変革を担う人材のポートフォリオを考えて頂けたらと思います。