この記事は CADDi Tech/Product Advent Calendar 2025 の 5 日目の記事です。
こんにちは、キャディで CADDi Quote の開発をしている majimaccho です。 今回は、2025 年 11 月に開催されたアーキテクチャカンファレンス 2025 のキーノートセッションに参加した際のある一つの講演に電撃を受けたようなビビビッと来た話を共有したいと思います。 文字にすると当たり前だな〜と自分でも思ってしまいますが、自分の中で本当に腹落ちしたことをシェアしたいと思います。
TL;DR
アーキテクチャカンファレンス 2025 に参加して、このイベントのキーノートを聞いて自分の考え方が大きく変わりました。
今回の気づきを一言で表すと、以下の通りです。
- 技術的な意思決定において、関係者全員がトレードオフを理解した上で意思決定できるように支援することがアーキテクトの役割である
- 技術的な意思決定において、自分がいいと思っているアイデアを伝えるだけでは十分ではない
- ただ意見を伝えるだけでは、意見を持っている人の 1 人に過ぎない
アーキテクチャの意思決定はトレードオフであるということは理解していたつもりでしたが、そのことに対する向き合い方が間違っていたと気付かされました。
この記事について
この記事は、2025 年 11 月に開催されたアーキテクチャカンファレンス 2025 のキーノートセッションの内容に基づいていますが、セッション内容の紹介や要約を目的としたものではありません。 あくまで、私個人の気づきや学びを共有することを目的としています。
想定読者
ミドルくらいのエンジニア、技術リードやアーキテクト、システム設計に関心のあるエンジニアを想定しています。
イベントとキーノート
今回の記事は アーキテクチャカンファレンス 2025 のキーノートセッションに基づいています。 Gregor Hohpe 氏の「アーキテクト思考 ― チームでより良い技術的意思決定を導くリーダーシップ」というタイトルの講演でした。
architecture-con.findy-tools.io
反省： イベントに参加する前の自分の考え方
アーキテクチャ上の意思決定はトレードオフであるということはわかっているつもりでいました。 しかし、アーキテクチャ上の意思決定を行う際に、潜在的に自分の持っているバイアスに気付かず、自分の意見を押し通そうとしてしまっていることがありました。
つまり、結論ありきで、その結論を正当化するための理由付けをしていました。
また、自分がいいアイディアを考えて、それを通すことのみが技術的なリーダーの役割（アーキテクトはその最上級）だと思っていました。 自分の意見がなぜいいのか、他者の意見がなぜ悪いのかというコミュニケーションをしてしまっていたことがありました。 時には「〜の方が直感的」「〜の方が自然」「〜の方が好み」なんていう言い方をしてしまっている時もあります。自分はアーキテクトと呼ばれるポジションではないですが、技術的な意思決定を行う立場ではある。その上で、これらは悪い振る舞いだと考えるようになりました。
目から鱗が落ちた話
和訳： アーキテクトは部屋の中で最も賢い人ではない。彼らは他の全員をより賢くする人だ。
このスライドを見たときに、ハッとしました。そして、この講演を通じて、自分の考え方が大きく変わりました。反省の項に書いたように、自分の意見が正しいということを主張してきたのではないかと考えさせられました。またそれは、最も賢い人であろうとしてしまっていたのだと気付きました。
ここからは、この講演で特に印象に残ったポイントをスライドと合わせて紹介します。 ※ あくまで、私自身が印象に残ったポイントであり、講演内容の要約や紹介を目的としたものではありません。
魔法の砂時計
このスライドでは、「バズワードになっているような内容
（マイクロサービス | CQRS | DDD | クリーンアーキテクチャ）が必要だから、人と時間、お金を確保して実行に移すけれども、なぜその方法なのか、なぜ他の方法ではないのか意味のあるロジックが不足している状態でことがよくある。この状態では、多くのリソースをかけて、何かを大きなことを成し遂げたとしても、得たかった成果は得られない可能性が高い」という話がありました。砂時計の形は How と Why の間のロジックが極めて薄いことを表現しています。
このロジックの部分が非常に重要で、意思決定を行う際に当然重要なはずだけれどもなぜか欠落してしまうものだという話でした。 そんなことがあってはいけないのは誰でもわかっているはずなのに、なぜか起きてしまう、ということに心当たりがありました。特にジュニアの時ほど、ベストプラクティス 1 つしか知らない状態でそれを盲目的に信じてしまったり、それを正当化するための理由付けを後から考えてしまったりしてしまうことがあると思います。
選択肢と次元を発見する
よくある意思決定の例として、モノリス vs マイクロサービスの話がありました。
スケーラビリティの話をする際に、モノリスとマイクロサービスを比較することがよくあります。
この軸のみで比較した場合、マイクロサービスに軍配が上がります。 しかし、この時に、もう 1 つの次元を加えることを提案していました。それは、デザイン時なのかランタイムなのか、という次元です。
軸を加えることで、4 章限のマトリクスが生まれます。
（次のスライドの写真を撮りそびれましたが、左上は複製、右下はモジュラーモノリスだということが示されます。）
実際（発表者）が同様の議論を Google で行った時に複製が選ばれたと言われていました。Hohpe 氏がこの Google で議論をしたのは、モジュラーモノリスやマイクロサービスという言葉が生まれる前です。今の時代の私たちは最初から、モノリス・モジュラーモノリス・マイクロサービスという言葉がある状態で議論を始めることはできるでしょう。
しかし、それらがどう異なるのか、どの軸で比較すればよいのかを考えることは依然として重要です。 自分の関心のある軸だけで議論を始めてしまうと、他の重要な観点が抜け落ちてしまう可能性があります。テーブルに十分な選択肢と判断軸を揃えられるかというのが、アーキテクトの手腕が問われる部分だと思います。
異なる観点を考慮する
この「軸を発見する」ということは、異なる視点を持つ関係者同士でのコミュニケーションにおいても重要です。アーキテクチャは短期・長期での開発速度、運用負荷、テスト容易性、セキュリティ、ビジネス戦略あらゆる側面（次元）があります。そういった関係者が認識を揃えるということはそれぞれの次元が考慮されていることを確認することでもあります。
データを揃える
「データがなければ、あなたは意見を持っている人の 1 人に過ぎない」
異なる立場の人たちが集まって意思決定を行う際に、各々が自分の意見を持ち寄るだけでは、単なる意見のぶつかり合いになってしまいます。できるかぎり具体的で測定可能なデータを揃えることが重要です。 しかし、データを揃えることにコストがかかりすぎる場合もあります。その場合は、各々の意見がどのような前提に基づいているのかを明確にすることも有効です。 前提条件を明確にすることは、無意識のバイアスに気付くことにもつながります。
アーキテクトブーメラン
How の話をする時に Why に立ち返ってから選択肢をプリンシプルに照らし合わせて評価することが重要であるとこのスライドとその前で説明がありました。名前をつけてもらえた＋イラスト化ことで、この考え方を忘れにくくなりそうです。
アーキテクトエレベーター
アーキテクトは会社組織の最も上のレイヤー（経営層、CTO）にも、最も下のレイヤー（開発者）にも説明責任がありますが、各層の語彙は完全に異なっているので言葉を使い分けなければなりません。
完全に語彙が異なるとはっきり言われていました。つまり、アーキテクトは各層の語彙を理解し、適切に翻訳して伝える能力が求められるということです。開発者の語彙で経営層に説明しても伝わりませんし、その逆も同様です。 開発者からアーキテクトと呼ばれるようになるまでに新たな領域の学習が求められるということだと理解しました。
おわりに
アーキテクトというロールを特別に担っているわけではない私ですが、技術的な意思決定を行う立場として非常に学びの多い講演でした。 企業によってはそのロールが明確に定義されていない場合もあるかもしれませんが、技術的な意思決定を行う立場にあるエンジニアであれば、意識すべき内容だと思います。 AI が普及していく中で、技術的な意思決定を行う立場にあるエンジニアの役割はますます重要になっていくと思います。
意思決定に必要な選択肢と次元を揃え、関係者全員がトレードオフを理解した上で意思決定ができるように学ぶべきことは多いと感じたイベントでした。
