要求抽出において、
アジャイル界隈で使われるユーザーストーリー(マッピング)とDtoD、
アジャイルでなくても使われるシナリオ
マーケティングから来たカスタマージャーニー
慶応SDMの本で男の人同士で抱き合っていたストーリーテリング
なんかを、独断と偏見でまとめてみる。
■まずは、シナリオやストーリーテーリング
要求抽出する場合、
誰が(どんな役割の人が)どんな業務(ユースケース)に関わってる?
と、ユースケースで業務を抽出し、
その業務の手順をアクティビティ(図)にまで落とすということが考えられる。
ただ、この場合、抽象的に物事が進められてしまうので、具体的にストーリーを
追っていくと、抜けていたり、「あっ違う!」というケースがある。
そこで、(製品ならプロトタイプだけど、サービスだと目に見えないので)
具体化して、実際に流れを追っていく、「シナリオ」や「ストーリーテーリング」
がある
シナリオは、具体的に場面設定・登場人物設定をして、時系列に操作内容などを
追っていく。
ストーリーテリングも、(男の人同士が抱き合って箱を持つのが目的ではなく・・
・慶応SDMの本を持っていない人には意味通じないと思うけど)ストーリーの
スタートからエンドまでを実演して、内容を確認する。
どちらも、最初から最後まで具体的に追ってみるというところはおなじで
違いはシナリオは自然文で書き、ストーリーテリングは実演するところといえる。
■ユーザーストーリーとユーザーストーリーマッピング
アジャイル界隈だと、ユーザーストーリーとユーザーストーリーマッピングが
この辺の操作に該当する。
ユーザーストーリーマッピングを学ぶときに読むべきスライド3選
http://hosukepoi.hatenablog.com/entry/2013/05/30/222338
にその辺のことが書いているので、まあ、ここから引用しちゃいましょう。
(引用は太字箇所)
ユーザーストーリーとは?
ユーザーストーリーとは、顧客の視点からサービスや商品の要件を記述したものです。
書くときは
<役割>として
<機能や性能>が出来る。
それは<ビジネス価値>のためだ。
という風に書きます。
役割がアクターで、「機能や性能ができる」点はユースケースに近いものがある
(もうちょっと真面目に言うと「機能や性能ができ」ているというのが、ゴール、
そのゴールの達成手段として、こういう機能があるというのが、ユースケース)
が、それの目的であるビジネス価値が書かれている点がユースケースと違う
(ユースケースは実行したらどんな価値を生み出すのかというゴールは分からない)
また、ユースケースのアクターはシステム境界に属する「ユーザー」で書くもの?だが、
ユーザーストーリーの場合は、結果を受け取る「エンドユーザー」で書くことが多いかも?
なお、ユーザーストーリーのほうが細かいという指摘もあるが、
いや、それはユースケースだって、細かく書ければ、いくらでもかけるよと反論されたら
おしまいなので、そこはめんど~くさいから突かないこととする(本質的にはゴールと
ユースケースの違いが有る)
そして
上のようなユーザーストーリーを時系列順に挙げていき、さらに優先度付けをおこなうことで、サービス・商品が満たすべき要件仕様を整理し、全体像をチーム全員で共有するためのツール
がユーザーストーリーマッピング。
ということは、ユーザーストーリーマッピングはシナリオと同じ・・・?となってくるけど、
ユーザーの時間軸でならべるという点では同じだが、
ユーザーストーリーマップは、優先度も考慮して並べる
シナリオは、もっと具体化して、ヌケや考え方の違いをチェックする。
という点でちがう。
もっと、利用局面的に言うと
ユーザーストーリーマップは、
アジャイル開発におけるプロダクトバックログをどうするかの話
シナリオは、
要求獲得(一小工程前工程*)における要求の意識合わせの話
で場面が違う
(*一小工程前工程:要求分析は
要求獲得→狭義の?要求分析(矛盾、曖昧さ排除、優先順位付け)→仕様化(可視化)→検証
とすすむ。ユーザーストーリーマップは要求分析の優先順位、ユーザーストーリーやシナリオは要求獲得場面)
■カスタマージャーニーマップ
ユーザーストーリーマップでは、じゃあ、ユーザーはどう感じるのか?がわからない。
シナリオやは、普通、感情は書かない・・・10人10色だから、かけない
その点、ストーリーテリングは体感できるけど、他人には分からない
(箱をもって、男の人同士で抱き合うと、どういう気持ちか他者にはわからない-くどいって ^^;)
そこで、カスタマージャーニーマップ。
これは、シナリオ+そのときの感情を表現する
(感情表現してれば、カスタマージャーニーマップって言うみたい。ちょっとぐらい違っても)
有名なのは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
にちょっと載っている
発見から納品へ:アジャイルなプロダクトの計画策定と分析
っていう本にでているらしい。
流れとしては、ユーザーエクスペリエンスマップと同じような感じ
ユーザー、インタラクション、なんだったっけか(ポスターにはあった)
・・・終わりから2つ目が環境みたいなかんじで、
いくつかのフェーズにわかれて、それを段階ごとに検討し、まとめていく。
これって、
ユーザー→システム境界→・・・データ(って、どこかにあった)のように
内部へと分析していくので、表層部分を見ればシナリオ、ユーザーストーリー
データ部分を見ればER図などと、いろいろな図に展開できる。
ただ、感情とか、ゴール(→意図)というニュアンスはない気がする。
感情に関しては、上記のカスタマージャーニーマップは表現している。
ただ、カスタマージャーニーマップはユーザーの表層的な分析の為、
DtoDのようなデータ分析を行わない。
意図とかになると、ゴール指向分析(とくにKAOS)になるけど、疲れたので、
このへんでやめる。
ざっくり感でみると、こんなかんじ