エンジニアがプロダクト志向の開発を実践した方法

ユーザーストーリーマッピングは、名前の通り「ユーザーストーリーマップ」を作成することです。

ユーザーストーリーマップは、「ユーザーのアクティビティ」「アクティビティの実施時に感じる課題」「その課題に提供できる価値」「価値を提供するために必要な機能」をマッピングしたものです。複数人でワークを行い、付箋を使いながらディスカッションをします。最終的な成果物は下の画像のようなものです。

ユーザーストーリーマップを作ることで、次のようなメリットがあります。

• ユーザーに焦点を当てて思考できる
• 参加者が同じ景色を見ることができる
• 限られたリソースで何をやるべきか判断できる

どれも重要ですが、私は「ユーザーに焦点を当てて思考できる」点が最も本質的で重要な点だと考えています。

また、この項目は1人でも効果を感じることができます。もちろん、複数人で実施した方が効果は大きいです。（できればエンジニア以外の顧客接点の多い人も含みたいです。）しかし、まずは一人からであってもユーザーに意識を向けて思考するツールとして利用できるので、ユーザーストーリーマッピングの知識は持っておいて損はないと思います。

私たちのチームでは以下の手順でユーザーストーリーマッピングを実践しています。

ターゲット（ペルソナ）を決める

一番最初にプロダクトのターゲット（ペルソナ）を決めます。「決める」というのは、具体的に定義されている状態にするという意味です。0から生み出す必要があるわけではなく、実際のお客さまをモデルにして記載するのも良いです。

後の手順で誰のどんな課題をどのように解決するのかを議論するため、プロダクトのターゲットとなる具体的な人物像を想像できる状態になっている必要があります。

実際のお客様の姿がイメージできていればなんでも良いですが、次のようなフォーマットを使うと良いです。

ペルソナの要望・課題を洗い出す

ペルソナが定義できたら、ペルソナが感じている要望や課題を洗い出します。

私たちのチームではブレインストーミング→KJ法の流れで進めるのがしっくりきたので、おすすめです。

まず、洗い出すフェーズでは、一旦現在の制約を無視してブレインストーミングします。ブレインストーミングの際は、付箋に要望・課題を書き出して無邪気に発表し合います。1つの付箋に具体的な要望・課題を書くと良いです。このフェーズではお互いの意見を否定せずに、議論を発散させましょう。複数人で実施できる場合は、自分が気づかなかった視点がでてくることも多いです。

洗い出した要望・課題を分析し、本質的な課題を見極める

次に、要望・課題を分析し、本質的な課題を見極めます。

1つ前の手順で多くの要望・課題の付箋が作られるので、洗い出した内容を整理・分析します。ここではKJ法を使って同質なものをまとめることから議論をスタートさせると、議論が活性化しやすいです。同じことを言っている付箋が多かったら重要そうと考えたり、付箋のまとまりを動かして関係性を表現したりして、ユーザーの本質的な課題を分析しましょう。

ただし、安易にグルーピングすると本質的な内容が抜け落ちることがある点には注意してください。大事なのはユーザーストーリーマップを作ることではなく、ユーザーにとって価値のあるプロダクトを作ることです。

本質的な課題からユーザーのアクティビティを時系列で書き出す

ユーザーの課題を深掘りできたら、次はユーザーが取ると考えられるアクティビティ（=行動）を時系列順に書き出します。

プロダクトとは無関係の世界線を考えることもできますが、私の経験では、現状のプロダクトを使った時の行動パターンから書き出すと考えやすかったです。例えば、「〇〇ページにアクセスする」「△△という行動をとる」など自由に書きます。

ここで重要なのは、一つ前の手順で洗い出した「課題」と「ユーザーがとるであろうアクティビティ」を相互に行き来し、漏れなくマッピングすることです。そうすることで、「プロダクトの中でユーザーが理想のアクティビティをとるのに足りない点はどこなのか」、「どのような機能があるとユーザーにとっての価値を提供できるか」を考察することができます。また、アクティビティと課題のマッピングをすることで、洗い出した課題に漏れがなかったかも確認できます。

ユーザーのアクティビティを成り立たせる

ユーザーのアクティビティの中で、課題を抱えていそうなところに対して、提供できる価値を考えます。理想とのギャップがありそうなところはないかを探すと考えやすいです。

ここでプロダクトの提供する価値を考えることで、次の手順で機能を具体化するときに何を満たす機能を作ればよいかを考えやすくなります。理想状態とのギャップを生み出している課題に再び目を向けて、どうすればユーザーの課題が解決できるのかを考えます。

機能を具体化する

ユーザーが求める価値が考えられたら、ここで初めてその価値を提供するための具体的な機能を考えはじめます。これまでの手順でユーザーの本質的な課題に目を向けてきたことで、より良い機能案を考えられるはずです。技術的制約も合わせて考える必要はありますが、ここでは無邪気にアイデアを出して発散させて良いです。

機能の優先順位を考えて、どこまでをMVPとするかを決める

機能案を具体化した後は、優先順位を考えてMVPとするラインを決めます。

