イベントストーミングから始めるドメイン駆動設計

by おだかとしゆき

Slide 1

Slide 1 text

イベントストーミングから始めるドメイン駆動設計概念モデリングと生成AIで加速するシステム開発おだかとしゆき as JGEEM（@EM4326168385309） 2025.6.7 JJUG CCC 2025 Spring

Slide 2

Slide 2 text

自己紹介おだかとしゆき株式会社MonotaRO シニアアーキテクト as JGEEM（@EM4326168385309）事業(J)会社(G)の元(Ex)EM / 53才現職はアーキテクチャと格闘定年までできることしたいことを探る日々定年後もキャリアは続く/ AIIT 科目等履修生 / 貢献てなんだろう see also scrapbox，speakerdeck 2

Slide 3

Slide 3 text

本日の資料 ● 各種モデル: Miro ● 生成AI: Gemini, DeepResearch, GoogleAIStudio ● レポート: ○ ファストリ戦略分析とマップ骨子, ○ 有明プロジェクト業務プロセス詳細調査 ○ 業務プロセス責務と関心事の整理 3

Slide 4

Slide 4 text

セッションの目的と背景

Slide 5

Slide 5 text

セッションの背景と目的 ● 事業の競争優位性？エンジニアが意識すること？ ● ビジネスや業務のこと、もっと知りたいけど業務エキスパートに凸るのも、、忙しそうだし ● 構造化とか抽象化とかいうけど何なん 5

Slide 6

Slide 6 text

セッションの背景と目的 ● 事業の競争優位性？エンジニアが意識すること？ ○ もちろん。エンジニアリングは事業活動の一環 ● ビジネスや業務のこと、もっと知りたいけど業務エキスパートに凸るのも、、忙しそうだし ○ 公開情報から事業理解を深め、予備知識を得る ● 構造化とか抽象化とかいうけど何なん ○ 各種モデリングの手法は、現実を扱いやすくする 6

Slide 7

Slide 7 text

セッションの背景と目的エンジニアが公開情報から事業活動を分析し、注力すべきビジネスプロセスを効果的に見極め、各種モデリング手法を用いて保守性の高いソフトウェア設計に繋げるプロセスを、生成AIを使ってコストパフォーマンスよく進める 7

Slide 8

Slide 8 text

セッションの背景と目的エンジニアが公開情報から事業活動を分析し、注力すべきビジネスプロセスを効果的に見極め、各種モデリング手法を用いて保守性の高いソフトウェア設計に繋げるプロセスを、生成AIを使ってコストパフォーマンスよく進める 8

Slide 9

Slide 9 text

今日、持って帰ってほしいこと 9

Slide 10

Slide 10 text

今日、持って帰ってほしいこと ● モデリングの意義 ○ なぜモデリングするのか？ ○ 何がうれしいのか？ 10

Slide 11

Slide 11 text

今日、持って帰ってほしいこと ● モデリングの意義 ● 特に「複数のモデル」を作成する意義 ● 各モデルを通して問題領域を眺めることで視点を移動させるということ ○ 具体 ⇔ 抽象 ○ 動的 ⇔ 静的 11

Slide 12

Slide 12 text

今日、お伝えしたいこと ● 各モデルの目的は何か？ ● それらのモデルを糸口に事業をどう捉えるか？ 12

Slide 13

Slide 13 text

今日、お伝えしたいこと ● 各モデルの目的は何か？ ● それらのモデルを糸口に事業をどう捉えるか？ 13 モデリングの本質的な価値： ● 多角的な視点（具体/抽象、動的/静的）でドメイン (事業領域) を捉え、理解を深め、より良いソフトウェア設計に繋げる

Slide 14

Slide 14 text

今日、お伝えしたいこと ● 各モデルの目的は何か？ ● それらのモデルを糸口に事業をどう捉えるか？ 14 モデリングの本質的な価値： ● 多角的な視点（具体/抽象、動的/静的）でドメイン (事業領域) を捉え、理解を深め、より良いソフトウェア設計に繋げる

