アジャイル時代におけるモデリングの役割分担と、その本質的な意義を再考する
うっかりGeminiさんとモデリング談義が弾んでしまい、あっという間に3時間溶けていく体験をしたので、せっかくなので記録として残しておく。
結論としては下記の通り。
モデリング工程と主導者の整理（解像度アップ版）
1. 概念モデリング
目的： ビジネスの「WHY」と「WHAT」を定義し、北極星（ノーススター）を描く。
主導者：ビジネスアナリスト w/ 業務エキスパート
空気感： インタビューやワークショップ形式。技術詳細からは距離を置き、ビジネスの構造や価値の流れを可視化する。
2. 接合モデリング
目的： ビジネスの理想（北極星）と技術的現実（現在地）をすり合わせ、実現可能な航路図（アーキテクチャの骨格）を描く。
主導者：ビジネスアナリスト w/ テックリード
空気感： 「二人三脚」での壁打ちやディベート。ビジネス要求と技術的健全性をぶつけ合わせ、システムの骨格（コンテキスト分割や連携）を決定する、最も創造的な場。
3. ジャストインタイム・モデリング
目的： 実装直前の迷いをなくし、開発の速度と品質を両立させるための、日々の航海術。
主導者： テックリード（がファシリテートし、開発チームを巻き込む）
空気感： チームでのハドルやホワイトボーディング。テックリードが議論をリードし、エンジニアが実装を具体化し、時折PO/BAがビジネス視点で問いを投げかける、開かれた共同作業。
/icons/hr.icon
対話ログ
先日、あるシステムアーキテクトの方と、ビジネスアナリシスやソフトウェアエンジニアリングにおける「モデリング」の効能について深く語り合いました。
「保守性の高い基幹システムを、DDDやオブジェクト指向のアプローチで構築したい」という彼の強い思いから始まった対話は、やがて「アジャイルな開発スタイルの中で、一体『誰が・いつ・何を』モデリングすべきか？」という核心的な問いへと発展していきました。
その思考の軌跡と、対話の末に見えてきたクリアな役割分担モデルを、ここに記録として残します。
すべての始まり：企画・概念設計におけるモデリングとは？
最初の問いは、「企画や概念設計の段階で、モデリングに何を期待するか？」でした。
アーキテクトは当初、自身の考えをこう整理してくれました。
アーキテクトの初期提案：
企画段階のモデリングは、ビジネスの「価値」を起点に、3つの効能を生み出す活動だ。
1. 問題領域の整理： 価値を基準に、現実世界から本質を抜き出す。
2. 問題領域の分割： 本質的な概念を、言葉が通じる単位（コンテキスト）に分ける。
3. 問題領域の連携： 分割した概念を繋ぎ、価値を生み出すネットワークを定義する。
これは、DDDの思想を反映した、非常に的確なフレームワークです。しかし、この理想的なアプローチには、現実の壁が立ちはだかります。対話を通じて、私たちはいくつかの「批判的な問い」に直面しました。
その「価値」、本当にみんなの認識は合っているのか？
分割の「境界線」は、誰が、どうやって引くのか？手戻りのリスクは？
理想の「連携」モデルと、既存システムや組織という「現実」のギャップをどう埋めるのか？
これらの問いに唯一の正解はありません。しかし、これらの問いを無視しては先に進めないことを確認し、議論は「設計フェーズ」へと移っていきます。
第二の問い：「それ、ウォーターフォール的じゃない？」
次に私たちは、設計フェーズにおけるモデリングの効能（青写真、共通言語、品質の事前検討など）について考えました。しかし、ここでアーキテクトから鋭い指摘が入ります。
アーキテクトからの違和感：
「青写真を描き、品質検討してから実装に入る…という流れは、ウォーターフォール的だ。価値に集中して、設計・実装・フィードバックの改善ループを高速に回すにはどうしたらいいだろう？」
この一言が、議論を大きく前進させました。
そうだ、設計を「フェーズ」として固定的に捉えるから、アジャイルな流れと矛盾するんだ。ここから、私たちの考えは「一度きりの設計イベント」から**「継続的なモデリング活動」**へとシフトします。
ジャストインタイム・モデリング： 完璧な青写真を最初に描かない。実装直前に、必要な範囲だけをモデリングする。
軽量モデリング： 目的は共通理解。ホワイトボードやスケッチで十分。
リファクタリングによる進化： フィードバックを元にコードを改善する行為こそが、モデルを育てる活動である。
この「継続的モデリング」の考え方で、アジャイルとモデリングは両立できる、という結論に至りました。
第三の問い：ジャストインタイムの罠と「スーパーマン問題」
しかし、ここで新たな課題が生まれます。
みんながそれぞれの持ち場で「ジャストインタイム」にモデリングを始めたら、システム全体の整合性、つまり森全体の姿は誰が担保するのか？
この課題に対し、アーキテクトから「POがモデラーを兼任すれば、ビジネスと実装が繋がって理想的では？」という仮説が出されました。一見、名案に思えます。しかし、対話で深掘りすると、ある問題に行き着きます。
スーパーマン問題：
ビジネスに精通し、ステークホルダーをまとめ、かつ高度なモデリングスキルも持つPOは、まさにスーパーマン。そんな超人に依存する組織は脆く、現実的ではない。
ここから、私たちは「一人の天才」に頼るのではなく、「チームの協調」で課題を解決する方向へと舵を切ります。その答えが、ビジネス価値に責任を持つPO/ビジネスアナリストと、技術的健全性に責任を持つテックリードの「二人三脚」でした。
結論：対話から生まれたモデリング工程と主導者
これまでの長い対話を経て、私たちはついに、現代の開発スタイルに合った、解像度の高い役割分担モデルにたどり着きました。
/icons/hr.icon
モデリング工程と主導者の整理（解像度アップ版）
1. 概念モデリング
目的： ビジネスの「WHY」と「WHAT」を定義し、**北極星（ノーススター）**を描く。
主導者： ビジネスアナリスト w/ 業務エキスパート
空気感： インタビューやワークショップ形式。技術詳細からは距離を置き、ビジネスの構造や価値の流れを可視化する。
2. 接合モデリング
目的： ビジネスの理想（北極星）と技術的現実（現在地）をすり合わせ、実現可能な**航路図（アーキテクチャの骨格）**を描く。
主導者： ビジネスアナリスト w/ テックリード
空気感： 「二人三脚」での壁打ちやディベート。ビジネス要求と技術的健全性をぶつけ合わせ、システムの骨格（コンテキスト分割や連携）を決定する、最も創造的な場。
3. ジャストインタイム・モデリング
目的： 実装直前の迷いをなくし、開発の速度と品質を両立させるための、日々の航海術。
主導者： テックリード（がファシリテートし、開発チームを巻き込む）
空気感： チームでのハドルやホワイトボーディング。テックリードが議論をリードし、エンジニアが実装を具体化し、時折PO/BAがビジネス視点で問いを投げかける、開かれた共同作業。
/icons/hr.icon
おわりに
この整理は、決して唯一無二の正解ではありません。しかし、モデリングの真の目的が「完璧な設計書を作ること」ではなく、**「関係者間の対話を通じて、共通理解を形成すること」**であるという、私たちが忘れがちな本質を思い出させてくれます。
この対話の記録が、皆さんの現場で「モデリング」という活動を、より効果的で、より楽しいものにするための一助となれば幸いです。