小チームでコンテキスト責務を持つ_1ヶ月間の実践知

26.07.30 DDDとモジュール分割、実際どうだった？を語り合う勉強会

Transcript

1. 小チームでコンテキスト責務を持つ、 1ヶ 月間の実践知 DDDとモジュール分割、実際どうだった？を語り合う勉強会 ⼩野寺 宣裕 2026.07.30
2. ⾃⼰紹介 名前 ⼩野寺 宣裕 所属 スペースマーケット / Trustユニット GitHub: deera0520
3. 会社紹介
4. ドメイン駆動設計（DDD）のおさらい 業務のモデルを設計の中⼼に置き、モデルとコードを⼀致させる設計思想 • 複雑さの主因は技術ではなく業務 • 業務の⾔葉でモデルを作り、その⾔葉をコードの名前にする • 戦略的設計、戦術的設計
5. 今回、話す内容 戦略的設計 戦術的設計 境界づけられたコンテキスト（ BC） エンティティ、値オブジェクト コンテキストマップ 集約、リポジトリ BCの責任を小チームに持たせ、そこでの実践内容を共有します DDD Starter Modelling Process — ddd-crew DDDを8ステップで進めるガイド。6番目に 境界とチーム という内容がありました。 https://github.com/ddd-crew/ddd-starter-modelling-process
6. ミッションと取り組み ミッション • 課題解決を要求品質以上で限られた期間ので届ける • 満たす条件は期間と品質 • 開発速度を取り戻す 取り組み内容 • ⼤規模リファクタリング。 コア機能の旧基盤から新基盤への移⾏。昨年から継続。 • 単純な書き換えではなく、適切なモジュール分割、RubyからTS、 REST から GraphQL 、データ構造の変更など
7. これまでの半年間の進め⽅とその課題 これまで進め方: 7〜9名で、設計を書いてレビューして実装する。 AIによりコードを書く速度は確実に増えた 1. 解像度が揃わない 2. レビューが機能しない 3. 境界の会話ができない 一人の範囲が広く、 特定メンバーしかレビューをできな い 「大きな単位で 同じ仕様を見ても 掴んでいる深さが違う 切り出すべきか」を 話す余裕がない
8. ⽬指す状態 特定領域に対して意思決定ができる すなわち、 ⾃信を持って『説明ができる』『説明できる』状態
9. 直近の体制 振り返りをもとに、移行チーム全体で方針を相談して、この形になりました プロジェクトマネージャー Aチーム Bチーム Cチーム コンテキストA コンテキストC コンテキストD BFF コンテキストB FE App 各チーム3名体制。明確に責任範囲を定義することでオーナーシップを発揮し複雑性をコントロール。小 チームがそれぞれの課題を定義し、それぞれの方法を探求している状態になった。
10. 境界を切るときの観点 作り変えやすいか 移行の当事者として、この先も変わると分かっている 複雑さを隔離できるか 絡み合うものを分けて、依存を下げる 小チームが深く持てるサイズか 一人が広く持つと、また浅くなる 「将来ほかから使うかもしれない」は理由にしていません。それだけだと YAGNIになるので。 課題の 3つ目にあった「境界の会話」を行い、このような形になった
11. ⾃チーム施策紹介 モブワークの取り組み モブワーク 導⼊の背景‧課題 3⼈で同じ画⾯を⾒て進める 理想と現実 ⼀⼈で設計を書いてレビューに出す従 来のやり⽅を廃⽌し、設計を⼀緒に進 める形へ移⾏。 理想は「⼀⼈が⼤きな範囲を持って意 思決定すること」ですが、現状の実⼒ では困難。 割り当ては多め ドメイン知識‧プロジェクト推 進⼒ 量は週16時間（3〜4時間を週4⽇）を モブワークに投資しました。 メンバー間でドメイン知識とプロジェ クト推進⼒に濃淡がある。 期待する3つの狙い 1. チーム内での出戻りを最⼩限 にする 2.ドメイン知識のスムーズな伝達 3. レビューがボトルネックにな らない
12. リモート＆モブワークツール • sssx • orca • ssh共有 デファクトスタンダードと⾔われるものがなく試⾏錯誤
13. 1ヶ⽉間の取り組みの結果 • ⼤きめな設計を進め実装に着⼿したのは今週から 蓋を開けると、移⾏設計が複雑で想定より考慮する事が多かった。 • モブならレビュー不要は検証できていない • 6⽉までは品質が⾜りず、7⽉は速度がでなかった
14. スピードがでなかった要因の分析 個人 + レビュー1名 モブ（同期・全員合意） ゲートは 1つ 3つ全部を通さないと進まない これまでの半年は、レビューはゲートが少ない構造であるため浅さが発生していた。 対して、複雑な課題に対して、深く内容を検討することはできた。
15. 現状の課題 モブと個人ワークの配分は、まだ答えが出ていない → 戻せない判断だけをモブに乗せる、という切り分けで試す 「モブならレビューが要らない」は未検証 → 8月は実装が進むので、そこで答え合わせ 一人で判断に責任を持てる範囲が、まだ広がっていない → ここが広がることが、一人がAIを使って大きな範囲を持てる目安
16. 所感とアクション • ベストまではまだ遠い • 論点整理をモブで⾏い実装は各⾃ • モブではタイムボックスを意識 • AIレビューの作り込みなど、できることはたくさんある 8月も継続探求 ！ エンジニア探求が大事！
17. スペースマーケットでは あああ 新しい仲間を募集しています！
18. ご清聴 ありがとうございました
19. 参考資料 DDD Starter Modelling Process — ddd-crew DDDを8ステップで進めるガイド。6番目に「境界にチームを沿わせる」が入っています。 github.com/ddd-crew/ddd-starter-modelling-process Bounded Context Canvas — ddd-crew BC1つの責務と公開インターフェースを埋めるテンプレート。 github.com/ddd-crew/bounded-context-canvas Context Mapping — ddd-crew（Michael Plöd） 9つのコンテキストマップパターンと、3つのチーム関係。 github.com/ddd-crew/context-mapping いずれも CC BY-SA 4.0
20. CONFIDENTIAL