スプリントレビューやユーザーインタビューで良いFBを引き出すためのTips

スプリントレビューやユーザーインタビュー、ユーザーレビューの場では、プロダクトを良くするための情報を引き出すことがとても重要です。

しかし実際には、

• 抽象的なフィードバックしか出てこない
• 「もっと使いやすくしてほしい」などのふわっとした意見になる
• 本当に知りたい業務の話が出てこない

といった経験をしたことがある人も多いのではないでしょうか。

自分も受託開発の現場で、こうしたレビューやインタビューを行う中で試行錯誤してきました。この記事では、プロダクト改善につながる情報を引き出すために、自分が実践しているTipsを紹介します。

Tips1: 誰を呼ぶか

まず重要なのは、レビューの場に誰を呼ぶかです。

ここでは、受託型のビジネスで社内システムを開発する案件を前提に話します。

特にスプリントレビューでは、できるだけ理由をつけて

• 意思決定者（Chooser）
• 実際のユーザー（User）

の両方が参加するミーティングを、プロジェクト立ち上げの初期段階でセッティングするようにしています。

この2者は、同じプロダクトに対してまったく違う視点を持っていることが多いです。

意思決定者（Chooser）の視点

意思決定者は、組織や業務全体の最適化を考える立場にあります。

例えば次のような視点です。

• 既存業務や既存プロダクトとは違うコンセプトのものを作りたい
• 多少の使いやすさを犠牲にしてでも、新しく作ったプロダクトで業務を回せるようにしたい

つまり、業務や組織の変革を意識した視点です。

ユーザー（User）の視点

一方でユーザーは、日々実際に業務を行う立場です。

そのため、次のような期待を持つことが多いです。

• 既存プロダクトでできることは、新しいプロダクトでもできるようにしてほしい
• 既存業務やプロダクトの延長線上で、今の作業を楽にするものにしてほしい

つまり、日常業務の効率や安心感を重視した視点になります。

どちらの視点も重要

この2つの視点は、どちらが正しいというものではありません。
どちらもプロダクト開発には重要な視点です。

だからこそ、

• Userだけ呼ぶ
• Chooserだけ呼ぶ

のではなく、両方を呼ぶミーティングを設定することが大切だと考えています。

同じ場で同じプロダクトを見てもらい、それぞれのフィードバックを共有することで、

「同じものを見ても、視点によって評価が違う」

ということを関係者全員に認識してもらうことができます。

ただし、UserとChooserの間には上下関係がある場合も多く、ユーザーが本音を言いにくいこともあります。そのため、

• 言いたいことを言える雰囲気を作る
• 議論が平行線になりそうなときに次のアクションを合意する

といったファシリテーションも非常に重要になります。

Tips2: 良いFBの尺度を教える

ミーティングでは、どんなフィードバックが欲しいのかを最初に提示するようにしています。

例えば、最初に次のように伝えることが多いです。

「こういう機能が欲しい、という話よりも、
実際にどういう作業をしているのかという話を聞きたいです。」

また、議論が脱線しすぎないように、次のようなことも伝えています。

「脱線しすぎていると思ったら止めますが、
仕事をする上でのこだわりなどもぜひ聞かせてください。」

このようにスプリントレビューの初回でどんな情報が欲しいかを最初に定義しておき、そういったFBをもらったらそれが欲しかったんですよ！と伝えることで相手もどんなことを喋ったら良いかのコツを掴めるようになり、より具体的で有益な話が出やすくなります。

Tips3: どんな観点で観察するか・質問するか

ユーザーの話を聞くときには、ユーザビリティの観点を意識するようにしています。

国際規格 ISO 9241 では、ユーザビリティは次のように定義されています。

特定のコンテキストにおいて、特定のユーザーによって、ある製品が特定の目標を達成するために用いられる際の、効果、効率、ユーザーの満足度の度合い

つまりユーザビリティは、次の3つの観点で捉えることができます。

• 効果（Effectiveness）
• 効率（Efficiency）
• 満足度（Satisfaction）

ユーザーに質問するときも、この3つを意識して質問を切るようにしています。

よくない質問例

例えば次のような質問です。

このソフトウェアをより使いやすくするためにはどうすればいいですか？

これは非常にオープンな質問なので、回答する側も

• 「UIが分かりにくい」
• 「もう少し早く動くといい」

といった抽象的なフィードバックになりやすいです。

自分的にうまくいった質問例

代わりに、次のような質問をすることが多いです。

効果

〇〇を完了するためには、どんな情報や作業が必要ですか？

効率

実際に触ってもらいながら、

• 手間がかかっていそうな部分
• 迷っていそうな部分

を観察しながら質問します。

〇〇ページに行くまでの操作で、ここで立ち止まったときに何を考えていましたか？

満足度

この作業をするときに、特に重要視しているポイントはありますか？

このように質問をすると、単なるUIの感想ではなく、業務の背景や判断基準について話してもらえることが多くなります。

Tips4: 観察の仕方

ユーザーがプロダクトを触っている様子を観察するときには、いくつかの方法を試しています。

思考発話法

ユーザビリティテストでよく使われる方法に、思考発話法（Think Aloud）があります。

ユーザーに操作してもらいながら、

「何を考えて操作しているのか」

を声に出して説明してもらう方法です。

最初に説明して、できるだけ意図を話してもらうようにお願いはしますが、実際には

• 途中で無言になってしまう
• 作業に集中してしまう

ということが多く、あまり期待しすぎないようにしています。

回顧法

思考発話法が難しいことも多いため、自分は回顧法を使うことがよくあります。

これは、操作が終わったあとに振り返ってもらう方法です。

例えば、ユーザーが途中でつまずいたり、作業をやめてしまったときに、次のように質問します。

さっきの操作のとき、本当は何をしようとしていたんですか？

この質問をすると、

• 本来やりたかったこと
• 期待していた操作
• どこで迷ったのか

といった情報を聞くことができます。

Tips5: 「一人のためのデザイン」を過度に恐れない

最後に紹介したいのは、一人のユーザーのためにデザインすることを過度に恐れないという考え方です。

書籍『アジャイル・ユーザビリティ』には、次のような内容があります。

思い切って発想を転換しましょう。つまり、「すべてのユーザではなく、1人のユーザのために製品を設計する」のです。余計な機能を排除して製品をシンプルに保ちましょう。機能満載の製品を作り上げたところで、長寿もしくは頻繁に使用される機能は20%だけ。45%の機能は全く使用されないとも言われているのです。

もちろん、細かすぎるカスタマイズを前提とした設計はよくないかもしれません。

しかし自分は、

1. まず一人のユーザーのためのデザインをする
2. 次に二人目のユーザーの意見を聞く
3. そこから抽象度を高めて複数ユーザーに展開する

という進め方が重要だと考えています。

また、ステークホルダーに対しても、

「代表ユーザー」を連れてきてもらう

という意識を持ってもらうことが大切だと思っています。

まとめ

スプリントレビューやユーザーインタビューで有益なフィードバックを得るためには、単にデモを見せて感想を聞くだけでは不十分です。

自分の経験では、特に次のポイントが重要だと感じています。

• 誰を呼ぶか（ChooserとUserの両方）
• ミーティングの目的を最初に定義する
• ユーザビリティの観点で質問する
• ユーザーの行動を観察する
• 一人のユーザーのためのデザインを恐れない

レビューの場は単なる確認の場ではなく、ユーザーの仕事や意思決定の背景を理解する場でもあります。少し質問の仕方や場の作り方を変えるだけで、得られる情報の質は大きく変わります。みなさんもトライしてみてください！