🗂
アーキテクチャカンファレンス参加報告（二日目のみ）：ドメイン戦略における「進め方」の判断軸

2025/11/24に公開
 はじめにこんにちは！日々開発に奔走しているエンジニアの R9999 です。
アーキテクチャカンファレンスの二日目の複数のセッションを受けてきたことをまとめ、日々感じている進め方は、正解なんてものはないと思っていますが、よりよい "複雑なドメインにどう立ち向かうか"、"プロダクト開発の進め方" について、答え合わせのような形でまとめてみようと思います。
我々開発者が、新しいプロダクトや既存システムのリアーキテクチャを進める際、「どこから手をつけるべきか？」「何が優先されるべきか？」は、多かれ少なかれ悩むことはあると思います、事業の軸はコレでいいのか、システムはこんな状態なので手を入れるならココだが、プロダクトとしてはどうか、システムプロダクトとしては良さそうだが、費用・投資対効果としていいのか、どういう戦略、戦術にしていくのがいいのかと感じながら、全ての納得感を得たわけではないですが、本記事では、カンファレンスで得た知見を元に、開発者が陥りがちな「進め方」の落とし穴を避け、目標達成に繋がる判断基準についてまとめていきます。

 1. ドメインの複雑性に向き合う：なぜ「進め方」の戦略が必要なのかドメインが複雑してきた背景は、人の価値観が多様化してきたことで、ビジネスの展開の仕方、向き合い方が変わってきたことによって、さまざまなドメインを意識しつつ、システムを構築してきたことで、複雑になってきていると感じています。

例えば、金融インフラストラクチャやSaaS型の基幹システム、あるいは病院向けの巨大で高密度な電子カルテシステム など、ドメイン固有の知識と、それが構造的な性質としてアーキテクチャに与える影響は計り知れないと感じています。

また、ビジネスの進め方も、トップダウンの設計だけでは限界があり、全容を掴みきれない広さや、例外パターンの山（高密度さ）が存在します。例外パターンが多すぎて、イレギュラーがレギュラー化している状態もあり、困難な状態が生まれています。

この複雑なドメインで開発をスケールさせ、疎結合を保ち、変化に柔軟に対応できるか、これがアーキテクチャが解くべき最大のチャレンジとなります。
ヘンリーさんが提示されていた、高密度な話。この状態遷移とユースケースを想像しただけで、業種は全く異なりますが、親近感を覚えました。


 2. 進め方の戦略：状況によって変わる「最初の一歩」プロダクト開発を成功させるためには、そのプロジェクトが「新規開発」なのか「既存開発（このときの話はリアーキテクチャ）」かによって、進め方の戦略を分ける必要があるという話がありました。

 戦略①：新規事業・コアドメインの構築の場合プロダクトを進める上で、サービスのコアになる、一番難しいところから進めていくのがいい、という考え方は、「コアドメイン」から進めるべきだと提言されていました。これは、コア構築せず、周辺から進めたとき、コアが当たらなかった時は意味のないものを構築するという話であるので、その通りと感じつつ、とはいえ、いきなり、大きく始めるのではなく、小さくはじめて効果を得てから実施という話ではあります。
コアドメインとは：サービスの差別化できるところ、他社が作ってもうまくいかない部分。
優先順位：ビジネスの価値をうむところから着手し、特に新規を立ち上げるときは、複雑性を解消するために難しいものから選択するのが効果的
人材配置：コアドメインには、ドメイン駆動設計（DDD）を適用することが推奨され、「よくできる人をあてる（ドメインエキスパート）」ことが成功の鍵とされています。
このアプローチは、最も重要なビジネスロジックと向き合い、複雑性を早期に解消し、競争力の源泉を確固たるものにするための戦略になります。

 戦略②：既存開発（リアーキテクチャ）の場合リアーキテクチャは、全部いきなり進めるのはよくないので、依存関係が少ないところから進める必要があります。いきなり根幹から手を入れいようとすると依存関係が多いので、大改修・ビッグバンリリースになりがちなので、避けた方がよいとされています。そのため、以下のような段階的なアプローチが推奨されています。
