要求抽出において、
アジャイル界隈で使われるユーザーストーリー（マッピング）とDtoD、
アジャイルでなくても使われるシナリオ
マーケティングから来たカスタマージャーニー
慶応SDMの本で男の人同士で抱き合っていたストーリーテリング
なんかを、独断と偏見でまとめてみる。
■まずは、シナリオやストーリーテーリング
要求抽出する場合、
誰が（どんな役割の人が）どんな業務（ユースケース）に関わってる？
と、ユースケースで業務を抽出し、
その業務の手順をアクティビティ（図）にまで落とすということが考えられる。
ただ、この場合、抽象的に物事が進められてしまうので、具体的にストーリーを
追っていくと、抜けていたり、「あっ違う！」というケースがある。
そこで、（製品ならプロトタイプだけど、サービスだと目に見えないので）
具体化して、実際に流れを追っていく、「シナリオ」や「ストーリーテーリング」
がある
シナリオは、具体的に場面設定・登場人物設定をして、時系列に操作内容などを
追っていく。
ストーリーテリングも、（男の人同士が抱き合って箱を持つのが目的ではなく・・
・
慶応SDMの本を持っていない人には意味通じないと思うけど）ストーリーの
スタートからエンドまでを実演して、内容を確認する。
どちらも、最初から最後まで具体的に追ってみるというところはおなじで
違いはシナリオは自然文で書き、ストーリーテリングは実演するところといえる。
■ユーザーストーリーとユーザーストーリーマッピング
アジャイル界隈だと、ユーザーストーリーとユーザーストーリーマッピングが
この辺の操作に該当する。
ユーザーストーリーマッピングを学ぶときに読むべきスライド3選
http://hosukepoi.hatenablog.com/entry/2013/05/30/222338
にその辺のことが書いているので、まあ、ここから引用しちゃいましょう。
（引用は太字箇所）
ユーザーストーリーとは？
ユーザーストーリーとは、顧客の視点からサービスや商品の要件を記述したものです。
書くときは
＜役割＞として
＜機能や性能＞が出来る。
それは＜ビジネス価値＞のためだ。
という風に書きます。
役割がアクターで、「機能や性能ができる」点はユースケースに近いものがある
（もうちょっと真面目に言うと「機能や性能ができ」ているというのが、ゴール、
そのゴールの達成手段として、こういう機能があるというのが、ユースケース）
が、それの目的であるビジネス価値が書かれている点がユースケースと違う
（ユースケースは実行したらどんな価値を生み出すのかというゴールは分からない）
また、ユースケースのアクターはシステム境界に属する「ユーザー」で書くもの？だが、
ユーザーストーリーの場合は、結果を受け取る「エンドユーザー」で書くことが多いかも？
なお、
ユーザーストーリーのほうが細かいという指摘もあるが、
いや、それはユースケースだって、細かく書ければ、いくらでもかけるよと反論されたら
おしまいなので、そこはめんど～くさいから突かないこととする（本質的にはゴールと
ユースケースの違いが有る）
そして
上のようなユーザーストーリーを時系列順に挙げていき、さらに優先度付けをおこなうことで、サービス・商品が満たすべき要件仕様を整理し、全体像をチーム全員で共有するためのツール
が
ユーザーストーリーマッピング。
ということは、ユーザーストーリーマッピングはシナリオと同じ・・・？となってくるけど、
ユーザーの時間軸でならべるという点では同じだが、
ユーザーストーリーマップは、優先度も考慮して並べる
シナリオは、もっと具体化して、ヌケや考え方の違いをチェックする。
という点でちがう。
もっと、利用局面的に言うと
ユーザーストーリーマップは、
アジャイル開発におけるプロダクトバックログをどうするかの話
シナリオは、
要求獲得（一小工程前工程＊）における要求の意識合わせの話
で場面が違う
（＊一小工程前工程：要求分析は
要求獲得→狭義の？要求分析（矛盾、曖昧さ排除、優先順位付け）→仕様化（可視化）→検証
とすすむ。ユーザーストーリーマップは要求分析の優先順位、ユーザーストーリーやシナリオは要求獲得場面）
■カスタマージャーニーマップ
ユーザーストーリーマップでは、じゃあ、ユーザーはどう感じるのか？がわからない。
シナリオやは、普通、感情は書かない・・・１０人１０色だから、かけない
その点、ストーリーテリングは体感できるけど、他人には分からない
（箱をもって、男の人同士で抱き合うと、どういう気持ちか他者にはわからない－くどいって ＾＾；）
そこで、カスタマージャーニーマップ。
これは、シナリオ＋そのときの感情を表現する
（感情表現してれば、カスタマージャーニーマップって言うみたい。ちょっとぐらい違っても）
有名なのはMONA
https://suedesign4.files.wordpress.com/2011/03/customer-exp-map.jpgより引用
ここに至る過程は
https://suedesign4.wordpress.com/deliverables/task-3/参照。
上の段の「サービスエクスペリエンス」では（下から見てね）
ユーザーが、どのようなもの(object)を使って、インターアクションし、
その場面（環境）はどうで、どんな行動（アクティビティ）をする
というシナリオがまとめられている
その上で、そのアクティビティに対してどんなことが期待され、感情がどう変化するか
折れ線グラフで下に書いてある。
日本語で詳しく見たい場合は、このサイト
カスタマージャーニーマップについての簡単なまとめ
http://u-site.jp/weblog/customer-journey-map
ちなみに、上記サイトはペルソナごとに作っている。
ユーザーごと（ペルソナごと）に作ったほうが、うまくいく
（ペルソナごとに感情が違うから）
■DtoD(Discover To Deliver)
SES2015で、DtoDというのが出ていたので、それをちょっと見した.
（今確認したけどSES2015の予講集にはないので、論文なしポスターかしら）
ちなみに、DtoDは
http://www.ogis-ri.co.jp/learning/1227855_6722.html
にちょっと載っている
発見から納品へ：アジャイルなプロダクトの計画策定と分析
っていう本にでているらしい。
流れとしては、ユーザーエクスペリエンスマップと同じような感じ
ユーザー、インタラクション、なんだったっけか（ポスターにはあった）
・・・終わりから２つ目が環境みたいなかんじで、
いくつかのフェーズにわかれて、それを段階ごとに検討し、まとめていく。
これって、
ユーザー→システム境界→・・・データ（って、どこかにあった）のように
内部へと分析していくので、表層部分を見ればシナリオ、ユーザーストーリー
データ部分を見ればER図などと、いろいろな図に展開できる。
ただ、感情とか、ゴール（→意図）というニュアンスはない気がする。
感情に関しては、上記のカスタマージャーニーマップは表現している。
ただ、カスタマージャーニーマップはユーザーの表層的な分析の為、
DtoDのようなデータ分析を行わない。
意図とかになると、ゴール指向分析（とくにKAOS)になるけど、疲れたので、
このへんでやめる。
ざっくり感でみると、こんなかんじ
アクセス
トータル
ランキング
