現代においてビジネスとITの橋渡し役は誰が担うのか - ビジネスアーキテクトとプロダクトマネージャーの関係から考える

ITアーキテクトの起源

ITアーキテクトという職種は、1990年代から2000年代にかけて確立されました。僕がキャリアをスタートした頃です。特にIBMやMicrosoftなどの大手ITベンダーが、「ITアーキテクト」「ソリューションアーキテクト」といった職種を定義し、主にエンタープライズシステムの設計を専門とする役割を担わせました。

当時のエンタープライズシステム開発は、いわゆるウォーターフォール型が主流であり、ITアーキテクトは「ユーザー要件から、技術的制約を意識しつつ、上流工程でシステムのアーキテクチャを固める」ことが求められました。

2000年代にIBMのプロジェクトマネージャーと会話したときには「まずITアーキテクトが、何をどう作るか定めないと、プロジェクトマネージャーは登場しないよ」と言っていたのが印象的でした。外資ITベンダーではITアーキテクトという職種が非常に重視されていました。僕もコミュニティイベントなどを通じて交流しましたが、みなさん、知的好奇心に溢れ、技術の可能性を信じ、新たなビジネスの創出に突き進んでいました。

しかし、このような「上流工程でアーキテクチャを定める」という役割が世の中に拡がっていくと「ユーザー要件からスタートする」という重要な部分が抜け落ち、象牙の塔のアーキテクト問題が発生します。

象牙の塔のアーキテクト問題

「象牙の塔」の語源は19世紀に遡りますが「自ら望んで俗世間から離れ、主に精神的で難解な探求を行う場所の隠喩」です。転じて、 象牙の塔のアーキテクト（Ivory Tower Architect）とは「開発現場の実態もわからずに、理想論的な設計を押し付けるアーキテクト」を意味します。

象牙の塔のアーキテクトは、 技術書籍や誰かが提唱した理論を鵜呑みし、実際の開発や運用が困難な理想論的アーキテクチャを押し付けます。また、上流工程でしか関わらないことから、実装段階での苦労や問題が共有されず、その被害を広げることになります。

2000年代はフレームワークや技術基盤の選択肢が少なく、機能も不十分なため、システム開発会社がフレームワークやアーキテクチャを作り込むのは良くあることでした。こうした場合、ユーザー要件に関係なく作り込むので「複雑な要件に対応できないシンプルな仕組み」か「複雑な要件に対応するためにシンプルな要件でも複雑な仕組み」になります。45歳以上のエンジニアの中にはオレオレフレームワークを作った黒歴史がある人も多いはずです（僕もです）。

ちなみに「象牙の塔のアーキテクト」は、現代になっても続いている問題です。「必ず〇〇の原則に従うのだ」とか「〇〇設計論が美しい、絶対だ」というタイプです。そうした原則や設計論を知っていることは重要ですが、一方で「銀の弾丸はない」という原則も理解しておくべきです。ITアーキテクトを目指す人が象牙の塔に引きこもるのは必要な過程（中二病）ですが、そこにいてもユーザー要件がわかるわけではないので、引きこもりを脱し、現場に足を運ぶようになると、本当に優秀なITアーキテクトになれるでしょう。

アーキテクチャ設計の民主化

さて、2000年代にクラウドやDevOpsが登場し、2010年代に一気に普及し始めると、ITアーキテクトの役割にも変化があります。

クラウドサービスの機能が拡充し、システム基盤構築に必要なコストや技術的障壁が大幅に低下することで、結果として、チーム単位でもアーキテクチャ設計が求められ、多くのエンジニアがアーキテクト的な役割を担うようになります。

特に大きな影響を与えたのは2014年に公開された記事「Microservices（マイクロサービス）」でしょう。9つの特徴の1つとして「Decentralized Governance（分散型ガバナンス）」が紹介され、中央集権的に標準化された言語やフレームワークを否定しました。「自分で実装し、自分で運用する文化」（build it / run it ethos）によって、チームは自律的に技術を選定し、実装するようになります。

これまでITアーキテクトという一部の人材がシステムの全体像を定めていた流れに対し、多くのエンジニアがアーキテクチャ設計に取り組むようになったのはアーキテクチャ設計の民主化とも言えることでしょう。

現代の標準化といえるIDPとSRE

