ドッグフーディングで意識したいこと

※すみません、この記事にワンちゃんは登場しません

自社のプロダクトを自身でユーザーとして使いつつ、改善していくのをドッグフーディング（Dogfooding）といいます。正式リリース前の社内テストのことを指す場合もありますし、すでにリリースされているものを一般のユーザーと同様に継続的・日常的に利用しながらテストして改善に役立てていくことを指す場合もあります。

ドッグフードの販売を手がける企業の社員が、実際にドッグフードを食べていたというエピソードが由来でそう呼ぶんだとか。ホントかな😅

私がCDOを務めるアストロラボでは、BtoBのサービスである、「備品管理クラウド ASSETZ（アセッツ）」「契約書保管クラウド CONTRFINDER（コントラファインダー）」を自社で開発、運営しています。どの企業でも使えるものなので、もちろん自社でも利用しています。

ASSETZとCONTRFINDERについて日々ドッグフーディングしているなかで、レビューのフィードバックと検証、反映のサイクルをスムーズにまわしていくために、ドッグフーディングの効率的なノウハウやフレームワークが確立された例なんかがあればいいなと思って探してみたのですが、「ドッグフーディングとは〜です」といった辞書的なものや、「ドッグフーディングいいですよ。」以上のことは書かれていないものだとかはあっても、具体的なやり方とかコツみたいのはちょっと見つけられませんでした。。どなたかいい事例をご存知でしたらぜひ教えてほしいです！

そこで、まだまだちゃんとまとまったものではないのですが、社内で試行錯誤しながら見つけた、ドッグフーディングで意識したいポイントを書き出してみました。

その1：
対象と事実を明確に

1）どこで（対象のアプリ・画面）
2）何をしようとして
3）何につまづいたか（取り違えた、すぐに見つけられなかった、意味がわからなかった など
レビュワーはこの3つをはっきり伝わるように書く（話す）。まずこの前提として、機能や画面、UIのパターンなどもふくめ、それぞれ何と呼ぶかを用語集として社内で定義しておくとブレがなくて良いです。

例えば、

「スマホの＊＊でバナーを押してもアラートとか出ないので何度も押してしまった。あとでメールでお知らせがあったのでわかった」

という指摘はじつはこういうことを言わんとしていた
↓ 

「スマートフォン用ネイティブアプリの￥￥画面で＊＊をしようと［登録］ボタンをタップしても何のメッセージも表示されないので、ちゃんと受けつけられたのかわからずに何度もタップしてしまった。結局メールで完了通知が来ていたので登録できていたことはわかった」

のように、具体的にどこの何を指し示しているのかを解明するのに時間がかかってしまう、といったことを避けられます。

4）どうしたら改善するかの案
「ここで○○○ができないので、これを△△△してほしい」という、「どう変えるか」の具体的な案はレビューにはあんまり必要ありません。「これを備え付けてほしい」という“要件”ではなく、「（最終的に）これがしたい」という“要求”が知りたいわけです。

レビュワーが慣れていないととくに、要件のかたちで指摘を挙げやすいというのはあると思うのでそう書いてもらってもいいのですが（後述しますが不慣れなユーザーの視点もとても大事）、その場合も上記の1）〜  3）は必須です。

最適な解決策は、目先の対処療法的なものとはかぎりません。というか、たいていの場合、あしらいや配置などの表面的な調整ではさくっと解決しないことが多いです。また、そうした部分最適化は全体の一貫性を崩し、ユーザー体験をそこなう可能性もあります。
構造や他の機能とも総合的・複合的に見直して検討することで、そもそもその指摘された課題自体存在しなくなるようなよりスマートな変更が最適な改善案として導き出されることもしばしばです。

そのためには、4）ではなく、なぜ4）に思い至ったのかを知るために、1）〜  3）をしっかり共有する必要があるのです。

一般的に、ユーザーが自分のほんとうのニーズを自ら正しく言語化できることはほぼありません。なので、ユーザーの言葉をそのまま受けとるのではなくて、観察から本質を導き出すのがユーザーリサーチの大前提とされています。

その2：
指摘にネガティブな感情は添えない

「イライラした」「気持ち悪い」「めまいがする」「吐きそう」
すべて実際に指摘事項リストに書かれた文中で目にしたことがあるものです。

使っていて感じた不快感、認知的不協和を解消したい心理は理解できますが、デザイナーもエンジニアも、わざわざ不快にさせようと思ってそうしたわけではありません。レビューは、結果としてそうなってしまっている原因をひもとき、もっと良いものにするための機会でもあります。

そこに開発の実務担当者がいようがいまいが、生産的なレビューの場でネガティブ何なきもちをぶつけたところで、誰にとってもいいことはひとつもありません。とりあえず甘いものでも食べましょう。じっさい、集まって対面でレビューを共有、検討する場ではお茶とお菓子を用意しておくのもよいと思います。

その3：
架空のニーズに対応しないように

基本的に、あくまでレビュワー自身がユーザーとして実際に直面したことを指摘として挙げます。想像力はもちろん大事ですが、「こう感じる人もいるかも」は仮説なので、がんがん挙げてもらうのはよいとしても、あらためて検証が必要です。できればその「こう感じる人」当事者でありうる誰かを見つけてきて、レビューを依頼したいところです。