Slide 15

Slide 15 text

おしながき ● ドメイン駆動設計(DDD)の基本的な考え方とメリット ● 私がよく使う）モデルの目的と概要 ○ 作成手順も少しだけ ● 公開情報からビジネス理解を深めモデリングする ○ 生成AIの使いどころ 15

Slide 16

Slide 16 text

ドメイン駆動設計 (DDD)の基本的な考え方とメリット

Slide 17

Slide 17 text

DDDの基本的な考え方 ● ドメイン(事業活動)中心 ● ドメインモデル ● ユビキタス言語 (同じ言葉) ● 境界付けられたコンテキスト (区切られた文脈) ● 関心の分離 ● 共創と進化 17

Slide 18

Slide 18 text

そのメリット ● 複雑性への対応 ● 共通理解 ● 保守性と拡張性 ● ビジネスアジリティ ● 価値への集中 18

Slide 19

Slide 19 text

ハードル高いんよ、、 ● 複雑性への対応: 「複雑」を「扱いやすく」するには多くを整理・整頓 ● 共通理解: 意思疎通は本当に難しい。いわんや複雑なものをや ● 保守性と拡張性: 具体的にどうしたら、、え？抽象化？？ ● ビジネスアジリティ: 保守性と拡張性を得て初めて効果 ● 価値への集中: これが最重要なのは分かるが、誰がどうやって判断するの？ 19

Slide 20

Slide 20 text

ブロッカーは裏返せ ● 複雑なものから不要なものを捨てて扱いやすくすれば、コミュニケが捗る・コードも扱いやすくなる ○ コードが扱いやすいなら保守性・拡張性が高いはず？ならビジネスアジリティだって！ ● 価値への集中って要はコスパでしょ？業務エキスパートと事業活動を肴にわいわいしたら見えてくるんじゃね？ 20

Slide 21

Slide 21 text

真のブロッカーが見えてきた ● 複雑なものから不要なものを捨て ⊃ 捨像つまりモデリング ● 業務エキスパートと事業活動を肴にわいわい ⊃ その前にまずエンジニアだけで素振り 21

Slide 22

Slide 22 text

量的なブロッカー ● 本来は重要な領域なのに（だからこそ？） ○ よく分からない・触りたくない ○ いざ変更するとあちこちに影響しまくる ○ 調査とテスト含めて半年かかります??? ● リアーキテクチャすべきな気はするが、、 22

Slide 23

Slide 23 text

量的なブロッカー ● 本来は重要な領域なのに（だからこそ？） ○ よく分からない・触りたくない ○ いざ変更するとあちこちに影響でまくる ○ 調査とテスト含めて半年かかります??? ● リアーキテクチャすべきな気はするが、、 23

Slide 24

Slide 24 text

なぜ素振りが必要か ● 「わいわい」と一方的に教えてもらうのもアリですが、双方がある程度知識を持ってるほうが盛り上がる ● 業務エキスパートはたいてい忙しい（キーマンなので） ● というわけで、まずエンジニアだけで素振りして予備知識を仕入れたら良いことがありそう 24

Slide 25

Slide 25 text

● エンジニアのシニア・ジュニア間にもフラクタル構造が ● 業務知識を獲得済みのチームに新規参戦したジュニアが他のメンバと同じ視点を得るにはオンボーディングが重要 ○ 「ドキュメント読んどいて」では不十分（そもそもドキュメント揃ってます？） ■ シニアエンジニアは忙しい ● メンタリングコストを捻出しにくい ○ じゃあ OJT で！ ■ 個人メモ止まり・曖昧な認識 ● 永遠にドキュメント化されないちなみに 25

Slide 26

Slide 26 text

ちなみにちなみに ● ジュニアを AI に置き換えても同じ構造が ● AI を超上流工程でも使いたい ○ 1shotじゃ一般論しか出てこない ■ 当社の事業領域や業務ルールなど、文脈知識をインプットしたい ● ドキュメント化されていない ○ AI もまだまだだな??? 26

Slide 27

Slide 27 text

