---
title: EventStorming Workshop
tags: event_storming_workshop
robots: noindex, noarchive
---

<style>
.center {
text-align: center;
}
</style>

### EventStorming
- [Alberto Brandolini](https://twitter.com/ziobrando) さんが提案
- モデリング手法の一種
- ビジネスに関わるイベントを時系列順に並べる（タイムライン）
- ビジネスプロセス（物語）全体を俯瞰できるようにする
- 最終的には一枚の絵にボトルネックもコアドメインも現れる（Big Picutre EventStorming）

----

### EventStorming

*"EventStorming enables cross-perspective conversation"*

###### [Introducing EventStorming](https://leanpub.com/introducing_eventstorming)

----

### Event（ドメインイベント）
- 物語の構成要素
- 行動の結果/成果
- 「商品がカートに追加された」、「商品が発送された」
- past tense（過去時制）で表現される
- アクターを固定することで生じてしまう制約をなくす
- 状況やトラブルと混同させない

----

{%speakerdeck baasie/from-eventstorming-to-coddding-at-javaland?slide=24 %}

----


----


----

### [Introducing EventStorming](https://leanpub.com/introducing_eventstorming)
- EventStorming の実践方法の話だけかと思いきやソフトウェア開発についての問題提起（著者のスタンス）も細かく書かれている
- EventStorming を始める時の障害
- 会場設営やファシリテーターの振る舞い

<div class="center">

</div>

----

### 「ソフトウェアの価値を届ける」とは
- 動作するソフトウェアを届けること？
- コーディング？
- それまで存在しなかったモノを作ること？

----

### ソフトウェア開発の本質は探求でコードを書くのは副次的なモノ
- 解決したい問題を理解すること
- 大事なのは型とかではない
- ステークホルダーが言っていることを理解しないといけない
- 綺麗なコードに感嘆を示すのではなくなぜその設計になっているのかという点に視点を向ける

----

### ぶっちゃけて言うと、エンタープライズソフトウェア開発を回すための一般的なプラクティスはう○こです。
### 探究ではなく生産することに最適化してしまっています。
### ダイエットするときに体重の増減だけに気を遣って、日頃の習慣や食事量、運動量に気を使わないのと同じくらいアホです。

----

### 一般的なアジャイルの現場
- 計画と納期に最適化していて発見には最適化していない
- 優先度のつけられたタスクをこなすだけ、仕様通り動けばいい
- 決まった仕様は探求を妨げる制約になる
- 最適解から遠く離れたところからのイテレーション
- イテレーティブな改善はコストがかかるのでなるだけ良い初期値から始めたい

----

### 一般的なアジャイルの現場
- PO が SPoF
- 全体像を把握しているのは PO だけ（誰も把握してないケースもある）
- 習慣を破った時に発見の機会がある
- 探求をしている時間は与えられない
- タスクをこなすことで精一杯

----

### 組織の問題
- 知識のサイロ化
- 縦割りは探求の障害
- 影響力や権力が強い人にひきづられる
- [群盲象を評す（木を見て森を見ず）](https://ja.m.wikipedia.org/wiki/%E7%BE%A4%E7%9B%B2%E8%B1%A1%E3%82%92%E8%A9%95%E3%81%99)

<div class="center">

</div>

----

### 部門が違うステークホルダーを全部集める必要があるか？
- ある
- 閉じたサイロで最適化されていても全体最適だと言えるか？
- サイロの境界部分に未検討の事柄やバグが潜んでいることが多い
- 返品交換で倉庫に商品が戻ってきたときに在庫追加はしてないんだけど注文管理的には大丈夫です！いや、経理的にも在庫管理的にもダメです！

----

### コーディング以外の障害も多い点は考慮する必要がある
### 正直言ってあまり気乗りしない

----

### それでもできるだけ良いソフトウェアを届けたいという思いはみんなもってるはず

----

### ソフトウェア開発者はドメインエキスパートから学ぶ必要がある
### 一貫性のあるモデルを発見するにはビジネスプロセスの全体像を俯瞰する必要がある
### （正直やったことないけど）とりあえずやってみよう

----

### アイスブレイク
- シンデレラを題材に EventStorming
- [Cinderella story](http://www.irishinlondontheatre.co.uk/free-playwriting-course-the-story-of-cinderella)
- [映画](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%B3%E3%83%87%E3%83%AC%E3%83%A9_(1950%E5%B9%B4%E3%81%AE%E6%98%A0%E7%94%BB))

----

### RealtimeBoard
- オンラインホワイトボード
- 複数人で同時編集できる
- [Ice Break/Cinderella](https://miro.com/welcomeonboard/rcCRDvKRsOY1J5RRmwXp2Q17nwfdN4XKddrMPSCpKJShqJzKjVKnC8SZ2fkx2N1U)

----

### 諸注意（開発者向け）
- 細かい言葉探しはしない
- ビジネスプロセスの全体像を俯瞰することが目的
- Bounded Context が決まらないうちに名詞を探しても意味がない
- 「ソフトウェアを作る」ということは一旦忘れる

----

### 諸注意（開発者向け）
- 「起きたこと」をただ洗い出していく
- 順方向/逆方向の一貫性が取れていることを確認する
- あるイベントが起きることを説明できるだけの情報が可視化されているかどうか

----

### 今回扱わなかった内容
- カオス探索 ---> タイムラインを整理
- Pivotal Event（重要そうなイベントを仮決めして並び替え）
- Swimlane（アクターの関心ごとに線引き）
- Two parallel flows may require independent models.

----

### 今回扱わなかった内容
- People / Systems
- イベントだけではビジネスプロセスの一貫性を確かめることができない
- People の種類に応じて特別なアクションを取る必要が出てくる
- 「重要なのはわれわれと外部システムの境界で何が起きているか、です。そして、境界線や無人島を認識するには、少し “他方側” についても可視化されている必要があります。」

----

### 今回扱わなかった内容

- Problem（紫の付箋） / Opportunity（緑の付箋）
- Event が中断されることがあるような Problem
- Problem に対する具体的な解決策
- 注力すべき問題の選択
- Hot Spot
- 投票

----

### 今回扱わなかった内容
- Big Picture のあとは？
- user story mapping
- value mapping
- design level EventStorming
- Design Level EventStorming
- Policies、Command、ReadModel、Aggregate

----

### その他
- 同じデータを持っているからと言って同じモデルであるとは限らない
- データとモデルを同一視してはいけない
- 「〇〇というデータを持っているから△△なのだ」みたいなモデルの決め方は歪んでくる
- 普遍なのは振る舞い

----

### 参考資料
- 書籍
- [Domain-Driven Design: The First 15 Years](https://leanpub.com/ddd_first_15_years)
- [Introducing EventStorming](https://leanpub.com/introducing_eventstorming)
- youtube
- https://www.youtube.com/watch?v=WvkBKvMnyuc
- https://www.youtube.com/watch?v=xIB_VQVVWKk
- https://www.youtube.com/watch?v=NGXl1D-KwRI
- ブログなど
- [新しいモデリング手法: EventStormingをはじめるための準備](https://yoskhdia.hatenablog.com/entry/2018/11/09/200556)
- [Event Storming and Narrative](https://speakerdeck.com/yoskhdia/event-storming-and-narrative)
- https://www.eventstorming.com/resources/
- https://buildplease.com/pages/fpc-6/
- https://www.infoq.com/news/2016/05/software-development-challenges
- カンファレンス
- http://exploreddd.com/workshops/domain-driven-design-and-event-driven-microservices.html
- 勉強会
- [Introducing EventStorming読書会@西新宿](https://readeffectiveakka.connpass.com/event/127630/)

----

### アイスブレイクやってみた感想/気づき
- RealtimeBoard
- 付箋のサイズに悩む
- 日本語だと改行しないといい感じに文字が付箋に表示されない
- 背景の白用紙は邪魔かも（付箋を移動するときに一括選択しづらい）
- スタート時に付箋で遊び始める

----

### アイスブレイクやってみた感想/気づき
- Pivotal Event
- 知ってるストーリーだったから場面が変わるところを基準として選びやすかった
- 場面が変わると主観や場所が変わる
- ある Event を契機に parallel で timeline ができるところを選ぶといいかも
- 複数のアクターからの関心を集めているところ
- どこかで登場人物が増えるとそこに関心がいく

----

### アイスブレイクやってみた感想/気づき
- 先に Swimlane を切るべきか？
- 一旦後でいいと思う
- 複数の部門から関心がある Event を同一視しすぎずになんとなく違うということがわかるように配置する

----

### アイスブレイクやってみた感想/気づき
- past tense
- 過去形でないものはアクターの主観が混じっていてそれはイベントではなくアクションかもしれない
- 同じイベントでも主観が変われば表現が変わる
- 制約というより思い込みという表現を使った方がいいかも？

----

### アイスブレイクやってみた感想/気づき
- それぞれの登場人物の視点で役割分担してイベントを出すべきだった
- シンデレラ（嫁候補）、王子様&王族、継母＆姉妹、魔法使い＆動物たち
- イベントを辿るのはそれぞれの登場人物の担当の人にやってもらった方がいいかも
- ファシリテータはあくまでファシリテータ

----

### アイスブレイクやってみた感想/気づき
- 逆順でイベントを辿る
- ユースケースとかチャプターの区切りがあった方いいかも
- イベント（ユースケースなど）の区切りが可視化されてないので繋がり得ないものをつなごうとしてしまう
- あるイベントが他のレーンのイベントに依存してたらそのあとはどう辿る？
- 他のレーンのイベントが自分のレーンのイベントが発生する理由足り得るがを確認して自分のレーンに戻る

----

### アイスブレイクやってみた感想/気づき
- 感情の変化をイベントとして良いかどうか
- 継続している状態をイベントとして表現するのは難しいかも

----