バックオフィス基盤第1グループの廖です。アーキテクチャーConference2025に参加してきました。 2日間にわたるセッションを通じて、多くの学びを得ました。特に印象に残ったポイントと、これまでの開発経験を交えて感想をシェアしたいと思います。

学び

1. マイクロサービスは目的ではなく、あくまでも手段の１つである

1日目の「モダナイズの現実と選択：マイクロサービスが最適解か？」の基調講演で、講演者のSam Newmanさんは過去にコンサルとして企業から依頼を受けた際に一番怖い言葉が「We are doing microservices」だと語っていました。一部の企業では、上層部がマイクロサービスが良さそうだという理由で導入を決定することがあります。しかし、実際には多くの問題が発生し、マイクロサービスが適していないと感じても、既に選択したために無理に継続するケースがあるそうです。モノリスにも、全体を管理しやすい、横断的に開発しやすいというメリットがあります。だからこそ、真の目的と解消したい根本的な問題は何なのかを考えることが重要だと再認識しました。確かに、今までの開発経験を振り返ると、今の会社に入った時点ですでにマイクロサービスが浸透していて、マイクロサービスを選択したメリットはある程度理解できていると思っていたのですが、その「なぜ」もモノリスに戻す選択肢もそこまで深く考えたことがあまりなかったです。

学び/気づき

よくよく考えると、今まで開発してきたマイクロサービスの中で、以下のような問題が発生したことがあります。

サービスの分割しすぎたことがあります。サービスの分割が過剰になると、APIの数や開発工数、コストが増加します。また、データが複数のサービスを跨ぐため、運用時の調査コストも上がります。そのため、新規にマイクロサービスを作る際には、本当に必要かどうか、その責務を自分やチームに問い続けることが重要です。
モノリスから一部機能を切り出してマイクロサービスが作られましたが、まだ密結合が解消されてない部分があります。この経験から、ドメインの整理が不十分なままマイクロサービスを導入すると、システム全体の複雑性が増し、期待した効果が得られないこともあるかと気づきました。

Next Action

今後は、新しいマイクロサービスを立ち上げる議論が発生する時、その必要性と責務を明確にし、チーム全体で議論することを徹底しようと考えてます。

2.モノリスとマイクロサービス以外、他にも選択肢がある

今回はSam Newmanさんの講演でもいくつか他の登壇者の講演でも聞いたモノリスとマイクロサービス以外の選択肢として、モジューラモノリスという方法を紹介していました。この方法は名前の通りにモノリスとマイクロサービスの結合体のようなものです。モノリスとしてのシンプルさを維持しつつ、ドメインごとにモジュールを分けることによって、マイクロサービスと似たような独立性も保つことができます。デメリットとしては、モノリスと同じく、コードベースが大きくなりがちで、かつ、デプロイ単位が同じになることで、小さい修正でもデプロイ負荷がマイクロサービスと比べたら高いです。まだ実践したことはありませんが、今後の選択肢の1つとして、頭の片隅に入れておこうと思います。この話から、設計はA案かB案の二者択一ではなく、さまざまな視点で考えると他の選択肢もあるのではないかと改めて思いました。

学び/気づき

モジュラモノリスという選択肢を知ることで、設計の幅が広がりました。これにより、プロジェクトの要件に応じて最適なアーキテクチャを選択することができるようになります。

Next Action

現在、技術戦略として「アーキテクチャや技術スタックをある程度統一する」という方針を採用しているため、プロジェクトの要件に応じてモジュラモノリスを選択する機会はあまりないかと思います。ですが、新規事業立ち上げの際には、モジュラモノリスも含めた複数のアーキテクチャの選択肢を検討し、チーム全体で最適な方法を選ぶようにします。

3.アーキテクトは一番賢い人である必要がない

Gregor Hohpeさんの「アーキテクト思考」講演では、一番印象に残ったのは下記のいくつかのポイントです。

アーキテクトは一番の賢い人である必要がなく、他の人が賢くなるように導いていく人であるべきです。
ベストプラクティスをそのまま追随するのは危ない。「Google/Meta/Netflixはその設計だったらうちもこれをコピーしよう」という発想は危険で、なぜかというと、企業・チームの状況は違うからです。全ての設計にはその理由、本当の目的をよく考えるべきです。
一人で責任を取って全てを設計するより、チーム全員の知見を集めて設計した方がいいです。

チームの中で最も経験豊富なメンバーが設計し、レビュー会か共有会などで他のメンバーたちが意見を言うが、それでも大枠はその設計に従って開発することが今までたくさんあったなと思いました。自分も一人で設計し、その設計をそのまま他のメンバーに渡したことがあります。このやり方は、長期的な視点で考えると健全ではないなと感じました。
なぜこの設計になったのかの経緯を深掘りしにくいという問題があります。また、経験者の設計だから大丈夫だろうと安易に考えてしまいがちです。その結果、設計に潜むリスクが見えない、または見えても言いにくい状況が生まれます。さらに、チームとしては経験者に頼りっぱなしになり、他のメンバーたちは意思決定や他の業務の面で成長しづらくなります。経験者がチームから離れた後、なぜこの設計になったのかという質問が外部から来たら、結局答えられる人がいない可能性もあります。また、どんなにすごい人であっても、人として思考の偏り・好みなどがあるので、個人の力よりチームの力を集めて沢山の角度から材料を集めて判断した方が最適な選択に導いていけるはずです。

