参加記録 EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう

https://www.eventstorming.com というのは、「みんなでワイワイ付箋はって議論しながら、ドメインモデリングやろうぜ！」という会だと思っていたのですが、実際自分でやってみないとわからんと思い以下のワークショップに参加することにしました。

https://readeffectiveakka.connpass.com/event/129320

Event Stormingの詳細は冒頭のリンクを見ていただきたいと思います。Event Strorming推奨者(？)が執筆途中の本も販売されています。

やってみた感想は、Event Stormingは一手法に過ぎないので慣れればやり方を洗練させることができるし、他のドメインモデリング手法と組み合わせても効果を発揮するかもしれない、といったところです。最後にもう一度感想はまとめています。

当日の手順

今回のワークショップはEvent Stormingを使って「かつてない図書館」をモデリングするという会です。20人ほど参加者が集まり、各参加者の頭の中には野心的な「かつてない図書館」のビジネスモデルがある、という前提です。

当日は以下のような手順で進みました。

• 1: キックオフ 25分
• 2: カオス探索 30分 <- コレが一番ブレインストーミングっぽい

ここでベタベタとオレンジ色の付箋を大量に貼っていきます。オレンジ色はドメインイベント(後述)を表します。

イベントストーミング面白い！ #event_storming pic.twitter.com/LQ59ax6ahY

— シロクロつけるパンダ (@applideveloper) May 12, 2019

3 ~ 9 は2の結果をフェーズごとに異なる視点で深く分析、そして整理していくイメージ。

• 3: タイムライン強化 30分
• 4: 人々とシステム 30分
• 5: ウオークスルー 30分
• 6: 逆光ナラティブ 30分
• 7: お金を追加 30分
• 8: 問題と機会 25分
• 9: 問題の選択 30分
• 10: クロージング 30分

(2: カオス探索) オレンジ色の付箋でドメインイベントをベタベタ貼っていくフェーズ

このフェーズでは参加者各々が「かつてない図書館」で発生する「ドメインイベント」をオレンジの付箋に書いて巨大なホワイトボードに貼っていきます。ドメインイベントは図書館で発生する重要な出来事を「動詞の過去形」で表したものです。例えば「本を借りた」「本を返却した」「本を本棚に並べた」などでしょうか。

各人が他人を待たずにどんどんドメインイベントを付箋に書いて貼っていく方がEvent Storming的にはよいとされているようです。この時点では他者と重複する内容を貼っても構いません。

注意点として、これはITシステムの設計パターンであるEvent Sourcingとは異なるので、Event Sourcingを念頭にITシステム内で実装するイベントを考えるのでなく、ITシステムを忘れた上で純粋に対象ドメインからドメインイベントを挙げていかなくてはなりません。

しかし、やってみるとこの「ドメインイベント」として何を挙げていいかなかなかわからない。「本を借りた」くらいならすぐ出ますが、ちょっと考え始めると「司書もモデリング対象…？司書にひもづく動詞って…」と悩んだり、「図書カードが発行された」というドメインイベントに対して「図書カードが発行された、に関連する他のイベントってなんだろう。そもそも図書カード何をするためのものなのか決めないとわからないのでは…」と結構手が止まること多数。

Event Stormingの本を読んだだけでは、一旦このフェーズで勢いが出始めたらどんどん付箋が貼られていくようなイメージでしたが、実際には悩んで手が止まることが多いかもしれません。これは本を読むだけでは得られない発見でした。スムーズに行かない部分も含めて貴重な経験です。

3 ~ 9 のフェーズ

ドメインイベントを洗い出すフェーズ、カオス探索が終わったら、あとは整理と分析のフェーズが続きます。ドメインイベントを時系列に並べたり、関連する登場人物や第三者・システムを列挙したり、時系列に並べたイベントを時系列の逆からたどって漏れがないか検討したり、と様々な手法と視点を用いてドメインモデリングを深く行っていきます。

