この記事の結論
- 自社が典型的な利用者でないとき、社内の使用感は判断を誤らせます
- 知識・環境・動機の三つの偏りが、社内検証の結果を実態からずらします
- 初回体験と例外的な状況の検証は、外部の協力者でしか代替できません
自社プロダクトを自分たちで使う取り組みは有効ですが、万能ではありません。むしろ、限界を知らずに使うと、社内での使いやすさを市場での使いやすさと取り違え、改善の方向を誤らせます。
本記事では、社内検証で見える問題と見えない問題を分け、外部検証と併用すべき境界を整理します。ドッグフーディングの定義そのものはドッグフーディングとは何をすることかで扱っています。
判断を歪める三つの偏り
社内の人がプロダクトを使うとき、外部の利用者とは決定的に違う条件が三つあります。
知識の偏り
社内のメンバーは、プロダクトの構造、用語、設計意図を知っています。画面に「ステータス: 保留」とだけ書いてあっても、それが何を意味し、次に誰が何をするのかを補って理解できます。外部の利用者には補う材料がありません。
この差は、説明文やラベルの検証をほぼ無効にします。社内で「分かりにくい」と言われなかったのは、分かりやすかったからではなく、知っていたからである可能性が高いのです。
環境の偏り
社内では、同じ種類の端末、安定した回線、業務時間中の落ち着いた状況で使います。外部の利用者は、古い端末、不安定な回線、移動中や接客の合間といった条件で使います。
読み込みに数秒かかる画面は、社内では気にならず、現場では致命的になります。文字の大きさ、タップ領域、通信が切れたときの挙動も同様です。この点はモバイルファーストUXの設計原則でも扱っています。
動機の偏り
社内の人には「うまくいってほしい」という動機があります。多少の不便は好意的に解釈し、詰まっても自力で解決しようとします。外部の利用者は詰まったら離脱します。
同じ操作の詰まりが、社内では「ちょっと分かりにくい」、市場では「使われない」という結果になる。この落差が、社内検証で最も見落とされる部分です。
見えるものと見えないもの
偏りを踏まえると、社内検証で扱える範囲がはっきりします。
| 見えやすいもの | 見えにくいもの |
|---|---|
| 毎日使うと現れる摩擦・手数の多さ | 初めて触る人がどこで詰まるか |
| データが溜まったときの破綻 | 用語や説明文の分かりにくさ |
| 例外ケースの発生頻度 | 対象利用者の業務の前提 |
| 実運用での費用や処理時間 | 端末・回線・利用環境の差 |
| 結局使われない機能 | 離脱の判断がどこで起きるか |
左の列は、継続して使わないと現れないため、社内検証が最も力を発揮する領域です。右の列は、知識と動機を持たない人でないと観察できません。両方を同じ手段で賄おうとすると、どちらかを取り違えます。
自社が典型的な利用者かを確かめる
最も深刻な誤判断は、自社が対象利用者と大きく異なるのに、社内の使用感を根拠に仕様を決めてしまうことです。
判断の材料として、次の項目を対象利用者と社内で書き出して比べます。
- その業務にかける時間と頻度(日常業務か、月に一度か)
- 前提となる知識(業界用語、既存システムの理解、ITへの習熟)
- 判断の権限(自分で決められるか、承認が必要か)
- 使う状況(デスクか現場か、片手か両手か、中断されるか)
- 失敗したときの影響(やり直せるか、取り返しがつかないか)
想定例:飲食店向けの発注管理サービスを開発している場面を考えます。社内で毎日使うことで、一覧の並び順や入力の手数といった問題は次々と見つかりました。一方で、実際の店舗では発注作業が営業終了後の疲れた時間帯に、他の締め作業と並行して行われます。この前提は社内では再現できず、「一画面で完結させる」という現場側の要求は、店舗を訪問して初めて明らかになりました。
こうした業務の前提を把握する手段として、UXリサーチのインタビューや現場観察があります。手法の詳細はUXリサーチの基本手法を参照してください。
社内の声が仕様を歪めるとき
もう一つの限界は、社内の要望が優先されすぎることです。社内の人は開発チームに直接話せるため、要望が通りやすく、対象利用者からは要望が届きにくいという非対称があります。
この非対称を放置すると、社内の業務に合わせた細かい設定項目や例外処理が積み上がり、外部の利用者には過剰で分かりにくいプロダクトになります。この問題は社内でだけ通用するプロダクトの罠で詳しく扱います。
対処は仕組みで行います。社内から上がった要望には「これは対象利用者にも当てはまるか」を確認する欄を設け、当てはまらないものは別の扱いにします。判断できない場合は、外部の利用者に確認するまで保留にします。優先順位の付け方は社内の不満を仕様に変える手順で整理しています。
併用の設計
社内検証と外部検証は、どちらかを選ぶものではなく、担当する領域を分けて併用するものです。
- 社内検証:継続利用でしか出ない摩擦、データが溜まったときの挙動、費用と処理時間、使われない機能の特定
- 外部検証:初回の理解のしやすさ、用語と説明文、対象業務の前提、離脱が起きる箇所
- 現場観察:実際の利用環境、他の作業との並行、中断への対処
外部検証は大がかりに考えなくても始められます。対象に近い方に実際に操作してもらい、画面を見ながら考えていることを話してもらう。この形でも、社内では出てこない詰まりが見つかります。
限界を織り込んで使う
ドッグフーディングは、継続利用でしか現れない問題を見つける手段として有効です。同時に、知識・環境・動機の偏りにより、初回の理解しやすさや対象業務の前提については判断を誤らせます。
自社が典型的な利用者かどうかを先に確かめ、離れているほど外部検証の比重を上げる。社内から上がった要望には、対象利用者に当てはまるかの確認を挟む。この二つを守れば、社内検証は判断材料として機能します。
チェックリスト
- 対象利用者と社内の属性の差を書き出したか
- 初めて触る人の様子を観察したか
- 社内知識なしで理解できる言葉になっているか
- 端末・回線・環境の差を確認したか
- 外部の協力者に見てもらう工程があるか
- 社内の意見が強すぎて要望が歪んでいないか
よくあるご質問
社内検証だけでリリースを判断してはいけませんか?
社内の利用者と対象利用者が近い場合(たとえば開発会社が開発者向けツールを作る場合)は判断材料になります。属性が離れているほど、外部の協力者による検証を併用する必要が高まります。
外部検証は何人くらいに見てもらえばよいですか?
案件により異なりますが、操作の詰まりを見つける目的であれば、対象に近い方に少人数ずつ、改善しては再度見てもらう進め方が現実的です。人数を増やすより、対象層に合っているかを優先します。
社内の意見が割れたときはどう判断しますか?
意見の強さではなく、その人が対象利用者にどれだけ近いかと、実際の利用記録で判断します。声の大きさで優先順位が決まると、社内だけに最適化された機能が増えていきます。
関連する記事
- PoC・検証ドッグフーディングとは何をすることか自社プロダクトを自分たちで使う「ドッグフーディング」の定義を、社内お試しとの違いから整理します。業務の本番として使い、不便でも旧手段に戻らない設計が、検証としての価値を生む理由を解説します。
- プロダクトUXリサーチの基本手法 — インタビュー・ユーザビリティテスト・分析ユーザーが本当に困っていることを知るための基本手法を整理します。インタビューの設計と誘導の避け方、ユーザビリティテストの観察、定量分析との組み合わせ、ペルソナの使い方、小規模チームでの現実的な進め方まで解説します。
- プロダクトモバイルファーストUXの設計原則 — スマホ完結型サービスの作り方1画面1目的、親指の届く範囲、入力削減、通信への配慮というモバイルファーストの原則と、登録・本人確認・決済・通知をスマホだけで完結させる設計、Webとネイティブアプリの使い分け、検証とアクセシビリティの考え方を解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開