📖 第 1 章：なぜ今、ドメインモデリングなのか？

1.1 開発現場で聞こえる悩み

スクラム開発をしていると、よくこんな声を耳にしませんか？

• モデルをちゃんと作りたいけど、そんな時間がない
• 実装が進むにつれて設計が崩れていく
• バックログはあるけど、どこか整合性が取れていない

こうした悩みの多くは、「ドメインモデル」という考え方が軽視されていたり、チームの中でうまく活用できていないことが原因になっていることが少なくありません。

1.2 本書の出発点：「モデルは話すための道具」

まず最初に伝えたいことは、ドメインモデルとは「重厚な設計書」ではない、ということです。 むしろそれは、**チームで会話するための“思考の道具”**であり、軽く始めて少しずつ育てていくものです。

モデルを作る目的は、美しい設計を描くことではなく、実装前に「話が通じる状態」を作ることにあります。

1.3 ドメインモデルとは何か？

ドメインモデルとは、次のように定義できます。

現実世界の業務ルールや構造を、ソフトウェアとして理解しやすく表現したもの

その形はさまざまで、クラス図かもしれませんし、イベントストーミングの結果かもしれません。 大切なのは、それがチーム全体で共通認識を持てる表現になっていることです。

「注文」「商品」「支払い」といった業務の中心にある概念が、どのように関係し、どのようなルールで動くのか。 これを共有できていれば、曖昧な仕様や無駄な修正は減り、開発がスムーズに進みます。

1.4 DDD（ドメイン駆動設計）が再注目される理由

近年、ドメイン駆動設計（DDD）があらためて注目されています。 その背景には、ソフトウェアの複雑さがますます増しているという現実があります。

• マイクロサービス化
• 高頻度リリース
• 非同期処理の普及
• 多様な業務要件

こうした中で、「早く作る」だけでは限界が来ています。 業務の本質を正しく捉える力が、より一層求められるようになっているのです。

1.5 Scrum × モデルというアプローチ

かつて DDD は「重たい」「ウォーターフォール的」といった誤解を受けることもありました。 しかし今では、「チームで話すためのモデル」「会話を支える道具」として再評価されつつあります。

Scrum のように短いサイクルでフィードバックを重ねていく開発スタイルと、 軽やかに使えるドメインモデルの技法は、非常に相性が良いのです。

本書では、Scrum の各フェーズと調和する形で、どのようにモデリングを行っていけるかを、段階的に解説していきます。

🔚 第 1 章まとめ

• ドメインモデルは重い設計書ではなく、会話のための道具
• 業務の構造を正しく理解することが、品質と速度の鍵になる
• モデルと Scrum は矛盾せず、むしろ自然に共存できる

📖 第 2 章：モデルはこうして作る ─ 実践ステップガイド

2.1 モデル作成は「クラス図」から始まらない

「モデルを作ろう」と言うと、多くの人が最初に思い浮かべるのはクラス図かもしれません。 しかし、実際には**モデリングの出発点は“図を描くこと”ではなく、“現場を知ること”**です。

では、何から始めればいいのか？ この章では、ドメインモデルを現場で育てていくための 6 つのステップを紹介します。

2.2 Step1：ユースケースの理解から始める

最初のステップは、ユースケースの深掘りです。 すなわち、「ユーザーは何を達成したいのか？」「どんな場面でそれが使われるのか？」を明らかにすることです。

たとえば「注文キャンセル」という機能があるとしましょう。

• 注文は支払済みか？
• 出荷準備は完了しているか？
• ゲスト注文と会員注文でルールは異なるのか？

── こういった業務的な前提条件を知らなければ、モデルは正しく設計できません。

🎯 モデルの良し悪しは、図の美しさではなく、ユースケースの理解の深さにかかっています。

2.3 Step2：ユビキタス言語を発見する

次のステップは、ユビキタス言語の整理です。

これは単に用語集を作ることではなく、「その言葉は、どの文脈で、どんな意味を持つのか？」をチームで明確にするプロセスです。

よく使う手法：

• 用語カード（紙でもデジタルでも OK）
• イベントストーミング（会話しながら構造を発見）

