ID:83134さん

freeeの支出管理事業部にて、DDDをベースとした設計文化を組織に展開するプロセスを推進。Event Storming・CQRS・ADRといった設計手法を、PoCで検証した上でチームへ導入し、設計判断の組織知化を進めています。複雑な業務ドメインの構造設計と、AI駆動開発を支える組織基盤の構築を、プロダクト開発と並行してマネジメントしています。

組織として以下の状態を作ることに責任を持っています： 1. 複雑な業務ドメインを、拡張性の高い構造として設計できるチームになっていること 2. 設計判断が個人の暗黙知にとどまらず、ADRなどで言語化され、組織知として蓄積されていること 3. AIを前提とした開発手法（ADR・設計ドキュメントを丁寧に整え、AIに実装させる）が、組織として再現性を持って運用できていること 4. ドメインエキスパートとエンジニアが、Event Stormingなどを通じて密に協働できる文化を持っていること 5. 戦略的DDDと戦術的DDDの両方が、実務で機能している状態

## アプローチの考え方 freeeのような大規模な組織で、DDDのような構造設計のアプローチをゼロベースで導入するには、トップダウンに「DDDを使え」と指示するのではなく、**実践と検証を通じて有効性を示しながら、組織に浸透させていく**必要があると考えました。 そのため、以下のステップで進めています： 1. **PoCでの検証**：Event Storming・CQRSといった手法を、まずPoC（小さなプロダクト）で実際に運用し、有効性を確認する 2. **設計判断の言語化**：ADRで設計判断を記録し、なぜその選択をしたかを組織に共有可能な形にする 3. **再現性の確保**：自分一人の知識として留めるのではなく、チームメンバーが同じ方法論で動けるよう、ドキュメント体系を整える 4. **AI駆動開発との統合**：ADRや設計ドキュメントを「AIが実装する前提のインプット」として位置づけ、品質と開発速度の両立を実現する ## 直面した問題と工夫 ### 問題1：DDDの戦術的パターンと戦略的アプローチの混同 DDDという言葉は広く知られていますが、「DDDを実践する」と言ったときに、戦術的パターン（Entity、Value Object、Repository）の実装に終始してしまう例が多くあります。本質的な価値である戦略的DDD（Bounded Context、Ubiquitous Language、Context Map）が抜け落ちると、複雑なドメインの構造化という本来の目的を達成できません。 **工夫**：戦術と戦略の両方を意識的に運用するため、ADRには「なぜこのBounded Contextをこう切ったか」「このContextでのUbiquitous Languageは何か」といった戦略レベルの判断も記録するようにしています。これにより、戦術的な実装が戦略的な意図と切り離されないようにしています。 ### 問題2：ドメインエキスパートとの対話の頻度・密度の確保 freeeでは、社外のドメインエキスパート（BPO会計事務所のお客様）と対話する機会はありますが、社内に常駐していないため、モデリングのイテレーション速度が制約されます。Event Stormingのような手法は、ドメインエキスパートと密に対話しながらモデルを進化させる前提のため、この制約をどう回避するかが課題でした。 **工夫**：FDE的なアプローチで、お客様に直接ヒアリングしながらPoCを開発することで、対話の密度を高めています。また、ヒアリングで得た知見をADRや設計ドキュメントに記録し、組織内で共有することで、対話に参加していないメンバーもドメイン知識をキャッチアップできる仕組みを作っています。 ### 問題3：AI駆動開発との両立 直近では、Claude Codeを月1万ドル規模で活用しており、AIに実装を任せる比率が高まっています。一方で、AIに任せると設計の意図が曖昧になりやすく、品質が下がるリスクもあります。 **工夫**：「AIが実装する前提のインプット設計」という考え方を確立し、ADR・設計ドキュメントを丁寧に整えることで、AIに対して明確な意図を伝える仕組みを作っています。CQRSの採用理由の一つも、複数のAIエージェントが並行開発しても衝突しない構造を作るためです。Bounded Contextの切り方も、AI並行開発を意識して設計しています。 ## 成果 - チームの設計方針統一および開発効率の向上 - 複雑な業務ドメインにおける拡張性の高い設計を実現 - ADRによる設計文化の組織への展開（設計判断が個人知から組織知へ） - AIを前提とした開発手法の確立による品質と開発速度の両立 ## 今後の展望 DDDのような構造設計は、AI時代に「何を作るか」を決める力として、エンジニアの価値の中心になっていくと考えています。今後は、戦略的DDDのアプローチをさらに組織に浸透させ、ドメインエキスパートとエンジニアが密に協働しながら、複雑なドメインを構造化していく文化を作り続けたいと考えています。

