2025年2月末にLTSオフィスにてRoger T. Burlton氏（Process Renewal Group 代表）によるチュートリアルが開催されました。経産省の「デジタルスキル標準」をはじめとしてビジネスアーキテクチャに関する多様な議論が巻き起こる中、本領域を牽引するロジャー氏はどのような理論を提唱しているのでしょうか。
今回は、LTS常務執行役員 山本政樹が本領域のコンサルタントとして、またLTSの社内ビジネスアナリスト大井悠がBA実務家の視点で、ロジャー氏のビジネスアーキテクチャ論への見解、そしてそれを日本企業に適応するにあたっての課題感やアーキテクトに必要なスキルについてお伝えしていきます。
チュートリアル概要 ～ビジネス全体像を捉えて全体最適を目指す～
大井：
今回の講師であるロジャー・T・バールトン氏は、ビジネスプロセスマネジメントの世界的な専門家で、顧客へのコンサルティングや執筆活動、様々な専門コミュニティ活動への参画を通して知見を提供しています。また、ビジネスプロセスマネジメント（BPM）の知見を発展させ、エンタープライズアーキテクチャ（EA）やビジネスアナリシスといった専門コミュニティと協調しながらビジネスアーキテクチャを整合されたコンセプトとしてまとめてきました。
今回のチュートリアルではロジャー氏の著書『Business Architecture –Collecting, Connecting, and Correcting the Dots-』をベースに、ビジネスアーキテクチャの概念やマインドセットに関する講義とケーススタディによる演習が行われました。
ビジネスアーキテクチャとは、戦略、ステークホルダー、IT、ビジネスプロセス、データ…など様々な観点でビジネスの構成要素を捉え、ビジネス全体における戦略実現に向けて各々の整合性をとっていくという考え方です。
私たちは変革を企画する際に、プロジェクトという単位で取り組みを組成しがちですが、プロジェクトという括りを設けることで、視野がプロジェクトのスコープの中に閉じてしまいます。ビジネスはいろいろな部門、ビジネスプロセス、IT基盤がさながらオーケストラのように連携しながら実行されます。そのため、特定のスコープに閉じた取り組みだけでは全体最適を目指すことは難しくなります。
ビジネスアーキテクチャの考えでは、1つのソリューション、1つのプロジェクトといった単位ではなく、事業・組織全体の構造がどうなっているのかを理解したうえで、戦略意図を実現するためにどのように変革していくべきか、またどこを変革していくべきかを選定します。そして切り出された個々のプロジェクトが、ビジネスアーキテクチャ全体の変革意図から外れていないか、を適宜モニタリングし、整合性が保たれるように調整します。 チュートリアルではどのようにビジネスアーキテクチャの構造を捉えるのか、戦略と整合をとっていくのか、ケイパビリティを開発するのか、ビジネスアーキテクチャを実現し、評価するための観点が説明されました。
ロジャー氏は広大な世界観を持つ
山本：
ビジネスアーキテクチャとは個々のプロジェクトに閉じた取り組みではなく、戦略・ビジネスモデル・ITの全てを内包していますね。ビジネスアーキテクテクチャに関する理論は他にも様々なものがあるわけですが、ロジャー氏の理論は他と比較して、非常に広大な世界観を持っていると感じています。
大井：
そうですね。
例えば過去のEAでは、ITアーキテクチャの視点が強く、ビジネスアーキテクチャは個々のシステム（アプリケーション）が支えている、業務機能の認識のみに偏りがちでしたが、ロジャー氏はビジネスを根底から捉えていて、アプリケーションはもとより、戦略やビジネスモデルもビジネスアーキテクチャの一部としています。
EAや他のビジネスアーキテクチャの方法論と、ロジャー氏が定義するビジネスアーキテクチャの考え方は、重なる部分もありますが、その範囲にはかなり差があるのではないでしょうか。
山本：
そうですね。ロジャー氏は、現在最も広い視野でビジネスアーキテクチャを捉えている人物だと思います。チュートリアルで会話した際に、彼は一部のビジネス変革に関する方法論が、方法論の論理的整合性を追求するあまりに、議論の視野が狭くなってしまっていることを嘆いていました。
ここまでもキーワードとして登場しているように、ビジネス変革の方法論にはビジネスアーキテクチャだけでなく、ビジネスプロセスマネジメントやビジネスアナリシスなどの様々なものがあり、ビジネス変革という視点では大きく同じ世界観を共有しています。近い世界にある方法論なので、似たような概念が登場したり、同じ言葉を共有していたりするわけですが、登場した背景も運営者も異なるので、それぞれの方法論は独自の定義がされています。本来であれば、方法論間で同じ言葉は同じ定義の方が良いですし、異なる方法論を連携して使える方がのぞましいのですが、個別の方法論の立場からみると、他の方法論で定義されている概念や用語に受け入れられないものがあったり、方法論を連携させようとすると矛盾が生じてしまう部分が現れてしまったりします。
よって特定の方法論の中だけで完璧な論理的整合性をとろうとすると、他の方法論の考え方を受け入れるのではなく、それらの都合の良い部分だけ取り入れるか、そうでない部分は概念を切り捨ててしまったり、他の方法論とは違う独自の定義を別に作ったりした方が、その方法論単体としての完成度は高くなります。それはその方法論の監修者の立場としては満足のいくものになるのかもしれません。しかし、現実のビジネスに方法論の境界はありません。どれだけ方法論単体としての完成度が高くても、他の方法論も参照したいときにその差異が大きすぎると、扱いづらいものになってしまいますし、ユーザーを混乱させる要因にもなります。
ですからロジャー氏は、それぞれの方法論の研究者が、議論をオープンに行い、お互いの方法論で連携できる部分を探したり、使い分けの考え方を明確にしていったりすることで、ユーザーフレンドリーなものにしていくことが大切だと考えているようです。それぞれの観点や定義の差異を認めつつも、むしろ議論を活発にして、その議論から方法論の垣根を超えて価値のある考え方を探していくという姿勢ですね。
大井：
ロジャー氏は個々の方法論の狭い枠組みに囚われず、ビジネス全体から俯瞰した目線で、独自のビジネスアーキテクチャ論を編み出していますよね。
山本：
実は私は、2017年頃に初めてロジャー氏のビジネスアーキテクチャの概念を聞いた当初は、「方法論の寄せ集め」のような印象を受けたのです。ところが、しっかりと話を聞いてみるとそうではなく、個々の方法論のテリトリに縛られずに関係性があるものを繋げ、概念を広げていった結果、たどりついたイメージが彼のビジネスアーキテクチャの世界なのだと気づきました。
ロジャー氏は、最終的にはビジネスプロセス・IT以外にも、社内の人間関係等の人間的な要素へのアプローチが必要であることも考慮して、ビジネスアーキテクチャを構築しています。そういった部分から、ロジャー氏には常に人間を向いた前向きさを感じます。
ビジネスアーキテクトは人の心に訴求する仕事
大井：
ビジネスアーキテクトはこのような広大な理論をもとに、ロジックを組みモデリングするだけでなく、様々な部署のステークホルダーの視点を合わせて合意を得なくてはなりません。
そう考えた時、結局ビジネスアーキテクトに求められるものは何なのでしょうか。
山本：
ビジネスアーキテクトはロジックと感情のバランスが大事だと思っています。デジタルや構造の世界にいると、ロジック重視で語ってしまうところがありますが、実際のビジネスは感情の塊です。 皆、変化の恐れや不安は持っていますし、「全体最適は大切」と言いつつも、自分や自部門の立場が悪くなることには、たとえ合理的な判断であっても反対することもあります。長期的な投資が大切、と口ではいいながらも、現実には短期の業績創出に忙殺されたりもします。そういった感情的なものや、“理想と現実”が複雑に絡んでいる変革の現場を前に進めるためには、人間に対する洞察が必須です。そのような感情を持つことは人として当然なのだ、という前提にたって、それでもなぜ変革が必要なのか、不確実性にどう向きあうのかという議論を丁寧に行っていく必要があります。組織は人間の集合体だからこそ、素晴らしいことも残念なことも起きることを理解し、内部の視点を合わせて全員が同じものを合意できるように導かなくてはなりません。
大井：
人の心をいかに動かすのかが、変革プロジェクトの明暗を分ける要因となりますよね。
それでいうと「信頼感」はビジネスアーキテクトに欠かせないのではないでしょうか。この人は自分のことをよくわかってくれている、と信頼を寄せてもらうからこそ成り立つポジションだと思います。
山本：
そうですね。
とある基幹システム刷新のリーダーを担当されていた方も、信頼貯金・信頼貯金が大切だと仰っていました。「あなたがそう言うのであれば、正解だろうから信じるよ！」と言ってもらえるような関係性作りが必要ということです。
専門家チームで日本のビジネスを変える
大井：
勿論ビジネスアーキテクトには論理性・知識、そして信頼感・感情のバランスは必須ですが、これを一人の人間が全て体現するのは難しいと感じています。
山本：
大切なのは異なる視点や考え方を持っている人が、普段から協業し、オープンに議論することだと思います。現実の企業が変革では、このような多様な目線をふまえて変革を進められていないことが多いと感じます。
例えばIT視点が強い人は、技術の世界からビジネスを覗いているので、先ほど例に出したような、普段ビジネス部門が置かれている状況での心理的ストレスや、個々の従業員の感情的な側面をしっかり捉えられていないと感じることが多いです。逆にビジネス視点ばかりが強いと、技術の持つ可能性やリスクに驚くほど無知であったり、自分や自部門の都合だけを意識してしまって全体最適に意識が向けられていないことがあります。もちろん経営であったとしても、全体を俯瞰できているようで、実は個々の現場の事情は押えられていなかったりと、どこか情報の偏りはありますよね。
ですから、さまざまな立場の人が集まって、皆の見え方を同じ机の上に広げて議論した際に、そこにどのような風景が広がるかということが大切だと感じます。
大井：
見えているものは立場によって違い、さらに一部分しか見えてないことが現実ですよね。ビジネスアーキテクトは、それらを全部一貫した視野で見なくてはならないのですが、日本企業では機能が分化されており、ビジネスアーキテクトのように機能横断でアーキテクチャの構造を管轄するポジションが置かれているケースはかなり稀です。身近に模範となる人材がほとんどいないことに課題を感じています。
山本：
そうですね。日本ではビジネスアーキテクトという専門職のポジションが稀で、体系的に学び訓練する環境も整っていません。ビジネスアーキテクトというポジションを設けたとしても、必要な経験・スキルが備わっていない、周囲からの理解を得られにくい、といった側面からそのアーキテクトが1人で変革を実現するのは難しいでしょう。ですが、ビジネス部門、ITチーム、ビジネスアナリストといった、異なる立場の人が協力してチーム戦で挑めば、その機能を代替できる可能性はあるのではないでしょうか。
チーム戦とはいっても大きな横軸での繋がりが必要で、ITに強い人・ビジネスに強い人と様々な領域のスペシャリストを集めて「ビジネスアーキテクツ」を結成するイメージですね。
仮にアーキテクトというポジションを置かなくとも、多様な専門的知識と横軸の繋がりで、経営層への提案・サポートするチームが出来たら良いと思います。LTSとしてもこれまで以上に、そのような企業の変革を進める人材と体制を構築するお手伝いをしていきたいですね。