🔍 たとえば「注文」という言葉一つを取っても：

• 顧客の操作では「カート」
• 物流では「出荷対象」
• 会計では「請求の起点」

── これほど意味が分かれます。

こうした言葉のズレが、設計のズレに直結するのです。

2.4 Step3：エンティティと値オブジェクトを見分ける

続いて、モデルを構造化するために重要なのが、エンティティと値オブジェクト（VO）の判別です。

• エンティティ：識別子（ID）を持ち、ライフサイクルを追えるもの 例：注文、顧客、配送など
• 値オブジェクト：属性情報であり、意味によって等価性を判断するもの 例：住所、金額、期間など

👀 見分けるポイント：

• それは「追跡すべき存在」か？
• 「一時的な属性の集まり」として扱えるか？

たとえば「料金プラン」が「変更可能な ID 付きの存在」ならエンティティ、 「ある瞬間の条件セット」なら VO と考えます。

2.5 Step4：集約（Aggregate）の境界を定める

モデルがある程度整理されてきたら、**集約（Aggregate）**という考え方が必要になります。

集約とは：

業務ルールの一貫性を保つための、エンティティのまとまり

たとえば「注文」という集約は次のように構成されるかもしれません。

• 注文本体（Order）
• 注文明細（OrderLine）
• 支払い情報（Payment）

このとき、「一緒に更新されるべき境界」はどこか？ 「他の集約とどう連携するか？」を設計していきます。

💡 ポイント：

• 集約は小さく・明確に
• 他の集約とはID で接続して疎結合に

2.6 Step5：ドメインサービスを抽出する

設計を進めていると、次のような悩みが出てくるかもしれません。

「このロジック、エンティティにも VO にも入らない…」

そうした処理の置き場所として登場するのが、ドメインサービスです。

🧠 例：

• クーポンの有効性チェック
• 決済手段によるキャンセル可否の判定

これらは複数のエンティティにまたがるロジックであり、 意味を持った“動詞的な名前”でサービスとして切り出すのが適切です。

❌ NG 例：「Helper」「Utils」など意味のない命名

✅ OK 例：「CouponValidator」「PaymentCancellationPolicy」など行動の名前

2.7 Step6：モデルをテストで検証する

最後のステップは、モデルの検証です。

図や設計書だけでは、モデルの実用性は測れません。 現実のユースケースに沿ってテストを書いてみることで、「本当に使えるか？」を判断します。

おすすめ手法：Example Mapping

• ストーリー → 受け入れ条件 → 例（Example）→ ビジネスルール この構造に当てはめてテストを書くことで、モデルの意図や弱点が浮き彫りになります。

🛠 モデルの実力は、テストで語れるかどうかに現れます。

🔚 第 2 章まとめ

• モデルは「図を書くこと」ではなく「現場の理解」から始まる
• 言葉を揃え、役割を分け、関係性を整理する
• モデルの完成度は、会話・設計・テストの循環で高まっていく

📖 第 3 章：Scrum のリズムにモデリングを組み込む

3.1 Scrum には「設計フェーズ」がない

まず押さえておきたいのは、Scrum にはウォーターフォールのような「設計フェーズ」や「モデリングフェーズ」は存在しないということです。

Scrum は、計画と実行と振り返りを繰り返す反復的・増分的なフレームワークです。 つまり、設計やモデリングもまた、サイクルの中に埋め込まれて行われるのが前提です。

モデリングは「準備が整ってから行うもの」ではなく、 「チームの会話の中で継続的に育てるもの」なのです。

3.2 リファインメントでモデルの原型を探る

モデリングが最も活躍するのは、Scrum イベントの中でもバックログリファインメントの場です。

この場では、プロダクトバックログアイテム（PBI）を次のスプリントで扱える粒度に分解していきますが、 その作業は単なる分割ではなく、業務構造を見つけ出すプロセスでもあります。

たとえば：

• 「この“支払い方法”って、どういう属性を持っている？」
• 「この処理、誰が責任を持つべき？」
• 「この振る舞いは、どの状態からどの状態へ？」