toC向けスタートアップ在籍時に、受託として請け負った店舗向けSaaSプロダクトの設計・開発を、フルスタックエンジニア兼プロダクト設計者としてマネジメント。予約・会計・EC・POSという4つの異なるドメインを横断するプロダクトの構造設計、開発プロセス、グロース施策までを一貫して担当しました。

プロダクトとして以下の状態を作ることに責任を持っていました： 1. 予約・会計・EC・POSという異なるドメインが、1つのプロダクトとして統合された体験を提供できること 2. 店舗運営者のリアルなオペレーションと、ユーザー向けアプリ体験が一貫した設計で統合されていること 3. 受託案件でありながら、ユーザー数を継続的に成長させられるプロダクトであること 4. データ分析を元にした継続的な機能改善のサイクルが回っていること

## アプローチの考え方 予約・会計・EC・POSという異なるドメインを1つのプロダクトとして提供する際、最も重要なのは「**それぞれのドメインの境界をどう設計するか**」という判断でした。境界を曖昧にすると、機能が増えるほど依存関係が複雑化し、保守不可能なコードになります。一方、境界を厳密に切りすぎると、ユーザー体験として分断された印象を与えてしまいます。 このバランスを取るために、以下を意識して進めました： 1. **ドメインモデルの境界設計**：各ドメインが独立して進化できるよう、データモデルとAPIの境界を明確に分離 2. **ユーザー体験の統合**：境界はバックエンドにあるが、フロントエンドではシームレスな体験として統合 3. **店舗運営者の業務観察**：実際の店舗オペレーションを観察し、UXとシステム設計に反映 ## 直面した問題と工夫 ### 問題1：4つのドメインの優先順位の判断 予約・会計・EC・POSのどれを優先して機能拡張するかは、店舗運営者のニーズによって変わります。受託案件であるため、クライアントの要望を全て受け入れていると、プロダクトとしての一貫性が失われるリスクがありました。 **工夫**：データ分析でユーザーの利用パターンを観察し、本当に頻度高く使われている機能を優先的に磨き込みました。クライアントとの対話でも、データを根拠に「この機能は本当に必要か」を議論できるようにしました。 ### 問題2：受託でありながらプロダクトとして成長させる 受託開発は基本的に「仕様通りに作る」ことが期待されます。一方、私はプロダクトとして10万ユーザー規模まで成長させたいと考えていました。 **工夫**：単に仕様を実装するだけでなく、データ分析や店舗運営者の観察を元に、機能改善やグロース施策を提案・実装しました。クライアントにとっても、ユーザー数が増えることはプラスなので、積極的に提案を受け入れてもらえました。 ## 成果 - ユーザー数10万人規模、100店舗導入 - 予約〜決済〜管理の一連の体験を統合し、業務効率化に寄与 - リアルなオペレーションとアプリ体験の統合設計を本格的に経験 - 現職（freee）でのDDDアプローチに繋がる、複雑ドメイン構造化の原体験となった ## この経験から得た学び このプロジェクトを通じて、複雑な業務ドメインをどう構造化するかという軸が、自分のキャリアの中心テーマとして固まりました。現職のfreeeでDDDをベースとした業務再設計を進めているのも、この経験が原体験になっています。