なぜユーザーストーリーによる要件定義にピンとこなかったのか

最近、システム企画や要件定義フェーズで、ユーザーストーリーを使う手法が多い。
ユーザーストーリーマッピング、カスタマー・ジャーニー・マップナラティブアーク、別名、ストーリーマッピングなど。
内容に詳しくないと、どれも似たような内容じゃないの、とか思ってしまう。

アジャイル開発の要件定義では、ユーザーストーリーをよく強調されるが、どうしても納得感がなかった。
最近、ストーリーテリングに関する本をいくつか読んでみて、ユーザーストーリーはなぜ要件定義で必要になったのか、自分なりに考えるところがあった。
ラフなメモ書き。

【参考１】
何のために作るのかを考えながら作ることについて考えたこと?「ユーザーストーリーマッピング」感想 - Qiita

ユーザーストーリーマッピングについて - ryotaku's Tech Blog

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

「ストーリーマッピングをはじめよう」を読んだ : void chachaki::Blog::main()

人材育成コラム -- ITスキル研究フォーラム(iSRF／アイサーフ)

【読んだ本】ストーリーマッピングをはじめよう／ドナ・リシャウ｜クリタトオル｜note

「ストーリーマッピングをはじめよう」を読んだ | けんちゃんくんさんのWeb日記

【参考３】
UXデザインで使いたい「３つのストーリー」、UXにクライマックスをつくってみよう | 起業tv

ユーザーの心に響く体験の「物語」を創りだす、ストーリーマッピング | ツナググループ・イノベーションズ

【参考４】
カスタマージャーニーマップとは？ UX向上を達成する7つの事例と作成方法 | 実践！ プロも使うラピッドUX手法 | Web担当者Forum

【1】なぜ、ユーザーストーリーはシステム企画や要件定義で必要になったのか？

システムを利用するユーザはITに詳しくないから、ストーリーという物語形式で伝える必要があるから。
顧客から、システムの要件や仕様を引き出す為のツールの一つとして、ストーリーという物語形式が有効だから。

たとえば、カスタマー・ジャーニー・マップでは、Webサービスを利用する顧客との接点（チャネル）が最近はWeb、SNS、商店など複雑に絡み合っている為、O2Oの動線として扱い、顧客体験による顧客価値、顧客心理、顧客行動の分析に使う。
その時に、物語形式で語ってもらう。

たとえば、ユーザーストーリーマッピングでは、プロダクトバックログに溜まったシステム要件を表したユーザーストーリーを元に、横軸にユーザ行動の時系列や処理ステップ、縦軸に実装すべき優先順位の表に、ユーザーストーリーをプロットする。
横軸に優先順位度別にスライスして、優先順位が最も高いユーザーストーリーがMVP、つまり、顧客に提供すべき最低限の機能を満たした新製品になる。

よって、ITに詳しくないユーザから要求をユーザーストーリーで引き出し、それらを抽出してプロダクトバックログにまとめた後、ユーザーストーリーマッピングに当てはめれば、自然にリリース計画が定まることになる。

従来のアジャイル開発では、システム要件や仕様を収集してまとめる手法が正直なかった。
だから、とても苦労していた。
そこで、ユーザーストーリーをキーとして、ITに詳しくないユーザと開発者が深く会話できる基盤が揃う。

【2】では、僕は、なぜユーザーストーリーによる要件定義にピンとこなかったのか？

ユーザーストーリーがアジャイル開発の要件定義で重要なツールであり重要な概念なのに、僕はどうしても腑に落ちなかった。
ストーリーという概念が、小説や映画みたいな適当なラフなモノみたいに思えて、到底、システムやプログラムという硬い箱に収まるようには思えなかったから。

実際、ダラダラとした小説や映画を見ても、システムなんて連想できない。
ふりかえれば、僕は現代文が大の苦手だった。
小論文はまだしも、随筆や小説みたいに、執筆者の思いや考え方を推測しろ、と言われても、身近な友人や家族すら完全に理解できないのに、赤の他人の気持ちがすぐに分かるのか？
現代文のテストでは、出題者の意図を分かりなさい、というが、教師の気持ちすら分からないのに、理解できるのか？
ストーリーにはそんな反発があったかもしれない。

最近、「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」を読む機会があった。
小説を書きたいのではなく、アウトラインによる執筆方法を調べていた時に見つけた本なのだが、内容はまさに、欧米の脚本家が映画や小説をどのように物語として構成すべきか、という考え方、手法が述べられていた。
いわゆる、脚本は三幕形式による構成、物語の基本構造は英雄伝説なのだ、という主張なわけだが、僕としては、ストーリーはこれだけ構造化されているものなのか、とすごく参考になったし、ようやく腑に落ちた経験をした。

【3】以前、「言語技術トレーニング」という本も読んでいた。

「大学生・社会人のための言語技術トレーニング」の感想: プログラマの思索

英語の考え方と学習方法: プログラマの思索

「言語技術トレーニング」の一節には、こんな事が書かれていた。

バーバラ・ミントの「考える技術・書く技術」はロジカルシンキングの原本として有名だが、「プレゼンテーションの導入部は常にストーリー形式を取ります」と書かれている。
この意味は、物語の構造を理解すれば、自分で物語の形式を用いて説明したり、スピーチしたり、プレゼンテーションを組み立てるスキルに応用できるよ、ということだ、と。
なぜなら、物語は古今東西に関わらず同じ形式であり、世界中の誰もが馴染みやい形式だから、と。

また、「言語技術トレーニング」の一節には、こんな事も書かれていた。

バーバラ・ミントの「考える技術・書く技術」では、「古典的なストーリー展開、状況→複雑化→疑問→答えによって、書き手と読み手が同じ立場に立ち、そこで初めて、読み手を書き手の考え方に沿って導ける」と書かれている。
しかし、古典的なストーリー展開の説明は、バーバラ・ミントの「考える技術・書く技術」に一切ない。
なぜなら、欧米人にとって、古典的なストーリー展開、つまり、物語の構造とは、小学校で習うべき基礎知識だからだ、と「言語技術トレーニング」の著者は言う。

「言語技術トレーニング」では、物語の形式は、いわゆる英雄伝説、冒頭→発端→山場→頂点（クライマックス）→結末という流れで説明してくれている。
ちなみに、「ナラティブアーク」あるいは「ストーリーマッピング」に相当すると思う。
実際、物語は時系列に出来事をプロットして、その緊張度合いが逆U字型の曲線で描かれる。

一方、日本の学校教育で僕は、物語の構造を「状況→複雑化→疑問→答え」という形式で教えてもらって習った、という記憶はない。
たぶん、今もないだろう。
つまり、ストーリーという言葉に違和感があるのは、ストーリーの基本構造を今まで習得してなかったから、その重要性を体の底から理解できていなかったから。

【4】そんな状況で、偶然にも、小説分析ツールyWriterなるソフトを見つけて、色々知ることができた。
yWriterを使って、実際の小説を分析してみたら、なるほど、小説はストーリーの集合体であり、各ストーリーは構造を持ち、役割があるのだ、と気づくことができた。

ブレンミコミコポ　yWriterの使い方

ブレンミコミコポ　yWriter for Androidの使い方

BCCKS / ブックス - 『yWriterで物語を書こう』神楽坂らせん著

yWriterの体験を後で書く。
yWriterのおかげで、僕はユーザーストーリーの考え方を理解できたような気がした。