── といった問いを通じて、業務の意味構造を発見するのがリファインメントにおけるモデリングの本質です。

💡 ホワイトボードで図を描いたり、用語カードで意味を揃えたりすることで、軽量なモデリングが自然と進みます。

3.3 スプリントプランニングでモデル粒度を決める

リファインメントで見えてきた構造をもとに、スプリントプランニングでは**「どこまでを今スプリントで実装するか」**を決めていきます。

このとき重要なのが、モデル単位でスコープを切る視点です。

例：

• 「この状態遷移の前半だけを先に作る」
• 「このエンティティの振る舞いのうち、基本パターンだけを先に実装する」
• 「永続化は次のスプリントに回して、今はメモリ上でのモデル検証に留める」

Scrum のスプリントは小さな実験の場です。 モデルも一度に完成を目指すのではなく、部分的に実装しながら理解を深めていくのが理想です。

3.4 スプリント中にモデルを検証・進化させる

スプリントが始まると、実装フェーズに入ります。 ここでは、作業が進む中でモデルを検証し、場合によっては修正していくという姿勢が重要です。

実際にコードを書き始めると、こんな気づきが出てきます：

• 「このエンティティ、状態を持たせすぎてるな」
• 「テストを書いてみたら、ルールが抜けてた」
• 「この分岐、モデルとしては不自然だな」

Scrum の原則にもあるように、間違えても、気づいて適応できればいい。 モデリングも同じです。一度決めた構造に固執せず、気づきに応じて変えていくことが大切です。

3.5 スプリントレビューでモデルを語れるか？

スプリントレビューでは、ステークホルダーに向けて成果物を示し、フィードバックを得ます。

このとき、単に「動きました」ではなく、なぜこの構造にしたのか、なぜこの責務分割なのかといったモデルの背後にある意図を説明できるかどうかがポイントになります。

例：

• 「注文は状態ごとに役割が異なるので、ドメインサービスに処理を分けました」
• 「この属性は業務の共通ロジックだったので、値オブジェクトとして定義しました」

🗣 こうした説明が自然にチーム内で交わせるようになっていれば、モデルが生きたものになっている証拠です。

3.6 レトロスペクティブでモデリング手法を改善する

スプリントの最後に行う振り返り（レトロスペクティブ）では、チームのプロセス改善を話し合いますが、 その対象に**「モデリングのやり方」**も含めてみましょう。

問いかけの例：

• モデルの説明がチーム全体に共有されていたか？
• 意味のズレや用語の誤解が途中で発生しなかったか？
• モデルの見直しをどのタイミングで行ったか？

このような振り返りを通して、「モデリングという行為そのもの」をチームの学習対象にすることができます。

🔚 第 3 章まとめ

• Scrum には専用のモデリング時間はない。だからこそ日々のイベントに組み込む
• モデルは「設計書」ではなく「会話の道具」として扱うべき
• モデルをレビューや振り返りで語れるかが“チーム共有度”のバロメーター

📖 第 4 章：モデルを活かすための「Ready」の再設計

4.1 Scrum には「Ready」という言葉がない？

まず意外に思われるかもしれませんが、Scrum Guideには「Ready（準備完了）」という状態についての公式な定義はありません。

とはいえ、多くの現場では次のような表現を使っています：

• 「この PBI（プロダクトバックログアイテム）、Ready ですか？」
• 「スプリントに入れるには Ready が必要ですよね」

これらは、スプリントに入れる前にそのアイテムが実装可能な状態にあるかどうかを確認するための“事実上の基準”です。

しかしここで問題なのが ──

その基準に、ドメインモデルの観点が含まれていないことが多いという点です。

4.2 よくある Ready 定義とその欠落

多くのチームで使われている Ready 定義は、おおむね以下のようなチェックリストです：

項目	内容
✅ 分割済み	ストーリーが実装可能な粒度に分割されている
✅ 目的明確	ビジネス上の背景や目的が共有されている
✅ 受け入れ条件	期待される動作や結果が記述されている
✅ 関係者確認済み	ステークホルダーの合意が得られている
✅ 実装可能性あり	チームの能力と時間で対応可能と判断されている

