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

概念モデリングと生成AIで加速するシステム開発
2025.6.7 JJUG CCC 2025 Spring

Transcript

1. イベントストーミングから 始めるドメイン駆動設計 概念モデリングと生成AIで 加速するシステム開発 おだかとしゆき as JGEEM（@EM4326168385309） 2025.6.7 JJUG CCC 2025 Spring
2. 自己紹介 おだかとしゆき 株式会社MonotaRO シニアアーキテクト as JGEEM（@EM4326168385309） 事業(J)会社(G)の元(Ex)EM / 53才 現職はアーキテクチャと格闘 定年までできることしたいことを探る日々 定年後もキャリアは続く/ AIIT 科目等履修生 / 貢献てなんだろう see also scrapbox，speakerdeck 2
3. 本日の資料 • 各種モデル: Miro • 生成AI: Gemini, DeepResearch, GoogleAIStudio • レポート: ◦ ファストリ戦略分析とマップ骨子, ◦ 有明プロジェクト業務プロセス詳細調査 ◦ 業務プロセス責務と関心事の整理 3
4. セッションの 目的と背景
5. セッションの背景と目的 • 事業の競争優位性？エンジニアが意識すること？ • ビジネスや業務のこと、もっと知りたいけど 業務エキスパートに凸るのも、、忙しそうだし • 構造化とか抽象化とかいうけど何なん 5
6. セッションの背景と目的 • 事業の競争優位性？エンジニアが意識すること？ ◦ もちろん。エンジニアリングは事業活動の一環 • ビジネスや業務のこと、もっと知りたいけど 業務エキスパートに凸るのも、、忙しそうだし ◦ 公開情報から事業理解を深め、予備知識を得る • 構造化とか抽象化とかいうけど何なん ◦ 各種モデリングの手法は、現実を扱いやすくする 6
7. セッションの背景と目的 エンジニアが公開情報から事業活動を分析し、 注力すべきビジネスプロセスを効果的に見極め、 各種モデリング手法を用いて 保守性の高いソフトウェア設計に繋げるプロセスを、 生成AIを使ってコストパフォーマンスよく進める 7
8. セッションの背景と目的 エンジニアが公開情報から事業活動を分析し、 注力すべきビジネスプロセスを効果的に見極め、 各種モデリング手法を用いて 保守性の高いソフトウェア設計に繋げるプロセスを、 生成AIを使ってコストパフォーマンスよく進める 8
9. 今日、持って帰ってほしいこと 9
10. 今日、持って帰ってほしいこと • モデリングの意義 ◦ なぜモデリングするのか？ ◦ 何がうれしいのか？ 10
11. 今日、持って帰ってほしいこと • モデリングの意義 • 特に「複数のモデル」を作成する意義 • 各モデルを通して問題領域を眺めることで 視点を移動させる ということ ◦ 具体 ⇔ 抽象 ◦ 動的 ⇔ 静的 11
12. 今日、お伝えしたいこと • 各モデルの 目的は何か？ • それらのモデルを糸口に 事業をどう捉える か？ 12
13. 今日、お伝えしたいこと • 各モデルの 目的は何か？ • それらのモデルを糸口に 事業をどう捉える か？ 13 モデリングの本質的な価値： • 多角的な視点（具体/抽象、動的/静的）で ドメイン (事業領域) を捉え、理解を深め、 より良いソフトウェア設計に繋げる
14. 今日、お伝えしたいこと • 各モデルの 目的は何か？ • それらのモデルを糸口に 事業をどう捉える か？ 14 モデリングの本質的な価値： • 多角的な視点（具体/抽象、動的/静的）で ドメイン (事業領域) を捉え、理解を深め、 より良いソフトウェア設計に繋げる
15. おしながき • ドメイン駆動設計(DDD)の基本的な考え方とメリット • 私がよく使う）モデルの目的と概要 ◦ 作成手順も少しだけ • 公開情報からビジネス理解を深めモデリングする ◦ 生成AIの使いどころ 15
16. ドメイン駆動設計 (DDD)の 基本的な考え方と メリット
17. DDDの基本的な考え方 • ドメイン(事業活動)中心 • ドメインモデル • ユビキタス言語 (同じ言葉) • 境界付けられたコンテキスト (区切られた文脈) • 関心の分離 • 共創と進化 17
18. そのメリット • 複雑性への対応 • 共通理解 • 保守性と拡張性 • ビジネスアジリティ • 価値への集中 18
19. ハードル高いんよ、、 • 複雑性への対応: 「複雑」を「扱いやすく」するには多くを整理・整頓 • 共通理解: 意思疎通は本当に難しい。いわんや複雑なものをや • 保守性と拡張性: 具体的にどうしたら、、え？抽象化？？ • ビジネスアジリティ: 保守性と拡張性を得て初めて効果 • 価値への集中: これが最重要なのは分かるが、誰がどうやって判断するの？ 19
20. ブロッカーは裏返せ • 複雑なものから不要なものを捨てて扱いやすくすれば、 コミュニケが捗る・コードも扱いやすくなる ◦ コードが扱いやすいなら保守性・拡張性が高いはず？ ならビジネスアジリティだって！ • 価値への集中って要はコスパでしょ？ 業務エキスパートと事業活動を肴にわいわいしたら 見えてくるんじゃね？ 20
21. 真のブロッカーが見えてきた • 複雑なものから不要なものを捨て ⊃ 捨像 つまりモデリング • 業務エキスパートと事業活動を肴にわいわい ⊃ その前に まずエンジニアだけで素振り 21
22. 量的なブロッカー • 本来は重要な領域なのに（だからこそ？） ◦ よく分からない・触りたくない ◦ いざ変更するとあちこちに影響しまくる ◦ 調査とテスト含めて半年かかります??? • リアーキテクチャすべきな気はするが、、 22
23. 量的なブロッカー • 本来は重要な領域なのに（だからこそ？） ◦ よく分からない・触りたくない ◦ いざ変更するとあちこちに影響でまくる ◦ 調査とテスト含めて半年かかります??? • リアーキテクチャすべきな気はするが、、 23
24. なぜ素振りが必要か • 「わいわい」と一方的に教えてもらうのもアリですが、 双方がある程度知識を持ってるほうが 盛り上がる • 業務エキスパートはたいてい忙しい（キーマンなので） • というわけで、まずエンジニアだけで素振りして 予備知識を仕入れたら良いことがありそう 24
25. • エンジニアの シニア・ジュニア間にも フラクタル構造が • 業務知識を獲得済みのチームに新規参戦したジュニアが 他のメンバと同じ視点を得るには オンボーディングが重要 ◦ 「ドキュメント読んどいて」では不十分 （そもそもドキュメント揃ってます？） ▪ シニアエンジニアは忙しい • メンタリングコストを捻出しにくい ◦ じゃあ OJT で！ ▪ 個人メモ止まり・曖昧な認識 • 永遠にドキュメント化されない ちなみに 25
26. ちなみにちなみに • ジュニアを AI に置き換えても同じ 構造が • AI を超上流工程 でも使いたい ◦ 1shotじゃ 一般論しか 出てこない ▪ 当社の事業領域や業務ルールなど、 文脈知識をインプットしたい • ドキュメント化されていない ◦ AI もまだまだだな??? 26
27. オンボーディングにおいて • 「OJTでキャッチアップするしかないっしょ」は甘え ◦ 新規参入者に（人にもAIにも） フレンドリーな体裁のインプットが不可欠 ◦ 文脈知識を得た AI は最強のメンターに？ ご参考: AI-Agent開発における文脈知識の獲得とモデリングの活用 さらに補足: • モデリングと論理的推論（あるいはエンジニアリングを進歩させるナレッジとは） • 帰納法・演繹法・アブダクションについてモデリングと抽象化の観点から考えを深める 27
28. 公開情報から ビジネス理解を深め モデリングする
29. 公開情報を収集/分析する (してもらう) • ファーストリテイリング社を題材にさせていただきました ◦ みんな大好きユニクロさん ◦ 私もヘビーユーザーですが、ビジネス・業務面では 縁もゆかりもありません 29
30. 公開情報を収集/分析する (してもらう) • 企業選定のポイント: 公開情報が潤沢 ◦ 直近1年間に統合報告書をリリースしている ◦ 直近3年分程度の有価証券報告書、決算説明資料、 プレスリリースが公開されている ◦ 第三者によるマーケティング分析が公開されている 30
31. 公開情報を収集/分析する (してもらう) • 企業選定: ざっくり生成AIに聞いちゃいましょう 31
32. 公開情報を収集/分析する (してもらう) • 企業選定: 生成AIの提案から選定するにあたって ◦ 当然ですが）生成AIの回答はまじめに読みましょう ◦ 気になりどころを質問して解像度を上げましょう ▪ 興味を持てるまで聞きまくりましょう ◦ 最重要）最終的には自分で選びましょう 32
33. 公開情報を収集/分析する (してもらう) • 企業情報収集のポイント ◦ 生成AIにお願いするの一択 ▪ 自分でイチから収集/分析する必要はないでしょう いい時代になりましたね 非上場企業を対象とする場合は自力収集しないと、、 どんな情報があったらいい？と参考にしていただければと思います。 33
34. 公開情報を収集/分析する (してもらう) • 生成AIに情報収集をお願いする（ https://g.co/gemini/share/f965f6350d98 ） ◦ どんな資料を分析したらいい？進め方は？ ▪ ファーストリテイリング社発行のIR資料（内容と確認ポイント） • 統合報告書 / アニュアルレポート • 決算説明会資料 / ファクトブック • 有価証券報告書 ▪ 第三者による分析レポート・記事（内容と確認ポイントと備考） • 証券会社のアナリストレポート • 業界レポート / 市場調査レポート • ビジネス系メディアの記事 / 書籍 ▪ 深い洞察を得るための進め方 ←これ重要 34
35. 公開情報を収集/分析する (してもらう) • 得られた回答の分析をお願いします （ https://g.co/gemini/share/fa452c3d8e6d ） ▪ 収集フェーズで得たアウトプットを そのままDeepResearchへのリクエストに流用します ▪ レポート: ファストリ戦略分析とマップ骨子 • DeepReserchの仕事はまだ続きますが、一旦はここまで • しっかり読み込みましょう 35
36. 公開情報を収集/分析する (してもらう) • さらにそのままモデリングもお願いしてみた ◦ ぜんぜん無理でした ◦ mermaid記法の表現力に限りがあるのか、 現時点でモデルの限界なのか、 私の指示が未熟なのか、、 36
37. 概念モデリングによる事業活動の可視化 • ざっくりと流れを紹介 ◦ 活動システムマップ で事業活動全体を俯瞰し、 競争優位性の源泉となる要素を特定する ◦ 対象の要素について、 ビッグピクチャー を描いて大まかな流れをつかみ、 フォーカスすべき業務領域(区切られた文脈)を特定する ◦ 選定した業務領域を構成する業務間の係わりを コンテキストマップ で示し、最も重要な業務を特定する ◦ 業務を代表するユースケースのプロセスを プロセスモデル で示し、 そのプロセスを構成する要素を発見する ◦ 得られた要素を 構造化 し、新たな洞察を得る起点にする 37
38. 概念モデリングによる事業活動の可視化 • ポイント: 目的意識を持つ ◦ 何がしたいのか？ ▪ 全体の俯瞰から始まり、スコープを絞り込んで 注力すべき領域を発見する ◦ 何が嬉しいのか？ ▪ 少ないコストで高い効果を得る 38
39. 概念モデリングによる事業活動の可視化 • 競争優位性を獲得したい!!! ◦ 競争優位性を獲得・維持するためには、 重要なプロセスを繰り返し改善する 必要がある ◦ 対象のプロセスを構造的に捉え、高い保守性を得ることは 迅速性(→適時性)を高め・コスト効率を高める ◦ 業務フローやイベントストーミングのような動的なモデルを 構造化し、静的なモデルを得て、深い洞察に至ることは 設計プロセスそのもの 39
40. 【再掲】モデリングの流れ • 活動システムマップで事業活動全体を俯瞰し、 競争優位性の源泉となる要素を特定 する • 対象の要素について、ビッグピクチャーを描いて大まかな流れをつかみ、 フォーカスすべき業務領域(区切られた文脈)を特定 する • 選定した業務領域を構成する業務間の係わりを コンテキストマップで示し、最も重要な業務を特定 する • 業務を代表するユースケースのプロセスをプロセスモデルで示し、 その プロセスを構成する要素を発見 する • 得られた 要素を構造化し、新たな洞察を得る起点にする 40
41. 【再掲】モデリングの流れ • 活動システムマップで事業活動全体を俯瞰し、 競争優位性の源泉となる要素を特定 する • 対象の要素について、ビッグピクチャーを描いて大まかな流れをつかみ、 フォーカスすべき業務領域(区切られた文脈)を特定 する • 選定した業務領域を構成する業務間の係わりを コンテキストマップで示し、最も重要な業務を特定 する • 業務を代表するユースケースのプロセスを プロセスモデル で示し、 その プロセスを構成する要素を発見 する • 得られた 要素を構造化し、新たな洞察を得る起点にする 41
42. 活動システムマップ • ここから Miro を併用していきます • わたしの脳内都合で、活動システムマップのはずが 別のモデル（戦略マップ風）になってしまいました • 目的: ◦ 事業活動全体を俯瞰し、 競争優位性の源泉となる要素を特定する 42
43. 活動システムマップ まずは無造作に要素を置いていく • レポート (ファーストリテイリング社の競争優位性の源泉 ：ビジネス戦略の分析) に出てきた要素(主要なビジネスプ ロセス)を配置します 43
44. 活動システムマップ 戦略マップ 関係あんじゃね？って思われるものを「適当に」線でつなぐ • この辺は感覚ですね (自社なら？) • 各ビジネスプロセスの関連を 線で表します (向きは気にしない) • 活動システムマップのはずが 戦略マップ(下位が上位に寄与する)風に なってしまいました 44
45. 戦略マップ 線が集中しているところや、 起点になっているところを詳細化してみる • ここではやはり 情報製造小売業 が 気になったので深掘りしたところ、 有明プロジェクト という 取り組みが フォーカスされたので さらに深掘りして 情報を得ています 45
46. ビッグピクチャー • as イベントストーミング です • 有明プロジェクトとは何者かをざっくり把握します • 目的: ◦ 大まかな流れをつかみ、フォーカスすべき 業務領域(区切られた文脈)を特定する 46
47. イベントストーミング イベントストーミングで使う付箋の意味を • よく見るやつですね • 業務領域を分析する観点 • 複雑な現実を 意味付けられた付箋に合うよう捨像して 要素間の連携を分析するため 47
48. イベントストーミング • どこかで起きた業務イベントをトリガーにして • 何らかの業務ルールに基づき • または更新されたリードモデルを観測したアクターにより • コマンドが実行され • 集約や外部システムが更新されると • また業務イベントが起きる • 気になりどころはワークショップで大活躍 48
49. イベントストーミング • 時間の都合でイベストの詳細は割愛します 🙇 • さらに深く知りたい方のために ◦ 実践！モノリスからマイクロサービス！Event Stormingによる ドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo [speakerdeck] [youtube] ◦ AWS Summit Japan 2024 での福井さんのセッションも 素晴らしかったが公式の動画も資料も見つけられなかった [セッションレポート] 49
50. ビッグピクチャー ざっくりプロセスにしてみる • 上の画像はいわゆる ビジネスモデル • 「有明プロジェクト」で画像検索した結果 ◦ ヒットしない場合は後段の要領で 生成AIに相談しましょう ▪ BPMレベル2(詳細事業機能)です • これらの情報をもとに全体の流れを ビッグピクチャーとして表してみましょう 50
51. ビッグピクチャー フォーカスすべき業務領域の見当を付ける • プロセス（流れ）を最初から最後まで 声に出して説明してみる （ウォークスルー） • 事業活動として価値を創出している 業務領域はここじゃね？的な 感覚がきっとある 51
52. コンテキストマップ • いわゆるDDDのコンテキストマップとは目的が異なる • 目的: ◦ 業務領域を構成する業務間の係わりを示し、 最も重要な業務を特定する 52
53. コンテキストマップ • DDD的コンテキストマップ（文脈の地図） ◦ コンテキスト（区切られた文脈）間の 関係とその種類（緊密な関係、利用者と供給者、互い に独立）を示します（出典）※ 増田さんお借りしました • ここでは、コンテキスト＝業務領域を構成する要素 （より小さな業務領域or業務）間の責務の分離と関係性を 見ることを目的にします 53
54. コンテキストマップ • まずはフォーカスすべき業務領域を掘り下げ、 より小さな業務領域or業務に分けます ◦ もちろんDeepReserchです（chatは前出の続き ▪ https://g.co/gemini/share/fa452c3d8e6d ◦ レポート: 有明プロジェクト業務プロセス詳細調査 ▪ しっかり読み込みましょう 54
55. コンテキストマップ • 違和感のある記述を訂正しつつ、 各業務の 責務 と 必要な情報 を整理します ◦ さらにDeepReserchです（chatは前出の続き ▪ https://g.co/gemini/share/fa452c3d8e6d ◦ レポート: 業務プロセス責務と関心事の整理 ▪ こちらもしっかり読み込みましょう 55
56. コンテキストマップ レポートを読み下しながら業務を置き、 業務間を線でつないでみる • まずは戦略マップを書いたときと 同じぐらいの適当さで要素を置く • レポートを読み込み、 業務プロセスを想像しながら、 因果関係を矢印の方向として落とし込み、 業務の責務と必要な情報を書き出してみよう 56
57. コンテキストマップ • ポイント: ◦ 書いたらウォークスルーして→直して→ ウォークスルーして、、を繰り返してみましょう ◦ 業務の過不足がありそう？なんか変？と 違和感の元を添削しましょう 57
58. コンテキストマップ 最もアツい業務はどれだ？ • 線が集中しているところ ／起点になっているところ • 事業活動として 価値が高そうなところ （ビッグピクチャと同じ観点） • ご自身が担当する プロセスでも良いと思う 58
59. コンテキストマップ • ポイント: ◦ 「必要な量だけ、つくり・運び・販売する」という文脈において、 重要と目されるのは 需要予測 と 生産計画 だろう ◦ 販売データやトレンドだけに依らず、VoCなども取り入れて予測す るプロセスは、まさに 情報製造小売業の中核 に相応しいだろう ▪ ファストリ社は分かりやすい戦略により判断できた ▪ 分かりやすい判断根拠がない場合は、 他社事例と比較して「際立って特色のあるプロセス」を 見極めるのが良いでしょう 59
60. プロセスモデリング • 最もアツい業務を分析する • 目的: ◦ 業務を代表するユースケースのプロセスを示し、 そのプロセスを構成する要素を発見する 60
61. プロセスモデリング • 今度は推論モデルに業務プロセスを分析してもらう ◦ GoogleAIStudio（トークン消費が激しそうなので ◦ prompt概要: ▪ 需要予測プロセスの詳細分析 ▪ DeepReserchによるレポート3種を添付 ▪ OOPに精通した熟練エンジニアとしてイベスト手法で分析 ▪ 画像の代わりに<アクター><コマンド>のようにタグで表現 61
62. プロセスモデリング • ポイント: ◦ 生成する粒度を揃えたかったのでビジネスプロセスモ デル(BPM)のレイヤで粒度を指定した(出典) ▪ ビッグピクチャなら FL2（詳細事業機能） ▪ 今回指定したレイヤは FL4（詳細業務機能） ▪ 詳細なプロセスモデルでは FL7（単位操作） 62
63. プロセスモデリング • BPM レイヤ一覧（青字は言い換え、()内は粒度の個人的な感覚） ◦ FL0: 事業単位 ◦ FL1: 事業機能 ◦ FL2: 詳細事業機能 ◦ FL3: 業務機能 業務領域（コンテキストマップ: 生産計画） ◦ FL4: 詳細業務機能 業務（プロセスモデル: 日次生産計画を調整した） ◦ FL5: 単位作業 作業（詳細プロセスモデル: SKUごと反復処理） ◦ FL6: 要素作業 手順（詳細プロセスモデル: 仮所要量を再計算する） ◦ FL7: 単位操作 操作（あれ？） ◦ FL8: 要素操作 63
64. プロセスモデリング • ともあれ生成AIってすごいですね ◦ ちゃんと出てきた ◦ 正直ダメかなと思ってた ◦ 今回、一番助けられた（自力だと挫けてたかも？？ 64
65. プロセスモデリング 検証も兼ねてイベントストーミングの体裁にしてみる • 当初、需要予測でアプローチしましたが生産計画に変更 65
66. プロセスモデリング • 気になるプロセスをさらに深掘りする ◦ 「日次生産計画の見直しと調整 (リアルタイム反映)」が気に なりました ◦ これはきっと、月次計画から日々の需要変動などを加味しつ つ、自動化されていない調整業務などを経て最終確定する業 務です ◦ 「自動化されていない調整業務」が多くあり、もはや意味も 分からないままトイル的に行われているに違いありません 66
67. プロセスモデリング • 先ほどのchatの続きで深掘りをお願いします ◦ 粒度はFL.7(単位操作)を指定し、さらに注文を付けます ▪ コマンドは単一責任原則を踏襲したメソッド程度の粒度 で定義し、集約とコマンドの関係性においては、カプセ ル化を強く意識して定義してください • 生成AIってすごいですね 67
68. プロセスモデリング 検証も兼ねて（ry • 注文が行き過ぎたせいか、アプリケーションの動作に 寄り過ぎてしまった感がありますが、、 • イベントストーミングのお作法に沿わないところも整えます 68
69. 構造化モデルへの落とし込み • 構造化モデル＝ドメインモデルでいいんですが、、 • ドメインモデルって、業務エキスパート的に 取っつきにくい気がしませんか？ • 目的: ◦ 得られた要素を構造化し、 新たな洞察を得る起点にする 69
70. 構造化モデルへの落とし込み • なので業務エキスパートの方々とわいわいするために 純粋に業務上の概念を構造化したモデルを作成します ◦ 概念構成図 と呼んでます 70
71. 構造化モデルへの落とし込み プロセスモデルを構造化する • プロセスモデルから、集約・コマンド・イベントを 抜き出して並べます 71
72. 構造化モデルへの落とし込み プロセスモデルを構造化する • 「流れ」的な要素を矢印で示しつつ、要素を添削して 全体を構成します 72
73. 構造化モデルへの落とし込み プロセスモデルを構造化する • さらに構造化を進めます • リードモデル、 集約、コマンド、 ユースケース、イベント、 外部リソースやアクターの 位置を決めて配置します 73
74. 構造化モデルへの落とし込み いろいろな気付きを書き込む • 素朴な疑問や気付き、 思ったことをどんどん 書き込みます • ここで忖度したら 負けです。ジュニアも グイグイいきましょう 74
75. • なんかできました🎉 合ってるかどうかは知らんけど!!! • でもいいんです。精度なんて二の次です。 目で見て、指を指して、 認識を揃えるネタができたことをまずは喜びましょう • ゼロから認識合わせるより修正したほうがきっと早い 話にならなくても、雑絵を描き始めるきっかけにはなる 75 わいわいしに行こうぜ！
76. 【おまけ】戦術的設計へ 集約、エンティティ、 値オブジェクトを識別する • 想像の産物から ソフトウェアの設計に進むのは 狂気の沙汰ですが、この営みで 重要な集約を発見したとして、 その設計とは？という 戦術的設計とのつなぎを少しだけ 76
77. まとめ
78. • モデリングの意義 • 特に「複数のモデル」を作成する意義 • 各モデルを通して問題領域を眺めることで 視点を移動させる ということ ◦ 具体 ⇔ 抽象 ◦ 動的 ⇔ 静的 78 【再掲】 　今日、持って帰ってほしいこと
79. 【再掲】 　今日、お伝えしたいこと • 各モデルの 目的は何か？ • それらのモデルを糸口に 事業をどう捉える か？ 79 モデリングの本質的な価値： • 多角的な視点（具体/抽象、動的/静的）で ドメイン (事業領域) を捉え、理解を深め、 より良いソフトウェア設計に繋げる
80. 戦略マップ • 目的 ◦ 競争優位性の源泉となる 要素を特定する • 抽象度レベル ◦ 事業活動全体 • 種別 ◦ 静的 80
81. ビッグピクチャー • 目的 ◦ フォーカスすべき 業務領域を特定する • 抽象度レベル ◦ 事業プロセス • 種別 ◦ 動的 81
82. コンテキストマップ • 目的 ◦ フォーカスすべき 業務を特定する • 抽象度レベル ◦ 業務領域 • 種別 ◦ 静的 82
83. プロセスモデル • 目的 ◦ 業務プロセスを 分析し、構成要素を発見する • 抽象度レベル ◦ 業務～操作 • 種別 ◦ 動的 83
84. 概念構成図 • 目的 ◦ 業務上の新たな洞察を得る • 抽象度レベル ◦ 操作 • 種別 ◦ 静的 84
85. モデル別 目的まとめ 85 モデル 目的 抽象度 動的 / 静的 戦略マップ 競争優位性を特定する 事業 静的 (構造) ビッグピクチャー 重要業務領域を特定する 事業 動的 (流れ) コンテキストマップ 最重要業務を特定する 業務領域 静的 (構造) プロセスモデル プロセスを分析し、 構成要素を発見する 業務～ 　操作 動的 (流れ) 概念構成図 新たな洞察を得る 操作 静的 (構造)
86. 【再掲】 なぜモデリングなんて面倒なことを!? • 競争優位性を獲得したい!!! ◦ 競争優位性を獲得・維持するためには、 重要なプロセスを繰り返し改善する 必要がある ◦ 対象のプロセスを構造的に捉え、高い保守性を得ることは 迅速性(→適時性)を高め・コスト効率を高める ◦ 業務フローやイベントストーミングのような動的なモデルを 構造化し、静的なモデルを得て、深い洞察に至ることは 設計プロセスそのもの 86
87. ありがとうございました 87