オンボーディングにおいて ● 「OJTでキャッチアップするしかないっしょ」は甘え ○ 新規参入者に（人にもAIにも）フレンドリーな体裁のインプットが不可欠 ○ 文脈知識を得た AI は最強のメンターに？ご参考: AI-Agent開発における文脈知識の獲得とモデリングの活用さらに補足: ● モデリングと論理的推論（あるいはエンジニアリングを進歩させるナレッジとは） ● 帰納法・演繹法・アブダクションについてモデリングと抽象化の観点から考えを深める 27

Slide 28

Slide 28 text

公開情報からビジネス理解を深めモデリングする

Slide 29

Slide 29 text

公開情報を収集/分析する (してもらう) ● ファーストリテイリング社を題材にさせていただきました ○ みんな大好きユニクロさん ○ 私もヘビーユーザーですが、ビジネス・業務面では縁もゆかりもありません 29

Slide 30

Slide 30 text

公開情報を収集/分析する (してもらう) ● 企業選定のポイント: 公開情報が潤沢 ○ 直近1年間に統合報告書をリリースしている ○ 直近3年分程度の有価証券報告書、決算説明資料、プレスリリースが公開されている ○ 第三者によるマーケティング分析が公開されている 30

Slide 31

Slide 31 text

公開情報を収集/分析する (してもらう) ● 企業選定: ざっくり生成AIに聞いちゃいましょう 31

Slide 32

Slide 32 text

公開情報を収集/分析する (してもらう) ● 企業選定: 生成AIの提案から選定するにあたって ○ 当然ですが）生成AIの回答はまじめに読みましょう ○ 気になりどころを質問して解像度を上げましょう ■ 興味を持てるまで聞きまくりましょう ○ 最重要）最終的には自分で選びましょう 32

Slide 33

Slide 33 text

公開情報を収集/分析する (してもらう) ● 企業情報収集のポイント ○ 生成AIにお願いするの一択 ■ 自分でイチから収集/分析する必要はないでしょういい時代になりましたね非上場企業を対象とする場合は自力収集しないと、、どんな情報があったらいい？と参考にしていただければと思います。 33

Slide 34

Slide 34 text

公開情報を収集/分析する (してもらう) ● 生成AIに情報収集をお願いする（ https://g.co/gemini/share/f965f6350d98 ） ○ どんな資料を分析したらいい？進め方は？ ■ ファーストリテイリング社発行のIR資料（内容と確認ポイント） ● 統合報告書 / アニュアルレポート ● 決算説明会資料 / ファクトブック ● 有価証券報告書 ■ 第三者による分析レポート・記事（内容と確認ポイントと備考） ● 証券会社のアナリストレポート ● 業界レポート / 市場調査レポート ● ビジネス系メディアの記事 / 書籍 ■ 深い洞察を得るための進め方 ←これ重要 34

Slide 35

Slide 35 text

公開情報を収集/分析する (してもらう) ● 得られた回答の分析をお願いします（ https://g.co/gemini/share/fa452c3d8e6d ） ■ 収集フェーズで得たアウトプットをそのままDeepResearchへのリクエストに流用します ■ レポート: ファストリ戦略分析とマップ骨子 ● DeepReserchの仕事はまだ続きますが、一旦はここまで ● しっかり読み込みましょう 35

Slide 36

Slide 36 text

公開情報を収集/分析する (してもらう) ● さらにそのままモデリングもお願いしてみた ○ ぜんぜん無理でした ○ mermaid記法の表現力に限りがあるのか、現時点でモデルの限界なのか、私の指示が未熟なのか、、 36

Slide 37

Slide 37 text

概念モデリングによる事業活動の可視化 ● ざっくりと流れを紹介 ○ 活動システムマップで事業活動全体を俯瞰し、競争優位性の源泉となる要素を特定する ○ 対象の要素について、ビッグピクチャーを描いて大まかな流れをつかみ、フォーカスすべき業務領域(区切られた文脈)を特定する ○ 選定した業務領域を構成する業務間の係わりをコンテキストマップで示し、最も重要な業務を特定する ○ 業務を代表するユースケースのプロセスをプロセスモデルで示し、そのプロセスを構成する要素を発見する ○ 得られた要素を構造化し、新たな洞察を得る起点にする 37

