新規開発でイベントストーミングを実践したら体験が良かった話

■イベント
Sansan vs サイボウズ 開発生産性Tips夏祭り
https://sansan.connpass.com/event/324156/

■発表者
技術本部 Bill One Engineering Unit　杉崎 ⻯也

■ Bill One 開発エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

■Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Transcript

1. Sansan技術本部 新規開発でイベントストーミングを 実践したら体験が良かった話 Bill One Engineering Unit 杉崎 ⻯也
2. 杉崎 ⻯也 Sansan株式会社 技術本部 Bill One Engineering Unit Core Business UMグループ VoIP系の会社からSansan株式会社へ⼊社し、Bill Oneの グループにジョイン。 元PHPerですが、最近はフロントエンド中⼼に書いてます。 その他としては業務プロセスの改善活動やサービスの 課題解決のための横断的な活動なんかもしています。
3. 背景
4. マイクロサービス横断の申請承認(workflow)サービスを作りたかった - 要件を素早く設計に落とし込みたい - ローンチまで2ヵ⽉を切っていた - エンジニア以外との伝⾔ゲームを避けて仕様の⼿戻りを減らしたかった - 業務理解と設計を並⾏したかった - プロジェクト全体で、業務フローと概念・設計の理解を統⼀したい - 業務フローをプロジェクトチーム全員にインプットして進めたかった - ちょうどイベントストーミングを実施する機会があった
5. よし、とりあえず イベントストーミングをしてみよう
6. - DDDの戦略的設計を実現する⼿段で、有識者と共に業務フローを明らかにする - その後、特定したコンテキストと集約を詳細化・修正して具体化する イベントストーミングってなんだっけ 境界づけら れたコンテ キスト ユビキタ ス⾔語 サブドメ イン アプリケー ション サービス エンティティ 値オブジェ クト 集約 戦略的設計 戦術的設計 コンテキス トマップ Big Picture Business Process Modeling Software Design
7. 事前準備: 参加者の選定 初回の場合はイベントストーミング経験者に参加してもらい、 ファシリテーションをしてもらうと良い 今回は以下の構成で実施 PdM デザイナー 経験者 1⼈ 1⼈ 4⼈ エンジニア 1⼈
8. - スムーズに進められるようにする - システムのゴールの決定と、最⼩限の要件(MVP)などイベントストーミ ングを実施するスコープを決めておく。 - それなりの時間、何⼈かを拘束することになるので、事前に参加者にや り⽅を説明するなどで当⽇効率よく進められるようにしておく。 事前準備: 参加者の選定 7
9. ⽤意するもの
10. 紙・ペン・付箋・ホワイトボード
11. 部屋・体⼒・快適なネット環境
12. ドメインエキスパート
13. 実践
14. フェーズ - フェーズとして3つに分けられる。 - ドメインエキスパートは⻑くてもBPMまでの参加で充分。 Big Picture Business Process Modeling(BPM) Software Design イベントの洗い出し 時系列の整理 イベント駆動での業務フローの整理 境界づけられたコンテキストの特定 コンテキスト・集約の詳細化
15. 登場する付箋 発⽣した出来事 過去(分詞)形で書き出す コマンドを実⾏する主体 コマンドを実⾏するため の状態 ドメイン整合性の単位 システムに対するアクシ ョンの指⽰ イベントの後に 実⾏されるコマ ンドの規則 注意事項・留意点 外部のシステム
16. 実際の流れ 1. イベントを過去(分詞)形で書き出す 2. イベントをタイムラインに並び替える（似ているイベントをマージ） 3. ホットスポットの洗い出し 4. 1~3を繰り返す 5. 並び替えたら業務フローが正しいか左から順に確認 6. フェーズ(pivotal event)で区切る 7. コマンド、アクター、ポリシー、外部システム、リードモデルを洗い出す 8. 集約を洗い出す 9. (後⽇)コンテキスト境界を決める
17. 進め⽅(Big Picture: イベントの貼り出し) 16 過去(分詞)形で付箋を張り出す。書き⽅についてわからない⼈も多いので補助する。 間違ってたり関係ないことでも議論のタネになるので全部書く。
18. 進め⽅(Big Picture: 時系列に並び替える) 17 書き出した付箋を並び替え、ハッピーパスを考える。留意点や注意点をホット スポットとして書き出しておく。ここまでを2~3回繰り返して内容を洗練させる。
19. 進め⽅(BPM:コマンドとポリシー) 18 具体的なアクターが存在しないケース(〜をしたら通知する、⾃動的に実⾏する) について、ポリシーを定義して続くコマンドと結びつける。
20. 進め⽅(BPM:リードモデルとアクター) 19 ポリシーと異なり具体のアクターが存在する場合、イベントからリードモデル を定義し、そこにコマンドを実⾏するアクターを結びつける。
21. 進め⽅(BPM: 集約を⾒つける) 20 コマンドとイベントを関連付ける対象が必要なので、その間に集約を差し込 む。ここでの集約はざっくりした暫定的なものと考える。ここまできてユビキ タス⾔語の定義付けをしたら、会議は解散して集約を個別に深堀りしていく。
22. フローの完成と深堀り(Software Design) 21 その後開発チームでコンテキストと集約を洗練させ、イベントストーミングを 完了する。ここで現実的な実装の困難さを⾒つけることがあるので、ドメイン エキスパートなどと相談してフローを修正していく。
23. やってみて
24. やってみて: ⽣産性向上に寄与した点 - 参加したメンバー内での理解の共有 - ユビキタス⾔語ができたことで、以後の議論や実装がスムーズになった - 対話の中でドメインエキスパートの思想が⾒えて、より理解が深まった - ドメインエキスパートの意図が共有されることで、仕様としての⼿戻りの懸念 が減ることが期待できた - イベントストーミングの成果物が残されることの利点 - 開発ストーリーをイベントごとに切りやすく、⾒通しが⽴てやすかった - 業務フロー図として、そのままドキュメントとして活⽤できた - 他チームへの説明する際にもドキュメントとして有効だった
25. やってみて: ⼿戻りについて - 重要・転換点になるイベントであるpivotal eventの修正が発⽣した。 理想的な箇所(と思っていた)にpivotal eventを引いたが、実際には設計の都合上 難しいことに実装の際に気づいた。 - 妥協する必要のある箇所は、その後の集約をブラッシュアップするタイミングで ⾒直すことでこの⼿の⼿戻りは減らせるかもしれない。
26. やってみて: ホワイトボード - 対⾯で議論しながら、オンラインツールで付箋を書き出してもいい オフラインで実施する場合でも、ホワイトボートに物理的に付箋を貼付するよ り、オンラインのツールを使ったほうが良さそうだった。 今回の場合、ホワイトボードに貼った後に整理は ※ブランドリーニ⽒的には完全オフラインを推奨している。オンラインの場合の⼿引も提供している。 Remote EventStorming EventStorming in COVID-19 times
27. 要件と設計の間を埋めるピースとして活⽤したい - 今回のイベントストーミングの結果、⽣産性という視点での取り組みの⼀つとして、要件定 義〜設計のフェーズにおける仕様の⼿戻りを減らし、素早く設計を進める標準的な⼿法とし て今後は推進していく。
28. さいごに 27 ⽴場に囚われず リラックスして 集中議論しよう 回数を重ねて、 最適なやり⽅を⾒つけよう 場合によってはやらない 判断もしよう
29. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/