参加目的
2025年11月20, 21日に開催されたアーキテクチャConference2025に両日参加してきました。
普段はバックエンドエンジニアとして開発に携わっていますが、アーキテクチャ設計に関わる機会が増えてきたため、各社の事例を参考に知見を深めることを目的として参加しました。
登壇資料一覧はこちらです。
どの資料も非常に作り込まれており、ただ解説をしても意味がないと思うため、セッション内容については基本的に触れないようにします。
本記事では、セッションを見たり、ブースで各社のエンジニアの方々と会話させていただいた上で特に印象に残ったポイントや学びを自分なりに咀嚼してまとめていこうと思います。
現在の自分の状態
アーキテクチャ図を見て、何がどう繋がっているのか、どのような役割を果たしているのかは大体理解できます。
要求事項から必要なリソースを洗い出し、設計することも最近経験できています。
ただ、それが現時点での最適解なのか、将来的にどう影響するのか、他に比較すべき選択肢はないのかといった視点において、まだまだ経験値が足りていないと感じています。
今回のカンファレンスを通じてそのあたりの視点を少しでも補えたらと思い、参加しました。
カンファレンス参加前の考え
あるDX支援プロジェクトに参画しており、分断された複数システム（営業支援、採用管理、勤怠管理など）の統合と業務の一気通貫化を進めています。
当初は以下の理由から、モジュラーモノリスが妥当そうだと判断していました。
- 業務間の連携が密で、同期的な処理や横断的な整合性が重要
- 段階的な投資とリスク低減を優先し、大規模分割を初期から避けたい
初期からマイクロサービス化すると、サービス間通信や運用の複雑性が増しむしろ非効率になり得ます。さらに、複雑で変化の多いドメインでは分割の誤りが後戻りコストを大きくします。
参考にさせていただいたシステム設計の記事（Next.js × Hono × モノレポで実践する「リアルオプション戦略」：初期の開発速度と将来の柔軟性を両立させるWebシステム設計）でも、「将来の変更可能性を確保し、その時々の最適解を選択できる状態を維持する」という戦略が紹介されており、非常に共感しました。
加えて、初期の開発速度やその他諸々の制約も考慮すると、将来的により正確な投資判断ができる材料が揃ってからマイクロサービス化を検討するのが良いのでは、と考えていました。
参加後の学び①： システムの成長予測を考慮したアーキテクチャ選択
しかし、今回ブースで直接話を聞く中で、あらためて考えさせられたポイントがあります。
それは、「システムの成長を見込んだ上で、将来マイクロサービス化する際に本当に投資回収が見込めるのか」という点です。
モノリスがしんどくなってくれば切り出せば良い、という当初の考え方は一見正しいように感じていました。
しかし実際には、切り出すための工数やリスクも無視できません。
最悪の場合、当初マイクロサービスを避けた際の懸念（サービス間通信の複雑性、運用コストの増加など）と同じ問題に、移行コストを追加で払った上で直面する可能性があります。
「変更容易性」との言葉尻だけで判断をしかけていたことに気づかされました。
話を聞いたいくつかのプロダクトでマイクロサービス化を完了していたり、現在進行形で対応中という事例を聞きましたが、
開発当初と移行を決断した際の背景を聞くと、単に「しんどくなったから」ではなく、システムの成長予測と移行コストを天秤にかけた上での判断であることがわかりました。
また、前提としてこれらのプロダクトは不確実性が高い新規プロダクト開発であったため、自分の現在参画しているプロジェクトとは状況が異なる点も見えてきました。
それに対し、本プロジェクトでは既に行われている業務やそのボリュームの洗い出しが実施され全体像がわかっているので、将来的にどのようにシステムが成長していくのか、どのような負荷がかかるのかの予測は比較的立てやすそうな状況です。
このような 「成長予測が立てやすい」という前提 に立つと、後からの移行コストを避け、最初からマイクロサービスアーキテクチャを採用することも検討に値するのではないかと考えるようになりました。
ただし、Sam Newman（サム・ニューマン）氏がセッションで主張されていたように、あくまでマイクロサービスアーキテクチャは手段の一つであり、目的ではありません。
マイクロサービスかモジュラーモノリスかと言った手段の選択に囚われるのではなく、まずは明確な成果(Outcome)を定義した上で、その達成に向けた最適な手段としてアーキテクチャを選択していければと思います。
参加後の学び②： ドメイン理解にAIは使えない。人間中心のアプローチの重要性
こちらは『AI駆動開発を実現するためのアーキテクチャと取り組み』のセッションで話されていた内容です。
「ドメイン理解にAIは活用できない」という点は、直近のプロジェクトの経験と重なる部分があり非常に納得感がありました。
実際、普段から積極的にAIを活用している自分ですが、ドメイン理解自体にAIを効果的に使えた場面はありませんでした。
（もちろん理解した内容の整理やドキュメント化、要件定義の補助などでは役立つところはありました）
当然ですが、実際の業務フローは現場の方しか知りませんし、AIでヒアリングを代替することはできません。
人間が理解して初めて深掘りすべきポイントや疑問点が見えてくるため、あくまで人間が主体となってドメイン理解を進める必要があります。
逆に補助的に活用できたポイントとしては、以下のようなものがあります。
-
NotebookLMを使いプロジェクトの情報を全て集約（議事録、その他提供資料など）
- 専門用語リストを作成する際に活用
- 不明な専門用語や概念の調査
-
Claude Codeを使い、テキスト整理した業務フローからdraw.ioでの業務フロー図（スイムレーン）生成
- カスタムスラッシュコマンドで再利用化
- 要件からシステム構成図のドラフト生成
情報の整理や構造化に役立てたり、専門用語の調査など、ドメイン理解の補助的な役割としては有効でした。
また、インプットした情報から作図やドラフト生成などの活用も効果的と感じました。
しかし、業務ドメインの本質的な理解は別次元の話です。
実際の業務は現場で人間が行うものであり、その背景には過去から積み上げられてきた膨大なコンテキストがあります。
このような現場の暗黙知や業務の「なぜ」を理解するには、人間による観察とヒアリングが不可欠です。いくら高性能なAIがあっても、このコンテキストを完全に把握することはできません。
実感としてはあったものの、改めて言語化され明確になったことは有益でした。
今後もドメイン理解のフェーズでは人間中心のアプローチを重視していきたいと思います。
カンファレンス参加を受けての次のアクション
本カンファレンスで得た学びを踏まえ、以下のポイントで改めて意識して設計やAI活用を進めていきたいと思います。
-
アーキテクチャ選択方針
- 成長予測を踏まえたアーキテクチャ選択
- 明確な成果(Outcome)に基づく最適な手段の選択（マイクロサービスかモノリスかに囚われない）
-
ドメイン理解でのAI活用方針
- 人間中心のアプローチ維持し、AIは補助的役割に限定
- 情報整理、ドラフト生成などでの効果的な活用（チーム内で再利用性の高い仕組み作り）
おわりに
会場では各社のアーキテクチャ図が公開されていたりと、非常に学びの多いイベントでした。
ログインは必要ですが、以下サイトでもアーキテクチャ図が多数掲載されているので、こちらも活用しつつ自分の知見を深めていきたいと思います。
そしてなんと会場ではオライリーの書籍が10%オフで購入できました。自分は以下の2冊を購入しました。
限定Tシャツもゲットできて大満足です！👏
参考
Discussion