Slide 38

Slide 38 text

概念モデリングによる事業活動の可視化 ● ポイント: 目的意識を持つ ○ 何がしたいのか？ ■ 全体の俯瞰から始まり、スコープを絞り込んで注力すべき領域を発見する ○ 何が嬉しいのか？ ■ 少ないコストで高い効果を得る 38

Slide 39

Slide 39 text

概念モデリングによる事業活動の可視化 ● 競争優位性を獲得したい!!! ○ 競争優位性を獲得・維持するためには、重要なプロセスを繰り返し改善する必要がある ○ 対象のプロセスを構造的に捉え、高い保守性を得ることは迅速性(→適時性)を高め・コスト効率を高める ○ 業務フローやイベントストーミングのような動的なモデルを構造化し、静的なモデルを得て、深い洞察に至ることは設計プロセスそのもの 39

Slide 40

Slide 40 text

【再掲】モデリングの流れ ● 活動システムマップで事業活動全体を俯瞰し、競争優位性の源泉となる要素を特定する ● 対象の要素について、ビッグピクチャーを描いて大まかな流れをつかみ、フォーカスすべき業務領域(区切られた文脈)を特定する ● 選定した業務領域を構成する業務間の係わりをコンテキストマップで示し、最も重要な業務を特定する ● 業務を代表するユースケースのプロセスをプロセスモデルで示し、そのプロセスを構成する要素を発見する ● 得られた要素を構造化し、新たな洞察を得る起点にする 40

Slide 41

Slide 41 text

Slide 42

Slide 42 text

活動システムマップ ● ここから Miro を併用していきます ● わたしの脳内都合で、活動システムマップのはずが別のモデル（戦略マップ風）になってしまいました ● 目的: ○ 事業活動全体を俯瞰し、競争優位性の源泉となる要素を特定する 42

Slide 43

Slide 43 text

活動システムマップまずは無造作に要素を置いていく ● レポート (ファーストリテイリング社の競争優位性の源泉：ビジネス戦略の分析) に出てきた要素(主要なビジネスプロセス)を配置します 43

Slide 44

Slide 44 text

活動システムマップ戦略マップ関係あんじゃね？って思われるものを「適当に」線でつなぐ ● この辺は感覚ですね (自社なら？) ● 各ビジネスプロセスの関連を線で表します (向きは気にしない) ● 活動システムマップのはずが戦略マップ(下位が上位に寄与する)風になってしまいました 44

Slide 45

Slide 45 text

戦略マップ線が集中しているところや、起点になっているところを詳細化してみる ● ここではやはり情報製造小売業が気になったので深掘りしたところ、有明プロジェクトという取り組みがフォーカスされたのでさらに深掘りして情報を得ています 45

Slide 46

Slide 46 text

ビッグピクチャー ● as イベントストーミングです ● 有明プロジェクトとは何者かをざっくり把握します ● 目的: ○ 大まかな流れをつかみ、フォーカスすべき業務領域(区切られた文脈)を特定する 46

Slide 47

Slide 47 text

イベントストーミングイベントストーミングで使う付箋の意味を ● よく見るやつですね ● 業務領域を分析する観点 ● 複雑な現実を意味付けられた付箋に合うよう捨像して要素間の連携を分析するため 47

Slide 48

Slide 48 text

イベントストーミング ● どこかで起きた業務イベントをトリガーにして ● 何らかの業務ルールに基づき ● または更新されたリードモデルを観測したアクターにより ● コマンドが実行され ● 集約や外部システムが更新されると ● また業務イベントが起きる ● 気になりどころはワークショップで大活躍 48

Slide 49

Slide 49 text