このような定義は決して間違っていません。 ただし、これだけでは以下のようなモデルの曖昧さを見逃すリスクがあります。

• 「顧客」という用語の意味がチーム内でズレている
• 新しい業務ルールが既存のモデルにどう影響するか不明
• ストーリーに登場する言葉が定義されていない

4.3 モデル観点を加えた Ready チェックリスト

そこで提案したいのが、ドメインモデリングの観点を含めた Ready 定義です。 以下は現場で使われ始めている実践的なチェック項目です：

チェック	内容
🟩 用語の意味が明確か？	「顧客」「注文」などがチーム共通言語として定義されているか
🟩 業務ルールが理解されているか？	ストーリーの背景や目的、前提条件がチーム内で共有されているか
🟩 影響を受けるモデルが特定されているか？	既存のエンティティや集約に影響があるか判断されているか
🟩 モデルの変更有無が明らかか？	新たに設計が必要か、再利用か、改修かが分かっているか
🟩 不確実性が明示されているか？	設計に検討余地がある場合、その旨が明示されているか

これらは「完璧な設計があるか？」を求めるものではありません。 重要なのは、**設計的な不確実性が“見えている状態”**かどうかです。

4.4 モデル観点を含めた Ready テンプレート

より具体的なイメージを持ってもらうために、Ready 定義のテンプレートを以下に示します：

📝 Ready 定義（モデル観点つき）

1. ストーリーが 1 スプリントで完了可能な粒度に分割されている
2. 目的と期待されるビジネス成果が明確
3. 受け入れ基準（AC）が定義されている
4. 関係者との合意が済んでいる
5. 登場する用語が定義され、チームで共有されている
6. 影響を受けるモデル（エンティティ・集約・サービス）が特定されている
7. 設計上の不確実性がある場合、それが明記されている（タスク化含む）

このテンプレートは「設計が終わっていること」を前提にしていません。 むしろ、曖昧なところが明示されていることを重視します。

4.5 なぜ Ready にモデル観点が必要なのか？

モデル観点を加えることで、以下のようなメリットがあります：

• スプリント中の仕様ブレを防げる
• チーム内の言葉のズレに早期に気づける
• 影響範囲が可視化され、リファクタのタイミングも判断しやすくなる

言い換えるなら、モデル観点を Ready に含めることは、チームの「認識のズレ」を未然に防ぐ仕組みなのです。

🔚 第 4 章まとめ

• 「Ready」の定義は各チームが独自に設定できる
• モデルの曖昧さや用語のズレは、実装段階に入る前に明らかにすべき
• Ready 定義にモデル観点を組み込むことで、スプリントの安定性と品質が向上する

📖 第 5 章：そのモデル、うまくいかないかも？── よくある 5 つの罠と対策

ドメインモデリングは強力な武器になります。 しかし、扱いを誤ればすぐに混乱や停滞を引き起こす諸刃の剣にもなり得ます。

本章では、モデリングに取り組むチームが実際に陥りやすい5 つの典型的な落とし穴と、その対策を紹介します。

5.1 モデリング地獄：考えすぎて動けない

❌ よくある状況：

• 図ばかり作ってコードが一向に書かれない
• 設計会議が長期化し、「正解探し」のような状態に陥る
• 完璧な構造を追い求めて、前に進めなくなる

「もっといいモデルがあるはず…」と考えているうちに、スプリントが終わる。

✅ 対策：

話せる + 試せる状態になったら、まずコードにしてみましょう。 Scrum の原則にもあるとおり、動くものを早くつくることでフィードバックが得られます。

🔁 モデルも「書いて → 壊して → 直す」サイクルで育てるものです。

5.2 属人化：モデルが一部の人だけのものになる

❌ よくある状況：

• モデルの意図を説明できるのが特定のメンバーだけ
• 口頭伝承に頼っていてドキュメントが残っていない
• モデルが更新されても、チームに周知されない

「あの設計、◯◯ さんしか理解してないですよね…」

✅ 対策：

属人化を防ぐには、**「話す → 残す → 伝える」**を徹底することが重要です。

