こんにちは。AIRTRACK の豊田です。今回は技術マネジメントの話をします。

先日、チーム内でコロナ対策を万全に講じてイベントストーミングを実施してみました。

社内でもあまり行われていない取り組みのようなので、イベントストーミングとはなにかについて簡単に説明し、どのような課題を解決する手法なのかを見ていきます。加えて、実施にあたってどのような点について注意したのかといった点について、簡単に書きたいと思います。

この記事は実践寄りの感想になるため、イベントストーミングのやり方そのものについては深くは掘り下げていません。

AIRTRACK とは

サイバーエージェントの AI 事業本部で、主に広告配信や小売向けのソリューションを提供しているプロダクトです。2014年から創業を開始し、以降さまざまなクライアントを獲得しながら発展してきたプロダクトで、現在では AI 事業本部の小売 DX 部門を支えるプロダクトです。

AIRTRACK が挑戦するのは、まだまだ確固たるソリューションが存在しない小売業界のデジタル化（DX という言葉が最近ははやっています）という領域です。チラシのデジタル化です。独自のアルゴリズムを用いて、消費者が必要としているモノに関する広告を届けられるように日夜工夫しています。

少し開発体制の話をさせてください。

開発チーム全体はデータサイエンティストも含めると10名程度、ビジネスサイドを含めると15名程度の規模をもつプロダクトです。私はそのうちのテックリードを務めており、私以外にはエンジニアリングマネージャーを務める方がいます。私自身の職責はソフトウェアアーキテクトと技術周りのマネジメント・戦略設計です。エンジニアリングマネージャーは、ピープルマネジメント（とカタカナでいうとカッコいいが要するにエンジニアの人的側面の管理）やプロダクトの開発プラン、優先順位決めを行っています。

開発プロセスの特徴としては、スクラム開発を採用しているという点があげられます。スクラムの原則である「検査・透明性・適用」を重要視したプロダクト開発をしており、スプリントは1週間単位で回されています。認定スクラムマスターも在籍しています。

AIRTRACK 開発チームマネジメントの哲学は、「誰もがどのような業務であってもできるようにする」です。これにより、たとえば新卒であっても（多少サポートを受けながら）シニアがこなすようなレベルの仕事をすることができます。また、サーバーサイドエンジニアであってもフロントエンドもインフラも触るということが可能になっています。いわゆる暗黙知や属人化をできるだけ減らすマネジメントをしていきたいと考えています。そこにスクラム開発が生きてくるのです。

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

イベントストーミングとは、いわゆるワークショップ形式のアクティビティです。このアクティビティを通じて、ドメインイベントを中心としたドメインモデルを作っていきます。

このアクティビティの最大の目標はモデルを組み上げることです。ドメイン駆動設計をご存知の方であれば、ドメインモデルがどのような形になっているのかを落とし込めるアクティビティだと思うと想像がつきやすいかもしれません。

ドメインモデルを組み上げる作業は、私が思うに開発の中でもっとも難しいプロセスで、とくにステークホルダー間で認識を合わせ続けるのは普通に開発をしていると至難の業です。イベントストーミングはこの問題に立ち向かいます。

イベントストーミングでは、まず対象とするドメインで起こる「ドメインイベント（以下、イベント）」を抽出していきます。イベントというのは、過去に起きた出来事です。要するにたとえば、広告配信システムなら「案件を入稿した」「配信を開始した」「配信が中断した」などといった出来事がイベントとなります。これをまずは抽出していきます。加えて、イベント以外にも「コマンド」「外部システム」「方針」「読み取りモデル」といった要素も、ビッグピクチャの中に加えていきます。

そして抽出した要素たちをタイムラインに沿って過去から未来に並べていくことで、最終的な成果物（ビッグピクチャと呼びます）が作り上げられます。つまり、このアクティビティの結果、複雑な現実の業務全体をシステムの言葉に落とした成果物ができあがり、のちの実装時にはこの絵を参照しながら開発を進めていくことができるようになるのです。

ユーザーストーリーマッピングとは違い、かなりシステム側によったアクティビティです。議論を進めていく内容も、システムにどう落としていくかという観点を中心に進められていきます。このアクティビティを見た瞬間に、これはドメイン駆動設計をかなり意識しているなと感じました。実際、関連する用語が多々登場します。

一般的なイベントストーミングの実施手順については『Introduction EventSourcing』という本や、Qiita のこの記事、あるいはこの記事などに詳しいです。

イベントストーミングで解決したかった問題

私が今回イベントストーミングを実施するにあたって解決したかった課題は下記です。

• 今回実装の対象とするドメイン（業務内容）がそもそも複雑で、結局何をしたらよいかについて誰も全体像を描けていなかった。
• 業務を行うためのシステムを実装するにあたって、自分たちがどのようなドメインをシステムに落とそうとしているのか、実施前には整理できていなかった。
• また、直近でチームの人数が増えてきたが、それに伴ってドメインの知識が一部の人に偏って蓄積されてしまっており、属人化が進んでいた。

