本当にはじめられたイベントストーミング ―実践してみて見えたこと― / Practical EventStorming

FOLIO Scramble!

2020.06.18 URL変更のため上げ直しました。

Transcript

1. 本当にはじめられた イベントストーミング ―実践してみて見えたこと― 2019.08.14 Scramble! #3 FOLIO流 複雑なドメインとの戦い方
2. これはアンサーソング 同イベントで@yoskhdiaが発表した 明日からはじめられるEventStorming https://speakerdeck.com/yoskhdia/ lets-try-eventstorming に捧げます
3. わたし •よこな •Twitter: @ihcomega (あとでここに資料流します) •チキン南蛮が好きです
4. 10秒でおさらい command aggregate event read model policy actor external system issue 発生するイベント 連携する外部システム イベントを発生させるコマンド コマンドを実行するアクター アクターの判断材料 コマンドのトリガー 集約 イシュー この順に 付箋を貼り出す
5. 実践編でお伝えすること •いつ、どんなときにやればいいの？ •やってみてどうなの？
6. 　一、 イベントストーミングの 分類
7. イベストのタイプ 多様 一様 参加者の職種 (バックグラウンド) 低い 高い 視点の 高さ
8. FOLIOでやったもの 多様 一様 参加者の職種 (バックグラウンド) 実績なし ① ② ③ 低い 高い 視点の 高さ
9. ① 複数職種で: 機能のストーリー確認 ② エンジニアで: 役割分担の検討 ③ エンジニアで: 設計の準備として FOLIOでやったもの 多 一 低 高 実績なし ① ② ③
10. ① 複数職種で: 機能のストーリー確認 ② エンジニアで: 役割分担の検討 ③ エンジニアで: 設計の準備として ①と③を扱います FOLIOでやったもの 多 一 低 高 実績なし ① ② ③
11. 　二、 機能のストーリー確認
12. 様々な職種でものづくり 証券 バックオフィス カスタマー サービス コンプライアンス 経営企画 QA エンジニア デザイナー セキュリティ 投資戦略
13. 足並み揃えたいが… •大人数で会議をしてみる •アウトプットしづらい •当事者意識が薄れる •マネージャーが調整を頑張る •時間も手間もかかる •漏れる
14. イベストチャンス！ 何らかの機能やプロジェクトなど、 フローやストーリーがあるものを取り扱おうとして •関係者が多く調整が多発するとき •何から始めよう？と思ったとき •情報整理の術について迷っているとき •全体を可視化したいとき
15. command aggregate event read model UI policy actor external system issue スコープ
16. イベントとイシューに しぼって実施した command aggregate event read model UI policy actor external system issue スコープ
17. 結果
18. よいところ •パラレルに作業するため、参加者全員 が効率よくアウトプットできる •15人ほどでやったこともある •用語の統一や知識の移転ができる •早い段階で強力な共有コンテキス トを作れる •共有の手間や漏れリスクが減る
19. よいところ •苦労せず視覚的な成果物が生まれる このへんに ʘイシューが多いʗ あのオレンジ ʘって…？ʗ 右側は割と ʘ楽そうʗ
20. 工夫が必要なところ •急にやろうとすると参加者の時間調整 に少々苦労する •参加者の必須レベルを見極めて、 途中入退室可としたり、1回の中で パート分けをしたりする コンプライアンス部と 開発メンバーが 必須のパート 全員でやるパート
21. 工夫が必要なところ •成果物のポータビリティがとても低い 上に場所を取る •壁リソースが潤沢なら、移動しな い前提で場所選びをした方がよい •模造紙を活用して持ち運んだり、 パノラマ写真を撮ったり、歯を食 いしばってデジタル化したりする •成果物を継続的に使うか見極める
22. ファシリテーション •必ず準備しよう •ゴールやスコープは？ •誰に参加してもらうべきか？ •参加者の文房具リテラシーをあげるの はオススメ •付箋の剥がし方 •水性・油性マジックの違い
23. ファシリテーション •参加者の迷いを払拭しよう •「何このイベント？」と思ってい る人を導く(ただし、思考を狭めな いよう多くは指示しない) •誤りや重複を気にしないよう安心 させる •発言を付箋化するよう促す
24. ファシリテーション •意外と疲れるので、元気を保てる工夫 をしよう(参加者も疲れる) •飲み物やおやつを用意する •休憩を取る •動きやすい格好推奨(ヒールで足が棒になった…)
25. ファシリテーション •イベスト文化ができていくので、毎度 大きくやり方を変えない方がベター •たとえば、FOLIOでは「イシュー = ピンクの付箋」という認識が生 まれつつある •「あのへんにピンクが多い…」 •「このピンクをやっつけるぞ」
26. 　三、 設計の準備
27. メールアドレスの再設定 メアドが使えず ログインできぬ… 資産をお預かり中 ログインを諦めていただく わけにはいかない
28. メールアドレスの再設定 ご本人様確認を します
29. メールアドレスの再設定
30. メールアドレスの再設定 …という機能を開発する際に用いた
31. 開発あるあるな悩み •複雑な仕様と戦うための知識レベルが チーム内でバラバラである •設計をいきなり手分けするのは難しい •決まったことの記録や共有が不十分な ことがある
32. イベストチャンス！ •何から始めよう？と思ったとき •チーム内で知識移転したいとき •設計の前に情報整理しておきたいとき •タスクの分解に悩んだとき
33. command aggregate event read model UI policy actor external system issue スコープ
34. (イベストの登場人物ではないUIを除き) すべてを扱った command aggregate event read model UI policy actor external system issue スコープ UI
35. 結果
36. 可視化・情報共有・知識移転などのメリットは 前半の話と同様にもちろん存在する では、詳細な設計をするにあたり •イベストが役立ったことは？ •イベストだけではイマイチだった・足り なかったことは？ ※バックエンドにフォーカスした内容です ここまではいいとして…
37. QA イベストのその先へ ì í î ï ð ï ñ ò î ó ô õ ì î ö ÷ ø î ó ù ñ ð ú ñ ð 記 述 ü ñ ú î ð 図 画 面 ÿ ! ñ ÷ " ì î # î $ ER 図 見 積 ' ( ) 計 画 精 緻 化 開 発 ÷ " ì î $ ! , - . ï / 0 , õ î ï ì ü 1 ñ 2 解 決 ) 仕 分 3 4 ð ï 設 計 書 6 ñ ô
38. 見 積 ' ( ) 計 画 精 緻 化 QA イベストのその先へ ì í î ï ð ï ñ ò î ó ô õ ì î ö ÷ ø î ó ù ñ ð ú ñ ð 記 述 ü ñ ú î ð 図 画 面 ÿ ! ñ ÷ " ì î # î $ ER 図 開 発 ÷ " ì î $ ! , - . ï / 0 , õ î ï ì ü 1 ñ 2 解 決 ) 仕 分 3 4 ð ï 設 計 書 6 ñ ô ダイレクトに イベストが活きるのは このあたり
39. イシューの整理
40. イシューの整理 何をした？どうだった？ •挙がったイシューをすぐ解決するか、 解決に向けた計画を立てた •そのプロジェクトで「やること」と 「やらないこと」を明確に分けた •既にリストアップは済んだ状態なので スムーズ◎ VS データ化が大変△
41. command aggregate event read model UI policy actor external system read model UI external system aggregate issue command policy actor イシューの整理 イベストとの関係
42. ドメインモデリング
43. ドメインモデリング 何をした？どうだった？ •アウトプットは　 概念図 •イベストの結果は あまり活用でき ず、イチから検討 してしまった
44. •イベストで出た境 界の中身を埋める ようなアプローチ ができたかも •イベスト中にこと ばの定義を明らか にするプロセスが 足りなかったかも aggregate ドメインモデリング 次はこうしたい
45. command aggregate event read model UI policy actor external system issue read model UI external system command policy actor ドメインモデリング イベストとの関係 event
46. ユースケース記述
47. •イベストの結果を 元に丁寧に書いた •QAメンバーへの仕 様共有、テスト設 計書作成 •見積もりや計画 に役立った ユースケース記述 何をした？どうだった？
48. ユースケース記述 次はこうしたい •参加メンバーにとっては価値が薄い可 能性があるため、浸透の努力をしたい •非参加メンバーへの伝達手段 •メンテし続けるドキュメント •後世への記録 として価値はあるし、イベストを していると書き起こしやすい
49. command aggregate event read model UI policy actor external system issue read model UI external system aggregate ユースケース記述 イベストとの関係
50. ユースケース記述 イベストとの関係
51. command event policy actor event アクター 目的 事前条件 メインフ ロー 代替フロー 事後条件 command policy ユースケース記述 イベストとの関係
52. ユースケース記述 イベストとの関係 ※説明用に変更・簡略化しています
53. 設計の準備 まとめ
54. 設計とイベスト command aggregate event read model UI policy actor external system read model UI external system issue ユースケース記述 ドメイン モデリング イシュー 整理
55. 設計とイベスト command aggregate event policy actor external system external system issue ユースケース記述 ドメイン モデリング イシュー 整理 デザイン ？ read model UI
56. 設計とイベスト command aggregate event policy actor external system external system issue ユースケース記述 ドメイン モデリング イシュー 整理 デザイン ？ read model UI 設計を進めるのに 必要な思考の過程を 複数人で集中して 辿ることができる
57. よいところ •前半の計画や設計 を手厚く行う助け となり、後半でス ピードが出た 　(一番左がすごいことになってます 　 が、正直にお見せします) •いわゆる認識齟齬 による手戻りはな かった 計画 実績 時 間 (グラフはJIRAより取得)
58. •参加したメンバー 内での共有が強力 な反面、外への共 有は意識的にやる 必要がある 工夫が必要なところ border ？ … ？
59. 　四、 おわりに
60. イベストはおすすめか？ •工夫は要るがまずやってみて損はない •少しでも良いなと思ったら、何度か やってみると洗練されていく •アクティビティそのもののみならず、 「イベストで出たものをどう活用して いくか？」を考えることに価値がある し、ここにチームごとのカラーが出る
61. 参考文献 • 「新しいモデリング手法: EventStorming (イベントストーミング) をはじ めるための準備」from yoskhdia’s diary https://yoskhdia.hatenablog.com/entry/2018/11/09/200556 • Alberto Brandolini「Introducing EventStorming」 • ダグ・ローゼンバーグ、マット・ステファン「ユースケース駆動開発実践ガ イド」
62. T H A N K Y O U