EventStorming SoftwareDesign as a Cooperative Game

2020.8.2 にモデリング会で EventStorming のうちの ProcessModeling を行った際、参考にした資料です。

Transcript

1. Event Storming
   software design as a cooperative game
   Modeling-Kai 2020.08.02
   

   View Slide

2. 現状と今日進めること
   ● 前回やったこと
   ○ Big Picture で全体を視覚化した。
   ○ どんな Command から どんな Event が発生していくかを書き出した。
   ● 今回やること
   ○ Cooperative Game で間のプロセスのモデリングを行う。
   

   View Slide

3. Vision から詳細化、そして戻る
   https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming/83
   今日は
   ここ
   

   View Slide

4. 今日の進め方
   ● Big Picture の Events をもとに、Cooperative Game を進める。
   ● プロセスの開始から、順に付箋を並べていく。
   ○ Command → Event の 間を埋めていく。
   ○ カラーベースの文法にしたがって、順番に並べる。
   ● Rush to the Goal.
   ○ まずは 1つのHappy Path を通す。複数Pathを並行して進めない。
   ○ 疑問点、分岐は一旦 HotSpot の付箋を置いて進める。
   

   View Slide

5. Cooperative Game を使いたくなる状況
   ● Process Modeling の実施方法
   ● Big Picture を書いてみて
   ○ そこで見つかる複雑な問題に、明確な答えはない。
   ○ 背景の違うメンバー全員で合意を取るのは難しい。
   ● 共通のゴールを持ちたい。
   

   View Slide

6. Cooperative Game: Model Sessionのやり方
   進め方は 3通り (組み合わせOK)
   ● 頭から : ユーザからのコマンド、または外部ソースのイベントから
   ○ わかりやすい、自然なストーリー
   ○ 分岐が一番起きやすい。 Rash to the Goal が大事かも。
   ● 後ろから : Event + People + Value から戻る
   ○ 無駄がない
   ○ 経験がいる、結果が明確である必要がある。
   ● ごちゃごちゃに : イベント周りのブレストから。
   ○ 現状の矛盾を出しやすい、議論がなければスケルトンを作りやすい。
   ○ 議論が暴走しやすい。散らかる。
   

   View Slide

7. 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
   

   View Slide

8. Game Rules: Cooperative Game
   ルールは4つ。(Software Design まで入ると、5つ目が増える)
   1. 全てのプロセスパスが完了する
   2. カラーベースの文法に則っている
   3. 全てのステークホルダーが合理的に満足している
   4. 全てのホットスポットに対処できている。
   5. アグリゲートが一貫している。
   

   View Slide

9. プロセスパスが完了するとは？
   ● ビジネスプロセスは、一連ステップだけでは終わらない
   ○ 最終的にメインストリームに戻るものもある。
   ○ 異なる終了条件で終了するものもある。
   ● プロセスのあるべき姿
   ○ 開始: 与えられたトリガー(Command あるいは 外部Event)
   ○ 終了: Eventと Model の組み合わせ
   ■ Event: System Happy (これ以上やることない)
   ■ Model: User Happy (終わったと認識できてる)
   ● People + Value で表現
   ○ 「可能な限り幸せ」な状態で終わる。
   ■ 例: キャンセルは全員にとっての完全な幸せでないが、可能な限りの幸せ。
   

   View Slide

10. カラーベースの文法 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
    

    View Slide

11. カラーベースの文法 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/
    

    View Slide

12. カラーベースの文法 3:付箋の補足(Event)
    [Event] 常に以下4つの状況の結果
    トリガー
    ユーザインタラクション ユーザ起点。Command, System が手前にくる。
    複数イベントがトリガーされることもある。
    外部システム センサーとか。一定間隔サンプルとかなら、時間トリガー。
    時間 分周期のタイマーとか、１日の終わりにとかタイムアウトとか。
    特殊ケースがあるなら、ポリシーでカバーする。
    カスケード あるイベントが起きると、このイベントもというようなもの。
    間にポリシーなどが挟めるかもしれない。
    

    View Slide

13. カラーベースの文法 4:付箋の補足(Command, People)
    [Command]
    ● システムで起こっているアクション。ユーザの意思決定。
    ● 呼び方はチームで。Action でも Intention でも。
    ● コマンドは完了を意味しない。
    [People]
    ● まずは何かをする人を表す。利用者も、内部ユーザも。
    ● 異なるタイプの人、異なるステップで分けるのが有効なこともある。
    ○ 通勤目的の切符購入、休暇目的の切符購入。
    ○ モデルに欠陥が出てきたとき、差別化する対応はよくある。
    

    View Slide

14. カラーベースの文法 5:付箋の補足(System, ReadModel)
    [System]
    ● 一般化して書くのはよくない。明示的にする。
    ○ Social Media < Twitter, Facebook (代表的なものを書く)
    ● 対話型システムの場合、横に長くなって行きがち。
    ○ Systemの後ろにEventを並べることがおすすめ。対話結果を重視する。
    [ReadModel]
    ● 与えられた決定を行うために必要な情報。
    Event 1
    System
    Event 2
    Event 3
    

    View Slide

15. カラーベースの文法 6:付箋の補足(Policy)
    [Policy]
    ● イベントに対するリアクション。
    ○ 暗黙的に行われるもの
    ○ 明示的に行われるもの
    ○ 自動対応
    ● イベントとコマンドの間にはなくてはならないもの。
    ○ 明白すぎて気付きにくいこともあるが、２つの間には常にビジネス上の意思決定がある。
    ● 名前に時間をかけすぎないつけなくてもいい。
    ○ 何をするか、まずは実施することを声に出す。それでも名前が決まらないこともある。
    ● 嘘が多く混ざる場所。
    ○ ポリシー通りの実態があるとは限らない。
    ○ 議論の余地のあるトピックが多くある。
    ● 「いつも」「すぐ」と合わせて読む。
    ○ コーナーケースが見えてくる。
    

    View Slide

16. カラーベースの文法 7:付箋の補足(Value, Hotspots)
    [Value]
    ● それぞれのStep で作られる、または削除される。
    ○ わかりやすいのはお金
    ○ なんらかの機会、不一致状況。時間、ストレス、満足。
    ● 原書だと2020.8.2時点では記述なし。
    [HotSpots]
    ● 矛盾、おかしいところ、質問を書く。
    ● Rush to the Goal を使って一つずつ解決していく。(次のステップ)
    People
    :(
    People
    :)
    

    View Slide

17. Model Session 中盤の対処
    ● 目に見えないものは口にしない。
    ● Rush to the Goal.
    

    View Slide

18. 参考
    ● 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/
    

    View Slide