技術とビジネスを越境するアーキテクトの実践
セッション終盤、テーマはデブサミのテーマでもある「事業成長」とアーキテクチャの関係へと踏み込む。技術とビジネスをどう接続し、アーキテクトは何を担うのか。
まず語ったのは米久保氏だ。「アーキテクトにとって最も重要なのは事業理解だ。ビジネスモデルや戦略、売上規模や投資額、将来求められる成長率といった数値を、『経営の話』として切り離してはいけない。それらを理解して初めて、事業に整合したアーキテクチャ戦略を描ける」。
米久保氏が例に挙げたのは、自身が担当するエンタープライズ向けBtoBプロダクトだ。既存顧客を前提とした事業では、ゼロイチの軽快さよりも、十分な機能セットと高い安定性が求められる。そうした前提から、エンタープライズ要件に耐える基盤設計や柔軟なカスタマイズ性、プラグインアーキテクチャ、さらにはマルチテナントではなくシングルテナントを選択する判断が導かれたという。
重要なのは、流行技術ありきで設計しないことだ。目的が先にあり、技術はあくまで手段である。手段が目的化しないためにも、アーキテクトは事業を深く理解し、ビジネスサイドと適切な議論ができる関係性を築く必要があると米久保氏は強調した。
小田中氏もこれに同意する。SaaSにおけるFit to Standardの是非一つを取っても、保守性や多様性、ユーザー体験といったビジネス価値と結び付けて説明できなければ、技術的判断は受け入れられない。ビジネス理解は前提条件だという指摘だ。
続いて尾髙氏が、事業会社の立場から語る。事業会社では、技術が利益を生まなければ生き残ることすらできない。そのため、技術活動が事業戦略とどれだけ整合しているかが、よりシビアに問われる。
「1行のコードがいくらの利益を生むか、直接示すことはできない。しかし、自分たちの取り組みが、どのような構造を通じてビジネス価値を生んでいるのかを整理し、説明することはできる。それもアーキテクトの仕事だ」
そのためには、見通しの良い構造や、安全に変更できる文化・組織を整える意義を、まず周囲に理解してもらう必要があるという。
さらに尾髙氏は、「良いシステムは良い組織から生まれる」と話す。どれほど上位で保守性や疎結合を唱えても、現場のマネージャーが合意していなければ浸透しない。組織は文化であり、最終的には個人の集合体だからこそ、個人の成長を押し上げる取り組みが欠かせないというのだ。
話題はやがて、アーキテクトが直面する「壁」に及んだ。尾髙氏は、25年積み重ねてきた基幹システムのリアーキテクチャを例に挙げた。マイクロサービスやイベントソーシングを導入するには、帳票中心・RDB前提で築かれてきた従来の世界観を前提から見直す必要がある。その転換に対して、すぐに現場の同意が得られたわけではなかったという。「なぜ今、変える必要があるのか」を理解してもらうこと自体が、大きなハードルだった。
その打開策として尾髙氏が紹介したのが、既存チームの負担を最小限に抑えつつ、段階的に移行できる雛形を用意する取り組みだ。いきなり全面刷新を迫るのではなく、部分的に置き換える導線を整えることで、変化への心理的ハードルを下げていった。AI活用なども含め、「楽になる」体験を先に示しながら進める工夫が有効だったという。
一方、米久保氏は「壁は、乗り越えるたびに形を変えて現れる」と語る。一人で完結するアーキテクトから、組織をスケールさせる立場へと移る中で、技術だけでは解決できない課題が増えていった。組織を変えるには仲間が必要であり、コネクションを広げ、時には社内政治とも向き合う必要があると率直に語る。
「社内政治」という言葉にはネガティブな印象がつきまとうが、実際には、多数の人間が関わる組織で物事を進めるための合意形成プロセスを指している。その過程では、立場や関心の異なる人々のあいだで丁寧なコミュニケーションを重ねることが不可欠だ。異なる価値観や時間軸を翻訳し、相互に理解可能な形でつなぐ行為こそがアーキテクトに求められる越境力であるという点で、三者の認識は一致した。
セッションの締めくくりとして、アーキテクトを志す人に向けたメッセージが送られた。
米久保氏は、「アーキテクトの形は一つではない。技術から入っても、業務から入っても構わない」と前置きしたうえで、その本質は肩書きではなく、事業や組織に対してどのような価値を生み出すかにあると語る。
これを受けて尾髙氏は、「アーキテクトになること自体を目的にしてほしくない」と強調した。何を実現したいのか、どんな課題を解きたいのかを問い続けた結果として役割が立ち上がり、そこに後から名前が与えられるという立場だ。
両者の言葉は、アーキテクトとは到達点ではなく、価値創出の過程で自然に立ち現れる役割であることを静かに示していた。
