はじめに

こんにちは、ギフティでエンジニアをしている @memetics10 です。

ギフティでは、新たなモデリング手法としてイベントストーミングを取り入れています。 今回は、社内でイベントストーミングを実践していく中で見えてきた勘所を共有します。 イベントストーミングの効果を最大化する手助けになれば幸いです。

イベントストーミングとは

念の為、イベントストーミングの概要を説明します。すでにご存知の方は読み飛ばしていただいて問題ありません。

イベントストーミングは、Alberto Brandolini 氏が考案した、様々なステークホルダーとのコラボレーションの中でビジネスドメインを探求するワークショップ型のモデリング手法です。 技術的な知識が不要な手法なので、ソフトウェア設計のみならず、既存事業の健全性を評価して改善点を発見したり、新しいビジネスモデルの実行可能性を探ったりと様々なシーンで利用できます。 これらのシーンにおいて共通している点は、異なる背景を持つステークホルダー間で横断的な会話を可能にし、サイロや専門分野の境界を越えたコラボレーションができるところです。

ワークショップの工程としては 3 つのフェーズがあり、それぞれで目的が異なります。

• フェーズ1: ビッグピクチャー

  • イベントを時系列で列挙することでビジネスの全体像を明らかにしつつ、論点を洗い出すことを目的とします

• フェーズ2: プロセスモデリング

  • 各イベントがどのようなプロセスで発生するのかを明確にすることを目的とします

• フェーズ3: ソフトウェアデザイン

  • 集約を定義し、ソフトウェアとして実装できるようにすることを目的とします

当初イベントストーミングに期待していたこと

社内でイベントストーミングを行うにあたり、期待していたことは以下の 2 つです。

• ドメインに対する理解のチームメンバー格差を埋めること。また、認識のズレを修正し共通理解を得ること。
• モデリングを個人の仕事ではなく、チームの仕事にすること。

主観的には、「モデリング」はデキる個人が ER 図 のようなデータ構造を考える仕事になっているように見え、ドメイン知識をすでに持っていて、かつそれを上手に構造化できるエンジニアでないと「モデリング」が成立しない状況に課題感がありました。 また、個人の作業によって完成したモデルは実装前に他のチームメンバーへと共有されはするものの、モデルを考案した本人と同等の深い理解を得られないまま、結果的にドメイン理解の格差や認識のズレにつながってしまうことも課題と捉えていました。

そういった中で、ドメインに対する共通理解を得ること、また、モデリングを個人ではなくチームの仕事にすることを期待して、イベントストーミングを取り入れてみることにしました。

イベントストーミングが優れていると感じる点

弊社では過去 3 つのプロジェクトでイベントストーミングを行いました。 当初の期待通り、チームで同期的にモデリングを行うことでドメインに対して同じ理解を得ることができました。 これは、イベントストーミングがコラボレーションに主眼を置く手法だからこそ得られた成果だと思います。

しかしそれ以上にイベントストーミングが優れていると感じるのは、イベントの分析をすることで、事業的に重要な課題にフォーカスできることでした。 最初に時系列を伴うイベントに注目し、それらの発生プロセスを後回しにする手法のおかげで「結局のところ最終的に何が実現できればいいんだっけ？」という重要な問いにすぐに立ち戻ることができます。 イベントがコマンドの裏返しであることを考えると、一見イベントではなくコマンドから議論を始めても問題ないように思えますし、確かに最終的な図だけを見るとイベントから発散した痕跡は残りません。 それでもなおイベントから議論を始める理由は、プロセスよりも実際に発生したファクトが重要だという前提があるのだと思います。 さらに言えばイベントにも重要度の違いがあり、あるイベントは事業にとって非常に重要な一方で、あるイベントは実のところ必須ではない…といった発見ができれば、システムに不要な複雑さを持ち込まずに済むかもしれません。 実際に弊社でも、もともと必要と思われていた複雑な構造を一旦捨てて、重要なイベントにフォーカスすることで、問題解決のための最小構成について議論することができました。 イベントストーミングを始めたての頃には気づけませんでしたが、これはイベントストーミングを効果的に行う上でのキーポイントだと思っています。

イベントストーミングを行う上で注意したい点

価値あるモデルを生み出せるかどうかは、結局のところワークショップ参加者次第

イベントストーミングは優れたモデリング手法です。しかし、身も蓋もない話ではありますが、価値あるモデルを生み出せるかどうかは結局のところワークショップの参加者次第だと感じています。 価値あるモデルにするために、まずは適切なメンバーを集めましょう。適切なメンバーとは、ドメインの問題に対して適切な質問ができる人と、質問に対して適切に回答ができる人のことです。 イベントストーミングはさまざまなメンバー間のコラボレーションを強く推進する手法であるため、メンバーが適切であることは必須条件となります。 また、ファシリテーターの能力も非常に重要です。ワークショップの目的から外れないよう、適宜場をコントロールする必要があります。

利用目的を決める

イベントストーミングはソフトウェア設計に限らず、さまざまなシーンで利用できる手法です。それゆえに、利用目的を決めておかないと期待する成果は得られないかもしれません。 弊社で利用した際は、目的をドメインに対する共通理解を得るまでにとどめておき、実装するためのモデルは別の方法(例えば ER 図のようなもの)で再検討するという割り切りをしていました。 理由は 2 つあり、1 つ目はイベントストーミングで得られたモデルを実装しようとすると CQRS/ES 前提になるためです。 CQRS/ES もまた優れたアーキテクチャですが、実装と運用のコストをペイできないという意味で、あらゆる場面で適用できるものではありません。 2 つ目は、ワークショップの限られた時間内に深いモデル(ドメインの課題をエレガントに解決するモデル)を発明するのが困難だからです。 この問題は、ワークショップを繰り返し行うことで解決できるかもしれませんが、その分多くの人の時間を割く必要がある点は無視できません。 そのため弊社では、ドメイン理解のための素直なモデルを得ることを目的としてイベントストーミングを利用しました。

スコープを決める

イベントストーミングは時間がかかります。ケースバイケースではあるものの、フェーズ 1 からフェーズ 3 までしっかりやると 10 時間くらいはかかる印象です。 また複数人で同期的にワークショップを行う都合上、時間の確保が難しい問題もあります。 そのため、分析対象となるドメインのスコープを事前に決めておくことをお勧めします。 また、分析対象のスコープに合わせて、ワークショップの実施フェーズを制限することも有効です。 弊社では CQRS/ES を採用せず、ドメイン理解のための素直なモデルを得ることを目的としたため、フェーズ 3 のソフトウェアデザインは実施しない判断をしました。 別の選択肢として、分析スコープを非常に広く取る場合は、フェーズ 1 のみを行いビジネスの全体像を明らかにするだけに留めるという判断も有効かもしれません。 また、イベントを発散する前にスタートとゴールになるイベントをそれぞれ決めておくこともスコープを絞る上でお勧めです。

最後に

以上、イベントストーミングの勘所について、弊社での経験をもとにご紹介しました。 イベントストーミングの知見は国内ではまだまだ少ないため、この記事が少しでも参考になれば幸いです。 最後までご覧いただきありがとうございました！