ホワイトボードと付箋を使うのは同じで、各フェーズごとに付箋の色を使い分けていくことになります。

3番目以降のフェーズでも必要に応じて漏れていたドメインイベントを追加していっても良いのですが、やはり2: カオス探索でのドメインイベントの網羅性と質がその後のフェーズでの分析の質を大きく作用するような印象です。

3 ~ 9 のフェーズ、あるいはEvent Storming全体の質を向上させるには、いかにして2: カオス探索をうまくやるか、質と網羅性の高いドメインイベントを挙げていくかに集中するのが良いと思います。その点について記事の後半で私の意見を述べています。

やってみてわかったこと、事前のEvent Stormingに対するイメージとの違い

Event Stormingも実際やってみないといいところも悪いところもわからないもの。本を読んだだけではわからないことを発見することができました。

まず1つ目は、Event Stormingはドメインモデリング手法であって、斬新なアイデアを思いつくための方法ではないだろうということ。参加対象者として、まだ明確に文章化や図解にはできてないが、豊富な経験をもとに頭の中には複雑で細かいルールが詰まっている、というような人々が集まって対象ドメインを分析し、明確な共通理解を得るには良い手法だと思います。でもこれで参加者のなかから100億円儲かる斬新なアイデアが出るわけ無いですし、当たり前だけど斬新なアイデアなんて「手法」で思いつくものじゃないですよね。

それから2つ目は、ついついソフトウェアエンジニアはITシステムを実装するときの事を考えてモデリングをやってしまいがちだということです。先にも述べましたが、Event Storming自体はITシステムのことを忘れて純粋にドメインモデリングのみに集中するものです。図書館の例だと、本を借りる、本を入荷する、といった図書館自体の仕組みについて考えるのであって、図書館のITシステムについて考えるわけではありません。わかっていてもなかなかこれは難しいことでした。

反対に、ITシステム上の制約がドメインイベントの種類を決めるケースもありました。図書館に普通の貸出フローと同時にオンライン貸出予約システムを導入するとなると、普通の貸出フローに沿って利用者が本棚で本を手にとって貸出カウンターに行くまでに、別の利用者が同じ本に対してオンライン貸出登録を済ませている事が考えられます。これは純粋なドメインモデリングの話ではなく、ITシステム側で考える非同期処理の競合の話のようですが、これによって「本を借りた」というドメインイベントが「本を手に取った」「貸出カウンターにおいた」「貸出申請をした」などより詳細なレベルのドメインイベントへの分割を要することがわかります。

3点目として法律も重要であり、ITシステムがドメインイベントを決めるケースがあるという他にも、法律がドメインイベントの種類を決めるケースもあるとおもわれます。今回のワークショップでも一部法律に明るい参加者が関連法案に対する知識をもとに「ここで利用者からお金を取るなら、どうじに著作者にお金を払わなくてはならない」といった指摘をしていました。当然こういった手順は対応するドメインイベントを必要とします。しかし、現実の世界では関連法規を全部暗記している人などほぼいないと思われるので、ドメインイベントの洗い出しに法律の理解が必要な場合、実際には時間をかけてやる必要がありそうです。

2回目以降ワークショップをやるなら…改善案

馴染みのある対象をドメインモデリング対象にしる

今回特に2: カオス探索のフェーズでドメインイベントの洗い出しの網羅性が低い箇所があり、適切なイベントを思いつけず悩んでしまうといった状況になることがあったと思います。

おそらくその原因は現実の事業に対するモデリングと違って、「かつてない図書館」という対象ドメインは参加者全員にとって未知のものであり、かつ事前に「どのあたりがかつてないのか」を明確できていなかったので、ドメイン対象に詳しくない人たちが悩みながら話す状況になってしまったからかなと思います。

