こんにちは。株式会社Schooでソフトウェアエンジニアをやっている @schoo_shogo_nakashima です。現在進行中のプロジェクトにおいてイベントストーミングに初挑戦しています。そこで出会った難しさとそれをどう乗り越えたかについて書いていきたいと思います。
イベントストーミングは業務を理解するための手法
システム設計を行うためには、対象となる事業と事業を実現するための業務を理解することが欠かせません。その業務理解の手法の一つにイベントストーミングというものがあります。イベントストーミングは業務プロセスを可視化し、理解するための手法です。イベントストーミングでは関係者が集まりブレインストーミング形式で業務プロセスの洗い出しをしていきます。業務プロセスは以下の図のように付箋と矢印でシンプルに表現されます。
イベントストーミングでは付箋として表現する要素の種類や、どの要素間で矢印を張れるかといったルールが比較的厳密に決まっています。これにより、可視化された内容の意図がわからなくなるといった、ありがちな問題が発生しにくくなっているように感じます。
また、このルールが業務プロセスをシステム設計に落とし込むことを前提としたものであるため、後続の設計作業がスムーズに進むことも期待できます（実際にはまだ設計フェーズに進んでいないため、あくまで期待を感じているという状態です）。
いかがでしょうか？イベントストーミングに対する期待が高まってきませんか？現実世界の問題をシステム設計に落とし込む方法を模索してきた私にはイベントストーミングが一つの答えに思えました。そこで、直近のプロジェクトでさっそくトライしてみることにしました。
イベントストーミングの入り口には壁があった
まずは書籍やWeb上にある情報を通じてイベントストーミングについて学び、次にヒアリング対象の業務範囲を決定し、実際に業務を運用しているエキスパートとのミーティングの場もセッティングしました。
準備は万端。あとはイベントストーミングを実施するだけ、という段階で私は一つの壁にぶつかりました。それは「上手くファシリテーションする自信がない」という問題でした。このままではおそらくグダグダのうちにミーティングが終わってしまうだろうという予感がビシビシとしていました。
「なんだそんなことか」と思われるかもしれません。しかし、ミーティングが数日後に迫っている私にとってこれは切実な問題でした。具体的な不安要素をいくつか並べていきます。
- 自分はイベントストーミングのファシリテーションをしたことがない
- 参加するメンバーはイベントストーミングの知識を持っていない
- 凡例だけでは進め方の感覚をつかんでもらうことは難しそう
- 気の利いたサンプルを作っている時間はない
まとめると、経験不足と準備不足といったところでしょうか。今回のヒアリングの目的は業務プロセスを明らかにすることです。イベントストーミングを取り入れることはあくまで個人的な実験という位置付けでした。そのために多くの準備時間を使うことが得策とは思えず、こういった状況となっていました。これは新しい取り組みを実験的に小さく始めようとした際に陥りがちな問題ではないかと思います。
イベントストーミングのみで戦う必要はない
では、新しい手法は諦めて既に慣れている方法を使って安定した成果を出し続けるのが良いのでしょうか？この答えはNoだと思います。それではやり方を進歩させることができません。では、周囲に説明して準備の時間をしっかりと捻出すれば良いのでしょうか？これが可能な場合の答えはYesだと思います。しかし、実験的な取り組みに多くの時間を捻出する判断は難しい場合が多いかと思います。
そこで、今回はヒアリングを二段階に分けることとしました。
第一段階のヒアリングではまっさらな状態から業務プロセスの概要を掴むところまで進むことを目標としました。ここでは既に慣れている方法を使ってヒアリングを行いました。私が使った方法は「業務イベント」「担当者」「実施タイミング」といった業務を説明する要素を以下のような表として整理する方法です。
| No. | 業務イベント | 担当者 | 実施タイミング | インプット | アウトプット | 備考 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 |
この方法は見た目こそ地味ですが、表を埋めていけば良いということが一目瞭然で、進め方に迷うことは少ないというメリットがあります。一方で、条件分岐や並列処理を記述しにくいというデメリットもあります。
まずはこの方法を使ってヒアリングすることで業務プロセスの大枠を掴み、参考となる資料も共有いただくことができました。
そして、第二段階に進む前の準備として、ヒアリングした内容や参考資料をもとにしてイベントストーミング形式のフロー図を作成しました。この作業は私一人で行いました。
最後に、第二段階のヒアリングでは第一段階でヒアリングしきれなかった詳細を理解することを目標としました。ここでは、作成したフロー図の見方を簡単に説明し、それから詳細のヒアリングを進めました。一度お話しいただいた内容をまとめたものを使っているので、業務エキスパートの方にとっても理解が容易だったのではないかと思います。そのおかげで、図が何を表しているかわからなくなるといった問題は発生しませんでした。結果として「ここの認識は間違っていますよ」といったダイレクトなご指摘をいただくことができました。
まとめると、見通しが悪い段階では慣れているシンプルな表現と進行で迷いを減らし、見通しが立った段階でイベントストーミングへの切り替えを行いました。これにより、最終的にはリッチな表現で例外ケースや業務上のペインなどを掴むことができました。
事業を理解し “続ける” 場所を作る
イベントストーミングやユーザーストーリーマッピングなどのワークショップ形式の手法では最終的に出来上がった成果物だけではなく、成果物を作り上げる時間を共有することこそが大切です。その時間があって初めて共通認識を生み出すことができ、メンバー間での認識の齟齬を減らすことができます。今回、業務プロセス表をイベントストーミングの図に変換する下準備こそ私一人で行いましたが、ヒアリングを通じてその図を育てていくプロセスは業務エキスパートの方々と共に進めることができました。
システム設計は一度やって終わりということはありません。事業の変化や業務の変化がある度に何度も設計を見直し、自分たちの事業や業務の理解を更新し続ける必要があります。今回イベントストーミングに取り組んだことで業務エキスパートとソフトウェアエンジニアが共に事業と業務を理解し続けるための場を一つ作ることができたのではないかと思います。
これからイベントストーミングに挑戦するために
私がイベントストーミングに対して感じた難しさの正体は、イベントストーミングの自由度の高さから来るファシリテーションの難しさでした。今回は他の方法と組み合わせることで、あえて自由度が低くなるようにしました。これにより、どうにか難しさを乗り越えることができました。
今回の経験から、初めてイベントストーミングに挑戦する際は、以下の点がポイントになると感じました。
イベントストーミングにこだわりすぎない: まずは使い慣れた方法で全体像を掴み、段階的に新しい手法に移行することで、取り組みの難易度を下げることができます。
複数の日に分けて行う: 複数の日に分けて進めることで、落ち着いて意見を整理する時間を作り出すことができます。
この記事がイベントストーミングに挑戦する皆さんの助けに少しでもなれば幸いです。
謝辞
最後になりましたが、今回ヒアリングがスムーズに進んだのは、業務エキスパートの方々の積極的な協力があったおかげです。また、共にヒアリングを行ってくれたメンバーは私にはない観点から業務プロセスを深掘りしてくれました。この場を借りて、みなさんに感謝を伝えたいです。ありがとうございました。プロジェクトはまだまだ始まったばかりです。これからも共に頑張っていきましょう。
参考文献
- Vlad Khononov. ドメイン駆動設計をはじめよう. オライリー・ジャパン, 2024
Schooでは一緒に働く仲間を募集しています！