こんにちはmofmofでエンジニアをしているshwldです。
最近仕事で既存のシステムと連携する新しいプロダクトの設計をEventStormingで行いました。
はじめに
新しいプロジェクトの設計に悩んでいるチームメンバーがいました。
そのプロジェクトの状況は、以下のようなものでした。
- Railsで作られたサーバ、PHPで組まれたサーバ、Node.jsで動いているサーバなど、既存のシステムが複数存在する
- Shopifyとの連携を筆頭にネットワーク越しに依存しているサービスが複数存在する
- バッチ処理が走ったあとでないと連携されない項目など、連携の条件が複雑
- それぞれのサービスのドキュメントはあるが、横断した連携手順はまとまっていない
- エンジニアが詳細を把握していないマニュアル操作が存在する
エンジニアサイド、ビジネスサイド、双方がたくさんの会話を重ねて設計を進める必要があり、設計にとても時間がかかりそうな状況。
そこで、Domain Modeling Made Functionalに記載のあったEventStormingというワークショップを使うと良いのではないか（EventStormingやりたかっただけとも言える）と思い、EventStormingを提案、実施しました。
EventStormingとは?
エンジニア以外も参加できるシステム設計のためのワークショップです。
Alberto Brandoliniさんが提唱され、https://www.eventstorming.com/ こちらに書籍もあります。
ブレインストーミングのようにメンバーから引き出したアイデアを用いて、共同でシステム設計を行います。
EventStormingを行うことでたくさんのメリットがありました。
- 共通の理解を促進する
- チーム全体が参加することで、ビジネスプロセスや要求に関する共通の理解を得ることができます。
- ボトルネックや課題点を明らかにする
- プロセスの中での課題点や効率化の余地を見つける手助けとなります。
- ビジネス要求を明確にする
- 実際の要求やユーザーストーリーを明確にすることができます。
- ソフトウェアの設計を始める
- イベント、コマンド、アグリゲートなどのドメイン駆動設計 (DDD) の概念を用いて、ソフトウェアの基本的な設計を行うことができます。
- コミュニケーション基盤を作る
- チーム内のコミュニケーションを強化し、異なる背景を持つ人々の間での共通言語を形成する手助けとなります。
事前に準備したこと
- やり方を再確認する
- 参加者を決める
- EventStormingで得たい結果をイメージしておく
- 会場や必要なツールの準備
やり方を再確認する
以下を参考にしました。
- https://www.eventstorming.com/
- https://www.youtube.com/watch?v=jC9lE4YqgyY
- https://miro.com/app/board/uXjVOM6Bdp0=/
参加者を決める
以下のような参加者で実施しました。
- プロダクトオーナー
- ステークホルダー
- エンジニア × 4
- デザイナー × 1
- ファシリテーター (自分)
計8名となりました。
それぞれの参加者の特徴は以下のようになっています。
プロダクトオーナー
ドメインについて最も深い知識を持っている方です。顧客要望からユーザーストーリーを作ったり、実際に運用を回す体制づくりや一部運用などをされています。
ステークホルダー
プロダクトオーナーが決めきれないような判断を行える権限をもった方。
エンジニア
複数あるシステムを横断してみているエンジニア3名と、今回登場するサービスの1つに関わっているエンジニア1名
デザイナー
複数あるシステムを横断してすべてのデザインをしている方
EventStormingで得たい結果をイメージしておく
EventStormingで何を解決したいのかをイメージしました。
複数システムの連携手順が複雑で、すべてを把握している人がいない状況でした。
エンジニアは各サービス間の連携については知っていますが、Shopify上で行われているオペレーションを詳細に知っているわけではなく、逆も然りでした。
今回は、2つの課題を解決する必要がありました。
- エンジニアが設計を始めるには足りない知識がある。
- 設計の根拠、リスク、妥当性などをビジネス側、デザイナーに説明し、判断してもらうための情報をまとめる必要がある
今までもEventStorming以外の手段で可視化し会話していた部分ではあるためイメージはしやすかったです。
後述しますが、実際はここでイメージした結果よりもより多くのメリットを享受できたと感じました。
会場や必要なツールの準備
フルリモートで進めているプロジェクトなので、ツールとしてMiroを選択しました。
Miroには、いつでも確認できる場所に、やり方の流れとサンプルなどを置いておきました。
その他事前に行ったこと
自分自身は他の小規模なプロジェクトで1回だけEventStormingを試したことがありました。
EventStormingがとても有用だったため、その時の感覚を忘れないうちに社内にも広めたく、サンプルプロジェクトを使って体験会を実施しました。
このときに今回依頼してくれたエンジニアの方が参加してくれており、体験会がきっかけでプロジェクトへの導入に繋がりました。
ちなみに、このときはUber Eatsのクローンを作るというテーマで体験を行いました。1時間の中で進める分だけ設計したので、詳細までは進めませんでしたが、大人数で進める体験ができましたし、こうして次に繋がったのは嬉しいです。
そして実践へ...
2時間のセッションを1回と1時間のセッションを2回。計4時間ほどで実施しました。
全部は見切れていないのですが、大枠で前節の目的を達成できたと感じています。
- エンジニアが設計を始めるには足りない知識がある。
- 設計の根拠、リスク、妥当性などをビジネス側、デザイナーに説明し、判断してもらうための情報をまとめる必要がある
具体的な流れをみていきましょう。
1. Big Picture: 全体像を把握する
a. イベントを集める
オレンジ色の付箋を使う
過去形でイベントをどんどん出していく。主語は省略する。
懸念がありそうなところ、時間がかかりそうなところは、深掘りせずに赤い付箋に懸念を書いて先送りする
主語(アクター)があったほうが都合が良い場合は黄色い付箋で追加する
↑実際に説明に使った内容
ブレインストーミングです。
現在のシステムに関して、起こりうるイベント、出来事をオレンジ色の付箋で、全員で付箋を貼っていきます。
Miroのタイマー機能を使い、15分ほどで実施しました。
最初はどうやってだしていくのか戸惑っている方もいましたが、ブレインストーミングなので、あまり気にしなくてよいと伝えました。
b. 時系列に並び替える
左を過去としてオレンジ色の付箋を時系列に並び替える
わからない付箋があれば、書いた人に説明してもらう
同義語を統一する。同じ用語が別のものを表している場合は違いを明らかにし、分ける
イベントを眺めながら時系列に並び替えていきます。
似たものがあった場合、同じことを表しているのか話し合って統一したりといったことをしました。
↑実際に説明に使った内容
こちらも15分ほどで実施しました。
途中、異なるユーザーで行われる同じようなイベントの存在が明らかになったとき、主語を入れるかどうかという議論が起こりました。
ここでは、黄色い付箋で入れるアクターをこのタイミングで入れてもらうようにしました。結果的には良かったと思っています。
2. Process Modeling & Software Modeling: イベントの出処を見つけ設計する
コマンドを青い付箋で追加する
アクターを黄色い付箋で追加する
ポリシーを紫の付箋で追加する
システムをピンクの付箋で追加する
リードモデルを黄緑の付箋で追加する
足りないイベントを追加していく
コンテキストを区切る
↑実際に説明に使った内容
以下の動画を参考にさせていただき、やり方を真似て実践しました。
以前実施したときは、ポリシー、アクター、コマンド、イベントなど、それぞれを独立して扱って繋げていたのですが、このようにひとまとまりにして扱うようにしてみました。
システムが多いのでイベントを置く際に、既存システムについてはどのシステムに属するのかをMiroのFrameを用いて名前付けし、コンテキストを区切りました。このとき既存システムをそのままコンテキストにしたわけではなく、本当に境界があるのかを考えながら区切りました。
残りの3時間半ほどはひたすらポリシー、コマンドやアクターをくっつけ、そこからどのように次のイベントにつながるのかを紐づけていきました。
いくつかポイントを書きます。
動画で紹介されていた「緑の円でマニュアル手順を可視化する」方法が便利
システム化が困難な箇所がいくつかありました。これらは緑の円を使いマニュアル操作を図示しました。
エンジニアからはあまり見えていなかった作業であり、ここに関しての会話を行えたのは大きな収穫でした。
不明点を赤い付箋で残すことの重要さ
その場で解決できない問題は「赤い付箋でコメント」を残しました。
プロダクトオーナーの方が赤い付箋を積極的に、運用手順や顧客への確認などをしないと解決できない不明点などを残すことに活用してくださいました。
エンジニアが調査しないとわからないポイントも赤い付箋で残し、全体のフローを通して不明点、課題点が多いことが明らかになりました。
削除処理は複雑
元々想像はしていましたが、削除のフローはとにかく複雑でした。
削除されたときには、システム的にはこのリソースを使えなくしないといけない。
運用的にはこのタイミングまでは使えるべき。など複雑な状況を整理する助けとなりました。
利用規約などにも影響する項目であるため、サービスとしてどのような形が良いのかという議論ができたのですが、イベントストーミングなしでここまでの解像度を持って会話ができただろうかと思うくらいやって良かったと思います。
集約の設計まではできなかった
一部集約を書けた箇所もあるのですが、全体を通して集約を可視化するところまではいけませんでした。一部書けた箇所については、イベントがどのような概念を扱っているのかを非エンジニアに伝えることができたと感じたので、今後集約の設計も進めて行ければと思っています。
感想
EventStormingを用いることで会話と設計を同期的かつ一度に実施することができ、共通の理解を促進する効果を強く感じました。
エンジニアは運用のことをみる解像度が上がりましたし、ビジネス側はシステム設計に関する解像度が上がりました。そして、密にコミュニケーションしながらすぐに不明点を解消できる状態でした。
それぞれがどのようなことを行っているかを把握することで、コミュニケーションの効率が一段階進んだ実感があります。
参加者の方からも感想を頂いているので、掲載します！
- デザイナーさん
- 最初はよく分からなかったが、出来上がったのをみたら全体の流れが把握しやすい
- デベロッパ
- システム的な流れが把握できてよかった
- POの方
- 最初とっつきづらかったが、ドキュメントとして残るのがよい
- あとから設計を見返すことができるのがよい
- 懸念点が洗い出せるのが良い
自分自身2回目の実践、ファシリテーションでしたが、今回もとても有意義でした。
こちらのプロジェクトに関しては継続してEventStormingを見返す。改善するということもやっていきたいと思います。
Discussion