今回はワークショップという形でしたが、「実際の」Event Stormingは現実の事業に関わるドメインをモデリングするため重要な関係者、つまりステークホルダーをよんでEvent Stormingを行います。Event Stormingの本にも「適切な参加者を招待する」ことの重要性が書いてあります。つまり、視点は違えどそれぞれがモデリング対象のドメインに対して一家言もっているということが重要なのだと思います。

ワークショップを練習の場と考え、そこで一家言持つ人々が参加している状況を再現するために、普通の図書館をモデリングしてもよかったし、エンジニアに馴染みのある既存のサービスをモデリングしても良かったかもしれませんね。

とはいえ、特に後半になるにつれ他の参加者から自分が考えていなかった分析の視点が提供されることがあり、手法自体の可能性は感じることができました。

一旦2: カオス探索をやった後にドメインモデリング対象を狭める

「かつてない」部分だけでなく、既存の図書館にもある機能だけに絞っても、たくさんの複雑な領域があることがわかりました。たとえば「図書カード」周りの処理は考えれば考えるほど複雑です。あるいは図書館の利用者が本を探してから借り、返すまでも、紛失や延滞、貸出登録の間違いなどを考えるとどんどん複雑になっていきます。本を本棚に並べるのも、多くの図書館では書架と呼ばれる普段は利用者に見えない場所に保管するなど、分析によってどんどんその管理の複雑差が明らかになっていきますし、さらに本の在庫管理を別ドメインとするか、図書館のメインのドメインとするかなどなかなか難しいところではないでしょうか。

ここで挙げた項目ひとつひとつが、一日がかりのEvent Stormingの対象となりうるような複雑さを持っていると思います。いったんEvent Stormingのカオス探索の段階で、これはモデリング対象が広範すぎてドメインイベントを網羅できない！となったら複数のEvent Stormingの開催に分割してもよいのかもしれません。

Event Stormingを分割する話は確か本には載ってなかった気がするのですが、あまりEvent Stormingばかりやって時間をとるのも現実の事業の中では難しいので悩みどころですね。

ブレインライティング

2: カオス探索の手順についてはブレインストーミングに近い手法だと思います。ブレインストーミングについては私が前にこんな記事を目にしていて、

いいアイデアなんか思いつくはずがない - Medium, 角 征典 (@kdmsnr) 東京工業大学エンジニアリングデザインプロジェクト

その記事内では

「いいアイデアが浮かばない」「使えないアイデアを出す」

と散々なこき下ろしようでした。わたしはブレインストーミングがそこまで使えないかはわからないのですが…

…少なくとも先に述べたようにこの2: カオス探索は斬新なアイデアを出すためのものではありませんので、ブレインストーミングに似た手法でも問題ないかと思います。ただ、それでもなかなかその場でドメインイベントを思いついて書き出すというのはハードルが高いので、可能なら記事内でも紹介されている「 ブレインライティング」を事前に行っていくと良いかもしれません。

もっとも、Event Stormingは参加者の全員が協力的でない場合も想定した手法なので、かならずしも参加者が事前に時間をかけて「ブレインライティング」をやってくれるというのは非現実的な想定かもしれません。

まとめ

記事の最初で言ったように、個人的にはEvent Stromingは一手法だと思っていて、手法であるからにはだんだん慣れて洗練させていくことができ、またEvent Stormingだけでなく複数の手法を組み合わせていくことでさらに有効な手段になる可能性もあると思います。ユーザーストーリーマッピングなどの手法と、もしかしたら組み合わせることができるかもしれませんね。

ドメインモデリングというITシステムの実装から離れた文脈で議論し、その手法の練習をするというのは新鮮な体験でした。ソフトウェアエンジニアとしてドメインモデリングの腕をもっと上げて行きたいと思うきっかけになりました。

それから話はそれますが、斬新なアイデアを思いつくためのものではないはずの会で、最後の方になってからなぜか一部の参加者から怪しげな(？)図書館のビジネスモデルが湧き上がっていたのは興味深かったですね笑