SecureNavi株式会社でSecureLightのエンジニアをやっているホッケ肉厚（@HokkeNikuatsu）です！
2025年11月21日に開催されたアーキテクチャ Conference 2025の1日目に参加してきました！
この記事では、私が参加して特に感銘を受けたセッションの内容と感想を共有します！
アーキテクチャ Conference 2025について
アーキテクチャ Conference 2025は、Findly Toolsが主催する「ソフトウェアのアーキテクチャの構想・判断・構築にまつわるリアルな知見を共有し、多角的な視点から設計判断への理解を深め、最適な設計を考えるためのエンジニアイベント」です！
場所はベルサール羽田空港、申込者数は5,000人超と非常に大きなイベントで、セッションの他にも協賛企業が開発しているウェブサービスのアーキテクチャ図の展示、企業ブースでの呼び込み、無料のコーヒーやお弁当のサービスなど様々な工夫が凝らされており、とても盛り上がっていました👏
イベントの今年のテーマは「最適なアーキテクチャをどう描くか」。
スペシャルゲストによるキーノートや、各社のアーキテクチャに関する試行錯誤の歴史や体験談など、面白い話をたくさん聞くことが出来ました！
セッション内容のグラレコもありました！
セッションレポート
セッション1：モダナイズの現実と選択：マイクロサービスが最適解か？ by Sam Newman
「Building Microservices」の著者でマイクロサービス分野の権威であるSam Newman氏による、マイクロサービスの概要・他アーキテクチャスタイルとの比較・マイクロサービスへのリアーキテクチャの進め方などに関するキーノートセッションでした！
冒頭では、マイクロサービスの定義を「サービス指向アーキテクチャ（Service Oriented Architecture）の形態の一つで、ビジネスドメインによって独立したサービスを個別にデプロイ可能なように分割するスタイルである」と説明するところから始まり、マイクロサービスが技術的な境界ではなく業務的な境界を意識した分割によってドメインを定義していくことを終始強調していたのが印象的でした。
マイクロサービスを取り入れることによるメリットは技術的関心事に閉じておらず、ビジネスサイドのステークホルダー含めビジネス全体を前に進めることを目的としたアプローチであることを改めて認識することが出来ました🙆♂️
また、マイクロサービスを導入する際のよくある誤解とマインドセットについての説明も分かりやすかったです。
特に、以下のような当たり前だけど非常に重要なtipsを丁寧に解説しており、説得力がありました。
- 手に負えないような大きな泥団子であっても、まずはモノリス、そしてマイクロサービスへと段階的な移行が出来ること
- 他の樹木や岩などに着生し最終的に宿主となる木を枯らしてしまうStrangler Fig（絞め殺しの木）のように、古いモジュールの周りを新しいモジュールでラップしながら徐々に置き換えられること
- 変更量の多い爆弾リリースの削減やリリース後のロールバック処理の簡素化など様々なメリットがあるので、デプロイとリリースは切り離して考える・実行すること
今までは単なる設計手法としか捉えていなかったマイクロサービスですが、この講演のおかげで一段階広い視点で俯瞰し理解を深めることが出来た気がします。
将来的なサービス統合などが発生する場合に備えて、マイクロサービスへの知見を更に深めたいと強く感じました👏
セッション2：Figma, Inc. CPO登壇 アイデアを爆速でプロダクトに落とし込むには by Yuhki Yamashita
Figma CPOのYuhki Yamashita氏による、デザインに対するマインドを開発のライフサイクルへ還元し、プロダクトの成長を実現するための考え方について深堀りするQA方式のセッションでした！
ちなみに、Yuhki氏は数年前に私が語学留学をしていた時に知り、「グローバルプロダクトのCPOをやっている日本生まれのすごい人がいる」ということに感銘を受けてファンになった方でした。
本人が見れるということで、一番楽しみにしていたセッションでした！（…が、オンライン登壇だと当日に気づき、ちょっとショックでした…笑）
まず、Yuhki氏いわく、Figmaのプロダクトが躍進した要因は（良くも悪くも）コロナ禍による影響によりプレコロナでは当たり前だったコミュニケーションの形が崩れた結果、URLのみでデザインを共有出来るブラウザベースのFigmaが業界のメインストリームになったから、と紹介していました。
そして、デザインの共有と認知の負荷が下がることによって、あらゆるロールのステークホルダーがデザインにアクセスしてFBやアイディアを出し合い、Figma上で行われるデザイン活動が個人に紐づくものではなくチームに紐づくものとなる、そんな「境界を曖昧にする」世界線を思い描いている、と語っていました。
技術的には関心事で細分化していくのがスタンダードだけど、価値を生み出すためにチームがそれぞれのタイトルに縛られず壁を取り除いてcollaborate（協業）していくマインドが大切であることを終始説いており、私が普段意識している考え方に近く共感しっぱなしでした🤔
また、AIがプロダクトディスカバリーやデザインワークなどに与える影響についてのQAもありましたが、Yuhki氏はAIを否定的には捉えておらず、適切にAIを使うことでヒトとAIは上手に付き合っていけるというスタンスを取られていたことが印象的でした。
最近もFigma Makeがリリースされたように、FigmaもAIを活用したデザインプロセスの変革に取り組んでいますが、それは全てのプロセスをAIに置き換えることを意味している訳ではなく、AIはヒトのinsight（洞察や新たな発見）をサポートするためのものであると話していました。
そのため、プロダクトの方向性を決めるアイディエーションやプランニングなどのプロセス、そしてその方向性をベースとしたレビュー、この2軸でこれからもヒトの価値は必要であり続けるだろうとのことでした。
私も、（少なくとも現時点では）AIにより個々人の生産性の平均値は上がったけど、より良いものを創造出来るのはヒトであると思っていたので、その時々でAIとの関わり方を柔軟かつ明確に定義していく重要性を再認識することが出来ました🙆♂️
セッション3：マルチドライブアーキテクチャ：複数の駆動力でプロダクトを前進させる by Loglass
事業変化によってアーキテクチャが限界を迎えるリスクを低減するために、経営戦略とアーキテクチャの間にある”駆動力”の差を分析し、最適解を実際の開発に落とし込んだ事例を紹介するセッションでした！
まず、開発が関わる事業活動を長期の戦略計画（Strategic）、中期の管理統制（Management）、短期の業務統制（Operation）の3つに分類すると、それぞれには以下の異なる駆動力があるとのことでした。
- 長期：ビジョン駆動（競争優位の源泉）
- 中期：イネーブルメント駆動（開発効率の強化）
-
短期：オポチュニティ駆動（ビジネス最前線の機会対応）
また、行う施策については効果（導入による純粋なメリット）と導入コスト（速度 × 結合度）を比較し、その時々で最も効果的な施策を選択することの重要性も説明されていました。
これらが整備出来ていないと、「ビジネスを前に進めたいのに改善に時間を食ってばかりいる」や、「長期的なゴールのための前進ばかりで保守性を犠牲にしている」などのよくある事態に陥るので、それぞれの施策を時間軸によるコスパを加味して適切に分離することで同時に実行可能になる、というのが大枠のメッセージだったと認識しています👀
事例紹介では、長期のビジョン駆動によりリアーキテクチャを実現したお話と、中期のイネーブルメント駆動で共通基盤化を実現したお話を聞くことが出来ました。
特にリアーキテクチャの話では、現場開発と距離を置き徹底的な調査、要件化、モデリングを行うことで他の改善活動との衝突を避けることや、その次のフェーズで理想的な設計と既存設計との乖離や衝突を防ぐために現場とのFBを重ねたことなどの工夫を説明されており、複数の大規模プロジェクトを進める際のtipsとして参考になる部分がたくさんありました。
また余談ですが、発表を聞いているとLoglassさんは自社内で独自のユビキタス言語を明確に定義し浸透させていたり、問題を構造化して分析 → 効果を測定するサイクルを定着させていたりと、構造化 & 適用の文化が根付いている印象を受けました😦
構造化は個人としても組織としてもまだまだだなと思っていたため、今回の事例を参考に適切な切り口で継続的な改善を進めていきたいと強く思いました！
セッション4：グローバルなコンパウンド戦略を支えるモジュラーモノリスとドメイン駆動設計 by DRESS CODE
複数プロダクトの高速リリースを可能にしたアーキテクチャの工夫について、特にモジュラーモノリスとDDDの構成にフォーカスして説明されていたセッションでした！
特に複数プロダクトを扱う上ではバックエンドの処理を適切に境界付けないとすぐに拡張性が悪くなってしまいますが、コード品質を保つために行っている以下のような工夫が印象的でした。
- APIのReadはService経由、WriteはDomain経由とする（Event Sourcingの場合でもDomain経由を徹底すること）
- ただし、他プロダクトのモジュールに対する処理の場合は…
- Readの場合はQuery Service経由とする
- Writeの場合は他プロダクトのAdapterやCommandを経由する
- 他モジュールへの処理がある場合には、自モジュールにそのデータのRead Modelも配置し、変更のイベントを発行してデータ更新することも検討中
- 全てのアプリケーションから呼び出される共通モジュールは専用の集約基盤を配置し、集約ルートに適切なvalidationを設定する & 集約のサイズを適切に保つ
また、モジュラーモノリスを採用する場合にDBをモジュールごとに分けるか、それとも統合するか、という議論のポイントについては、分離のバランス・運用効率・柔軟性の観点で同じDB内でスキーマ分離することを推奨されており、実運用を通じて見つけた解として貴重なナレッジでした✍
その他にも、AIによるコード生成の品質を高める方法について、集約を適切に分割すること、そして集約に適切な制約を課すことの重要性についても触れられていました。
特に集約のサイズについては、無理してサイズを小さく保つよりは、集約を適切に実装することを優先し、集約の大きさ・スケーラビリティ・AIとの相性は次点で検討しつつ境界を定義していくことが運用コストを含めた最終的な落とし所だったと振り返っていました。
スピードを緩めずに集約をベストな状態にメンテしていく難しさを感じると同時に、大事なのはどのようなメリデメがあるのかを把握した上で納得して運用するということなのかな、と思いました🤔
最近、私も将来的な拡張性を加味したドメインモデルの分離やCRUDの整理に悩んでいたところだったため、大規模サービスの設計方針を垣間見ることが出来て面白かったです！
まとめ
普段は見過ごしてしまうようなセッションにもあえて参加してみたりしましたが、どの内容も示唆に富んでいて大変多くの刺激を受けた一日でした！
ソフト面・ハード面で得たことをこれからの開発に活かしていきたいと思います！
また、今回は弊社エンジニアも数名誘って参加したので、お互いが参加したセッションの内容をすぐに情報交換し、普段の開発にどう活かしていくかを議論出来たことも有意義で楽しかったです！
今後は更に知識を共有する場を増やす施策を行っていきたいです🏃
採用やってます！
SecureNaviでは一緒に働く仲間を募集しています✋️
弊社では、SecureNavi・SecureLight・Fit&Gap・2線の匠クラウドなど様々なプロダクトを開発するチームがあります！
カジュアルにお話から始めることも出来るので、興味を持った方はぜひお気軽にご連絡ください🙏
募集ポジションはこちら👇️
求人一覧 - SecureNavi株式会社
カジュアル面談はこちら👇️
カジュアル面談 - SecureNavi株式会社
Discussion