ビジネスの成長に伴い、システムは複雑さを増してきています。新しい機能の追加、ユーザー数の増加、他システムとの連携拡大など、様々な要因がシステムの複雑性を高めていきます。CQRS（Command Query Responsibility Segregation）+ES（Event Sourcing）は、複雑化するシステムを健全に成長させ続けるために有効なアーキテクチャです。このアーキテクチャを学びたい方におすすめする1冊は11月に発売となる『CQRS+ES実践ガイド イベント駆動型モデリング／システム構築手法』です。その中から、発売前に「5-3 イベントストーミングの具体的な進め方」を抜粋してお届けします。
イベントストーミングの概要
イベントストーミングはチームで行う共同作業で、そのプロセスは大きく3つのフェーズに分かれます。
ビッグピクチャーではドメインで発生するあらゆるイベントを技術的な制約を考慮せずに洗い出し、時系列に沿って配置してシステム全体の概要を把握します。ビジネスプロセスモデリングではイベントの間の因果や依存をたどり、前提条件や副作用、例外的なケースまで含めてビジネスプロセスの全体像を描き切ります。ソフトウェアデザインではドメイン駆動設計の概念を使って、集約の特定、境界づけられたコンテキストの発見、外部システムとの連携方法の設計を行い、実装可能な設計図に仕上げます。
完成した図は開発チームの共通認識となり、実装の指針にも、変更や拡張の際の影響範囲の分析にも役立ちます。
実施形態
イベントストーミングはオンラインでも対面でも実施できます。どちらの形態にするかは、参加者がふだん同じ場所で働いているか、どれくらいの人数を集めたいか、議論にどこまで臨場感を求めるかを踏まえて選びます。
対面には参加者の熱量や身振りが伝わりやすく、付箋を囲んで自然に会話が生まれるという強みがあります。オンラインには地理的な制約を受けにくく、遠隔のメンバーやクライアントも巻き込みやすい利点があります。
オンラインでの実施
もともと提唱されたイベントストーミングは対面での実施を推奨するものでした。昨今では開発者同士が日常的に同じ場所で働いていないことが多く、またクライアントもリモート会議に習熟していて、オンラインでの実施が現実的な選択肢になっています。
注意すべきは参加人数です。あまりに大人数で開催してしまうと多くの参加者は傍観者になってしまいます。会話に加われない時間が続くのは参加者のフラストレーションになります。目安は4名程度です。もし、大人数で実施する場合には班分けするとよいでしょう。
取り上げる内容については事前にユースケースを絞っておきます。少人数での実施ではそのユースケースに詳しいメンバーをそろえることになるからです。また同時編集できるオンラインホワイトボードツールを事前に用意します。
対面での実施
対面での実施では、物理的なスペースさえ確保できれば参加人数を増やしやすく、大人数でひとつのドメインを対象にさまざまな議論を行って全体像をつかむのに向いています。
対面で実施する場合でも、付箋と物理ホワイトボードを使うか、オンラインホワイトボードツールを使うかという選択肢があります。同じ部屋に集まっていても、ツールの選択次第で進行の負荷は大きく変わります。
付箋と物理ボードを扱う場合は、付箋を何度も動かす作業が煩雑になりやすいため、付箋が丸まらないようにする剥がし方［2］なども事前に伝えておきます。
オンラインホワイトボードツールを使う場合、ワークスペースはひとつにまとめ、その中で班に分かれると議論が進みやすくなります。班ごとに大きめのモニターを用意したり、プロジェクターで現在の状況を表示したりすると議論の活性化につながります。みんなで同じ視点を共有することが議論を停滞させないコツです。
ビッグピクチャー
ビッグピクチャーはプロジェクトやドメイン全体を俯瞰する最初のフェーズで、関連するすべてのイベントを書き出し、発生順に並べていきます。精度や完璧さを求めすぎず、参加者全員の知見を可能な限り引き出すことに注力し、後々重要性が判明するイベントを取りこぼさないよう量を重視します。
イベントを書き出す
ブレインストーミングがアイデアを自由に書き出すように、イベントストーミングでもまずは参加者全員で、ドメインに起こり得るイベントを思いつく限り書き出していき、この段階ではアイデアを評価しません。各イベントは「注文された」「在庫が予約された」のように具体的かつ簡潔に過去形で表現します。
理想的には開始の合図とともに参加者全員が活発にイベントを書き出していく展開が望ましいのですが、参加者の経験が少ない場合、単に「書いてください」と促すだけでは行動を引き出せないことも多々あります。そのような場合は、ファシリテーターが質問を投げかけながらイベントを引き出していきます。慣れてくると、メンバーが自然と物語を語るように付箋を書き出してくれるようになります。
イベントは過去形で中立に書く
イベントは過去形で書き、あわせて表現は中立に保ちます。たとえば「本を貸した」「本を貸し出した」という書き方には、貸し手の目線が入っています。借り手から見れば同じ出来事は「本を借りた」になり、誰の立場で書くかで同じ事実が割れてしまいます。
そこで「本が貸し出された」のように、貸し手にも借り手にも偏らない表現で書きます。特定のアクターに寄らずビジネス全体を見下ろす、言わば神様の視点で書くことで、どの参加者から見ても同じひとつの事実になります。
イベントを定義しようとしたとき、そのイベントが適切であるか迷うことがあります。ビッグピクチャーでは特段気にせず、どんどんと書き出していくことをお勧めしますが、「いつ起きたか」を示すタイムスタンプをつけられるかどうかはイベントの妥当性を判断する基準になります。
たとえば「サーバがダウンした」は「2023年7月1日午後3時にサーバがダウンした」という特定の瞬間に起きた出来事として示せます。一方、「システムが安定している」というのは継続している状態であり、いつ何が起きたかという出来事ではないため、イベントとしては適切ではありません。
また「確認した」といったクエリに相当する操作は、基本的にイベントとしては扱いません。ドメインに対して実質的な影響を及ぼすものをイベントとして扱います。ただし、監査証跡が必要な処理などの場合は、例外的にイベントとして記録することもあります。
イベントを時系列に並べる
ある程度イベントが出そろったら、それらを発生順に並べます。参加者全員で配置を進めることで、不自然な順序に気づいたり、足りないイベントを発見したりできます。
たとえば「商品が注文された」の後に「配送が行われた」というイベントがある場合、その間の「支払いが行われた」「在庫が確保された」「出荷の準備が行われた」といったイベントが不足していることに気づきます。時系列に整理することで、こうした処理の抜けも確認できます。
付箋を整理していると、同じような意味を持つイベントが見つかることもあります。「注文が受け付けられた」と「注文を受け付けた」のように、同じ出来事を指して表現だけが異なっている付箋は、対話で確認してひとつにまとめます。オンラインツールを使用している場合は重複を削除し、付箋を使用している場合は重ねて整理するか、ペンを滑らせた労力に敬意を表しつつ破棄します。
ここで並べた時系列はあくまで暫定的なものです。のちの議論で順序の見直しが必要になることも多々あります。
ハッピーパス
イベントストーミングの議論はしばしば本筋から外れて収拾がつかなくなることがあります。特に開発者は例外処理やエラーケースに関心が高く、そこで議論が停滞しがちです。肝心の部分の議論に時間を割けなくなる事態を避けるため、ハッピーパスという考え方を導入します。
ハッピーパスは正常系の処理フローを示します。たとえばECサイトでの商品注文の場合、「商品が選択された」→「カートに追加された」→「注文が確定された」→「支払いが行われた」→「商品が発送された」→「配送が行われた」というフローになります（図1）。
このハッピーパスには「在庫切れだった」「支払いが失敗した」「配送先住所が不正だった」といった例外は含まれていません。それらは無視できない検討事項ですが、まずはこの基本フローを確実に押さえます。
このハッピーパスを先に固めておくと、例外フローはそこからの分岐として検討できます。
ハッピーパスを追っている最中にも、在庫切れや支払い失敗のような例外系のイベントは自然と口に出てきます。出てきた付箋をあえて捨てる必要はありません。いま議論しないだけで、後の例外フローの検討ではそのまま材料として使えます。脇に貼っておき、正常系を並べ終えてから立ち返れば十分です。
ホットスポット
自転車置き場の屋根の色ほど熱い議題はありません[1]。誰もが意見を言える身近な話題ほど議論は活発になるものですが、議論の熱量は、今ここで決めるべきことの証明にはなりません。
[1]パーキンソンの凡俗法則（Parkinson's law of triviality）と呼ばれる寓話です。C. Northcote Parkinsonが1957年の著書で示したもので、委員会は原子力発電所の建設計画を素通りさせる一方、自転車置き場の屋根の材質や色は誰もが理解でき、誰もが発言できるため、審議に長い時間が費やされると説きます。ソフトウェア開発の界隈ではバイクシェッディングの名でも知られています。
イベントストーミングの最中にも、その場では決定しきれない事柄やイベントではないもののドメインにとって重要な知識が浮上してきます。議論の本筋からは外れがちで、かと言って捨ててしまうには惜しいものです。こうした事柄はホットスポットとして記録します。
たとえば「支払いが行われた」という付箋を貼った途端、「決済手段には何があるのか」「クレジットカードだけでいいのか、コンビニ払いにも対応するのか」といった議論が白熱する、という場面が典型です。決済手段の検討はいずれ必ず必要になりますが、その場で決めきれるものでもなく、まずはハッピーパスの完成を優先します。そこで「決済手段の検討」と書いた付箋を残して、先へ進みます。ホットスポットは付箋を斜めに配置することで、通常のイベントと視覚的に区別します（図2）。
なお、私はホットスポットを大きく2種類に分けて扱っています。後で対応すべきTODO事項と、ドメインの重要な知識です。TODOは最終的に解消を目指しますが、ドメイン知識は継続的な参照情報として維持されることもあります。
この記事は参考になりましたか？
- 翔泳社の本連載記事一覧
-
- 認識がそろうチームほど「決めないこと」を書き残す イベントストーミングが議論の熱量に流され...
- このままでいいのかとざわめく心に問いかける 壁にぶつかるエンジニアに届けたいこの思い
- まじめに働きたい気持ちがエンジニアを追い詰める 職場の不機嫌が脳をバグらせる理由
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか？
この記事をシェア
