「ストーリーマッピングをはじめよう」本の感想～ストーリーによる企画や要件定義はSaaSと相性がいい

「ストーリーマッピングをはじめよう」本を読んで良かったのでラフなメモ。

【参考】
なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

あなたが開発しているプロダクトにストーリーはあるか。クリフハンガーに陥らないための作戦がここにある。 - The Dragon Scroll

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

yWriterは映画の脚本を作るためのアプリだったのではないか: プログラマの思索

【0】「ストーリーマッピングをはじめよう」本の感想は3つある。

1つ目は、ユーザーストーリーで物語を可視化できる。
システム要件を物語として構造化できる。

物語は三幕構成というロジカルな構成を持つ。
アリストテレスが古代ギリシャ悲劇を理論化して、何千年もの歴史がある。
世界中の誰もが馴染みやすい。

そもそも、人間の認知のメカニズムは、ストーリーになる。
人間は、事象を、物語を介して理解している。
たとえば、旅行、映画、体験談。
たとえば、内視鏡検査が痛かった体験談すら、ストーリーで家族に語る。

2つ目は、ストーリーはSaaSと相性が抜群に良い。
ストーリーに合わせて顧客を呼び込んで、顧客行動をWebの画面遷移のWebログで計測できる。
導線のクリフハンガーを特定できる。

ストーリーの効果をKPIで評価できる。
SaaSのKPIなら、AARRRを思い出す。

AARRRとは?サービスを成長させるための基本戦略【テンプレート付】｜ferret

つまり、購入率、CVR、成約率というKPIでストーリーの効果を評価できる。

3つ目は、課題解決に適用できる。
現状→問題→葛藤→目的達成→解決、という課題解決の流れは、古典的なストーリーの構造である、状況設定→複雑化→問題→解決と全く同じ。

課題解決には3種類のストーリーで使い分ける。
コンセプトストーリーで、新製品・新規機能をアピールする。
次に、潜在顧客に、オリジンストーリーでメッセージを伝える。
さらに、具体的な利用シーンをユセージストーリーで説明して、末永く利用してもらう。

つまり、新製品のコンセプトを打ち出してユーザを惹きつけ、顧客接点となるWebログイン画面から、物語のようなWebの導線を張ってユーザ誘導して、おとぎ話に落とし込む。
それぞれの機能は、利用シーンに合わせたストーリーで一貫した目的があり、ユーザはそれに一喜一憂して、ハラハラ・ドキドキさせられる。
そういうSaaSを目指すわけだ。

【1】ストーリーマッピングの特徴は3つある。

1つ目は、ユーザー体験を物語の各場面にプロットポイントとしてマッピングすることで、ストーリー化してしまうこと。
物語はナラティブアークと言われる。
ナレーションみたいなものだろうか。

「ストーリーマッピングをはじめよう」に出てくるストーリーには、7つのプロットポイントがあり、時系列のグラフとしてマッピングされる。
プロットポイントは、状況説明→事件や問題の発生→盛り上げ→危機→クライマックス→オチ（落とし込み）→エンディング、という流れ。
三幕構成では、状況説明→事件や問題の発生が、始まり。
→盛り上げ→危機→クライマックスが中盤。
落とし込み→エンディングが終わり、に相当する。

ストーリーの構造は、「考える技術・書く技術」に出てくるプレゼンテーションのイントロの技術「状況→複雑化→疑問→答え」と全く同じ。
一方、ストーリーはこの7つのプロットポイントを明確に意識し、観客の感情を上下させるように場面設定を論理的に組み立てなければ、興ざめしてしまう。

各プロットポイントにも特徴がある。
事件発生では、Call To Action、つまり、行動を求める声となるイベントを置く。
ユーザが後戻りできないような事件を引き起こす。

物語では、クライマックスが大事。
クリフハンガーとは、上昇途中やクライマックスで唐突に終わるストーリー。
これは避けなければならない。

halfalogueとは、盛り上がるだけで、オチのないストーリー。
クライマックスやエンディングが半分だけなのでイライラする。
これは避けなければならない。

エンディングでは、続き物をわざと残す。
別の物語につなげるために。

【2】2つ目は「ストーリーマッピングをはじめよう」では、ストーリーは3種類ある。
「コンセプト・ストーリー」「オリジン・ストーリー」「ユセージ・ストーリー」の３つ。

【2-1】コンセプト・ストーリーとは、製品概念の物語。
Concept＝構造、全体像。
顧客が製品に感じる印象を元に、課題解決する。
新製品や新機能の開発に取り組む時に利用される。

例は、ジョブズがiPhoneを始めて紹介したプレゼン。
Slackというコミュニケーションツールを最初に紹介したプレゼン。

注意点は、平坦な展開は避ける。
物語を支える要件を見極める。

【2-2】オリジン・ストーリーとは、潜在顧客が初めて購入する物語。
Origin＝発端、起点。
製品概念を知った後で、製品を実際に使ってもらう。
よって、顧客のチャネルや顧客接点が重要になる。

目的は、新規客を獲得し、リピート客にConvertする。
顧客接点を起点にあの手この手で販促する。
物語はプロモーションかな。