こうした課題に対して、イベントストーミングは非常に有効な手法なのではないかと以前から考えていました。百聞は一見にしかずということわざがありますが、最終的にひとつのビッグピクチャを全員で作り上げるこのプロセスは、まさに百聞は一見にしかずなのではないかと考えたのです。これは AIRTRACK の開発チーム運用の哲学ともマッチします。

結果的に、上記にリストアップした課題に対して、イベントストーミングは大きな効果を発揮し始めたように思います。まだイベントストーミングの結果は実装途中で、本当の効果が検証できるのはこれからですが。

実施した結果、

• 実施した本人がまず、ドメインの全体像を手に入れられた。
• メンバーと事後にドメインについて話をした際に明らかに以前と比べて理解度が違っていると感じられた。
• 参加者が楽しそうだった。

といった効果をすでに感じています。参加者にとって実りある会だったのであれば、ひとまず開催した価値はあったと思っています。

ただ一方で、こうした活動は一過性のものとせず、継続して行ってこそはじめて改善活動になっていきます。私は次に、どうしたらスクラムチームの開発プロセスにイベントストーミングという新しいプロセスを自然に統合していけるかについて思案しています。

事前検討

ガイドに載っているものをそのまま実施したとしても、組織にフィットするとは限りません。また、一度きりのものにしたくはなかったので、先ほど紹介した本や先駆者の記事を参考に、継続的に行えるよう会をデザインし直しました。これがうまくいっていれば、私は次回「継続のコツ」のような記事をアップしていることでしょう（笑）。

参加者は絞り、時間は1時間にした

参加者と時間についてはかなり絞りました。『Introducing EvnetStorming』内では、何日間にもわたって行われているようですが、その時間はありませんでした。なので、

• 参加者は全体で6名程度。
• 時間は1時間。

で行いました。そのため、今回実施する対象としたドメインもかなり小さいものを採用しました。

イベントストーミングで重要なのは参加者を正しく選定することです。「その場で」結論を出し切りたいです。なので、

• ファシリテータ: 会議の進行や参加者から質問を引き出したりする人。
• ドメインエキスパート: イベントストーミングで扱う業務領域に詳しい人。
• 開発者: 実際にその業務内容をシステムに落とす人、あるいは日常的にアプリケーションの開発に携わっている人。

の3つの役割の人たちをその場に集める必要があります。

今回は、データサイエンティストが広告配信において AB テストを行う際に、どうしたら彼らがやりたいことを実現できるかについて考える必要がありました。したがって、ドメインエキスパートはデータサイエンティストということになります。なので、彼らに参加してもらうことにしました。

ファシリテータは、今回がはじめての実施だったため、イベントストーミングについてある程度理解している必要がありました。なので、私が担当しました。本来であれば、ファシリテータは適切な問いを投げかけて議論を深める役割を担うので、イベントストーミングもわかっていて、かつドメインに関する知識もある程度ある人がよさそうではないかと考えています。

イベント、集約、Issue に絞って実施することにした

今回実施するにあたって、イベントストーミングをフルパッケージでは実施しないという手を取りました。これは FOLIO 社の方が発表されていたスライドの中で採用されていた手法で、初回を実施するにあたって非常にスマートに実施できそうだと感じたため採用しました。

イベントストーミングには、External System や Command といった多くの要素が存在しています。初めて実施するにあたって、1時間しかない中でこれらすべてを参加者に理解してもらいあげきるのは無理だと考えました。少々説明しなければならないことが多いためです。

したがって、スライドで紹介されていた「イベント」「集約」と「Issue」をあげるという手法を採用しました。これにより、最低限果たしたい目的は果たせました。ただ今後、要素は徐々に増やしていきたいと考えています。

事前に予行演習で課題を発見した

さらに1時間のワークショップを実施する前に、特定の小さなドメインに絞って2名で軽くイベントストーミングを実施しました。

その結果、思いつく限りのイベントを列挙する前に、イベントの始点となる付箋を何枚か用意しておくと、議論の起点となってよいのではないかというフィードバックを得られました。これも採用し、当日は始点をあらかじめ何枚か用意した状態でスタートさせました。

当日、始点の用意は発想の起点になったようです。このおかげで、私が見つけられていなかった始点も参加者がたくさん発見していきました。

ミニマムに実施した際のプロセス

上記をふまえながら、下記プロセスを最終的には採用しました。

1. ファシリテータは「始点」を用意しておく。
2. まず思いつく限りのイベントを列挙する。同時に議論の余地がある話を Issue として貼る。
3. タイムラインに載せる。
4. イベント間の依存関係を矢印で結ぶ。
5. 集約を発見し、命名する。

ファシリテータは「始点」を用意しておく

先ほども説明したとおり、予行演習で発見した「始点」の確保を行いました。これを行うことによって、そのドメインに関してあまり知識をもっていなかったとしても、議論に参加しやすい状態を担保しました。

「始点」は本当になんでもよいです。たとえば広告配信であれば、「広告配信ボタンを押した」「広告を入稿した」といった文言がひとつの始点になりえます。そこから派生するイベントをあとは列挙していくだけです。

