はじめに
「イベントストーミングってなにそれオイシイの？」って人向けに、「イベントストーミングっていいかも」って思ってもらうための惹きつけをするためにまとめた記事になります。
私自身がイベントストーミング導入のため、関係者にその意義を説明する際に、作成・利用した資料の内容そのものです。イベントストーミングという手法とその意義をビジネスサイドのメンバーにも理解してもらえることを目的として記載しています。
対象読者
- イベントストーミングを雰囲気だけでもサクッと知りたい方
- イベントストーミングに興味がある方
- イベントストーミングの導入を考えている方
- イベントストーミングの意義をほかメンバーに伝達したいと考えている方
記事を読むメリット
- イベントストーミングについて簡単にざっくり知ることができます。
- イベントストーミングの導入によって、どんな効果があるか実績を元に知ることができます。
- 他メンバーにイベントストーミングの意義を感じてもらうための助けとなります。
※ 実際に導入するまでに行った取り組み編としてと実践編を近日中に記載予定です。
イベントストーミングってなぁに？
簡単に説明すると
イベントストーミングとは、ビジネスの実現に重要な要素をもとに複数人で協調して以下のような図を作成する手法です
他の記事では以下のような言葉で説明されています
EventStorming is a flexible workshop format for collaborative exploration of complex business domains.
訳 : EventStormingは、複雑なビジネスドメインを共同で探求するための柔軟なワークショップ形式です。
イベントストーミング (Event Storming) とは、複雑なビジネスプロセスやドメインの知識を共有、可視化、そして理解するための協同作業ベースのモデリング手法です
イベントストーミングは、ビジネスモデル (≒ドメイン) を協調して探索する手法であり、特に強調することが特徴的で重要であると考えています。
そもそもドメインとは？
ビジネスを実現するための知識/ルール/要求
例)
・入居契約が登録されたら、入居者にデジタルなカギを送付する
・内見予約の期間中は仲介業者はTOTPで解除できる
・顔認証が、設置されているマンションに住んでいる場合家族の顔を5人分まで登録できる
※ 仕様と同等に感じられるかもしれませんが、システムの挙動ではなくビジネスの実現に必要不可欠な要素に着目している点で異なります
そもそもドメイン駆動設計とは？
ドメインを出来るだけそのまま実装に落としこみ、ドメインの変化(≒ビジネスの変化)に追随しやすい状態とすることを目的とした設計手法です。ですが、ドメインの変化に応じてプロダクトを継続的に変容させていくことは簡単なことではありません。これを解決するための手段がドメイン駆動設計で、システム的な観点で実装するのではなくドメインを中心におくことで、プロダクトの変更と、そのために必要なステークホルダーとのコミュニケーションを円滑にすることを実現します。まだドメイン駆動設計では、整理したドメインごとに、疎結合 / 高凝集で変更容易性を保ちやすくするための具体的な手法が提唱されています。
イベントストーミングのアプローチ
ここまでの説明を踏まえるとイベントストーミングは「ビジネスの継続的の変化に追従しやすいようにプロダクトを作り上げるために、必要なドメインを複数人で協調して議論 & 整理してドメイン知識を身に着けるための方法」と言えます。
言葉だけみると簡単に実現できそうに思えますが、実現するためにはいくつかの課題が考えられます。イベントストーミングがそれらの課題をどう解消しようとしているかをまとめています。
想定される課題
- ドメイン知識は開発メンバーだけでは習得が難しい場合もあり、ビジネスサイドのメンバーなど開発外のメンバーの力が必要となることが多いです。
- 開発的な知見がまったくない状態でドメインを整理したとしても、そのままプロダクトに反映することは難しいです。
- 開発のメンバー間はもちろん、ビジネスメンバーと開発メンバーの間で認識を合わせることは思いの外難しいです。同じ言葉を使っていたとしても、その言葉が意味することがずれている場合は多くあります。
課題解決のためのアプローチ
- 専門的な用語は使わずに視覚的にわかりやすい形式でアウトプットする手法であるため、ビジネスサイドのメンバーなども参加しやすくなっています。
- ドメイン駆動開発で提唱されている実装方法で重要となる要素が反映されたフォーマットが提供されています。そのため開発的な知見なく整理したドメインの知識であっても、そのままプロダクトに反映しやすい手法となっています。
- 複数人で協調して議論 & 整理するため共通の言語や認識を得やすい手法となっています。
上記のアプローチを取ることでイベントストーミングでは、ビジネスで重要なドメイン知識をプロダクトに反映しやすい形式で議論 & 整理することを可能とするために最適化された手法であると言えると考えます。
なんでイベントストーミングするの？
前述の通り、「イベントストーミングはプロダクト開発において重要なドメインの知識をプロダクトに反映しやすい形式で議論 & 整理するため」というのが一般的な目的になると思います。
そもそもドメイン知識というものを議論する必要があるの？複数人で実施する必要ある、効率悪くない？…といった疑問や懸念がある場合もあると思います。イベントストーミングを導入するか否かはチーム状況や解決したい課題によって変わると考えています。
ここでは実際に私のチームが抱えていた課題をもとに、なぜイベントストーミングを導入したかとその結果を簡単に紹介します。
解決したかった課題とイベントストーミングへの期待
私自身以下のような課題を感じていました。
- 考慮漏れ・想定不備が後段のプロセスで発覚する...
- 設計や実装が属人的でありスケールしづらい...
- チーム内・チーム間コミュニケーションのコストが高い...
- チーム内・チーム間コミュニケーションでロスが発生する...
- 孤独やプレッシャーを感じやすい...
- アセットが少なく、挙動に不安があったり不具合と思しき事象が発生し詳細な仕様を確認をしたい場合に、都度開発とコミュニケーションを取ったり、開発は実際に動かしたりソースを確認せざるを得なかったりコストが高くなってしまうことがある...
イベントストーミングには以下を期待していました。そして実際に導入した結果、改善することができました。
- 設計一部が型化され、品質が安定し属人性が排除されること
- 共通認識が形成されることでコミュニケーションが円滑となること
- 複数人で実施することで孤独感やプレッシャーが緩和されること
- プロダクトの挙動がアセット化され、不必要な確認コストの発生が抑制されること
※ 感じていた課題や開発プロセスについては以下で詳しく記載しているのでぜひ一読ください。
具体的な事例
具体的な事例(課題)として例えば以下が考えられます。
- 顔認証で利用するため顔を複数登録したい。でも3つまでしか登録できないが、どうすればいいかわからない。
- ワンタイムパスワードとTOTPって同じじゃないの！？
これらの課題に関して、具体的に以下観点で防止や改善をすることができます。
- 3つまでしか登録できないことや動線によって制御が異なるのが一律の仕様なのか、設定によるものなのか、想定外の挙動なのかイベントストーミングのアウトプットを参照することで理解できます。
- 仕様や設定によるものであった場合、事前にイベントストーミングをすることでビジネスサイドと該当の制御の仕方で問題ないことの共通認識を漏れなく取ることができます。
- 不具合で制御漏れだった場合、事前にイベントストーミングをすることで影響範囲を洗い出せて開発者はもちろん、QAメンバーも認識することで実装漏れがある状態でリリースされることを防げます。
- イベントストーミングを通して、利用される
言葉とその意味を精査して共通認識を深めていくので、「実は違うニュアンスで理解していました…」みたいなトラブルを事前に防げます。
留意事項
あくまで開発プロセスを改善する営みです。以下を実現することで改善を見込むことができます。
- 不明瞭なものが早いタイミングで明瞭となる
- 共通認識を持つことでコミュニケーションを円滑にすることができる
- アセットとして残すことで、挙動や制約を確認するための拠り所とすることができる
イベントストーミングの構造
全体の流れ
イベントストーミングでは以下のフォーマットに則って、 要素を矢印で繋いでフローを作っていきます
このフォーマットは下側のループと、上側のループの2つのパターンで構成されます。
下側のループ
下側のループでは、以下の順番で要素が矢印で繋げられています
- ドメインイベント
- ビュー
- アクター
- コマンド
- 集約 / 外部システム
- ドメインイベント
- …
「ドメインイベント」…といった良くわからない言葉を用いずに、より平易な言葉で表現すると以下のような感じになります
- 〇〇が△△された (何かが発生した)
- (その結果) □□画面で✕✗が表示される
- (その画面を) 〇〇が確認して
- △△を実行する
- (それは) ▢▢システムで処理されて
- 〇〇が△△された (何かが発生した)
- …
具体的なケースを当てはめて考えてみます。有給休暇を申請して実際に取得されるまでのフローを表現すると、以下のような流れになります。
- 有給休暇の申請がされた
- (その結果) 承認者の勤怠管理画面に通知表示がされる
- (その画面を) 勤怠管理者が申請を確認して
- 承認を実施する
- (それは) 勤怠管理システムで処理されて
- 有給休暇が取得された
- …
実際には、冗長な表現は省略して以下のように簡潔に表現します
「有給休暇の申請がされた」の前のプロセスを補完すると次のようになります
何か出来事(イベント)が発生した結果、画面などが更新されて、誰かがその画面を確認してなにかの処理を実行する。その結果別の出来事(イベント)が発生して…と続いていくフローとなります。
下側のループは誰かが画面を参照して次の行動が発生するフローを表現することができます。
上側のループ
有給休暇が申請されたとしても規定日数を超えて取得することはできません。
「規定日数を超えていない場合にのみ、勤怠管理者に承認を依頼したい」場合はどうすればよいでしょう？以下の2つの案が考えられます。
- フローはそのままで、コメントで補足
- 規定日数のチェックをしたうえで、超えてなければ承認に進むことをフローに組み込む
2を実現しようとする場合、先程の下側のループでは表現することはできません。なぜなら、誰かが画面を参照して次の行動が発生するフローであり、今回のように自動でチェックして次の処理を制御するフローを表現するためのものでないからです。 システムが自動でチェックして次の処理につなげるフローを表現することができるのが上側のループになります。
上側のループでは、以下の順番でループしています
- ドメインイベント
- ポリシー
- コマンド
- 集約 / 外部システム
- ドメインイベント
- …
言葉に表すと以下のような感じになります
- 〇〇が△△された
- (その際) ▢▢の条件を満たすなら
- △△を実行する
- (それは) ▢▢システムで処理されて
- 〇〇が△△された
- …
有給休暇が申請された際に、規定日数を超えていないかチェックして承認フローに進むか否かを判断する場合、以下のような流れになります。
- 有給休暇が申請された
- (その際) 規定日数の条件を満たすなら
- 有給休暇承認を依頼する
- (それは) ワークフローシステムで処理されて
- 有給休暇承認が依頼された
- …
有給休暇を申請してから、承認されるまでのプロセスを表現すると以下のようになります。
上側のループでは システムが自動でチェックして次の処理につなげる フローを表現することができます。
要素の詳細
イベントストーミングのフォーマット内で利用される要素についての説明です。一部独自に追加した要素があるため、一般的なものと独自のものとでわけて記載しています。独自要素部分は必ず必要なものではないため、実際にやってみて必要があれば試してみる運用とすることをおすすめします。
ここまでで傾いた四角で表現される要素の説明はしていませんでしたが、補足や懸念事項などのコメントを関連する要素に隣接する形で記載をします。
一般的な要素
独自要素
どうやって進めるの？
実際にどうやってイベントストーミングを実施していくかについてです。
ここではビットキーで取り扱っている業務を元に具体的な事例とともに説明していきます。
対象のビジネスは「賃貸管理物件を新たに契約した入居者にデジタルなカギを発行してアプリから物件のカギを解錠するまで」とします。
ビジネスイメージ
1. 準備
実際にイベントストーミングを開始する前に以下の準備が必要となります。
- 対象とするビジネス領域。対象としない範囲も決めておく
- 参加者の選定
- ツールの選定 (MiroやFigJamなど、draw.ioは非推奨)
- 場所の準備 (webでもよいですが、可能であれば物理的に同じ空間に集まれたほうがよい)
- 時間の確定とスケジュール調整 (参加者が複数チームにまたがるので時間の調整が結構大変…できるだけ事前にできるとよい)
2. ドメインイベントを抽出する
いざイベントストーミングやるぞ！となったら、まずドメインイベントを洗い出します。
参加者がそれぞれ、ビジネスに重要と思われるドメインイベントを書き出していきます。
重複や表記揺れは後で整理するので、このタイミングでは気にせずどんどん書き出していきます。
3. ドメインイベントを精査して並び替える
ドメインイベントが一通り洗い出されたら、参加者全員で1つずつみていき精査していきます。
重複しているものや今回のスコープ対象外のものを除外したり、表現がずれているもの修正したりします。このタイミングで使われる言葉が人によって異なっていたり、人によって意味している内容がずれている場合があるので、議論して認識を合わせます。
精査が終わったら、時系列順に並び替えて矢印でつないでいきます。どう繋げばいいかわからないものは、無理に繋げなくて良くて関係ありそうなドメインイベントの近くに配置しておきます。
作業の過程で新たなドメインイベントが必要であることが発覚した場合には追加します。
この作業は参加者全員で実施します。
4. イベントとシステム間のギャップを埋める
イベントストーミングのフォーマットに則って、ドメインイベント以外の要素を追加していきます。「集約」の要素に関しては機械的に決めるのが難しいため、中身は記載せずに空の要素を配置しておきます。作業の過程で新たなドメインイベントが必要であることが発覚した場合や粒度を整理したほうが良いことがわかった場合には都度修正します。
この作業は基本的には参加者全員で実施しますが、人数によっては事前に領域を決めて分担して実施することも可能です。
5. 全体を精査してコメント追加や修正する
成果物を順番に全部見ていって、懸念や考慮すべきことなどがないかなどを議論します。
解決すべきであるがその場で解決できない内容は赤色の付箋に記載します。考慮すべき内容や背景として把握しておくべき内容は赤以外の色の付箋で記載します。背景などを記載して残しておくことで後で見返した際に、どうして現状の整理となっているかの理解に役立つためおすすめです。
記載して残しておくか迷った場合には「作業の過程を動画で残す前提で記載はしない」とする運用をおすすめします。なんでも記載しすぎると散らかってしまいがちです。重要な情報に絞って記載をしておき、後で必要となるかも…といった情報は動画を見て確認する…といった運用を推奨します。特になぜこのように決まったか、といった意思決定の理由などを細かく残してしまうと本当に重要な情報が埋もれてしまうので、記載はせずに必要となったら動画で確認するのが良いと考えています。
この作業はかならず全員で実施します。参加者全員がこのフローを理解して懸念や疑問がない状態とすることが非常に重要です。またこの作業内でなされる議論に参加することでビジネスの理解がより深まりやすくなると感じているので、ここの作業は多少非効率に思えてもできるだけ参加者全員で実施することを強く推奨します。
6. 集約を抽出する
ここまででフローを整理され、ビジネスの要素とプロダクトが実現すべきふるまいは明瞭な状態になると思います。ここからはプロダクトに反映しやすくするため、またビジネス戦略をたてやすくするための整理をしていきます。
まずは、空の状態となっている集約を記載していきます。
集約に何を記載するべきかは非常に難しいですが、前後のコマンドやドメインイベントで名詞として利用されている文言を用いることが多いです。ドメイン駆動設計の文脈においては「一貫性を担保したい単位としてどのよつに集約を設計するか」といった観点もありますが、このタイミングで考慮するのは難しくビジネスサイドの人間には理解できないため、 参加者が理解しやすいデータのまとまり くらいのふわっとしたルールで実施することを推奨します。実装時には精査が必要ですが、ここでは参加者が理解しやすいことに重点をおいて整理するのが良いと考えています。
開発者だけで実施することも可能ではあると思いますが、 システム的な知見がない人間の理解しやすさ は扱いやすいプロダクトを作るためには重要と考えているため、できるだけ参加者全員で実施することを推奨します。
7. 境界づけられたコンテキストを整理する
集約を記載したら記載した集約をもとに、全体の要素を分類して自分たちが実現したいビジネスがどのような特徴で構成されるのか、特に注力すべき領域がどこか、を整理します。
具体的には以下を実施します。
- まず同じ言葉で表現される集約をまとめます
- 類似の集約が近くに配置されるようにします
- ビジネス的な関心事が大きく異なる間に線を引きます
- いくつかのまとまりができるので、まとまりごとに名前をつけます
- まとまりごとに、コアドメイン、支援ドメイン、汎用ドメインを割り振ります
これを実施することで、ビジネス的に重要な部分とそうでない部分が可視化され、より力をかけるべき領域を明瞭とすることができます。また各領域の対象となる集約も明瞭となるので、ここでの整理をもとにプロダクトのソースコード反映することで低結合で高凝集の実装を実現しやすくなります。
詳細な手順は成瀬さんが動画でまとめてくれており、非常にわかりやすいので一度視聴することを推奨します。
で、オイシイの？
実際に、開発期間が2ヶ月半程度のプロジェクトで初めて本格的にイベントストーミングを活用した際の経験をもとに記載します。
※ 詳しくは以下に記載しているので、ぜひ一読ください。
個人的な所感
やって良かった！！！！
体感としてはざっくり以下
- 考慮漏れや認識齟齬による戻りが格段に減った！
- チーム内、他チーム間のコミュニケーションがめちゃくちゃ円滑になった！
- みんなでワイワイ実施して、以前より楽しそうに開発できるようになった！
- 後からプロダクトの挙動や制御を確認したいときに、イベントストーミングのアウトプットを参照して解決できるシーンが増えた！不要なコミュニケーションが減った！
- イベントストーミングで整理した集約やコンテキストをプロダクトソースコードに反映することに関してはできていない部分もあるが、他の部分で十分なメリットがあった！
特にチーム横断でのコミュニケーションが非常に円滑になったと感じます！
アンケート結果
参加したメンバーにアンケートを回答してもらっています。改善すべき内容もありますが全体としてはポジティブな意見が大多数でした！
※ 5がポジティブな回答で、1がネガティヴな回答結果になります。
「イベントストーミング」に関して良かったこと・今後も継続していきたいことがあれば教えてください
- 職種横断でのコミュニケーションが増えて開発がしやすくなった、あと楽しく開発が出来た
- コメントになぜその結論に至ったのかを残しておくのが後から追いやすくてよかった
- 開発やビジネスサイド、QA、PdMが同時に参加することで疑問点だったりを早い段階で聞くことができてよかった
- 実際のユースケースなどをイメージしやすくなった。運用業務とシステム要件、期待する挙動といった全体像を把握できたのが良かった
- イベントストーミングのおかげで何をどう作るかが明確になった。
- 最初にコミュニケーションラインができたのが良かったと思っています。
- 開発やビジネスサイド、QA、PdMが同じ言葉で話せるようになったことで、認識のズレがなくなり、スムーズに進められました
- ふるまいの確認手順を図でわかりやすくまとめたことで、誰が何をしてイベントが発生するか。がわかるようになり、安心して作業を進められました
- 検証に入る前に、開発中のふるまいを確認できたことで、認識のズレや疑問点を早期に解消でき、スムーズに検証を進めることができた
- 全員の認識がかなり詳細に合わせられたこと。その後の開発やコミュニケーションが非常にすむーずになった。ややこしい要素がいくつかあったがほぼすべて事前に潰すことができ顕在化しなかったたと感じています。
「イベントストーミング」に関して良くなかったこと・改善したいことがあれば教えて下さい
- 時間的コストが大きい、仕様の更新があったときに対応し辛い
- 長いので1日中ではなく2、3時間にしてほしい、拘束時間が長すぎた
- リモートでもできなくはないが、細かいズレや進行のスムーズさに欠ける
- 〇〇さん以外のファシリテーターを作りたい
- 時間（コスト）がかかる。ルールが難しくイニシャルコストもやや高い。まだ数をこなしていないのでかなり工数がかかってしまったように思える。
- 開発中に変更となった仕様やふるまいがイベントストーミングの成果物に期間中落とし込めれば理想と思うが、どう進めればよいのだろうか？悩みます。
評価戻りも減った！
「評価戻り」は過去の同規模の開発と比較して、全体で **27%**削減されました！特にインパクトが大きいものに関しては **55%**も削減することができました！もちろん前半の認識合わせに時間を割いているので戻りが減って当然の部分もあるのですが、個人的にはかけたコストに見合う改善が得られたと感じています！
スプリントゴールが達成できるようになった！
イベントストーミングを始める前は恥ずかしながらスプリントゴールを達成できていませんでした…。ひどいときは未達成が7回連続で続いたときもあります。イベントストーミングを取り入れて運用が安定しだしてからは、5回以上連続で達成し続けています！
事前にイベントストーミングをすることで、評価戻りが低減したことや後段の戻りが減ったこともありますが、「メンバー全員の解像度が上がり、より適切に見積もることができるようになった」こが大きいと考えています。
楽しく開発できるようになった！
イベントストーミングを導入した後に、振り返ってみて開発体験が改善したかを回答してもらっています。全般的に良好な回答をもらっていますし、体感的にもより開発しやすくなったかなと感じています！
これが個人的には一番良かったです！！！！
いくつか要因があると思いますが…、今までの開発プロセスでは1人で作業をすることが多くまたドメインの知識が乏しい状態で開発に取り組む状況が多かったたです。今回イベントストーミングを取り入れることで周囲のメンバーと議論しながらドメイン知識を見につけた上で開発に取り組むことができるようになったことが大きな要因であると考えています。
※ 導入前後での開発プロセスの比較については以下に記載しているので、興味あれば一読ください。
注意事項
ここまで、「イベントストーミングはいいぞ！」ってことばかり言ってきました。実際にメリットはあると思いますが、銀の弾丸ではありません。実際に取り組んでみて注意すべきと感じたことをまとめます。
1. 導入する目的・ねらいを明確にし参加者に伝達する
なぜイベントストーミングを導入するのか、目的やねらいを言語化して共有することは必須です。これをしないと参加者も意義を理解しづらく協力を得づらくなると思います。意義を理解していないと仮に参加してもらえたとしても有意義な場にはなりづらくなってしまいます。
2. 時間がかかることを理解する
基本的に時間がかかります。イベントストーミングの作業自体も時間がかかりますし、参加者が習熟するのにも時間がかかります。実際に上手くできたとしてもすぐに成果としてわかるわけではなく、プロダクトをリリースして振り返ってみて初めて適切に効果を把握できると思います。
3. 序盤は小さく少しづつ試行する
そうはいっても時間的な余裕がない現場が大多数であると思います。個人的には時間をかける価値があると考えていますが、いきなり工数を大きく確保することは難しいと考えます。少しづつ試行しながら、コストに見合う価値があるか否か判断しつつ、自身の組織の状況に合わせて運用しやすい形に少しづつ改善しながら進めていくことを強く推奨します。
4. 必ず振り返りをする
最初から上手くいくことはほとんどありえないと考えています。教科書通りに導入するだけではメリットよりもコストの方が大きくなることが多いのではないかと感じます。前述の通り少しずつ自身の組織に合わせて改善することが、イベントストーミングのメリットを引き出すためには必須と思っているので振り返りはできるだけ実施することを推奨します。
5. 初回はファシリテーターがしっかり準備する
イベントストーミングにおいて、ファシリテーターの立ち回りが非常に重要となってきます。特に初回はできるだけ事前に準備して臨むことを強く推奨します。私自身の場合、1人だけでイベントストーミングを実践してみたり、対象とする範囲において事前に理解を深め重要となりそうなポイントや議論を進めるために必要となる最低限の情報を整理し事前に共有するようにしました。
※ 実際にイベントストーミングを導入するために実践したことは別途記事とする予定です。
6. 本格的に実施する際は、まとまった時間(2〜3時間以上)を確保する
試行と振り返りを終え、本格的に実践するぞ！となった場合、規模などにもよるとは思いますがまとまった時間を確保することを推奨します。私自身、なかなか全員が参加可能な時間を確保することが難しく、1時間〜1時間半で複数回にわけて実施したことがありました。しかし、議論が途中で終わってしまったり以前した内容を思い出す時間が必要となったりして、思った以上にスムーズに進められませんできた。この経験の反省として、丸1日イベントストーミングする時間として確保してしまったり、1泊2日でイベントストーミングを集中するための合宿をおこなったりしています。
丸1日は難しくとも、すくなくとも2時間から3時間程度はまとまった時間を確保したろうがスムーズにすすめられると感じています。
7. 楽しく実施する (否定やネガティブな発言は極力控える)
結論これが一番大切です！
参加者全員が能動的に議論することが非常に大切であり、普段はそれほど関わらないビジネスサイドのメンバーがいる場合もあるので、楽しく実施するというのが特に重要であると考えています。当たり前なことではありますが、否定的な発言やネガティブは発言で議論に不必要なものは極力控えるように事前に周知しておくなどの対応をしておくと良いと思います。
まとめ
イベントストーミング はいいよ！
目的の明文化や準備は必要なりますが、開発プロセス全般を改善する可能性があるよ！
なにより楽しく開発ができるようとなるよ！(個人的にはこれが一番！)
参考
Discussion