動機・背景について考えるジョブストーリーとは? プロダクト構築の新たな手法

Source

プロダクトデザイナー、エンジニア。

ユーザーストーリー
○○(ユーザーのタイプ)として、○○(行為)をしたい。そうすれば○○(結果)できるからだ。

以前、私はユーザーストーリーの問題点について記事を書き「ユーザーストーリー」を書くより、プロダクトの変更案をチーム内で話し合う方が効果的だと述べた。

現在は、私は新しいチームで最初の段階からプロダクトを構築しているのだが、この場合はチームが白紙の状態であるため、顧客の動機、出来事、予測などについての共通認識が異なり、問題が生じてしまう。

そこで、要点を定義する時に非常に役立つ「jobs to be done(片づけるべき仕事)」の哲学を取り入れたジョブ・ストーリーという方法を思いついたのでご紹介したい。

発想の源

ジョブストーリー
○○の場合、○○をしたい。そうすれば○○できるからだ。

私たちは、あるジョブにおける全ての設計上の問題について、引き金となった出来事や状況、動機や目的、意図する結果に焦点を置いて書き出している。

例を挙げよう。新規で重要顧客が契約した場合、その知らせを受けたい。そうすれば、新規の重要顧客との対話を始められるからだ。

なぜこの方法が好ましく、ユーザーストーリーより優れているのか、について述べようと思う。

ユーザーストーリーの問題点について

ユーザーストーリーの問題点を要約すると、仮定が多すぎて因果関係が分からないということだ。ユーザーストーリーの定型文(○○(ユーザーのタイプ)として、○○(行為)をしたい。そうすれば○○(結果)できるからだ。)にタスクを当てはめると、そこには”なぜ”と尋ねる余地がない。これでは、背景の分からないシーケンスの中で身動きが取れなくなってしまう。

私は、ユーザーストーリーを下の図のように考えている。


ペルソナと行為の間における仮定と分離性

ユーザーストーリーの最初の問題点は、まずペルソナありきで(これが本当に良くないのだが)、それから期待する結果を得るために必要と思われる行為を落とし込むというところだ。上の図で示した通り、行為とペルソナの間に因果関係は全くない。
ここで、実際のユーザーストーリーをいくつか見てみよう。


ユーザーストーリーの書き方の例

上の表を読む時、調整者や見積もり者というのは、本当に何か意味を加えてくれるのだろうか? もし、流れがあいまいになってしまうのであれば、調整者とは何か、なぜこの背景の中で登場するのかといった説明を添えるはずだ。

つまり、○○としての部分を削除しても意味が損なわれないのだ。

ジョブストーリー = 背景と因果関係


ジョブストーリーの定型文

では、上の図を見てほしい。これこそが効果的な方法なのだ!

ここに書かれている情報は、全て重要でとても有益だ。なぜなら因果関係に焦点を当てているからだ。ジョブストーリーでは、1つ1つのストーリーに可能な限り多くの背景を与え、実装だけでなく動機に注目しなければいけない。

では、上のユーザーストーリーの表の書かれたいくつかの例をジョブストーリーで書き直し、それぞれに動機と背景を加えてみよう。

ユーザーストーリー
調整者として、名前とオプションの記述を入力することで新しいゲームを作りたい。そうすれば、見積者を招待できるようになるからだ。

ジョブストーリー
私のゲームを入札に出す準備ができた場合、見積者が理解できるフォーマットでゲームを作りたい。そうすれば、見積者が私のゲームを見つけ、どんなプロダクトに入札しようとしているかを知ることができるからだ。 

ユーザーストーリー
見積者として、現在、見積もり中のアイテムを見たい。そうすれば、何について見積もっているかが分かるからだ。

ジョブストーリー
入札したいアイテムを見つけた場合、それを見たい。そうすれば、見積もりをしているアイテムが本当に考えている通りの物か確認できるからだ。

ユーザーストーリー
調整者として、見積もり、または再見積もりをするアイテムを選びたい。そうすれば、チームがアイテムを見て、見積もりをできるからだ。

ジョブストーリー
アイテムに値がつかない、またはついた値に満足できない場合、見積もり過程が再開することをみんなに知らせたい。そうすれば、あるアイテムの見積もりする必要があるとチームが分かるからだ。

複数の役割や出来事は、どのように扱えばいいか?
2014年7月28日追記
ジョブストーリーに関する素晴らしいフィードバックを受け、引き続きジョブストーリーを使って仕事をしていると、役割、またはキャラクターを「○○の場合」の一部に含ませると、とても役に立つことがある。

複数の役割が関わるプロダクト
役割またはキャラクターは、プロダクトに関わる役割が複数ある場合に使うと最も力を発揮する。例えばIT関連プロダクト(アドミニ、マネージャ、コントリビュータなど)やマーケットプレイスのプロダクト(販売者と購入者)などが挙げられる。理由は単純で、誰について話しているのかを明らかにするためだ。

eBayを例とした場合
ある購入者があるアイテムに入札した場合、対抗買いに気が付かず取りこぼさないか心配なので、対抗買いがあった時は即座に知らせを受けたい。そうすれば、入札額を評価し、更新するために充分な時間をかけることができるからだ。

原因や影響に関わる役割
時折、原因と影響のシナリオが設定され、ジョブストーリーが一度に複数の役割に影響を与える状況がある。

再びeBayを例とした場合
販売者が入札額に納得できず、プロダクトを市場から取り下げる場合、既に入札額を提示した購入者はプロダクトが撤退したことを即座に知りたい。そうすれば、それ以降、購入者はそのプロダクトの状況を監視する必要がなくなり、別の似たプロダクトを代わりに探すことができるからだ。

役割の代わりに出来事を使う
しかし、出来事が全ての役割や役割グループに影響を与える場合もあるだろう。例えばパスワードリマインダを得なければならない場合が挙げられる。この場合、特別な役割を当てはめる必要はない。顧客やある人といった用語を使って(ユーザという言葉は使いません)、出来事が基盤となる一般的な事象になるようにしよう。

顧客が携帯端末の使用中にパスワードを忘れた場合、携帯端末を使った簡単な方法でパスワードを再度手に入れたい。そうすれば、ログイン状態を維持したままニュースフィードにアクセスできるからだ。

なぜユーザーという言葉を使わないのか? ユーザーという言葉には生活感がなく感情移入が難しいからだ。しかし、代わりに顧客という言葉を使えば、奉仕し敬意を示す必要がある相手だと思いださせてくれる。

動機を定義し、実装を強調しない

ジョブストーリーは、動機、背景について考えさせてくれ、個々の実装をそこまで強調しない素晴らしい方法だ。なぜなら、人々は誰がどのように、という事に注目しがちで、なぜという点が完全に抜けてしまうことが多いからだ。なぜという点を理解することから始められれば、問題を解決するために創造的で独創的な方法を受け入れることができる。