• ユビキタス言語は書いて記録する
• モデルは図解（Miro、PlantUML など）で共有
• 意図はテストコードや Example Mappingに反映する

🛡 モデルの価値は、チーム全員で使えるかどうかで決まります。

5.3 先回り実装：未来を予測しすぎて破綻する

❌ よくある状況：

• まだ決まっていない仕様を「きっとこうなるはず」と先に作る
• その結果、未使用のクラスや属性がどんどん増えていく
• モデルが複雑になりすぎて、逆に扱いづらくなる

「あとで必要になりそうだから、先に入れておこう…」

✅ 対策：

Scrum の原則に立ち返りましょう。

「必要なときに、必要な分だけ作る」

モデルも同じです。今スプリントで必要な構造だけを対象にすることで、無駄を防げます。

• Ready 定義でスコープを明示
• 未確定な部分は「保留」としてドキュメント化

🎯 モデルは「予測」より「現在」にフォーカスしましょう。

5.4 ロジックの分散：ドメイン外にルールが漏れる

❌ よくある状況：

• UI 層だけにバリデーションがある（API 経由では通ってしまう）
• コントローラ層でビジネス判断をしている
• DB トリガにルールが埋め込まれている

結果として「仕様がコードに現れていない」状態になる。

✅ 対策：

ルールがどこに存在すべきか？常に問いましょう。

• 業務ルールはドメインモデル内に閉じ込める
• UI や DB はルールの実行場所ではなく、補助的な機能にとどめる
• ドメインサービスや値オブジェクトに、意味のある責務として実装する

📦 モデルは「仕様の置き場」です。 それを外に漏らすと、構造はすぐに崩れていきます。

5.5 説明できないモデル：意図が共有されていない

❌ よくある状況：

• なぜその構造になっているのかが他のメンバーに説明できない
• 責務分割や命名に一貫性がない
• モデルに対するレビューやフィードバックが起きない

「とりあえず動いてるけど、なぜこうしたかは…覚えてません」

✅ 対策：

Scrum のレビューやレトロの場を活用して、モデルの意図を“言葉にする”習慣をつけましょう。

• なぜこの構造にしたのか？
• どんな選択肢があって、それを選んだのか？
• 仕様の変化にどう対応したか？

こうした「意図の言語化」は、学習し続けるチームをつくる第一歩です。

🔚 第 5 章まとめ

落とし穴	防ぐための行動
モデリング地獄	試せる状態で一度実装。循環を早く回す
属人化	書く・描く・共有する
先回り実装	今必要なものだけ作る。保留は保留で
ロジック分散	ドメインに閉じ込める意識を持つ
説明できない構造	意図を語る習慣を持つ

📖 第 6 章：モデルは“対話の副産物”である

6.1 設計とは“書くこと”ではなく“話すこと”

ドメインモデルという言葉を聞くと、多くの人が「クラス図」や「アーキテクチャ図」を思い浮かべます。 しかし、私たちが本当に目指すべきなのは、図そのものではなく、その背景にある会話や理解の積み重ねなのです。

モデルとは、図を描いた「結果」ではなく、 チームでの対話の“副産物”として生まれるものです。

6.2 モデルは「対話 → 理解 → 構造」の流れで生まれる

たとえば、こんな場面を想像してみてください：

• 業務担当が「それって、こういう流れだよね」と口にする
• 開発者が「このパターンに似てますね」と気づく
• そこで「じゃあ、この構造で表現できるかも」と図が描かれはじめる

このように、言葉 → 理解 → 構造という自然な流れの中で、モデルは生まれます。

モデルは“作るもの”ではなく、見えてくるものなのです。

6.3 会話できないモデルは“死んでいる”

一方で、図だけが存在している状態 ──

• どのような会話の末にできたかが分からない
• 誰がどんな意図で設計したかが語れない
• 使っている言葉の意味が曖昧なままになっている

── こうしたモデルは、いくら図として立派でも実際には機能しません。

🧠 モデルは「話せる」からこそ価値がある。 それは単なる設計ではなく、コミュニケーションの結晶なのです。

6.4 Scrum の流れと“対話のモデル”は同じリズム

