EventStorming and Narrative
ということで、スライドがあまりにも薄いため補足を残しておくエントリです。
EventStormingと開発者の関係
書籍「Introducing EventStorming」を読んでいると、次のことに対して重きが置かれているように思います。
- 協同的な探求を通して知識のサイロ化を防ぐこと
- 開発者がドメインを学ぶこと
しきりに "Learning" という言葉が使われ、ドメインを学ぶ姿勢の重要さがより良いソフトウェア開発へのインプットとなることを感じさせます。
EventStormingでは、関係者を一堂に集めて知識の移転や問題の可視化をはかります。 ビジネスサイド、開発サイドという垣根を取り払って協同的に取り組むことで、全体最適の道を探ることになります。 また、開発者は学んだ知識をもってより適切な解決モデルの提案につなげることができるでしょう。
Narrativeで探求
ドメインのある一部を切り取ってみても部分最適にしかなりません。 かといって、全体すべてにリソースを分配するわけにもいきません。 コアとなるNarrativeを見つけ出して、そこに注力することを目指します*1。
ある断面だけではなく、始まりから終わりまでの流れを捉えることで、その改善がゴールへのパフォーマンスに貢献すると自信をもつことができます。 ソフトウェア開発の場面だけをみても、全体像を把握せずに設計を行うことは難しいでしょう。 流れを押さえることは何事でも基本に思えます。
また、物事の関係性でみていくと、思わぬ発見をすることがあります。 エキスパートといえども（多くの場合）沢山の知らないことがあります。 知見を持ち寄る、ということは人が獲得した知恵です。
Story vs Narrative
参考: Story vs. Narrative - Beemgee
Narrativeは、広義の意味でのストーリーとして機能します。 Narrativeは時間順に並んでいるのではなく、イベントの関係性で並んでいるため、順序を入れ替える余地があります。
ここには重要な示唆があるように思えます。 物事の連なりが可視化されることで、当たり前に思っていたことに対して疑問を投げかける契機となります。 イベントさえ論理的につながれば（つまり、後ろのゴールから順に辿ることさえできれば）ストーリーとして意味を持つのですから。
パースペクティブ設定の大事さ
EventStormingに取り組むなら、
- 今明らかにしたい事柄は？
- 私達は何のために集まっている？
ということを先に整理し、参加者の間で合意しておく方が効率的に思います。 会議を始める前にゴール設定が不可欠なように、事前準備はEventStormingに取り組むにあたっても有効なように思います。
ただし、手探り状態でワークショップに挑むこともあるかもしれません。 このときは、一度思っていることを吐き出すことに振り切った方が良いでしょう。 そのためのStormingであり、最終的に整理され、気付きが得られれば良いのです。
機能の話のその前に
私たち開発者はついうっかりソフトウェアデザインレベルから物事を考えがちではないでしょうか。 Big Pictureで考えようとしているところに、ある特定の機能の話をしだすとイベントが思ったように繋がりません*2。
- 目指したいゴールであるか
- ゴールからスタート地点に向かって辿ることができるか
を適宜確認しながら進むことが重要です。 イベントをゴールから辿ることで検証となる点は大きな利点です。 Big Pictureに合意ができたら、Processを考え、そこからSoftwareを考えて、と目線を下げていくことで、その逆を辿ればBig Pictureのゴールに貢献するかを確認できるようになると考えられます。
トッピングは自由！
書籍のなかでも「Notationを厳格にすること」がアンチパターンとしてあげられています。
ワークショップを完了することよりも、学ぶことの方が重要です。 「ビジネスゴールに至るために何が必要なのか」に主眼を置けば、基本のNotationに囚われる必要もないことが分かります。 これは書き留めておきたいよね、これは私達にとって重要だ、という関心を捉えて可視化することに制限は不要です*3。
イベントをNarrativeとして可視化することが基本にあるだけなのです。
