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

by SansanTech

Slide 1

Slide 1 text

Sansan技術本部新規開発でイベントストーミングを実践したら体験が良かった話 Bill One Engineering Unit 杉崎⻯也

Slide 2

Slide 2 text

杉崎⻯也 Sansan株式会社技術本部 Bill One Engineering Unit Core Business UMグループ VoIP系の会社からSansan株式会社へ⼊社し、Bill Oneのグループにジョイン。元PHPerですが、最近はフロントエンド中⼼に書いてます。その他としては業務プロセスの改善活動やサービスの課題解決のための横断的な活動なんかもしています。

Slide 3

Slide 3 text

背景

Slide 4

Slide 4 text

マイクロサービス横断の申請承認(workflow)サービスを作りたかった - 要件を素早く設計に落とし込みたい - ローンチまで2ヵ⽉を切っていた - エンジニア以外との伝⾔ゲームを避けて仕様の⼿戻りを減らしたかった - 業務理解と設計を並⾏したかった - プロジェクト全体で、業務フローと概念・設計の理解を統⼀したい - 業務フローをプロジェクトチーム全員にインプットして進めたかった - ちょうどイベントストーミングを実施する機会があった

Slide 5

Slide 5 text

よし、とりあえずイベントストーミングをしてみよう

Slide 6

Slide 6 text

- DDDの戦略的設計を実現する⼿段で、有識者と共に業務フローを明らかにする - その後、特定したコンテキストと集約を詳細化・修正して具体化するイベントストーミングってなんだっけ境界づけられたコンテキストユビキタス⾔語サブドメインアプリケーションサービスエンティティ値オブジェクト集約戦略的設計戦術的設計コンテキストマップ Big Picture Business Process Modeling Software Design

Slide 7

Slide 7 text

事前準備: 参加者の選定初回の場合はイベントストーミング経験者に参加してもらい、ファシリテーションをしてもらうと良い今回は以下の構成で実施 PdM デザイナー経験者 1⼈ 1⼈ 4⼈エンジニア 1⼈

Slide 8

Slide 8 text

- スムーズに進められるようにする - システムのゴールの決定と、最⼩限の要件(MVP)などイベントストーミングを実施するスコープを決めておく。 - それなりの時間、何⼈かを拘束することになるので、事前に参加者にやり⽅を説明するなどで当⽇効率よく進められるようにしておく。事前準備: 参加者の選定 7

Slide 9

Slide 9 text

⽤意するもの

Slide 10

Slide 10 text

紙・ペン・付箋・ホワイトボード

Slide 11

Slide 11 text

部屋・体⼒・快適なネット環境

Slide 12

Slide 12 text

ドメインエキスパート

Slide 13

Slide 13 text

実践

Slide 14

Slide 14 text

フェーズ - フェーズとして3つに分けられる。 - ドメインエキスパートは⻑くてもBPMまでの参加で充分。 Big Picture Business Process Modeling(BPM) Software Design イベントの洗い出し時系列の整理イベント駆動での業務フローの整理境界づけられたコンテキストの特定コンテキスト・集約の詳細化

Slide 15

Slide 15 text

登場する付箋発⽣した出来事過去(分詞)形で書き出すコマンドを実⾏する主体コマンドを実⾏するための状態ドメイン整合性の単位システムに対するアクションの指⽰イベントの後に実⾏されるコマンドの規則注意事項・留意点外部のシステム

Slide 16

Slide 16 text

実際の流れ 1. イベントを過去(分詞)形で書き出す 2. イベントをタイムラインに並び替える（似ているイベントをマージ） 3. ホットスポットの洗い出し 4. 1~3を繰り返す 5. 並び替えたら業務フローが正しいか左から順に確認 6. フェーズ(pivotal event)で区切る 7. コマンド、アクター、ポリシー、外部システム、リードモデルを洗い出す 8. 集約を洗い出す 9. (後⽇)コンテキスト境界を決める

Slide 17

Slide 17 text

