こんにちは、Repro の八木です。
今回は機能開発のタイミングで、デザイナー・プロダクトマネージャーが一体となり、曖昧な要件を具体化していった例を残しておきたいと思います。
私たちが運営している「Repro」は顧客データを活用し、 メールやプッシュ通知、Webやアプリ内ポップアップなどのチャネルを横断した付加価値の高いコミュニケーションを実現するカスタマーエンゲージメントプラットフォームです。
今回のプロジェクトに取り組むタイミングでは、事業のロードマップはあったものの、それをプロダクトに落とし込むためにもう少し深掘りが必要な状況になっていました。
例えば
- 実際に使うユーザーが何に困っていて、なぜこの機能を使うのかが深掘りできていなかった
- なので、具体的にどのような機能にすればいいかがわかっていなかった
このような課題があり、このままではプロダクトの具体的な検討に入ることは出来ない段階でした。
私はその段階から、具体的な検討が可能な状態への落とし込みを行いました。
今回は、その際に「ユーザーストーリーマッピング」という手法を使いながら機能を具体化していったときの話です。
自分たちも試行錯誤をしている段階ですが、参考にしていただければ幸いです！
まずは、複数ある機能一つひとつを「実際これはプロダクトで開発するとしたらどのような形になるのか？」という観点で解釈していく必要がありました。
落とし込むにあたっては、プロダクトマネージャーとデザイナーの2人で取り組んでいきました。
*対象の機能をコンセプトから具体化していく様子
例えば上記のように機能に対しての言語化を行い、PRD（プロダクト要求仕様書）の作成を進めて、徐々に認識を揃えつつ解像度を上げるような取り組みを行っていきます。
*当時使われていたPRDの目次
書き起こしたPRDの内容は、「事業としての価値」はまとめられていましたが、一方で「ユーザーが本当に必要としているか」「ユーザーにとっての価値はどのようなものか」はまだわからない状態でした。
つまり、ユーザーにとって価値ある単位を適切に捉えられていないため、プロダクトを提供する上での開発すべき単位や順番について、認識できていない状況にありました。
そこで、ユーザーにとっての価値とプロダクトを提供する単位を明確にするために、今回採用したのがストーリーマッピングでした。
ユーザーストーリーマッピングの実施にあたっては主にこちらの書籍を参考に進めていきました。考え方や手法として特に重要視していた点は以下です。
- ユーザーストーリー（今回の場合はユーザーの業務）を完全に理解すること
- プロダクトに価値を積み上げられるような単位がリリース単位として定義されていること
- より小さく作り、より早く学習すること
*ユーザーストーリーマッピングを始めるにあたって社内に共有した資料
今回の検討していた機能の領域では「実際に既に対象領域の業務に取り組んでいて、その上で課題を抱えている人がいるはずだ」という仮説があり、ユーザーストーリーマッピングはその課題や解決策を整理するために適していると考えました。
ユーザーストーリーマッピングを行う前段階として、実際の業務の課題感を知るために想定ユーザーと近い人にヒアリングを行いました。
ここで意識していたのは、可能な限り工夫と改善を繰り返し、対象領域の業務に取り組んでいる理想的なユーザーの業務内容を探りにいったことです。
頑張れば人力で解決できることではなく、サービスがないと解決されないような課題感を発見するために、現段階で該当領域の業務が回っていない人ではなく、すでに人力かつ高いクオリティで業務に取り組んでいる人に話を聞こうと考えました。
ヒアリングにはユーザーストーリーマッピングを一緒に行う予定のメンバーが全員参加して、みんなで深掘りをしていきました。
*インタビューの際に活用している検証テンプレート
ヒアリングを踏まえて「ここまでのクオリティで業務を行えている人はいないのではないか」という人の業務フロー・課題が明確になったため、それらを整理をして解決策を考えるためユーザーストーリーマップに落とし込むワークショップを開催しました。
ヒアリングしてきた情報をもとにして、ユーザーストーリーマッピングに落とし込むワークショップを開催しました。参加者はPdM, 僕, 機械学習のエンジニア, 機能をつくるエンジニアを呼んで、結果的に4名で実施しました。
*ヒアリングで伺ったA/Bテストの業務フローをスライドで可視化したものをワークショップの参加者に事前に共有していました。
*ヒアリングで聞いていた課題感もスライドに落とし込んでワークショップ参加者に事前に共有。
ヒアリングの結果をベースに議論しながら、miroを用いて全員で付箋を使って機能を出していきました。
*miroを用いてユーザーストーリーに落とし込んでいく
「ストーリーの流れ」「課題・ペイン」の箇所には、ヒアリングで得られた現状の業務の流れと課題を付箋で言語化していきます。
*実際のユーザーが取り組む業務ストーリーの流れと課題・ペイン
そこからは課題ごとに解決するならどういう機能があるのか、ということを付箋で出していきます。
*課題ごとに、サービスが提供する機能・価値に落とし込む
ただ、これだけではブレストにしかならないので、この段階でどの機能はいつの段階でプロダクトに乗せるのか？という観点で「MVPで載せるもの」「近い将来やるもの」「遠い将来やるもの」「やらないもの」というリリースタイミングを意識した段階に分けて、細かい機能ごとに分けていきました。
*機能を「MVP」「近い将来でやるもの」「遠い将来にやるもの」「やらないもの」で分類
このように分けてみたは良いものの、「MVP」「近い将来やるもの」などの段階に定義を置ききれておらず、ワークショップに参加した人の空気感で決められていたものになっており、チームに説明しづらい状態になってしまっていました。
そのため、それぞれの機能をなぜ行うのかを一貫した考え方のもとに定義するため、各段階の明文化・価値の定義を行いました。「最終的に遠い将来にやるもの」まで実現した時に、一番最初に理想として定義されていた状態になるだろう、という考え方で段階は置いています。
*各段階でどのような価値を届けられる状態になっているかを明文化しておく
これで、実際の業務に対しての課題感と、その解決策を段階にわけて定義することができました。
そこで終わりだと思っていたのですが、最後にもう1ジャンプを行う必要がありました。
まとめたストーリーの流れはその人たちのやってる業務をそのまま言語化したものにはなっていたのですが、サービスの中でどのような振る舞いをしていきたいと思っているのか？という点では落とし込めていませんでした。
*まとめていたユーザーストーリーの流れ
なので、このまま機能開発をしても、サービスを使うことでどのような業務になるのか？という点で検証ができない状態だったため、サービスを使うことでどんな業務になっていくか？という言葉にストーリーを変換していきました。
*各まとめていたユーザーストーリーの流れを「サービスの中の行動」としてストーリー化
ここまでくると、「出しているプロセスが価値になるか？がわかる」「プロセスを踏まえてラフなモックアップにできる」という状態になっているため、詳細な仮説検証を行えるレベルにかなり近くなりました。
次のプロセスとしてはユーザーにプロダクトを提供しつつ、都度検証を繰り返しながらプロダクトを前に進めていくことになります。
これまでユーザーストーリーマッピングを軸にプロジェクトの進み方を話ししてきましたが、最も大切なのはプロダクトやサービスを通じて、自分たちが意図している価値を提供し続けることです。
顧客にとっての価値をしっかりと見定め、それを正しく提供できる形でプロダクトに積み上げていくこと。提供できる形に責任を持つのがプロダクトデザイナーの仕事ですし、価値提供に向かってプロダクトと向き合い続けるのがプロダクトマネージャーの仕事だと思ってます。
今回の取り組みをプロダクトデザイン・開発に落とし込んでいく様子を、続きの具体的な例として、お話をできればと思っています。