こんにちは、DRAWER Enabling Architectureチームの刈部です。

この度、弊社はシリーズCの資金調達を実施しました。これを受けTech Blogを盛り上げようというPRの施策に乗っかり本稿に繋がるのですが、なかなか筆が乗らず気づいたら調達の発表から1ヶ月近く経ってしまいました。計画的に生きたい。

さて、この記事ではDRAWER開発チームにEventStormingを導入した件について、導入時の課題や良かった効果について紹介しようと思います。

EventStormingとは？

本題に入る前にEventStormingに関する簡単な紹介です。 EventStormingとは、ドメインモデリング手法のひとつです。ドメインエキスパートとステークホルダーがビジネスプロセスを協働して整理することを通じて、サブドメインや境界付けられたコンテキストを見つけ出します。

EventStormingでは3つのアクティビティを順に行います。

Big Picture: ビジネスプロセス上の意味のあるイベントを思いつくだけ付箋に書き出して時系列に並べます。
Process Modeling: 書き出されたイベントの発火条件やデータフローを整理します。
Software Design: Aggregateを抽出します。

EventStormingのアクティビティを進め方については本家の記事でも抽象的な説明が多いです。私自身正しく理解できている自信がありませんが、個人的にはBPM(Business Process Modeling)とDDD(Domain-Driven Design)を組み合わせたようなものだと簡単に理解しています。

EventStormingを導入した経緯

現在CADDi DRAWERの開発チームでは、事業の急拡大に対しシステムと開発組織をスケーラブルにするためリアーキテクチャを行っています。リアーキテクチャではサービス導入当初から運用されているモノリシックなシステムの分割やコアドメインとなるドメインモデルやデータモデルの整理が含まれています。まずそれらに仕掛かるために現状のシステムについて整理する必要がありました。下図は同僚が作成した資料になります。

この資料は画面から呼び出されるバックエンドのAPIと図面解析パイプラインなどが、それぞれどのテーブルを参照・更新しているのか整理したものになります。

これにより現状の把握は劇的にしやすくなりました。一方で「これらの操作は誰がどのようなユースケースで行っており、ビジネスプロセス上どのような意味を持つのか」という文脈は理解できません。ビジネスプロセスを整理した上でリアーキテクチャを進めるためにEventStormingを採用しました。

苦戦したこと

実際にEventStormingのアクティビティに取り組んでみると下記の課題にあたりました。

解釈がメンバー間で揃わない

EventStormingの各アクティビティについて明確な作法はありません。チームのメンバー同士でCommandやEventの粒度や書き方が異なることが度々ありました。共通言語がより少ないエンジニアと非エンジニアの間では「何を書くか」ではなく「どう書くか」について擦り合わせる時間が多く必要となりました。例えば「xボタンがクリックされた」や「xが確認された」のようなイベントです。それらはたしかに”発生する出来事”ではありますが、ビジネスプロセスにおける”重要な出来事”ではありません。

既存仕様に引っ張られる

EventStormingに限らないですが、ビジネスプロセスにおける”重要な出来事”ではなく今現在のUIやシステムの制約において”発生する出来事”にどうしても引きづられてしまいました。EventStormingのアクティビティに明確な作法がないため、行き詰まった時に既存仕様や既存設計から発想を拡げやすいからです。

異常系の扱い

設計が進んでいくと様々な考慮事項が見えてきました。特に異常系をEventStormingで表現するのは難しく、異常の内容に応じて細かく分岐を書こうとすると本来描きたいビジネスプロセスにノイズが多く発生するほか、矢印だらけの図になり非常に見づらくなってしまいます。難しいのは異常系のハンドリングそれ自体ではなく（技術的にはもちろん難しいわけですが）、EventStormingによって解像度が上がった時、我々エンジニアは未考慮のものを未考慮のままにして前に進みづらい性格をしているということです。そうするとビジネスプロセスよりも異常系の場合分けに時間を浪費してしまいます。

工夫したこと

身も蓋もないですが、まずはとにかく慣れることに集中しました。EventStormingもDDDも誰がやっても同じ結果になるものではなく、解像度を上げながら対話によってドメインモデルを深化するしかないと割り切りました。正しくEventStormingを行うことよりも、我々の扱っているビジネスプロセスの関心事に集中すると、自然と枝葉が削がれていきました。また、小さな成功体験を生むためにもまずは正常系のプロセスを1本通すことを優先し、細かい分岐は後回しとしました。

EventStormingは後のアクティビティになるにつれて点と点が結ばれていきます。すると前半に出した付箋にどのような意味を持つのか、または持たないのか答え合わせされていきます。これによりビジネスプロセスの中で本質的に何に関心を持つべきなのか学習が進みます。

下図が実際にチームで行った成果物になります。

これによってチーム内外で同じものを指差してコミュニケーションが取れるようになりました。システム間のI/Fについても貼られたDomainEventを参考に設計しやすいため、開発者間で認識がズレにくいという効果もありました。

そして全体へ...

前述の通りDRAWERは事業の急拡大に応じてチーム数が急増しました。しかし、システム境界やチーム境界が曖昧な部分があり、チーム間に歪みを生み、ディスコミュニケーションが起きていました。

今回のリアーキテクチャを期にビジネスプロセス全体をEventStormingによって整理して、見つけた境界付けられたコンテキストによってシステム設計や組織設計もしようという流れになりました。

良かった点

大まかに境界付けられたコンテキストが見えてきました。それによりチームやシステムの分割の材料になりました。
現状のチームの隙間に存在するEventや認識の違いが表出しました。またシステムに関係する箇所だけではなく、人力のオペレーションの複雑さも表出しました。

全体へ導入する進め方について、結果論ではありますがトップダウンに進めたことは功を奏しました。リソースや開発の優先度の調整が可能なポジションにある人が全体の旗振りをするのはとても効果的でした。

今後の展望

EventStormingによってビジネスプロセスやドメインモデルの解像度が非常に上がりました。チームを越えて認識を揃えられる点や実装に落とし込みやすい点においても非常に強力なフレームワークでした。一方で、EventStormingの本当の難しさはやって終わりではなく育てていくことにあると思います。

全体最適の共通言語として

組織が大きくなりチームが分割されていくと徐々に意思決定がサイロ化していきます。チーム間で情報が非対称であったりコミュニケーションコストが大きいと、自分達がコントロールしやすい選択をしてしまいます。そんな時、各チームでの最適な意思決定を行うのではなく今回のEventStormingの成果物に立ち戻れるようにしていきたいです。プロダクトの機能はシステムだけでなくオペレーションも含めて価値であるということを強く意識し、局所最適の積み重ねではなく全体最適を志向し続ける必要があります。