勉強会アウトプット
- サブドメインとコアサブドメインは同じ
- 業務領域がインダストリー
- 事業領域がコアサブドメイン含む、サブドメイン
- コアドメインは戦略的設計として重要な少しに絞る。出てきたものを全部これは大事これは大事としていると場当たり的で何も設計できていない。
- いちいち見てマッピングする癖は良くない。良い設計は頭の中で綺麗に収まり、口頭や手書きで簡単に自分の言葉で語れる認知のサイズに収まるのでソラで語れる。なので何か読む時もメモしながらではなく集中して読める。もちろん関係性の説明には図示は有効
- 戦略的設計も、戦術的設計も一貫して実行できることがエンジニアには大事。情報量を保ち続けられる
- なるべく決めるのは後回しにすることが大事
- 実装レベルでも呼び出しがわで差し替えられるようにする、依存性逆転が大事
- そもそも実装詳細や、開発をすることを決めるのは後にする。抽象の本質を掴む。ドメインモデリングから始めること
- 勉強も読書もいきなりパソコンに向かうより、先にドメインモデリングしてパソコンに向かって作業すると良い気がする
- 言葉にすることで意味が失われる
- 全く同じ言葉を言っていても、自分が思っている意味と、相手が思っている意味は違う。メンタルモデルを炙り出す、蒸留することが大事
- 以上の2点を押さえておくと抽象レベルの設計を行えて、その上本で読んだような言葉ではなく、具体的な反例を思いつきやすく実装の説明をする力にもなる
ワークを通して感じたこと
- ヒアリング練習をすることで少しづつドメインモデリングの知識が理解できてくる
- 前回の困りごとヒアリングワークを繰り返すことで、理解はユビキタス言語を蒸留することと実感できてきた
- 境界付けられたコンテキスト、ドメインモデリングについては既存のものについて分けて意思決定の基準にはできるようになってきたが、ゼロからそこを明確化するには今回のワークが大事だなと思った
- 前回、今回のヒアリングどちらでもうまくいっているものを聞き出して比較するのは有効だなと思った
- 完全にテンプレートにするのは難しいが、実感と正しいDDD知識をセットで持っておくと考える力、設計力になり、実装でもレビューでもAI活用でも役に立つ
以下、課題ワーク内容
やりとりの全体像
[設定] 美容室5店舗の社長
隠れた強み = 顧客情報を全スタッフで共有し、担当に依存しない
│
▼
[ヒアリング]
Q スタッフはいつ増えた？ ─────→ 沿革（7年目から出店）
Q 今のやり方の限界は？ ───────→ 二重予約／カルテ分散／集計遅れ
Q 電話予約は多い？ ────────→ 全体3割、店舗差あり
Q お待たせした店舗は？ ──────→ 3号店
Q 咄嗟のフォローを ────────→ ★ヒント「手が空いた人がすっと入る」
Q 他に困りごとは？ ────────→ シフト／在庫／歩合計算
Q 電話連携で解決しそう？ ─────→ 履歴も見たい
Q 履歴と枠が正しければOK？ ───→ 当日変更の可視化も
Q 電話で助かったと言われる点は？ → ★ヒント「担当が辞めても安心」
Q 共有すれば強みはそのまま？ ──→ 社長「強みは言葉にできていない」
Q 受付は他店も同じ？ ───────→ ★ヒント「カルテを見ればわかる」
│
▼
[フィードバック]
コア判定 :「美容知識のある受付」 → 一部一致（強みの結果であり原因ではない）
真のコア :「顧客情報の記録・引継ぎ」
│
▼
[学び]
結果 → 比較 → なぜ×2 → 否定で検証
不要だった問いかけ
- 「スタッフはいつ増えた？」 沿革は強みにもシステム要件にもつながりにくく、答えを聞いても次の判断が変わりません。
- 「お待たせした店舗はどこ？」 店舗名がわかっても、課題の性質は変わりません。聞くなら「なぜ入力が遅れたのか」でした。
- 「履歴と枠が正しければ問題ない？」 閉じた質問で、「はい」を誘導する形になっています。解決策の確認は、課題を出し切ってからで足ります。
- 「最新状況を共有すれば強みはそのまま」 強みが何かを確かめる前に、結論を置いてしまっています。根拠のない前提の上に主張を立てた形です。
効果的だった問いかけ
- 「今のやり方の限界は？」 開いた質問で、課題の全体像を一度に引き出せました。
- 「二重予約以外に困りごとは？」 網羅性を確保する問いで、シフト・在庫・歩合が出てきました。
- 「お客様から助かったと言われる点は？」 最も効果的でした。顧客の視点から聞いたことで、退職エピソードという核心のヒントが出ました。
- 「受付は他店も同じ？」 他社との比較を求める問いで、強みに一番近づいた場面です。
ただし、どれもヒントが出た直後に「なぜ」を重ねなかったため、到達しきれませんでした。
最短の問いかけ手順
- 結果を聞く 「他店より明らかに良い数字は何ですか？」
- 比較させる 「同じことが起きたら、他の店ではどうなりますか？」
- なぜを2回 1回目で現象、2回目で仕組みに届きます。
- 否定で検証 「それが明日なくなったら、何が困りますか？」
強みは本人も言葉にできていないことが多いので、直接聞くより、結果から原因へさかのぼる方が早く着きます。
3つの概念の本質
ユビキタス言語
業務側と開発側で、同じ言葉が同じ意味を指す状態を作ることです。言葉のズレはモデルのズレを示すので、「その言葉はどういう意味ですか？」「なぜそう言うのですか？」と問うことが、暗黙知を表に出す道具になります。
ドメインモデリング
解きたい問題にとって意味のある区別だけを残し、それ以外を捨てる決定です。今回なら「顧客は担当に属する」ではなく「顧客は店に属し、担当は一時的な割り当て」と区別することで、強みがそのままモデルに埋め込まれます。
境界づけられたコンテキスト
一つのモデルの意味が一貫して通用する範囲です。カルテでの「顧客」は髪の履歴を持つ継続的な存在、予約での「顧客」は枠を押さえる連絡先で足ります。意味が切り替わる線が境界であり、無理に一つへ統一しないことが本質です。
三つは一続きです。ユビキタス言語で言葉を揃え、言葉の意味が揺れる所に境界を引き、その境界の中で区別を磨く。図はこの思考の結果を書き留めたものです。