始点は最初にファシリテータが用意したもの以外に、参加者が自由に追加することもできます。もちろん時間内に会議を収め、成果物をすばやく作り上げるために「始点以外は貼り出さないようにしてください」と絞ってみてもよいでしょう。ここはファシリテータの腕の見せ所かもしれません。

始点の確保の最大の目的は、ドメインに関してあまり知識をもたない人でも参加できるようにするという点です。少なくとも始点があれば、参加者は質問を考えることができます。これが重要なのではないかと考えています。

まず思いつく限りのイベントを列挙する

先ほど説明した始点を起点にし、まず思いつく限りのイベントを参加者に列挙してもらいます。あげる内容は、ドメインに明らかに存在しないものでない限りはどんな些細なイベントであっても構わないです。オレンジの付箋で貼っていきます。

この段階では相当数のイベントが列挙されていくため、横に広いホワイトボードを用意しておくことをおすすめします。

また、先ほど説明した Issue もこの段階で貼っていきます。ガイドに従ってピンクの付箋を貼るようにしました。

タイムラインに載せる

先ほど列挙したイベントを、左から右に時間が流れるように順番を並び替えていきます。まず、まとめられるものをまとめ、不要だと思ったものは削除するというように整理をしていきます。

次に、まとめられそうなものや、不要そうなものを整理しきったあと、時系列順になるように位置を調整してさらに整理します。

無理に依存関係を整理する必要は、この時点ではありません。それは次のプロセスで行うためです。

イベント間の依存関係を矢印で結ぶ

タイムラインに一通り載せ終わったところで、お互いに依存し合うイベント同士を矢印で結び合います。（実施当日は私が勘違いしていた＆あとで知ったのですが、『Introducing EventStorming』の中にはこのフェーズは登場してきていません。ただ、意外に有用なように思いました。）

基本的には始点の付箋から次の付箋、次の付箋…というように矢印が続いていくはずですが、中にはスタート地点がわからないものもあるかもしれません。途中からある特定の時間帯や条件を満たすと発生するイベントがそれです。その際は、「…→」というような矢印を採用してみました。

スタート地点がわからないものには、特定のアクターが関与しているかもしれません。今回は行いませんでしたが、そうした特定のアクターについても整理して記載しておくと、規模の大きめなプロジェクトでは役に立ちそうに感じました。

集約を発見し、命名する

依存関係を結び終わると、「これらのイベントはお互いに強く依存しあっていて、整合性を保つ必要がありそう」というイベントのまとまりを発見できるかもしれません。これは集約と呼ばれるもので、ひとまとまりに処理を仕切る単位として認識しておくべきものです。

まとまりあったグループを線で囲います。囲い終わったあとに、もう一度そのまとまりで正しいのかを見て、正しそうであればひとつひとつ名前をつけていきます。これがモデルとして発見されていくのです。

次回以降

やはりフルパッケージで行いたいです。本来であれば Command や Policy なども採用して、もう少し細かく議論することも可能なはずです。

今回の抽出されたイベントは、やや粒度が大きめの内容が多かったので、この精度で十分間に合うのかどうかは気になっています。これはイベントのみをリストアップする手法の弱いポイントなのかもしれないと感じました。

また、実装に落とす際にシームレスなものかどうかはまだわかっていません。弊プロダクトのシステムは、イベントストーミングの中で使用される用語から連想される CQRS + ES のアーキテクチャを採用できているわけではありません（したいけど）。こうしたシステムに対しても効力があるのかは、検証の余地がありそうです。

まとめ: 設計を”タンジブル”にする

ドメインモデリングのような抽象作業は、何も手を打たないと抽象的な文章が羅列され、結局参照されないものができあがってしまいます。議論も口頭で行うと空中戦になりがちで、論点も散りがちです。その結果、システムやドメインに詳しくない人は、途端に議論への参加権を失います。これは健全な姿とは言えないでしょう。

こうした問題に対するキーワードとして「タンジブル（tangible）」というものがあります。この単語はノンネイティブには少し難しいですね。語源はラテン語の tangere で、この単語は英語に直すと touch です。これに -ble が付くので、touchable （触れられるもの）くらいの意味合いだと予想が立ちます。

タンジブルというのは要するに「触って感知できる状態にすること」です。モヤモヤしたものを実体化するという意味合いがあります。

モデリングにおいては、図表に起こしてひと目で見てわかる形にしておくというのが表現としてはわかりやすいでしょうか。モヤモヤしたモデルという存在を、図表という人間が目で見て観測可能な形にして用意しておく。これが設計をタンジブルにするという作業です。

イベントストーミングではまさにこの設計をタンジブルにする作業を行います。この手法が優れているのは、イベントを扱うのに特化して設計されているという点です。タイムラインに過去から未来に向けて項目を並べるというシンプルな作業ではあるのですが、これがイベントをタンジブルにするのにピッタリの作業です。

AIRTRACK では、こうした設計をタンジブルにするアクティビティを今後も設計し、積極的に開催していきたいと考えています！