イベントストーミング ● 時間の都合でイベストの詳細は割愛します 🙇 ● さらに深く知りたい方のために ○ 実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo [speakerdeck] [youtube] ○ AWS Summit Japan 2024 での福井さんのセッションも素晴らしかったが公式の動画も資料も見つけられなかった [セッションレポート] 49

Slide 50

Slide 50 text

ビッグピクチャーざっくりプロセスにしてみる ● 上の画像はいわゆるビジネスモデル ● 「有明プロジェクト」で画像検索した結果 ○ ヒットしない場合は後段の要領で生成AIに相談しましょう ■ BPMレベル2(詳細事業機能)です ● これらの情報をもとに全体の流れをビッグピクチャーとして表してみましょう 50

Slide 51

Slide 51 text

ビッグピクチャーフォーカスすべき業務領域の見当を付ける ● プロセス（流れ）を最初から最後まで声に出して説明してみる（ウォークスルー） ● 事業活動として価値を創出している業務領域はここじゃね？的な感覚がきっとある 51

Slide 52

Slide 52 text

コンテキストマップ ● いわゆるDDDのコンテキストマップとは目的が異なる ● 目的: ○ 業務領域を構成する業務間の係わりを示し、最も重要な業務を特定する 52

Slide 53

Slide 53 text

コンテキストマップ ● DDD的コンテキストマップ（文脈の地図） ○ コンテキスト（区切られた文脈）間の関係とその種類（緊密な関係、利用者と供給者、互いに独立）を示します（出典）※ 増田さんお借りしました ● ここでは、コンテキスト＝業務領域を構成する要素（より小さな業務領域or業務）間の責務の分離と関係性を見ることを目的にします 53

Slide 54

Slide 54 text

コンテキストマップ ● まずはフォーカスすべき業務領域を掘り下げ、より小さな業務領域or業務に分けます ○ もちろんDeepReserchです（chatは前出の続き ■ https://g.co/gemini/share/fa452c3d8e6d ○ レポート: 有明プロジェクト業務プロセス詳細調査 ■ しっかり読み込みましょう 54

Slide 55

Slide 55 text

コンテキストマップ ● 違和感のある記述を訂正しつつ、各業務の責務と必要な情報を整理します ○ さらにDeepReserchです（chatは前出の続き ■ https://g.co/gemini/share/fa452c3d8e6d ○ レポート: 業務プロセス責務と関心事の整理 ■ こちらもしっかり読み込みましょう 55

Slide 56

Slide 56 text

コンテキストマップレポートを読み下しながら業務を置き、業務間を線でつないでみる ● まずは戦略マップを書いたときと同じぐらいの適当さで要素を置く ● レポートを読み込み、業務プロセスを想像しながら、因果関係を矢印の方向として落とし込み、業務の責務と必要な情報を書き出してみよう 56

Slide 57

Slide 57 text

コンテキストマップ ● ポイント: ○ 書いたらウォークスルーして→直して→ ウォークスルーして、、を繰り返してみましょう ○ 業務の過不足がありそう？なんか変？と違和感の元を添削しましょう 57

Slide 58

Slide 58 text

コンテキストマップ最もアツい業務はどれだ？ ● 線が集中しているところ／起点になっているところ ● 事業活動として価値が高そうなところ（ビッグピクチャと同じ観点） ● ご自身が担当するプロセスでも良いと思う 58

Slide 59

Slide 59 text

コンテキストマップ ● ポイント: ○ 「必要な量だけ、つくり・運び・販売する」という文脈において、重要と目されるのは需要予測と生産計画だろう ○ 販売データやトレンドだけに依らず、VoCなども取り入れて予測するプロセスは、まさに情報製造小売業の中核に相応しいだろう ■ ファストリ社は分かりやすい戦略により判断できた ■ 分かりやすい判断根拠がない場合は、他社事例と比較して「際立って特色のあるプロセス」を見極めるのが良いでしょう 59

Slide 60

Slide 60 text

プロセスモデリング ● 最もアツい業務を分析する ● 目的: ○ 業務を代表するユースケースのプロセスを示し、そのプロセスを構成する要素を発見する 60

Slide 61

Slide 61 text