学び/気づき

アーキテクトは全ての設計を巻き取るというより、他のメンバーが賢くなるように導く役割を持つべきであり、チーム全体の知見を集めて設計することが重要であると学びました。

Next Action

今後は、設計のプロセスにおいてチーム全体の意見を積極的に取り入れ、設計議論会やレビュー会を通じて全員が理解し納得できる設計を目指します。

4.より広い視点を

同じGregor Hohpeさんの「アーキテクト思考」講演では、設計案に関する事例が挙げられました。例えば、B案の処理速度の5msはA案の15msより速度が３倍早いという数字が提示され、一見すると3倍という数字がとてもインパクト大きそうに見えますが、実際ページレンダリングの方は500ms処理時間がかかっています。この事例から見たら、細かいところを注視するより、視点を広げてこの選択が本当に最適なのかを考えることも重要です。エンジニアはやはり普段の仕事では自分のチーム・部署のやっていることに集中しがちな気がします。悪いことではないですが、集中しすぎてしまうと、ある問題に対して改善策を考える際に、普段関わっているところに対してしか改善案を考えられず、実際他のところを改善した方が効果が高い可能性があると忘れてしまいます。

学び/気づき

細部にこだわりすぎず、全体の最適化を図るために広い視点を持つことの重要性を再認識しました。

Next Action

今後は、問題解決の際に広い視点を持ち、他のチームや部署との連携を強化しつつ、全体の最適化を意識して改善策を考えるようにします。

次から実践したいこと

今回たくさんの講演を聞いてきた中、色々覚えきれないことがたくさんありますが、上記の紹介した感想以外に今後実践してみたいことも下記のようにあります。

AI駆動開発ライフサイクル（AI-DLC）
AWS社から提唱されるAIによる開発の進め方です。「AIはすべての開発プロセスを実行し、人間は検証、意思決定、監督の最終的な責任を持つ」という開発手法です。現状我々のチームでは生成AIを使って開発していますが、人によって活用度合いがまだバラバラです。今後はもっと生産性を上げるために、もっとAIと仲良くなりながら、このAI-DLCを導入してみたいと考えてます。
イベントストーミング
ドメイン駆動設計での開発を行う上で採用されている手法の1つです。（手法の詳細は割愛します）
新サービス立ち上げの際に今のチームでこの手法を実施されたようですが、他のサービスに対しても実施してみたいと考えています。
その理由は、隣接する既存のサービス間の境界線が曖昧になっており、依存関係の切り離しがうまくできていない部分があるためです。具体例として、数年前に作られた決済サービスがありますが、他のサービスでもまだ決済情報が管理されている部分があり、決済情報が管理画面などから参照される際に、参照先がどこにするべきかという混乱が生じやすい状況です。
元々このサービスを作り直したいと考えたこともありますが、もし設計がうまくできなかったら、悪く言えば、一つの問題から別の問題への変換になる可能性があります。最適な選択を導き出すために、まずはイベントストーミングを実施して、ドメインの整理と依存関係の明確化を図りたいと考えています。
全員アーキテクト思考
ヘンリー社の「全員アーキテクトで挑む、巨大で高密度なドメインの紐解き方」講演で聴いたコンセプトです。特定の個人・チームに設計を依存する状態があまり良くないと私自身の経験からも他の講演からも深く感じたことなので、グループマネージャーとして意識的にこの状態から脱却し、一人一人主体性を持って「全員アーキテクト」の環境づくりを心がけていきたいと思います。

余談1

今回のカンファレンスの基調講演では、講演内容に対してグラフィックレコーディングも行われて、結構わかりやすく内容がまとめられました。非常に参考になるかと思います。

余談2

Oisix社のMollard Michaelさんの講演では、クライミングと仕事に意外と「失敗を恐れず、トライし続ける」という共通点があると話されました。ちょうど今年から私もクライミングにハマり始めて、多少共感してはいますが、正直まだ臆病者として登る際にまだ落ちる失敗を恐れることがあって途中で諦めたことが何回もありました。ここで伝えたいのは、失敗を恐れても、この恐怖心と共存しつつも、恐怖心以外に何か改善できることがないかを分析・改善し、リトライし続けるのであれば、ゴールにすぐ到達できなくても進歩は見えると思います。

余談3

弊社の小堀さんも今回のカンファレンスに登壇してきたので、興味がある方は下記の紹介記事を読んでいただければと思います。
アーキテクチャConference2025にて「AIエージェントのためのゼロトラスト・アーキテクチャ」について登壇してきました

最後に

今回のアーキテクチャーカンファレンス2025に参加して、多くの貴重な知見を得ることができました。特に、マイクロサービスの適用に関する考え方や、モノリスとマイクロサービス以外の選択肢、アーキテクトの役割についての新しい視点を、今後のプロジェクトに役立てていこうと思います。
このレポートを最後までお読みいただき、ありがとうございました。