イベントストーミングで業務をモデル化する
業務とシステムの可変性を取り戻す。その第一歩として、モノタロウが取り組んでいるのが「ドメインモデリング」である。なかでも中心的な手法となっているのが、「ドメイン分割」と「イベントストーミング」だ。
イベントストーミングとは、業務の一連の流れを出来事（イベント）として洗い出し、それを時系列に並べていくことで、業務領域の境界やプロセスの構造を可視化するワークショップ形式のモデリング手法である。尾髙氏は、「受注した」「出荷した」など、業務的な節目となるアクションを過去形で表現しながら整理するこの手法を、「業務とシステムの橋渡し役」と位置づける。
モノタロウではこのイベントストーミングを頻繁に活用しており、総勢30名で一日かけてフルフィルメント全体を対象に実施した例もある。大規模なものは年に数回だが、数人で付箋を使って行うライトな形式は、ほぼ日常的に行われている。
なおこのとき、「最も単純な正常系に集中するのがポイント」だと尾髙氏は話す。「この場合はどうだ」「あのパターンは？」と細かい例外処理の話に入り込んでしまうと、議論の収拾がつかなくなってしまうからだ。「まずは1本、最後まで書き切ることを重視する」のが、とくに全体の業務構造を大づかみに把握するための「ビッグピクチャー」段階での注意点だ。
全体を整理するなかで見えてきた「曖昧な境界」には、さらなるモデリングを施す。たとえば、受注と配送のドメインの間に責務のねじれが見られた場合、そこにフォーカスして業務間のコミュニケーション構造を明確化していく必要がある。ここで活躍するのが「コンテキストマップ」だ。
コンテキストマップでは、情報のやり取りやインターフェースを図示し、各領域の責務を明確化することで、設計に向けた土台を固めていく。なお、ドメイン駆動設計（DDD）におけるコンテキストマップはモデルの変換責務や通信方向までを含むが、「モノタロウではより業務的な視点に絞ってシンプルに表現している」と尾髙氏は話す。
こうしてコンテキストマップを通じて領域間の関係性を把握した後は、さらに「怪しい」部分、つまり、責務や情報の流れにあいまいさが見られる領域にフォーカスを当て、再びイベントストーミングを実施する。こうして得られた、より細かな業務の時系列的な流れが「プロセスモデル」として整理される。
このプロセスモデルは、特定領域における業務の詳細な動きを可視化するもので、アプリケーション設計に向けた下地にもなり得る。しかしながら、この「業務の流れ」から、エンティティの構造や操作、責務といった「ドメインモデル」へと移行するには大きな飛躍が必要となり、「見た目以上にギャップが大きい」と尾髙氏は指摘する。
そこで、ギャップを橋渡しする目的でモノタロウが導入しているのが、独自の「概念構成図」と呼ばれる中間モデルである。この図では、プロセスモデルをもとに抽出した集約（ドメイン内でまとまった情報のかたまり）を中心に、主要な属性や操作、それを起点とするユースケース（業務上のアクション）を構造的に整理。さらに、それらと関わる人や役割との関係性を線で可視化することで、業務とシステムの接点を明確にしている。
このように、抽象度の異なる複数のモデルを行き来しながら段階的に詳細化していくことで、業務から設計への自然な接続が可能となるのだ。
もちろん、こうしたモデリングは一度きりで終わるものではない。むしろ、イベントストーミングの終了はスタート地点にすぎず、その後どのようにモデルを活用し、設計へとつなげていくかが重要になる。
「我々も、ドメイン境界を仮に定めてPoC（概念実証）に入るまでに、ざっくり5か月ほどかかりました。そこは覚悟を決めて、腰を据えて取り組んでいただきたい部分ですね」と尾髙氏は実感を交えて語る。
手法を選び、適合性を見極めながら、少しずつ前進と後退を繰り返す。抽象度の異なる複数のモデルを往復しながら、丁寧に、粘り強く。そうした探索的なモデリングの積み重ねが、やがて組織の構造を形作る設計へとつながっていくわけだ。