プロセスモデリング ● 今度は推論モデルに業務プロセスを分析してもらう ○ GoogleAIStudio（トークン消費が激しそうなので ○ prompt概要: ■ 需要予測プロセスの詳細分析 ■ DeepReserchによるレポート3種を添付 ■ OOPに精通した熟練エンジニアとしてイベスト手法で分析 ■ 画像の代わりに<アクター><コマンド>のようにタグで表現 61

Slide 62

Slide 62 text

プロセスモデリング ● ポイント: ○ 生成する粒度を揃えたかったのでビジネスプロセスモデル(BPM)のレイヤで粒度を指定した(出典) ■ ビッグピクチャなら FL2（詳細事業機能） ■ 今回指定したレイヤは FL4（詳細業務機能） ■ 詳細なプロセスモデルでは FL7（単位操作） 62

Slide 63

Slide 63 text

プロセスモデリング ● BPM レイヤ一覧（青字は言い換え、()内は粒度の個人的な感覚） ○ FL0: 事業単位 ○ FL1: 事業機能 ○ FL2: 詳細事業機能 ○ FL3: 業務機能業務領域（コンテキストマップ: 生産計画） ○ FL4: 詳細業務機能業務（プロセスモデル: 日次生産計画を調整した） ○ FL5: 単位作業作業（詳細プロセスモデル: SKUごと反復処理） ○ FL6: 要素作業手順（詳細プロセスモデル: 仮所要量を再計算する） ○ FL7: 単位操作操作（あれ？） ○ FL8: 要素操作 63

Slide 64

Slide 64 text

プロセスモデリング ● ともあれ生成AIってすごいですね ○ ちゃんと出てきた ○ 正直ダメかなと思ってた ○ 今回、一番助けられた（自力だと挫けてたかも？？ 64

Slide 65

Slide 65 text

プロセスモデリング検証も兼ねてイベントストーミングの体裁にしてみる ● 当初、需要予測でアプローチしましたが生産計画に変更 65

Slide 66

Slide 66 text

プロセスモデリング ● 気になるプロセスをさらに深掘りする ○ 「日次生産計画の見直しと調整 (リアルタイム反映)」が気になりました ○ これはきっと、月次計画から日々の需要変動などを加味しつつ、自動化されていない調整業務などを経て最終確定する業務です ○ 「自動化されていない調整業務」が多くあり、もはや意味も分からないままトイル的に行われているに違いありません 66

Slide 67

Slide 67 text

プロセスモデリング ● 先ほどのchatの続きで深掘りをお願いします ○ 粒度はFL.7(単位操作)を指定し、さらに注文を付けます ■ コマンドは単一責任原則を踏襲したメソッド程度の粒度で定義し、集約とコマンドの関係性においては、カプセル化を強く意識して定義してください ● 生成AIってすごいですね 67

Slide 68

Slide 68 text

プロセスモデリング検証も兼ねて（ry ● 注文が行き過ぎたせいか、アプリケーションの動作に寄り過ぎてしまった感がありますが、、 ● イベントストーミングのお作法に沿わないところも整えます 68

Slide 69

Slide 69 text

構造化モデルへの落とし込み ● 構造化モデル＝ドメインモデルでいいんですが、、 ● ドメインモデルって、業務エキスパート的に取っつきにくい気がしませんか？ ● 目的: ○ 得られた要素を構造化し、新たな洞察を得る起点にする 69

Slide 70

Slide 70 text

構造化モデルへの落とし込み ● なので業務エキスパートの方々とわいわいするために純粋に業務上の概念を構造化したモデルを作成します ○ 概念構成図と呼んでます 70

Slide 71

Slide 71 text

構造化モデルへの落とし込みプロセスモデルを構造化する ● プロセスモデルから、集約・コマンド・イベントを抜き出して並べます 71

Slide 72

Slide 72 text

構造化モデルへの落とし込みプロセスモデルを構造化する ● 「流れ」的な要素を矢印で示しつつ、要素を添削して全体を構成します 72

Slide 73

Slide 73 text