しかし、2020年代を迎える頃には、こうしたアーキテクチャ設計の民主化の問題点も指摘されます。プロダクト単位どころか、サービス単位に独自のツールやアーキテクチャが乱立し、人が辞めたり、異動することで、運用管理やセキュリティの問題が多発するようになります。ガバナンスが分散化し過ぎてしまったのです。

こうした「他人が作り込んだ技術的負債」は新しく参加したエンジニアにとって大きな負荷になります。そこで、改めて「開発者体験（DX：Developer eXperience）」の重要性が提唱され、開発におけるガバナンスのガードレールを敷くために「内部向け開発プラットフォーム（IDP：Internal Developer Platform）」の整備を目的としたプラットフォーム・エンジニアリングという分野が登場しました。

DevOpsの流れから成立したSRE（Site Reliability Engineering）が運用上の信頼性を重視するのに対し、プラットフォーム・エンジニアリングは開発者の開発スピードを重視します。これらは1つのものを2つの方向から見ているだけで、会社によっては分離されていても、その取り組みは密接に関わります。

こうしたプラットフォームを利用したツールやノウハウの整備は現代的な標準化と捉えることができます。

• プラットフォームエンジニアリングチームやSREチームが全社的な視点で開発環境や運用環境をプラットフォームとして整備
• 各サービスチームのエンジニアは、そのプラットフォームの上でスピード感を持ってサービスを開発・運用する

チームトポロジーにおけるプラットフォームチームとストリームアラインドチームの関係と理解していいでしょう。

現代における「ビジネスとITの橋渡し役」

ここまでの整理すると、

• アーキテクトという言葉には「全体を考える人」という印象があり、象牙の塔に引きこもりがち
• 一方で、アーキテクチャ設計は民主化され、プラットフォームを通じてガバナンスを保証する

という感じです。特にDXやウェブサービスの文脈では、この流れが顕著でしょう。

なので、ビジネスとITをつなぐ「ビジネスアーキテクト」という言葉も、ややネガティブに捉えられているのかな？という気がします。出自もITベンダーなのでSIer感が漂うこともあり、ビジネスとITの橋渡しの主導は社員の「プロダクトマネージャー」が望ましい、というのは正しい方向性です。

技術面についてはプラットフォームエンジニアリングチームやSREチームが全体アーキテクチャを緩やかに定義し、企業（事業）として必要最低限のガバナンスを効かせた基盤が整備します。チームはスピードとガバナンスを両立しながら、個別の要件に合わせたアーキテクチャを考えることができます。

アーキテクチャとアーキテクチャ設計の重要性は変わらないものの、技術の進化によってビジネスとITの橋渡しはさまざまな役割に溶け込み、再定義されつつある、と感じます。

現代においてビジネスとITの橋渡しをするロール

もちろん、現在でもエンタープライズの大型案件では「ITアーキテクト」は重要な役割です。一方でDXやウェブサービスの文脈なら、アーキテクトという言葉に囚われない方が「ビジネスとITを繋ぐ役割」にたどり着けると思います。

まずは、ビジネスとITの橋渡しにおいて、主な視点がどこにあるのかを意識する必要があります。

その上で、個人的な考えとして4つのロールに分割してみました。上に行くほどビジネスや製品戦略を重視し、下に行くほど技術や全社統制を重視します。ビジネスとITの橋渡しなので、そのバランスはゼロイチではなく、各ロールにおいて適切に分担されています。

こうした分割は優劣の問題ではなく、IT業界の成熟に伴う適切な分業です。ビジネスアーキテクトというのは「技術的な知識があるプロダクトマネージャー（もしくは、その支援ができる人材）」と言うあたりな気がしますが、どうですかね。プロダクトマネージャーに、どの程度の技術的知識を求めるのかは様々な意見がありそうです。テクノロジーディレクターは、重要な役割だと思っているのですが、なんか良い名前がなくて困っています。

この分割に対する異論は大歓迎なので @yusuke_arclamp にメンションください。

まとめ

ビジネスとITの橋渡しは、システム開発において重要な役割です。いまだにITアーキテクトという役割も重要でしょうが、技術の進化を前提に、プロダクト開発の文脈ではビジネスとITの橋渡しを様々なロールが協業しながら実現するようになっているようです。もっと明確な役割定義がなされ、多くの人が、その役割を目指していくことを期待しています。ここは簡単にはAIで代替できないと思うし。

【宣伝】2024年末に書籍を出版しました。クラウド、DevOps、マイクロサービス、プラットフォームエンジニアリングといったキーワードの歴史と、その内容や活用法について解説しています。