実在するかわからないニーズに最適化してしまうと、誰のためにもならない、下手をすると実在するユーザーにとっては逆効果となる”改悪”にもなってしまうおそれも…　へんに先まわりして、居もしないユーザーのありもしないニーズに振り回されることのないように慎重になりたいです。

レビュワーのKPIとして「レビュー数」「課題提議の数」を設定してしまうと、こうした無意味なレビューを作って数を稼ごうとしてしまいがちです。

背の高い人にしか見えないもの、背の低い人だけが気づけるものがあるように、多様な視点での評価を得るのが目的でもあります。とくに設計者や開発者自身はすでにそのサービス／プロダクトのエキスパートなので、初心者ユーザーのつまづきに気づきにくくなってしまっているものです。

実際のユーザーのなかで、
・リテラシー
・習熟度
・ロール（役割）
・権限
など多様なことなる目線からのレビューを集められるようにレビュワーのメンバーや環境をセッティングします。

このあたりは、ユーザーの実際の利用データを十分に収集でき、仮説の元となるデータの抽出とテスト、仮説の検証ができる環境が整っていれば、データドリブンならぬデータインフォームド（定量データと定性データおよび経験知からの直感を組み合わせた改善プロセス）を採用し、効果的な改善ができるかもしれません。

その4：
レビュワーはクライアントではありません

課題の本質を取り出すために、挙げてもらった指摘の意図するところや、つまづいた場面の詳細などについてレビュワー本人にあれこれヒアリングをすることになります。そして議論のなかで導き出した改善策について、それでつまずきが解消されそうか指摘を挙げたレビュワー本人にも確認してもらいます。

気をつけておきたいのは、指摘はレビュワー個人の“ご要望”ではないし、指摘の検討の場でレビュワーに個人的に“ご納得いただく”のがゴールではないということ。レビュワーはまな板のうえにのせる素材を提供する人であって、自分でふんだんに報酬を払い自分の舌を満足させる至高の料理を要求する美食家の客ではありません。

あくまで“レビュワーが代表・代弁しているユーザー”にとってどうしたら使いやすくなるのかを検討し、大多数のユーザーの満足度を向上させるのが目的である、という視点をきちんと全員で共有しておきます。

その5：
どの立場も対等に扱い、ご機嫌取りをしない

ユーザーの代表者・代弁者として遠慮せず指摘を挙げられるようにレビュワーを萎縮させないように気遣うのはとても大事です。

しかしながら、「しろうと信奉」「専門家軽視」「感情至上主義」に陥らないように注意します。“ユーザー中心”は正しいですが、これはシステム開発上の制約や都合をユーザーにとっての使い勝手より無自覚に優先する“システム中心”に対する概念であって、ユーザー様の言うことはぜったーい！（チャラい）ということではありません。

デザイナーやエンジニアは、専門的な見地・さまざまな事例や経験にもとづいて、その場・そのタイミングにかぎらない影響範囲や全体の一貫性・バランスを別の視点からみています。

パラダイムシフトが起きて以前の正解がもはや通用しなくなったような領域は別として、専門家たちがこれまでに多大なリソースをかけて検証し積み上げてきたベストプラクティスを侮るなかれ。素人の直感がそれよりも優先するのだという態度は、反知性主義と呼ばれています。専門家の知見に素直に頼るべきときはそうするのが合理的です。

（※ パラダイムシフト…それまで当たり前だと考えられていた認識や概念が通用しなくなる大きな変化のこと）

いっぽうでもちろん、デザイナーやエンジニアが、けっして偉いわけでもありません。多面的な観点が必要という話で、あくまで立場は平等です。

組織内での立場のギャップがレビュワーの発言の遠慮に影響を与えている場合は、それは組織風土の問題でもあるのでまた別の、組織づくり面での取り組みが必要かもしれません。

その6：
足すのではなく引いてみる

あれこれ課題が出てくると、それに対応したチョイ機能を付け加えたり、注釈を記載したりするという方向で対処する案が出がちです。それが常にいけないわけではないのですが、多機能リモコンのようにこまかな機能ひとつひとつに対応したボタン類やパーツがたくさん並んだUIは把握しづらく、使いにくいものになってしまいます。また、人類は基本的に説明文をいちいち読んで理解してから行動するように進化していません。

デザイン原則でよく言われるものに「KISSの原則」というのがありますが、これは「Keep It Simple, Stupid」の頭文字をドヤ顔で並べたもので、「常にシンプルにしよう」ということです。付け足すことで対処する前に、そもそもその迷ったり困ったりした事態が起きなくなるように、余計なものを減らせないかという方向で検討してみます。

その7：
とはいえ、いったんすべて挙げてみて、いったんすべて受け入れる

さて、いろいろと「意識したいポイント」をあげましたけども、

…忘れてください。

あれこれ事前に考えすぎてもレビューが出てきづらくなっちゃったら本末転倒で、せっかくのドッグフーディングが滞ってしまいますので、いったんとにかく気づいたことを挙げてみます。そのあとで丁寧にさばいて礼儀正しく議論をすればよいと思います。

他のレビュワーによって既出かどうかも、そんなの関係ねぇ!  はい、おっp（古い）、事前にいちいち調べなくてよいです。挙げたあとで既出とわかったらそれで次の指摘に移ればよいだけで、そのほうが効率的です。

以上、「ドッグフーディングで意識したいポイント」現状版でした。また追記やアップデートするかもしれません。