依存関係の少ないところから着手する：依存関係の少ないところから。これは機能であったり、運用に関わるオペレーションであったり、そのものを変更するところによって、影響する先が少ないものと捉えます。
コアドメインを薄くする努力：コアドメインが他の多くの部分に依存している場合、真ん中にある依存関係を後ろにずらす努力をし、そこから進める、という考え方もあるようです。この場合は、どのように進めるかは想像で語りますが、システムアプリケーションであれば、APIで切り替えできるようにしながら、交換可能な状態にして依存度を下げるものと推測しています（※懇親会の抽選にもれ、話をきけず・・・。）
リアーキテクチャの進め方で注意しなければならない点は、依存関係が少ないからといって、実施内容そのものは価値を出さない限り意味がありません。例えば、我々が開発者が「配送関連をマイクロサービスにしました！！！」と報告して、経営者・事業責任者から「何が嬉しいの？」という問いに答えられるよう、ビジネス価値との連携を意識する必要があります。

 3. 進化するアーキテクチャの形：モジュラーモノリスとAI活用複雑なドメインに取り組む際、アーキテクチャは進化する必要があり、マイクロサービスの話がぱっと思いつたりしますが、モジュラモノリスを行うにも、注意しなければならない進め方がありましたので、そちらをまとめます。

 モジュラーモノリスの進め方の注意点モノリスを単純に分割すれば成功するという話ではなく、ビジネスのドメイン（責任範囲）を深く理解しないまま、技術的な都合だけでサービスを細かく分割しすぎると、かえってサービス間の連携が複雑になり、モノリスよりも変更や結合のコストが高くなるという話がありました。
モジュラモノリスの説明
特徴：一つのアプリとしてデプロイされるが、内部はモジュールという単位で分離しています。
目的：論理的な分割にとどめることで、境界の調整コストを下げ、常に全員が境界の調整を実践できる環境を提供します。
実現方法：モジュール同士は public API を通じて連携し、お互いの詳細を隠蔽します。我々が目指すべき構成として、クリーンアーキテクチャをベースに、ユースケース層やドメイン層のレイヤーをモジュール単位で分割する設計が紹介されていました。

BFFを利用しながら共通化できる箇所は集約し、業種・業態によって、エンドユーザーが直接操作するとところ（UI/UX）は、オペレーションに沿うようにしているという話をいただきました。共通箇所はなんなのか、コアドメインをなんとするかの見極めは素晴らしいと感じます。


 最後に：プロダクト開発を進めていくには今回、さまざまなカンファレンスに参加しましたが、すごいと言われている方々も、何かしらの失敗を通じて今があり、これしたら良いなどは存在せず、事業、プロダクト、組織を見ながら、目標を設定し、実際に挑戦し、うまくいかなかったことに対して反省しつつも「伸びしろ」として捉え、次に繋げるにはどうするかを考える、という定期的な振り返り（KPTやYWTなど）が重要であることを改めて感じました。

 出席したセッション全てのセッションをまとめるよりは、今回、感じている自分自身のもやつきを中心記載しております。
DDDが導く戦略的トレードオフのアート
ドメイン駆動設計とマイクロサービスアーキテクチャ
SaaS拡大期の成長痛　〜モジュラーモノリスへのリアーキと生成AIの活用〜
【パネル特別企画】現場課題から考えるセマンティックレイヤーとデータモデリング
多様な最適化サービス開発をスケールさせる共通基盤とチーム構成
全員アーキテクトで挑む、巨大で高密度なドメインの紐解き方
制度的トラストを支えるアーキテクチャ - デジタル時代の公共性とその実務
AIで加速する次世代のBill Oneアーキテクチャ ― 成長の先にある軌道修正

 余談）アーキテクチャカンファレンス会場の道のり当日朝、電車遅延と会場を調べた結果、天空橋駅からを案内された・・・・めっちゃ遠かった・・・近いだろうと思っていたので走りました!（アプリだと１０分くらいと書いてあったけど、今見ると全然・・・そんなことない・・・）
第三ターミナルからいけば近かったのと、わかりやすかったのと、・・・会場はエレベーター降りたらすぐだった・・・。