進め⽅(Big Picture: イベントの貼り出し) 16 過去(分詞)形で付箋を張り出す。書き⽅についてわからない⼈も多いので補助する。間違ってたり関係ないことでも議論のタネになるので全部書く。

Slide 18

Slide 18 text

進め⽅(Big Picture: 時系列に並び替える) 17 書き出した付箋を並び替え、ハッピーパスを考える。留意点や注意点をホットスポットとして書き出しておく。ここまでを2~3回繰り返して内容を洗練させる。

Slide 19

Slide 19 text

進め⽅(BPM:コマンドとポリシー) 18 具体的なアクターが存在しないケース(〜をしたら通知する、⾃動的に実⾏する) について、ポリシーを定義して続くコマンドと結びつける。

Slide 20

Slide 20 text

進め⽅(BPM:リードモデルとアクター) 19 ポリシーと異なり具体のアクターが存在する場合、イベントからリードモデルを定義し、そこにコマンドを実⾏するアクターを結びつける。

Slide 21

Slide 21 text

進め⽅(BPM: 集約を⾒つける) 20 コマンドとイベントを関連付ける対象が必要なので、その間に集約を差し込む。ここでの集約はざっくりした暫定的なものと考える。ここまできてユビキタス⾔語の定義付けをしたら、会議は解散して集約を個別に深堀りしていく。

Slide 22

Slide 22 text

フローの完成と深堀り(Software Design) 21 その後開発チームでコンテキストと集約を洗練させ、イベントストーミングを完了する。ここで現実的な実装の困難さを⾒つけることがあるので、ドメインエキスパートなどと相談してフローを修正していく。

Slide 23

Slide 23 text

やってみて

Slide 24

Slide 24 text

やってみて: ⽣産性向上に寄与した点 - 参加したメンバー内での理解の共有 - ユビキタス⾔語ができたことで、以後の議論や実装がスムーズになった - 対話の中でドメインエキスパートの思想が⾒えて、より理解が深まった - ドメインエキスパートの意図が共有されることで、仕様としての⼿戻りの懸念が減ることが期待できた - イベントストーミングの成果物が残されることの利点 - 開発ストーリーをイベントごとに切りやすく、⾒通しが⽴てやすかった - 業務フロー図として、そのままドキュメントとして活⽤できた - 他チームへの説明する際にもドキュメントとして有効だった

Slide 25

Slide 25 text

やってみて: ⼿戻りについて - 重要・転換点になるイベントであるpivotal eventの修正が発⽣した。理想的な箇所(と思っていた)にpivotal eventを引いたが、実際には設計の都合上難しいことに実装の際に気づいた。 - 妥協する必要のある箇所は、その後の集約をブラッシュアップするタイミングで⾒直すことでこの⼿の⼿戻りは減らせるかもしれない。

Slide 26

Slide 26 text

やってみて: ホワイトボード - 対⾯で議論しながら、オンラインツールで付箋を書き出してもいいオフラインで実施する場合でも、ホワイトボートに物理的に付箋を貼付するより、オンラインのツールを使ったほうが良さそうだった。今回の場合、ホワイトボードに貼った後に整理は ※ブランドリーニ⽒的には完全オフラインを推奨している。オンラインの場合の⼿引も提供している。 Remote EventStorming EventStorming in COVID-19 times

Slide 27

Slide 27 text

要件と設計の間を埋めるピースとして活⽤したい - 今回のイベントストーミングの結果、⽣産性という視点での取り組みの⼀つとして、要件定義〜設計のフェーズにおける仕様の⼿戻りを減らし、素早く設計を進める標準的な⼿法として今後は推進していく。

Slide 28

Slide 28 text

さいごに 27 ⽴場に囚われずリラックスして集中議論しよう回数を重ねて、最適なやり⽅を⾒つけよう場合によってはやらない判断もしよう

Slide 29

Slide 29 text

Sansan 技術本部募集ポジション紹介 https://media.sansan-engineering.com/

Slide 30

Slide 30 text

No content