バリューストリームとイベントストーミングの一貫性担保
はじめに 〜VSMとESの関係性とは〜
バリューストリームマップは、顧客（サービス提供を受ける側）が体験する価値の流れを 「外から見た（Outside-In）」視点 で描いたものです。
これは「何を」「なぜ」達成すべきかという戦略的な地図です。
対して、イベントストーミングは、その価値を実現するために、サービス提供側が実行する業務プロセスを 「内側から見た（Inside-Out）」視点 で描いたものです。
それは「どのように」実現するかという戦術的な設計図です。
アナロジー表現
この2つは、建物の「外観のCGパース（バリューストリーム）」と、その建物を機能させるための
「内部の鉄筋や鉄骨、木材の組み立て構造や配管・配線図（イベントストーミング）」
のような関係です。
外観がどんなに立派でも、内部構造がぐっちゃぐちゃとか脆くては、価値がありません。
一貫性の担保はどのように行うか？
一貫性を保つ鍵は、2つの成果物モデルを意図的にマッピングすることです。
最も強力な方法は、バリューストリームの「各ステージ（バリューステージ）」 と、
イベントストーミングの「主要なドメインイベント」 を完全に一致させることです。
それぞれのモデルの関係性
・バリューストリームのモデル
バリューストリームで「注文受付」→「在庫確認」→「商品発送」というステージが定義されたとします。
この濃い緑付箋１つ１つが、バリューステージです。
・イベントストーミングのモデル
イベントストーミングの成果物には、それに対応する
「注文が受け付けられた」→「在庫が確認された」→「商品が発送された」というドメインイベント が、明確な境界（コンテキスト）の区切り目として存在していなければなりません。
バリューストリームは、イベントストーミングを行う際の「どの範囲（コンテキスト）に焦点を当てるべきか」を定義する、強力なガイドとして機能します。
1. 定性的なチェック：設計時の一貫性担保
「各バリューステージ ＝ 各コンテキストの提供価値 という定性的なチェック」
これはアーキテクチャ設計と組織設計における核心です。
なぜ重要か？
・バリューステージは、顧客にとって意味のある 「価値の区切り」 です。
・コンテキスト（境界づけられたコンテキスト） は、開発チームの「責任の区切り」であり、ソフトウェアの「デプロイの区切り」です。
もしこの2つがそもそも一致していないと、「顧客にとっての価値」と「チームの責任」がズレていることになります。
それにより、本来の認知境界と、アーキテクチャの境界のズレにより、認知的不協和をほぼ確実に生みやすくなります。（これは最早ビジネス負債です。）
例えば、「注文受付」という1つのバリューステージを実現するために、下図のように3つの異なるチーム（コンテキスト）にまたがる複雑な調整が必要になる、といった事態を招いたりします。
この３つの分断されたコミュニケーションパスが、顧客の価値をそもそも低下させている状況をつくります。
この図で、チームA・B・Cが非同期で連携してたら、もう世も末状態です。
チェックのタイミング
私のオススメは、スプリント計画（プランニング） や、バックログリファインメントの場です。
チェック方法
①. バリューストリームマップ（VSM）とイベントストーミング（ES）の成果物（物理的な壁やMiroなどのデジタルボード）を並べます。
②. 新しいユーザーストーリーやエピック（ソフトウェアに実装する機能の最も大きな単位）
を取り上げた際、
「このストーリーは、VSM上のどのステージに貢献するのか？」
「そして、それを実現するES上のコンテキスト（担当チーム）はどこか？」を 常にモデルを見ながらの対話で確認 します。
③. もし、VSMの１つのバリューステージがESの複数のコンテキストにまたがりすぎていることが判明したら、それは
・アーキテクチャ（コンテキスト境界）を見直すか
・チームの責任範囲を再編成する（コンウェイの法則の逆利用）べき
だという強力なシグナルです。なので、その場で即座に修正しましょう。
2. 定量的なチェック：運用時の一貫性検証
「バリューメトリクスを用いた定量的な振り返り」
これが設計時の「仮説」が、運用時の「現実」と一致しているかを検証する、データ駆動型のアプローチです。
バリューメトリクスとは？
バリューストリームの各ステージが、どれだけ速く、どれだけ詰まらずに価値を流せているかを測る指標で、具体的には以下のようなものがあります。
・リードタイム：VSMのステージ開始から終了までの実時間。
・プロセス時間：実際に作業していた時間。
・待ち時間：リードタイム – プロセス時間（＝価値の停滞）。
・フロー効率：プロセス時間 / リードタイム（＝流れのスムーズさ）。
（※もちろんこれ以外にも、バリューメトリクスはあります）
検証のタイミング
スプリントレビューや、四半期ごとのビジネスレビューが最適です。
検証方法
イベントストーミングの成果物（注文受付イベント、発送完了イベントなど）は、これらのメトリクスを計測するための 「計測ポイント」 そのものです。
①. そのため、必ず、各イベントのタイムスタンプを取得するようにシステムを設計します。
②. そして、そのタイムスタンプの事実をもとに、スプリントレビューで、開発チームとビジネスオーナーが一緒にダッシュボードを見ます。
③. その結果、以下のように
「我々は今スプリントで『決済』コンテキストの改善に注力した（設計・開発）。
その結果、VSM上の『決済』ステージの待ち時間が24時間から2時間に短縮された（定量的成果）。これは顧客価値に貢献している」
このように、開発チームの活動（ES） が、ビジネス上の価値（VSM） にどう貢献したかを、共通のメトリクスで議論することができるようになります。
🚨 一貫性が崩れたことを示すシグナル
「外観（VSM）」と「内部の構造（ES）」の一貫性が崩れると、システム（ビジネス）は必ず歪み、それが定量・定性の両方のシグナルとして現れます。
🗣️ 定性的シグナル
これらは、システムに関わる人々が「何かがおかしい」と感じていることを示す、主観的ですが強力なシグナルです。
①. 顧客からのクレーム
・シグナル
「注文したのに、確認メールが届かない」「ステータスがずっと『処理中』のままだ」といった問い合わせが多発する。
・判断
顧客が期待する価値の流れ（VSMで定義されているはず）と、システムが実際に提供しているプロセス（ES）の間に、致命的なギャップが存在することを示します。
②. ビジネス部門からの不満の声
・シグナル
「新しい割引ルールを追加したいだけなのに、なぜ3ヶ月もかかるんだ？」とビジネスサイドのステークホルダーが不満を漏らす。
・判断
VSM上の「価格設定」という価値領域が、ES上（内部構造）では複数のドメインにまたがる複雑なスパゲッティコードになっており、変更が困難であることを示します。
これは、明らかに価値（VSM）と構造（ES）の境界が一致していません。
③. 開発チームの混乱
・シグナル
「『返品処理』は、結局どのチームの責任なんですか？」
「この変更は、結局どのドメインにまで影響しますか？」
といった会話が開発チーム内で頻発するようになります。
・判断
VSMで定義された「返品」という価値の単位と、ESで描かれたコンテキスト境界（チームの責任境界）が不一致を起こしている明確な証拠です。
📉 定量的シグナル
一貫性が崩れている場合、たとえば「開発チームはずっと忙しくしている（ES）のに、顧客への価値提供リードタイム（VSM）が全く短縮されていない」といった恐ろしい事実が、定量的データによって明らかになります。
これらは、システムが期待通りに価値を流せていないことを示す、測定可能な「動かぬ証拠」です。
①. リードタイム / サイクルタイムの悪化
・シグナル
VSMで「注文から発送まで24時間以内」と定義（期待）しているのに、監視データ（注文受付イベントの時刻と発送完了イベントの時刻の差）が平均72時間かかっている（現実）。
・判断
これは、VSM（期待する価値）とES（現実のプロセス）が一致していない最も明確なシグナルです。
内部プロセス（ES）のどこかに、想定外の「詰まり」や「待ち」が発生していることを示します。
②. フロー効率の低下 (高い「待ち時間」)
・シグナル
イベントのタイムスタンプを分析すると、決済承認イベントから発送指示イベントまでの間に、平均8時間の「待ち時間」が発生している。
・判断
VSMではスムーズな「流れ」を想定していても、ESで描かれた内部構造が、実際にはバッチ処理や手動承認といったダムになっていることを示します。
つまり、そこで価値の流れが止まっています。
③. 特定ステップでの高いエラーレート / 再実行率
・シグナル
VSM上の「決済」ステップに対応する、ES上の決済実行ポリシーやPaymentGateway連携部分で、エラーレートが5%を超えている。
・判断
顧客の価値の旅（VSM）が、特定の内部プロセス（ES）の脆さによって、頻繁に中断させられていることを示します。
アラートの仕組み
もしも、ビジネスサイドと、イベントストーミングを一緒にできない場合には、必ずこのアラートの仕組みを用意しておきましょう。
これらのシグナルを検知した時こそ、バリューストリームマップとイベントストーミングの成果物を並べて見比べ、「我々の設計図は、現実の価値提供とズレていないか？」と問い直す絶好の機会となります。
まとめ
バリューステージの単位と、イベントストーミング中の各コンテキスト境界の粒度は必ず一致するように設計する重要性を描いてきました。
これは、VSM → ESというトップダウンアプローチ だけでなく、ES → VSMというボトムアップアプローチ の両方の反復活動が重要です。
最初は定量的なデータをそろえるのに、どうしてもコストが足りないという時には、
上記に書いたような定性的データのみからでもいいので、継続的に
「いま、VSMとESの成果物モデルは、本当に一貫しているのだろうか？」
と批判的になって、チェックしてみましょう。
この継続的な地味な作業が、負債を膨れ上がらせる前に回収するための重要な活動です。