Scrum のサイクルはこうです：

• リファインメントで「話す」
• プランニングで「決める」
• スプリント中に「試す」
• レビューで「説明する」
• レトロで「改善する」

このリズムこそが、対話からモデルを生み出し、育てていく流れそのものです。

モデルもまた、Scrum と同じように「検査と適応」を繰り返す存在なのです。

6.5 「言葉を揃えること」から始めよう

「モデルを作るぞ！」と意気込んで難しい図から始める必要はありません。 まずは身近な“言葉の意味”をそろえることが第一歩です。

問いかけてみましょう：

• 「“顧客”って、私たちのプロダクトでは誰のこと？」
• 「“注文”はいつ確定する？いつ取消せる？」
• 「“完了”って、業務上は何を意味している？」

このようなやりとりを通じて、モデルの土台が自然と形づくられていきます。

🟨 付箋で用語カードを作ってもいい 🟨 ホワイトボードで会話してもいい 🟨 「これ、どういう意味ですか？」と問いかけるだけでもいい

それが、最も自然なモデリングの始まりです。

🔚 第 6 章まとめ

• モデルは図ではなく、会話の結果としての“構造”
• 会話の中から構造が見える。それを形にしていくのがモデリング
• Scrum のイベントは、モデルを生む“対話のリズム”と完全に一致している
• 最初の一歩は「言葉を揃えること」から始まる

📖 第 7 章：Scrum の中にモデリングを定着させる技術

ここまで、ドメインモデルとは何か、そして Scrum とどう結びつくかを見てきました。 本章では、それらを「知識」にとどめず、日々の実践の中に定着させていく技術や工夫を紹介します。

7.1 モデリングは“タスク”ではなく“習慣”にする

「モデリングタスクを作ろう」── これはよくあるパターンですが、 モデリングは特定の誰かが行う“作業”ではなく、チームの会話の中で自然に発生するべき習慣です。

モデルを考えるのではなく、モデルで考える

それが、真にモデリングが定着した状態です。

🎯 モデリングは特別な時間にやるものではなく、会話の中に溶け込ませる工夫が必要です。

7.2 モデルを Ready の中で自然に意識させる

第 4 章で紹介したとおり、PBI の「Ready 定義」にモデル観点を組み込むことは非常に有効です。

おすすめは、次のような“準備用チェック”をテンプレ化して、日常的に使うことです。

📝 例：リファインメント用モデリングチェック（簡易版）

• この用語、誰がどういう意味で使ってる？
• このルール、仕様として誰が保証すべき？
• このストーリー、既存モデルにどんな影響がある？

これらをリファインメント時に口に出して確認するだけでも、チームの意識が“構造”に向くようになります。

7.3 モデルの「見える化」を仕組みとして持つ

「モデルはあるけど、どこにあるか分からない」 ── こうなると属人化・形骸化の一途です。

モデルはなるべく「見える化」して、誰でも・いつでもアクセスできる状態にしておきましょう。

🧰 実践例：

• Miro / Whimsical / PlantUML などで図解して Slack や Notion に貼る
• 用語カードやイベントストーミングの成果をチーム Wiki に記録する
• テストコードや Example Mapping にモデルの“意図”を残す

🧩 特に、テストは“仕様を語るドキュメント”として非常に強力です。 ドメインサービスや値オブジェクトのテストには、意図や背景が読み取れるような命名を心がけましょう。

7.4 レトロスペクティブで「モデリングのやり方」を振り返る

通常の振り返りでは、

• コミュニケーション
• 工数見積もり
• 実装効率

などが話題になりがちですが、そこに**「モデリングのやり方」という観点を加えること**で、設計力の底上げが可能になります。

🎤 たとえばこんな問いをレトロに持ち込んでみましょう：

• 「このストーリー、用語の意味が曖昧だったよね？」
• 「構造を図で描いたら、すぐ理解できたよね？」
• 「テストで業務ルールの漏れに気づけたの、よかったね」

このように、“話し方”や“考え方”の振り返りこそが、設計の習慣化につながる鍵です。

7.5 モデリングの失敗も“ふつうの出来事”にする

