Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
EventStorming SoftwareDesign as a Cooperative Game
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
98lerr
August 02, 2020
Technology
1.1k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
EventStorming SoftwareDesign as a Cooperative Game
2020.8.2 にモデリング会で EventStorming のうちの ProcessModeling を行った際、参考にした資料です。
98lerr
August 02, 2020
More Decks by 98lerr
See All by 98lerr
AWS Builder Cards Guide ver.2024.03.02
98lerr
3
520
5分でわかった気になるSystemsManager
98lerr
5
1.6k
週次も無理だったチーム内勉強会が 毎日になった話
98lerr
0
1.7k
AWSの基礎を学ぼうで学んだ9種類のDBを勝手にふりかえる
98lerr
2
2k
モデリング会イントロダクション
98lerr
0
280
Other Decks in Technology
See All in Technology
制約理論(ToC)入門 2026版
recruitengineers
PRO
6
2k
ガバメントクラウドでのランサムウェア対策
techniczna
2
1k
【CEDEC2026】『Relink』を拡張せよ - 『GRANBLUE FANTASY: Relink - Endless Ragnarok』の開発速度と品質を守るCI運用
cygames
PRO
0
140
生成 AI の基礎 〜 サンプル実装で学ぶ基本原理
enakai00
7
4.4k
AIエージェントを前提としたプラットフォーム エンジニアリング:GKEで作るAgent-Ready Golden Path
legalontechnologies
PRO
2
220
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
19k
攻撃と防御で学ぶAI時代のプロダクトセキュリティ演習
recruitengineers
PRO
7
2.2k
TypeScript入門 2026
recruitengineers
PRO
2
500
20260807_第6回_関東kaggler会LT_claw系bot xangiと始める、"寂しくない" kaggle
sugupoko
0
200
AIは実装を速くする。では、私たちは何を今作るべきか?-立場を越えてリリースに向き合ったチーム開発の実践 / 20260801 Hiromi Nakaya and Naoki Takahashi
shift_evolve
PRO
3
450
個人OSSが、机の上から世界に広がるまでの話
shinyasaita
1
370
20260804_Q4AzureUpdateBite_FabricDataAgentの精度を高める設計.pdf
matayuuu
1
120
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
360
Tell your own story through comics
letsgokoyo
1
1k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Building an army of robots
kneath
306
46k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
270
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
410
Skip the Path - Find Your Career Trail
mkilby
1
180
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
230
The Pragmatic Product Professional
lauravandoore
37
7.4k
Paper Plane (Part 1)
katiecoart
PRO
1
10k
Transcript
Event Storming software design as a cooperative game Modeling-Kai 2020.08.02
現状と今日進めること • 前回やったこと ◦ Big Picture で全体を視覚化した。 ◦ どんな Command
から どんな Event が発生していくかを書き出した。 • 今回やること ◦ Cooperative Game で間のプロセスのモデリングを行う。
Vision から詳細化、そして戻る https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming/83 今日は ここ
今日の進め方 • Big Picture の Events をもとに、Cooperative Game を進める。 •
プロセスの開始から、順に付箋を並べていく。 ◦ Command → Event の 間を埋めていく。 ◦ カラーベースの文法にしたがって、順番に並べる。 • Rush to the Goal. ◦ まずは 1つのHappy Path を通す。複数Pathを並行して進めない。 ◦ 疑問点、分岐は一旦 HotSpot の付箋を置いて進める。
Cooperative Game を使いたくなる状況 • Process Modeling の実施方法 • Big Picture
を書いてみて ◦ そこで見つかる複雑な問題に、明確な答えはない。 ◦ 背景の違うメンバー全員で合意を取るのは難しい。 • 共通のゴールを持ちたい。
Cooperative Game: Model Sessionのやり方 進め方は 3通り (組み合わせOK) • 頭から :
ユーザからのコマンド、または外部ソースのイベントから ◦ わかりやすい、自然なストーリー ◦ 分岐が一番起きやすい。 Rash to the Goal が大事かも。 • 後ろから : Event + People + Value から戻る ◦ 無駄がない ◦ 経験がいる、結果が明確である必要がある。 • ごちゃごちゃに : イベント周りのブレストから。 ◦ 現状の矛盾を出しやすい、議論がなければスケルトンを作りやすい。 ◦ 議論が暴走しやすい。散らかる。
Rush to the Goal 1. まずは最短ルートのゴールへの道筋を声に出していう。 2. 異論をキャプチャして、ホットスポットとして挙げる。 a. 代替パスをホットスポットとして全て挙げる。
b. とにかく一つゴールに向かう。 c. 終わったら、ホットスポットを一つ 選んで再度行う。 https://www.slideshare.net/ziobrando/software-design-as- a-cooperative-game-with-eventstorming/53 https://www.slideshare.net/ziobrando/software-design-as- a-cooperative-game-with-eventstorming/56
Game Rules: Cooperative Game ルールは4つ。(Software Design まで入ると、5つ目が増える) 1. 全てのプロセスパスが完了する 2.
カラーベースの文法に則っている 3. 全てのステークホルダーが合理的に満足している 4. 全てのホットスポットに対処できている。 5. アグリゲートが一貫している。
プロセスパスが完了するとは? • ビジネスプロセスは、一連ステップだけでは終わらない ◦ 最終的にメインストリームに戻るものもある。 ◦ 異なる終了条件で終了するものもある。 • プロセスのあるべき姿 ◦
開始: 与えられたトリガー(Command あるいは 外部Event) ◦ 終了: Eventと Model の組み合わせ ▪ Event: System Happy (これ以上やることない) ▪ Model: User Happy (終わったと認識できてる) • People + Value で表現 ◦ 「可能な限り幸せ」な状態で終わる。 ▪ 例: キャンセルは全員にとっての完全な幸せでないが、可能な限りの幸せ。
カラーベースの文法 1:やること • 大きくは以下を実施していく。 ◦ 青色(Command)とオレンジ(Event)の間に、ピンク(System) を置く ◦ オレンジ(Event) と
青色 (Command) の間に、薄紫色(Policy) を置く https://www.slideshare.net/ziobrando/software-design-as-a-cooper ative-game-with-eventstorming/40 https://www.slideshare.net/ziobrando/software-design-as-a-cooper ative-game-with-eventstorming/67
カラーベースの文法 2:色見本 https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-wit h-eventstorming/40 青: Command オレンジ: Event ピンク: System
薄紫色: Policy 緑色: Read Model 黄色: People 蛍光ピンク: Hot Spot (紫) (45°傾ける) ----------------- 赤/緑の小さい付箋: Values 薄黄色: Aggregate https://baasie.com/2020/07/16/eventstormin g-core-concepts-glossary-and-legend/
カラーベースの文法 3:付箋の補足(Event) [Event] 常に以下4つの状況の結果 トリガー ユーザインタラクション ユーザ起点。Command, System が手前にくる。 複数イベントがトリガーされることもある。
外部システム センサーとか。一定間隔サンプルとかなら、時間トリガー。 時間 分周期のタイマーとか、1日の終わりにとかタイムアウトとか。 特殊ケースがあるなら、ポリシーでカバーする。 カスケード あるイベントが起きると、このイベントもというようなもの。 間にポリシーなどが挟めるかもしれない。
カラーベースの文法 4:付箋の補足(Command, People) [Command] • システムで起こっているアクション。ユーザの意思決定。 • 呼び方はチームで。Action でも Intention
でも。 • コマンドは完了を意味しない。 [People] • まずは何かをする人を表す。利用者も、内部ユーザも。 • 異なるタイプの人、異なるステップで分けるのが有効なこともある。 ◦ 通勤目的の切符購入、休暇目的の切符購入。 ◦ モデルに欠陥が出てきたとき、差別化する対応はよくある。
カラーベースの文法 5:付箋の補足(System, ReadModel) [System] • 一般化して書くのはよくない。明示的にする。 ◦ Social Media <
Twitter, Facebook (代表的なものを書く) • 対話型システムの場合、横に長くなって行きがち。 ◦ Systemの後ろにEventを並べることがおすすめ。対話結果を重視する。 [ReadModel] • 与えられた決定を行うために必要な情報。 Event 1 System Event 2 Event 3
カラーベースの文法 6:付箋の補足(Policy) [Policy] • イベントに対するリアクション。 ◦ 暗黙的に行われるもの ◦ 明示的に行われるもの ◦
自動対応 • イベントとコマンドの間にはなくてはならないもの。 ◦ 明白すぎて気付きにくいこともあるが、2つの間には常にビジネス上の意思決定がある。 • 名前に時間をかけすぎないつけなくてもいい。 ◦ 何をするか、まずは実施することを声に出す。それでも名前が決まらないこともある。 • 嘘が多く混ざる場所。 ◦ ポリシー通りの実態があるとは限らない。 ◦ 議論の余地のあるトピックが多くある。 • 「いつも」「すぐ」と合わせて読む。 ◦ コーナーケースが見えてくる。
カラーベースの文法 7:付箋の補足(Value, Hotspots) [Value] • それぞれのStep で作られる、または削除される。 ◦ わかりやすいのはお金 ◦
なんらかの機会、不一致状況。時間、ストレス、満足。 • 原書だと2020.8.2時点では記述なし。 [HotSpots] • 矛盾、おかしいところ、質問を書く。 • Rush to the Goal を使って一つずつ解決していく。(次のステップ) People :( People :)
Model Session 中盤の対処 • 目に見えないものは口にしない。 • Rush to the Goal.
参考 • Introducing EventStorming ◦ https://leanpub.com/introducing_eventstorming • Software design as
a cooperative game with EventStorming ◦ スライド: https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming ◦ 動画: https://www.youtube.com/watch?v=awyMC9PZNfc (AgileByExample 2019) • 新しいモデリング手法: EventStorming (イベントストーミング) をはじめるための準備 ◦ https://yoskhdia.hatenablog.com/entry/2018/11/09/200556 • EventStorming; Core concepts, glossary and legend ◦ https://baasie.com/2020/07/16/eventstorming-core-concepts-glossary-and-legend/