ドッグフーディングの限界と誤判断

自社プロダクトを自分たちで使う取り組みは有効ですが、万能ではありません。むしろ、限界を知らずに使うと、社内での使いやすさを市場での使いやすさと取り違え、改善の方向を誤らせます。

本記事では、社内検証で見える問題と見えない問題を分け、外部検証と併用すべき境界を整理します。ドッグフーディングの定義そのものはドッグフーディングとは何をすることかで扱っています。

判断を歪める三つの偏り

社内の人がプロダクトを使うとき、外部の利用者とは決定的に違う条件が三つあります。

知識の偏り

社内のメンバーは、プロダクトの構造、用語、設計意図を知っています。画面に「ステータス: 保留」とだけ書いてあっても、それが何を意味し、次に誰が何をするのかを補って理解できます。外部の利用者には補う材料がありません。

この差は、説明文やラベルの検証をほぼ無効にします。社内で「分かりにくい」と言われなかったのは、分かりやすかったからではなく、知っていたからである可能性が高いのです。

環境の偏り

社内では、同じ種類の端末、安定した回線、業務時間中の落ち着いた状況で使います。外部の利用者は、古い端末、不安定な回線、移動中や接客の合間といった条件で使います。

読み込みに数秒かかる画面は、社内では気にならず、現場では致命的になります。文字の大きさ、タップ領域、通信が切れたときの挙動も同様です。この点はモバイルファーストUXの設計原則でも扱っています。

動機の偏り

社内の人には「うまくいってほしい」という動機があります。多少の不便は好意的に解釈し、詰まっても自力で解決しようとします。外部の利用者は詰まったら離脱します。

同じ操作の詰まりが、社内では「ちょっと分かりにくい」、市場では「使われない」という結果になる。この落差が、社内検証で最も見落とされる部分です。

見えるものと見えないもの

偏りを踏まえると、社内検証で扱える範囲がはっきりします。

左の列は、継続して使わないと現れないため、社内検証が最も力を発揮する領域です。右の列は、知識と動機を持たない人でないと観察できません。両方を同じ手段で賄おうとすると、どちらかを取り違えます。

自社が典型的な利用者かを確かめる

最も深刻な誤判断は、自社が対象利用者と大きく異なるのに、社内の使用感を根拠に仕様を決めてしまうことです。

判断の材料として、次の項目を対象利用者と社内で書き出して比べます。

• その業務にかける時間と頻度（日常業務か、月に一度か）
• 前提となる知識（業界用語、既存システムの理解、ITへの習熟）
• 判断の権限（自分で決められるか、承認が必要か）
• 使う状況（デスクか現場か、片手か両手か、中断されるか）
• 失敗したときの影響（やり直せるか、取り返しがつかないか）

仮に、店舗向けの発注管理サービスを開発しているとしましょう。実在の案件ではなく、説明のための想定です。社内で毎日使うことで、一覧の並び順や入力の手数といった問題は次々と見つかりました。一方で、実際の店舗では発注作業が営業終了後の疲れた時間帯に、他の締め作業と並行して行われます。この前提は社内では再現できず、「一画面で完結させる」という現場側の要求は、店舗を訪問して初めて明らかになりました。

こうした業務の前提を把握する手段として、UXリサーチのインタビューや現場観察があります。手法の詳細はUXリサーチの基本手法を参照してください。

社内の声が仕様を歪めるとき

もう一つの限界は、社内の要望が優先されすぎることです。社内の人は開発チームに直接話せるため、要望が通りやすく、対象利用者からは要望が届きにくいという非対称があります。

この非対称を放置すると、社内の業務に合わせた細かい設定項目や例外処理が積み上がり、外部の利用者には過剰で分かりにくいプロダクトになります。この問題は社内でだけ通用するプロダクトの罠で詳しく扱います。

対処は仕組みで行います。社内から上がった要望には「これは対象利用者にも当てはまるか」を確認する欄を設け、当てはまらないものは別の扱いにします。判断できない場合は、外部の利用者に確認するまで保留にします。優先順位の付け方は社内の不満を仕様に変える手順で整理しています。

やらないほうがよい社内検証

限界を超えた使い方をすると、検証は判断材料を増やすどころか、誤った確信を作ります。次の場合、社内検証は行わず、別の手段に切り替えるほうが結論を誤りません。

対象利用者の属性が社内と大きく離れている場合。 高齢の方向け、特定の資格を持つ専門職向け、ITに不慣れな層向けのサービスがこれに当たります。この場合、社内で使いやすかったという事実は、何の根拠にもなりません。それどころか「社内で問題なかった」という記憶が、外部での検証を省く理由に使われます。

社内に対象業務が存在しない場合。 業務がないところに無理に載せると、使うために業務を作ることになります。作られた業務には実際の締切も責任もないため、本番の負荷がかかりません。

検証の結果を誰も使わない場合。 判断する場も、判断する人も決まっていない状態で始めると、記録だけが溜まります。始める前に判断日を置けないなら、その時点で始めるべきではありません。

弊社がご相談を受けた際も、一つ目に当てはまる場合は社内検証をお勧めしません。費用のかからない手段なので提案しやすいのですが、この条件下では判断を誤らせる方向にしか働かないためです。代わりに、対象に近い方数名に実際に操作していただく形をご提案します。人数が少なくても、属性が合っているほうが判断の材料になります。

併用の設計

社内検証と外部検証は、どちらかを選ぶものではなく、担当する領域を分けて併用するものです。

• 社内検証：継続利用でしか出ない摩擦、データが溜まったときの挙動、費用と処理時間、使われない機能の特定
• 外部検証：初回の理解のしやすさ、用語と説明文、対象業務の前提、離脱が起きる箇所
• 現場観察：実際の利用環境、他の作業との並行、中断への対処

外部検証は大がかりに考えなくても始められます。対象に近い方に実際に操作してもらい、画面を見ながら考えていることを話してもらう。この形でも、社内では出てこない詰まりが見つかります。

限界を織り込んで使う

ドッグフーディングは、継続利用でしか現れない問題を見つける手段として有効です。同時に、知識・環境・動機の偏りにより、初回の理解しやすさや対象業務の前提については判断を誤らせます。

自社が典型的な利用者かどうかを先に確かめ、離れているほど外部検証の比重を上げる。社内から上がった要望には、対象利用者に当てはまるかの確認を挟む。この二つを守れば、社内検証は判断材料として機能します。

UXデザインや市場リサーチを含む検証設計についてご相談がありましたら、お問い合わせからお気軽にご連絡ください。