モデルが間違っていた、構造が破綻した、設計をやり直した ── これらを「失敗」として捉えるのではなく、Scrum における適応の一部として自然に受け入れましょう。

❌ NG な反応：「設計ミスだったな」「もっと事前に考えればよかった」

✅ OK な反応：「実装してみて気づいたことがあった」「次に活かせそう」

モデルも Sprint と同じく、「検査と適応」を繰り返す存在です。 モデリングの“失敗”もまた、学習の機会に変えていけます。

🔚 第 7 章まとめ

• モデリングを“習慣”として日常に組み込む
• Ready、リファインメント、レトロにモデル観点を差し込む
• 図やテストでモデルの意図を見える化し、属人化を防ぐ
• モデルの失敗も適応サイクルに取り込む

📖 第 8 章：まとめと最初の一歩

8.1 本書で伝えたかったこと

本書は、スクラム開発の現場で「ドメインモデルをどう活かすか？」という問いに答えることを目的にしてきました。 単なるクラス図や設計図としてではなく、会話の道具・共通理解のフレームとしてのドメインモデルのあり方を追いかけてきました。

振り返ってみると、次のような考え方が軸になっています。

📌 本書のキーメッセージ

1. モデルは“対話の副産物”である 　 ── 設計は図ではなく会話の中から生まれるもの
2. Scrum とモデリングは矛盾しない 　 ── モデルはフェーズではなく、イベントの中に自然に組み込まれる
3. 完璧ではなく“進化可能”なモデルを目指す 　 ── 試して壊して直す、その繰り返しの中で洗練されていく
4. チーム全体で育てる構造にする 　 ── 属人化させず、共有し、語り、更新する

8.2 よくある誤解を乗り越える

「モデリングは難しい」 「モデルって設計者だけの仕事でしょ？」 「Scrum だから、動くコードだけでいいんじゃないの？」

── こうした声が、現場にはまだまだ根強く残っています。

でも、スクラムこそ、会話に根ざした軽やかなモデリングが必要な場です。 小さなサイクルで検証と適応を繰り返すスタイルだからこそ、思考の補助輪としてのモデルがチームにとって強力な支えになります。

8.3 明日からできる「最初の一歩」

「ここまで読んだけど、じゃあ明日から何をすればいいの？」 ── そんな声に応えるべく、最もシンプルで効果的なアクションを一つだけ提案します。

「言葉の意味を揃える」ことから始めましょう。

チームで使われている用語に、ズレや誤解がないか？ ストーリーや画面仕様、DB 設計で「同じ言葉に違う意味」が混じっていないか？ それに気づき、問いかけ、対話してみてください。

8.4 おわりに：モデリングはチーム文化の一部になる

最初から綺麗なモデルは作れません。 でも、チームで話し合い、試してみて、少しずつ育てていくことで、 やがてそれは、**コードや図を超えて、“チームの考え方そのもの”**になっていきます。

モデリングは、一部のエンジニアだけがやる特別な作業ではありません。 Scrum の中で、誰でも・いつでも・自然に行える対話の技術です。# ✍️ あとがき

モデリングと聞くと、どこか“難しいもの”や“特別なスキル”という印象を持たれる方が多いかもしれません。

しかし本書を通してお伝えしたかったのは、

モデルとは、誰でも・どこでも・小さく始められる“対話の道具”である というシンプルな真実です。

私自身、現場でたくさんの失敗をしてきました。 「設計に時間をかけすぎてスプリントが回らなくなったこと」 「用語のズレに気づかず、テストやレビューで手戻りが起きたこと」 「属人化したモデルにチームがついてこれなかったこと」…

そんな経験を通してたどり着いたのが、 **「モデルは、まず“言葉を揃えること”から始めよう」**という考え方でした。

ドメインモデリングは特別な職種の人がやるものではなく、 チーム全体で使える「思考の補助輪」です。 それを Scrum のリズムに乗せて軽やかに回していけたら、きっと開発はもっと楽しくなります。

本書が、あなたのチームの会話と設計が少しでも豊かになるきっかけになれば幸いです。 最後までお読みいただき、ありがとうございました。