第8回は、JUGEM の yuriwo が18章から20章をまとめました。

プロトタイプとユーザテスト

ここで言うプロトタイプやベータ版は、本開発とは別のもの。何度かでてきたハイファイプロトタイプと呼ばれるもの。

その結果を受けて、プロトタイプを捨てて本開発をするんだよ。プロトタイプの定義を関係者で合意しておかないと、不幸な未来が見える。

ユーザテストでのアクシデント

ユーザテストでもし未完成の部分をユーザが操作したらどうする？

続きになにがあると思いましたか？と聞くと価値ある情報が得られることがある。

ペパボでの製品要求仕様は?

ペパボでは製品要求仕様やハイファイプロトタイプを作っているか？

XXプロジェクトでは、一番最初にUXをイメージできる動画を作ったよ。

ただ、実際に動くようになると触り心地がだいぶ違ったようなので、ハイファイプロトタイプってのはそういうところまで再現できたほうがいいのかもしれない。

minneではスマホアプリ用にWebの機能からペーパープロトタイプを作ったりした。

製品要求仕様やハイファイプロトタイプで解決しようとしている課題は何か

解決すべきユーザの課題は決まっていて(これは市場要求仕様の範囲かな？)、その解決方法が

• 問題を解決できているか
  • うまく解決できているか

という部分を低コストで判断したいのでは。

市場要求仕様の部分とあわせて考えると

• 問題があっているか
• 解決方法があっている
• いい解決方法か

という3段階があって、これを素早く検証しなければならないのだ。

ユーザテストのコスト的な問題

モックを作って、テストのシナリオを考えて、ユーザに会いにいくの大変だよ。そんな高速にまわせるのかな？

そういうことをやった結果、「スピード感がない」と思われてしまったりしないか？

結果的にはきっと無駄が少なくなるはず。それをどう説明するかの問題では。

一発でいいものができることもあるだろうけど、それは宝くじにあたるのと一緒で運(とセンス)でしかないのでは。

ユーザテストをやればよかったと思ったことは

ユーザからものすごい反感をかったり、出したけどすぐひっこめた経験はけっこうある。

人間の心情として、出してみたけど駄目だから引っ込めるというのは納得できるが、正式に出す前になかったことにするのは納得感がないと感じるかもしれない。

第三者の意見は圧倒的な根拠になってしまう。

ユーザテストの結果でころころと仕様を変えてしまうと、手戻り感を感じるかもしれない。そのあたりの価値観と進め方を事前に共有しておく必要はありそう。

サービスの提供側とユーザの心がズレていってしまうのはどうしてなんだろう。

サービスの提供側では利用者になりきれない場合が多い。そのためにリファレンスカスタマーを探すんだ。

何がきっかけでユーザテストをやるようになったか

職種間で意見が食い違った。じゃあインタビューをしようという話になった。

これは製品要求仕様のまえの市場調査をやったということになるのではないだろうか。

スクラム、ユーザテスト、アジャイル開発

わからないということを前提にしているのがよい。スクラムとユーザテストの共通点ではないか。

最初から答えがあるならウォーターフォールが最強。

どちらがよい、というわけではなくて、自分達が解こうとしている問題の性質にあわせてプロセスや道具を選択、改善していくことが大事。

ペパボのプロダクトマネージャの将来像

以前と比べると、ユーザテストやインタビューの必要性や有効性が理解されてきたように感じる。

一方で、熱意とテクニックのバランスの取れたプロダクトマネージャーの育成や学習が次の課題になるのではないだろうか。

そういった活動の一つがこの勉強会。

結局はいいプロダクトが早く開発できて、それで儲かれば文句ない。

「ユーザテストやってる間にどれだけ新機能作れるのか」という問いは間違っている。そういうことを説明しなくてもいいような組織作りが大事。

ミドル層がキーマンと言えるので、リーンスタートアップを読んでおしまい、から一歩前に出よう。

まずは本を読む。世の中には同じことで悩んでいて、いろいろな方法で解決している人達が既に沢山いる。

この読書会で共通認識が作られるつつある。もっと広げていきたい。

雑談

製品だけじゃなくて人間が成長する。チームの成長。それがさらに製品に返ってくる。