MVPとは、Minimum Viable Productの頭文字をとった用語で、日本語にすると「利用可能な最低限のプロダクト」のような意味です。たくさんの機能案が出てきますが、現実はリソースに限りがあります。ここで再びユーザーの課題と提供する価値に目を向けて、ユーザーにとってどの機能がどれだけ重要かを意識しましょう。

優先順位の考え方ですが、2軸あると思います。

1. 工数のかかり具合
2. 開発完了後の効果の大きさ

同じ工数なら効果が大きいものを選ぶべきですし、同じ効果なら工数が少なくすむものを選ぶべきです。実際は効果は大きいが工数もかかるような機能案が多く、取捨選択には苦労します。エンジニアだけで判断するのではなく、お客様との接点の多い仕事を担当しているチームにもアドバイスを求めるのが良いと思います。

実際に、私たちもチーム内で展開して意見をもらうようにしています。エンジニアの視点では気づけないことも沢山あることがわかるので、是非近いチームの方を頼って意見交換してみてください。

その際、相談相手が機能のイメージをつけやすいように、パワーポイントなどで良いので簡単なペーパープロトタイプを作っておくと話がスムーズです。（ここも実際の私の経験をもとにしています。ユーザーストーリーマップを使って説明したり、口頭で説明したりしてもうまく伝えられなかったですが、ペーパープロトタイプがあれば議論がスムーズになりました！）

開発

ユーザーストーリーマッピングで作るものを考えた後は、実際に開発するフェーズになります。

この章では一点だけ強調したいです。それは、「作る時にユーザーのことを忘れないようにしましょう」ということです。

せっかくユーザーのことを考えて用意した機能案も、実装を進める中で技術的な制約にぶつかり、アイデアをそのまま実現する事が難しいこともあります。そのとき、技術的な制約を回避するために重要な価値を損ねる変更をして、早くタスクを完了させたい気持ちになる時もあります。

もちろん技術的に不可能な場合は代替案を考える必要があります。しかし、代替案を考える時も、元々その開発項目を作った先にどんな価値を提供しようとしていたのかを意識して、最大限ユーザーにとって価値のあるものを作る必要があります。

ユーザビリティテスト

開発が終わったら、ユーザビリティテストを行います。ユーザビリティテストを行うことで、開発したものがユーザーにとってどうみられるのかを確認できます。

その結果、改善すべき点や次にやることのアイデアを得ることができます。

ISO9241-11の定義によると、ユーザビリティとは”システムの使いやすさ”のことです

ISO 9241-11の原文：

usability: “the extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”.

ユーザビリティテストは、システムがユーザーにとって使いやすいかどうかを評価するためのテストです。

様々な方法がありますが、この記事では思考発話法を使ったユーザビリティテストについて解説します。

思考発話法とは

ユーザーに操作中の思考・気持ちを口に出してもらい、その様子を観察することでユーザビリティの評価を行う手法です。

実施する際は、以下の準備が必要です。

1. 被験者を集める

まず、ユーザビリティテストに協力してくれる被験者を集めます。

人数については、大勢でテストするよりも少人数(5人以下)で何回かテストする方が良いと言われています。

参考サイト：Why You Only Need to Test with 5 Users

2. ユーザビリティを確かめるためのタスクを設計し、リスト化する

システムを触ってもらうために、タスクを設計します。

具体的な画面操作ではなく、ユーザーに達成してほしい行動をリストアップします。例えば、「〇〇画面でファイルをアップロードする」のような書き方が良いです。

実際に私が開発するツールでユーザビリティテストを実施した際のタスク例です。

3. 被験者に実際にタスクを実施してもらう

用意したタスクを実施してもらいます。その時に、頭の中で考えていることを口に出しながら操作をしてもらいます。

例えば、「このボタンを押すとファイルをダウンロードできると思うので押します。」「あ、ダウンロードボタンじゃなくてアップロードのボタンだったんだ…」「どこでダウンロード処理するか迷ったので適当にボタンを押します」のように、感じたことをそのまま言葉にしてもらうのが重要です。

テスト実施者は、その様子を観察し、分析します。

上の例だと、分析の結果、「ダウンロードボタンの位置がわかりづらそうだったのでもっと目立つ位置に変える必要がある」のような分析結果が得られます。

また、タスクを実施するときにユーザーの感想を数値化して記録しておくと良いです。定量的な数値が示せることで、テスト実施者以外にもテスト結果が伝わりやすいです。また、テスト実施者が冷静に分析する助けにもなります。

4. 分析した結果をまとめる

得られた結果をまとめて、チームにフィードバックします。この後議論するのが大事です。ユーザビリティテストの結果の分析が終わったら、ユーザーストーリーマップを見直し、修正するべき点があればアップデートし、次の施策を検討します。

ユーザーインタビュー

開発が終わった後、ユーザビリティテストとは別でユーザーインタビューも行えると次のアクションにつながります。ユーザビリティテストは操作について焦点を当てたものだったのに対して、ユーザーインタビューはユーザーの課題解決ができているかの確認と、次の仮説を立てることに焦点を当てます。