構造化モデルへの落とし込みプロセスモデルを構造化する ● さらに構造化を進めます ● リードモデル、集約、コマンド、ユースケース、イベント、外部リソースやアクターの位置を決めて配置します 73

Slide 74

Slide 74 text

構造化モデルへの落とし込みいろいろな気付きを書き込む ● 素朴な疑問や気付き、思ったことをどんどん書き込みます ● ここで忖度したら負けです。ジュニアもグイグイいきましょう 74

Slide 75

Slide 75 text

● なんかできました🎉 合ってるかどうかは知らんけど!!! ● でもいいんです。精度なんて二の次です。目で見て、指を指して、認識を揃えるネタができたことをまずは喜びましょう ● ゼロから認識合わせるより修正したほうがきっと早い話にならなくても、雑絵を描き始めるきっかけにはなる 75 わいわいしに行こうぜ！

Slide 76

Slide 76 text

【おまけ】戦術的設計へ集約、エンティティ、値オブジェクトを識別する ● 想像の産物からソフトウェアの設計に進むのは狂気の沙汰ですが、この営みで重要な集約を発見したとして、その設計とは？という戦術的設計とのつなぎを少しだけ 76

Slide 77

Slide 77 text

まとめ

Slide 78

Slide 78 text

● モデリングの意義 ● 特に「複数のモデル」を作成する意義 ● 各モデルを通して問題領域を眺めることで視点を移動させるということ ○ 具体 ⇔ 抽象 ○ 動的 ⇔ 静的 78 【再掲】　今日、持って帰ってほしいこと

Slide 79

Slide 79 text

【再掲】　今日、お伝えしたいこと ● 各モデルの目的は何か？ ● それらのモデルを糸口に事業をどう捉えるか？ 79 モデリングの本質的な価値： ● 多角的な視点（具体/抽象、動的/静的）でドメイン (事業領域) を捉え、理解を深め、より良いソフトウェア設計に繋げる

Slide 80

Slide 80 text

戦略マップ ● 目的 ○ 競争優位性の源泉となる要素を特定する ● 抽象度レベル ○ 事業活動全体 ● 種別 ○ 静的 80

Slide 81

Slide 81 text

ビッグピクチャー ● 目的 ○ フォーカスすべき業務領域を特定する ● 抽象度レベル ○ 事業プロセス ● 種別 ○ 動的 81

Slide 82

Slide 82 text

コンテキストマップ ● 目的 ○ フォーカスすべき業務を特定する ● 抽象度レベル ○ 業務領域 ● 種別 ○ 静的 82

Slide 83

Slide 83 text

プロセスモデル ● 目的 ○ 業務プロセスを分析し、構成要素を発見する ● 抽象度レベル ○ 業務～操作 ● 種別 ○ 動的 83

Slide 84

Slide 84 text

概念構成図 ● 目的 ○ 業務上の新たな洞察を得る ● 抽象度レベル ○ 操作 ● 種別 ○ 静的 84

Slide 85

Slide 85 text

モデル別目的まとめ 85 モデル目的抽象度動的 / 静的戦略マップ競争優位性を特定する事業静的 (構造) ビッグピクチャー重要業務領域を特定する事業動的 (流れ) コンテキストマップ最重要業務を特定する業務領域静的 (構造) プロセスモデルプロセスを分析し、構成要素を発見する業務～　操作動的 (流れ) 概念構成図新たな洞察を得る操作静的 (構造)

Slide 86

Slide 86 text

【再掲】なぜモデリングなんて面倒なことを!? ● 競争優位性を獲得したい!!! ○ 競争優位性を獲得・維持するためには、重要なプロセスを繰り返し改善する必要がある ○ 対象のプロセスを構造的に捉え、高い保守性を得ることは迅速性(→適時性)を高め・コスト効率を高める ○ 業務フローやイベントストーミングのような動的なモデルを構造化し、静的なモデルを得て、深い洞察に至ることは設計プロセスそのもの 86

Slide 87

Slide 87 text

ありがとうございました 87