マーケティング部、営業部、広報部が、オリジン・ストーリーを主体的に作る場合が多い。
つまり、技術部がメインではなく、潜在顧客をマーケティング部などがイメージして、ストーリーを作り出す。

注意点は、物語をどう終わらせるか？が大事。
物語をストーリーにマッピングできないと、クリフハンガーが発生し、せっかくの見込客が離れてしまう。
Webシステム上のユーザの導線を計測して、クリフハンガーを特定し、対策を取る。

どんなアフォーダンスをユーザに示すか？が大事。
つまり、Web画面上の手がかりをユーザに認知させること。
ストーリーの概念としては、Call To Actionが大事で、たとえば、ボタンという機能を作り込むのが大事。

【2-3】ユセージ・ストーリーとは、顧客がステップごとに製品を使っていく物語。
Usage＝利用、使い方。

プロットポイントごとにユーザの実行動がマッピングされる。
カスタマージャーニーを構造化したもの。

ユセージ・ストーリーには、長い旅もあれば短い旅もある。
大冒険型ストーリーなのか、連続ドラマ型ストーリーなのか。
物語のスケールを決めるのが大事。

Core Task（＝Item）が中心になる。

クリフハンガーを解決するストーリーがテーマになる。
物語を視覚化すると、クリフハンガーがはっきりする。

たとえば、初期のTwitterはユーザ同士がつながるだけで、その利用シーンをユーザはイメージできず、クリフハンガーが発生していた。
そこで、ツイートしてメリットが出るユセージ・ストーリーを作り、それをTwitterの導線で実現することで、現在の爆発的な利用につながった。

【2-4】3パターンのストーリーのいずれもターゲットである顧客行動をKPIで計測する。
具体的には、SaaSであれば、Webログからユーザのアクセス履歴は全て追跡できる。

目的は、ストーリーの効果を測定すること。
クリフハンガーを特定し、ストーリーとWebシステムのギャップを探し出し、Webシステムを改良していく。

これにより、購入率やCVR、成約率を向上できるし、顧客満足度を高めることもできる。

【3】3つ目は、ストーリーマッピングの技法は、経営戦略の分析・策定や行動方針にも適用できること。

「ストーリーマッピングをはじめよう」にはいくつか例がある。
ギャップ分析では、ストーリーを使って、クリフハンガーや平坦な物語と、ユーザや企業が目標にたどり着ける物語の差（ギャップ）をクリフハンガーとして視覚化する。

Webシステムや製品に対し、ユーザの行動分析にストーリーを使って、ユーザがどのように利用しているのか、クラスタリングみたいに複数のユーザの特徴を洗い出す。
それにより、製品の改良に役立てる。

要件評価では、バックエンドのシステム要件、フロントエンドのシステム要件をストーリーマッピングで視覚化し、ストーリーを評価する。

SWOT分析では、カスタマージャーニーや製品のSWOT分析をストーリーで語らせる。
ストーリーマッピングにより、物語の全体像が視覚化できる以外に、足りない所、機能していない所、可能性が眠っている所を明確にできる。

【4】「ストーリーマッピングをはじめよう」を読んで改めて思い浮かぶことは、なぜ、ストーリーが要件定義や企画フェーズで重要な役割を果たすのか？　という問題だ。

ストーリーは実はロジカルに構成できるから。
実際、ストーリーという物語形式は、アリストテレスの悲劇論の歴史から始める三幕構成というロジカルな形式で表現される。
普通の日本人が思うような起承転結みたいな浅はかな構成ではない、と思う。

プロット (物語) - Wikipedia

ストーリーは課題解決に適用できるから。
課題解決の構造は物語の構造と一致している。
現状とあるべきゴールに対し、ギャップが問題として発生し、その問題を解決する。
状況設定の後、主人公が達成すべき目的となるインサイト・イベントが発生し、苦難の旅を経て、目的を解決する。

ストーリーは顧客から要件を引き出せる。
ITに詳しくない発注側のユーザ、情報システム部門から、要件を引き出したり、要件を議論するには、ストーリーで語ると共通理解が捗る。

ストーリーはKPIで測定できる。
WebシステムのKPIはAARRRの他にもたくさんある。

要件定義されたストーリーは、プロダクトバックログ（PBL）に蓄積される。
PBLから実際のリリース計画にマッピングする時には、ユーザーストーリーマッピングの技法を使えば、時系列と優先順位の表にユーザーストーリーをマッピングできる。
よって、ユーザ体験を重視したストーリーを実現するために必要な機能要件は、ユーザーストーリーマッピングの表から、MVPとなる対象機能を抽出でき、開発チームは、スプリントの襦袢に実装していけばいい。

こういう流れを理解すると、ストーリーによる要件定義はSaaSととても相性が良い。
そして、SaaSはアジャイル開発にピッタリのシステムであり、ビジネスモデルでもある。

昨今、DXが日本企業でも流行しているが、僕は、DXとは、ソフトウェア開発のビジネスモデルを持たないレガシー企業が、既存事業をSaaSとして展開するための仕組みづくり、と理解している。
従来のようなレガシーな基幹システムの開発スタイル、要件定義の手法とは、全く違うやり方ではないか、と考える。

このストーリーによる要件定義手法については、今後も色々考えてみる。