Webサービスを運営する上で、重要な取り組みのひとつが改善です。ユーザの体験をすこしずつよくしていくことで、ユーザに長くプロダクトを使ってもらえるようになります。
ひとことに改善といっても、具体的にどうすればいいのでしょうか。たとえばKPIを計測して改善のための施策を考えたり、ユーザからフィードバックをもらって改善につなげるやりかたもあります。
これ以外の、改善のための効果的な取り組みとして、ドッグフーディングがあります。この記事では、ドッグフーディングとはなにか、目的ややりかたについて書きます。
ドッグフーディングとは、プロダクトを開発者自身が利用することをいいます。
開発者がユーザとしてプロダクトを使ったり、ペルソナになりきってプロダクトを使います。開発者がユーザ視点でプロダクトを使うことで、開発者としては見えなかったアイデアが出やすくなり、プロダクトの理解を深めることもできます。
また、ドッグフーディングは手動テストの側面ももちます。このため機能のリリース前などに行うのも効果的です。
ドッグフーディングは、とくに目的を定めず自由に使うこともあれば、たとえばレシピサービスで『買い物中にレシピの材料を確認するユーザ』のように条件を設定することもあります。
ドッグフーディングはMicrosoftやGoogle、トヨタなど世界を代表する企業でも実践されている手法です。
ドッグフーディングは、ユーザ視点で改善のためのアイデアを出すために行います。また、プロダクト全体の理解を深めたり、サービスが正しく動作するかテストするという目的ももちます。
プロダクトはユーザに日々利用してもらっています。フィードバックをもらう機会もあるでしょう。ユーザからのフィードバックは改善のための重要な役割をもちます。
ただ、開発者がプロダクトを長く開発していると、機能や施策に集中しすぎて、実際に使うユーザのことが見えなくなりがちです。客観的な判断ができなくなり、うまく改善につなげられないかもしれません。
自分でプロダクトを使い、ユーザとなることで、ユーザ視点で客観的なアイデアを出しやすくなります。これがドッグフーディングを行う目的です。
ドッグフーディングには、とくに決まったやりかたはありません。ユーザとしてプロダクトを使う、ただそれだけです。
ドッグフーディングを体系的に行う方法として、役割とストーリーを決めるやりかたがあります。これは次の7つの手順で行います。付箋を使ってやると意見を整理しやすいのでおすすめです。
まず、ドッグフーディングを行うためのユーザの役割とストーリーを洗い出します。
役割は、たとえばレシピサービスであれば『レシピ投稿者』『レシピ閲覧者』で、ストーリーは『スマートフォンからレシピを投稿する』『料理中にレシピをチェックする』などが考えられます。
洗い出した役割×ストーリーの重要度を決めていきます。これは改善のタイミングによって変わります。
たとえばレシピの投稿数をふやしたければ『レシピ投稿者』×『スマートフォンからレシピを投稿する』の重要度が高くなります。会員数をふやしたければ『レシピ閲覧者』×『会員登録する』がより重要になるでしょう。
重要度の高いものから、役割になりきりストーリーどおりに使ってみます。使いながら、思ったことを率直に書き出します。
たとえば「投稿画面の写真が選択しづらい」とか「レシピの料理画像がおいしそうに見える」など、いいこともわるいことも書いていきます。
使いおわったら、出てきた意見をグルーピングします。グループごとに名前をつけます。たとえば『投稿画面の写真選択』などです。
グループごとに重要度を決めます。決め方としては、どれを改善したらよりユーザの体験をよくできるか?という視点で決めます。
重要度の高いものから、グループの中にあるユーザの本質的な課題を抽出します。これはどういうことかというと、たとえば「投稿画面の写真が選択しづらい」の本質的な課題は「ユーザはもっと簡単に写真を選択・投稿したい」となります。
同じように見えますが、このふたつはまったく違います。『写真が選択しづらい』を解決するだけなら選択ボタンを大きくすればいいかもしれませんが、より抽象的に『もっと簡単に選択したい』という課題を解決する場合、選択の仕組み自体を変更しないといけないかもしれません。
グループから抽出した、ユーザの本質的な課題に対する解決策を考えます。
MVPの検証がおわって、実際のプロダクト開発に入ったらドッグフーディングをはじめます。たとえば週に1回30ふんなど、時間を決めて定期的に取り組むとよいでしょう。
ドッグフーディングは、プロダクトを改善するための効果的な取り組みのひとつです。役割とストーリーをイメージしながらプロダクトを使い倒し、思ったことを率直に書いていきます。
思いついた機能を単純に取り入れるのではなく、アイデアの裏にある本質的な課題に着目して、ゼロベースで解決策を考えることで、よりユーザにとって使いやすい機能につながります。
プロダクト開発者。開発・ブログ・副業がすき。 共著に『現場で使えるRuby on Rails 5』。 三重で妻とこども、ネコとのんびり暮らしています。
Follow @zenizhプロダクト開発者。開発・ブログ・副業がすき。 共著に『現場で使えるRuby on Rails 5』。 三重で妻とこども、ネコとのんびり暮らしています。
Follow @zenizh