ユーザーインタビューでは、ユーザーストーリーマッピングの際に整理した機能・ユーザーの課題・ユーザーに提供する価値について質問します。ユーザーストーリーマッピングの結果は、ユーザーストーリーマッピング実施時にあった情報をもとに立てた仮説に過ぎません。事前に立てた仮説が正しいかどうかを検証するためにインタビューを行う必要があります。

また、仮説の検証のためにインタビューをする中で、次のユーザーストーリーマッピングにつなげられるような、新しい情報が見つかることもあります。お客様の口からポロッと出てくる何気ない一言に大きなヒントが隠されていることがあります。

インタビュー実施の前に、以下のような項目を埋めています。

ユーザーインタビューの際は、本当に聞きたいことについて直接的に聞くのではなく、間接的な質問から帰納的に推論できるようなインタビュー設計をしていくのが良いです。

例えば、「〇〇機能は良い機能だと思いますか？」と質問してしまうと、インタビューを受ける人は「はい」と答えてしまう事が多いです。〇〇機能を使うシチュエーションについて、「そのシチュエーションでは何か課題はありませんか？」「一番ストレスに感じるのはどういう点ですか？」など、周辺領域の質問をしていき、本当に聞きたかったことを導き出す事が望ましいです。（これはかなりテクニックがいります。私たちのチームもまだまだ修行中で、日々難しさを感じています…）

また、ユーザーインタビューは実際のお客様との関係値がないエンジニアだけで実施するのは難しいので、営業・CSチームなど、お客様との接点のあるチームに協力を依頼する必要があります。分析の際も他チームを交えて行う事が望ましいです。

ユーザーインタビューで仮説を立てた後は、ユーザーストーリーマップを見直し、修正するべき点があればアップデートし、次の施策を検討します。

結果の分析

最後にここまで作ってきたものを照らし合わせて、分析を行います。実際は全部終わった後にまとめて行うというよりは、作りながらこまめに分析し、次のフェーズへと進んでいくのがおすすめです。

下に反省点としても記載していますが、結果の分析はやりっぱなしになったり、逆にやらないで放置してしまったりすることが多かったです。分析する際は具体的な次のタスクまで落とし込むことを意識して行う事が重要だと感じています。

それ以外は、プロダクトが置かれている状況は様々ですので、その時の状況に合わせて柔軟に分析し、次のアクションにつなげられるよう意識する事が重要だと思います。

課題と今後の展望

当然ですが、本記事に記載の内容を実践すれば完璧ではありません。私たちの組織もより良いプロダクトにしていくために、日々試行錯誤を続けています。

最後に本記事でご紹介した内容を実践した後に感じた課題と解決策を共有します。

2回目以降は動きが遅くなった

ユーザーストーリーマップで作るべきものを決めてから、開発完了して検証し始めるまではスムーズだったのですが、そこから次の改善に踏み出すのに時間がかかってしまいました。1回目とは違い、ある程度自信を持って作った動くものがあり、その延長線上の改善に目が向きやすくなったのが大きな原因かと思っています。

今あるものの延長線上ではなく、「ユーザーにとって一番良いものを作る」という姿勢を忘れないように気をつける必要があります。現在は営業・CSを担当する部門とも連携してお客様にヒアリングさせていただくタイミングを作り、そこでのコメントを分析して次に何が必要かを考えるようにしています。

また、1回目のユーザーストーリーマップ作成の際に、「検証すべき仮説」と「いつどのように検証するか」「何を持って完了とするか」が決められておらず、分析した後に次のステップに進みづらいという課題も発生しました。

私たちのチームでは「Asana」というタスク管理ツールを使用しているので、そこで「仮説」「検証内容」「完了条件」を明記し、放置されるタスクが内容管理することで、次のアクションに移れるよう仕組みを作り改善を図っています。

※絶賛試行錯誤中です。

完成品の検証しかしておらず、大きな手戻りが発生する時がある

顧客の本質的な課題に目を向けて開発できるようにはなってきたのですが、お客様が喜ぶものを1回で完璧に見つけるのは極めて難しいです。そのため、仮説に基づいて開発した後、実際にお客様に使っていただいたフィードバックで仮説が間違っていたと明らかになる場合があります。その場合、開発にかけた時間・努力は無駄になってしまいます。

そのような状況を回避するため、開発をする前に仮説の検証を行う取り組みを始めています。ちょうど私と同じチームのメンバーがアドベントカレンダーの記事として投稿していましたので、詳しくはこちらをお読みください。

まとめ

本記事では、お客さまの課題を解決するためのプロダクトを作るために実践してきたことを紹介しました。

実際にはここに記載した内容はうまくいった例で、色々と失敗もしています。また、本記事の内容もベストな方法ではないかもしれません。それでも、お客様にとって最高のプロダクトを作っていくために日々試行錯誤していくことが大切だと考えています。私たちもまだまだできることはあると思いますので、今後も様々なアプローチを試し、より良いプロダクトチームを作っていきます！

最後に、私たちはAIのデータ作成を事業として行っています。生成AI向けのデータ作成でお困りの方は是非TASUKIにお声かけください！

最後までお読みいただきありがとうございました。それでは、 ソフトバンクアドベントカレンダー2024 13日目にバトンを渡します。

関連サービス