この記事はスターフェスティバル Advent Calendar 2024の 17日目の記事です。
はじめに
スターフェスティバル株式会社エンジニアのまつやです。
皆さんは自社サービスをどれだけ理解してますか？
今回は、社内で利用されている業務管理システム改修を進める上で
課題や問題点を見つけるためにイベントストーミングをした話をしていきたいと思います。
※この記事に「僕のヒーローアカデミア」感のある話は全くないので悪しからず...
イベントストーミング is 何
手始めに、「イベントストーミングとは何か」について説明されている記事を見つけ、理解を進めることにしました。
下記引用がその内容です。
イベントストーミング (Event Storming) とは、複雑なビジネスプロセスやドメインの知識を共有、可視化、そして理解するための協同作業ベースのモデリング手法です。
伝統的なモデリングや要件定義の手法は、多くの場合、ビジネスステークホルダーとソフトウェア開発者の間にコミュニケーションのギャップが生じる可能性がありました。イベントストーミングは、このギャップを埋めるために生み出されました。この手法は、関係者が同じ空間に集まり、ホワイトボードや Miro などのオンラインコラボレーションツールを用いて直感的でインタラクティブな方法でドメインの知識を共有し、問題点やビジネスルールを特定することを目的としています。
引用元：https://zenn.dev/yamachan0625/books/ddd-hands-on/viewer/chapter5_event_storming
いざ、実践！！！！！！！！！！
通常は同じ場所に集まってホワイトボードなどに付箋を貼り付けながら進めるのですがリモートでのイベントストーミングだったため、Confluenceのホワイトボード機能を利用して進めました。
また、人を集める際に全員のスケジュールを合わせるのが難しかったため、分野ごとに担当者を選び、それぞれの業務内容をヒアリングしながらドメインイベントを書き出して、イベントストーミングマップの作成を進めました。
進めていく上でぶち当たった問題
ドメインイベントの粒度やポリシーの使い方が定まらない
イベントストーミングではいくつかのルールが存在しますが
今回記載させていただく2つについて抜粋しておきます。
ドメインイベント (Domain event)
ドメインイベントとは「過去に発生した出来事」を表します。イベントは過去に起きるものなので過去形の動詞で表現されます (例:「注文が承認された」「商品が出荷された」など) 。ドメインイベントはビジネス上の重要な出来事や変更を示すもので、ドメインの中心的な要素として捉えられます。ポリシー (Policy)
ドメインイベントが発生したときに何をすべきかを定義するビジネスルールやロジックを表します。ポリシーはあるドメインイベントに応じて実行すべきコマンドを決定するためのガイドラインとなります。
引用元：https://zenn.dev/yamachan0625/books/ddd-hands-on/viewer/chapter5_event_storming
話を進めていく中でドメインイベントの粒度を統一させるのに時間がかかってしまいました。
例えば、弊社サービスのごちクルでお弁当お手渡し時のドメインイベントを考えてみると次の図のようになります
上記でも発生するドメインイベントとしてやることはわかります。
ですが、他のドメインイベントを考えていく途中で「そういえばお支払い方法で変わることあるっけ？」となり、ごちクルで利用可能なお支払い方法でポリシーを記載してドメインイベントを分けるようにして以下のようにしました。
ドメインイベントがビジネス上の重要な出来事や変更を示すものという前提を忘れずに意識することで
分割してポリシーとドメインイベントを記載することができ、どの場合にどの書類がお客様の手に届くかが把握することができました。
専門用語や特殊な略称が頻発する
イベントストーミングを進めていく上で必ず各部門での専門用語や特殊な略語などが出てきます。
例えば技術者が
「この機能はAPIをコールしてデータを取得してJSON形式で返ってくるから、それをフロントエンドに渡してるんですよねーーー」
とこんなこと言われても非技術者は
「APIって何？コールって電話するの？」みたいな話しになりかねません。
また、逆に非技術者も同様で
「ここでレピュ通してフォームに登録した後に、管理フォームから依頼あげてもらって、運用チームに進めてもらってます！」
とこんなことを言われても非技術者は
「フォームって何のこと言ってんの？運用チームってどこの部署のこと言ってるの?」みたいな話にもなりかねません。
知らない用語が出てきた場合は、話し合いの途中で中断してでもその言葉で何を具体的に指しているのかを質問して明確し、聞かれた側も「なんでこんなことも知らんねん」ではなく、前向きに受け止め、お互いの理解を深める姿勢を持つことが大切だと思いました。
イベントストーミングを機に社内用コンテキストマップを作成するなども良いかもしれません。
最終的なイベントストーミングマップ
- 細かいドメインイベントの結合や分割
- ポリシーでの条件分割
といった作業を細かく繰り返していき、以下のようなイベントストーミングマップが完成しました。
※デカすぎて丁度良いモザイク感になった。
まとめ
今回のイベントストーミングを通じて、課題や問題点は見つかったものの、まだ氷山の一角だなと感じました。それに、自社サービスなのに知らないことが結構多いと気づきました。機能を作るときは、現場で運用している人たちの話をしっかり聞き、お互いの課題を理解しながら進めることが本当に大事だと思います。他のサービスでもイベントストーミングをやれば、同じように新しい発見があると思うので、ぜひ試してみてください。
さらに向こうへ、プルスウルトラ！!!!!
Discussion