不便な回避策は、自分自身の午後の作業が中断されたときによく浮き彫りになります。ファイル名を変更しないとアップロードできなかったり、通知が遅すぎたり、デザインレビューでは直感的に見えた設定を見つけるのに何度も試行錯誤したりすることです。実際の業務で製品を使ってみることで、デモでは決して見えてこない、そうした細かな不具合のリアルな影響を実感できます。
ドッグフーディングとは、組織が自社製品を改善するために社内で使うことを意味します。最も効果的なのは、従業員が実際に行う必要のある業務で使い、問題を報告してそれが解決されるプロセスが整っている場合です。単に安心感を得るためのアクティビティ数値を稼ぐだけの強制利用では、得られる価値ははるかに小さくなります。
社内利用で見えてくるもの
繰り返し使うことで、短いテストでは見落としがちな細部が明らかになります。蓄積されたデータ、作業の中断、スムーズにいかない引き継ぎ、そして毎日同じ無駄なステップを繰り返すストレスなどです。また、チームによって異なるデバイスや権限、作業スタイルが使われることで、新たな課題が見えてくることもあります。
例えば、自社のプロジェクト管理ソフトを使って採用キャンペーンを実施する企業を想像してみてください。マーケティング担当者や採用マネージャーは、管理者アカウントに慣れている開発チームが経験したことのない権限トラブルに直面するかもしれません。こうした気づきは、特定のワークフローに関する貴重な知見となります。ただし、初めて触れるユーザーが最初の利用時にその製品をどう理解するかまではわかりません。
問題が発生した状況(担当者の役割、アカウントの状態、何をしようとしていたかなど)を記録しましょう。社内の距離が近いと、ちょっとした雑談で済ませてしまいがちですが、文書化されていない修正は優先順位をつけにくく、忘れ去られやすいものです。目に見えるフィードバックループがあれば、従業員も「わざわざ気になる点を報告する価値がある」と確信できます。
「内部の視点」の限界
従業員は、製品の背後にある用語や意図、これまでの経緯をよく理解しています。プロダクトチーム以外のメンバーであっても、顧客には得られない説明を受けていることがあります。ニールセン・ノーマン・グループのドッグフーディングに関する考察でも説明されているように、そうした知識や慣れがあるため、ドッグフーディングをユーザー調査の代わりにすることはできません。
ドッグフーディングは、体系的な品質チェックやターゲットユーザーを対象とした調査と組み合わせて行うべきものです。その結果は、特にインターフェースの意味について従業員の間で意見が分かれた際などに、調査すべき新たな問いを与えてくれます。社内で問題なく使えたからといって、初めて訪れたユーザーが直感的に理解できるかどうかまでは保証できません。
また、日常的な社内導入に向かない製品もあります。専門的な医療システムや産業用システムを構築しているスタッフは、顧客と同じようにそれを使う機会が通常はありません。そうした環境で無理に日常利用を模倣しても、実態とはかけ離れた結果になってしまいます。大切なのは、社内利用によってどの現実的な利用状況を明らかにできるのか、そして、本来その製品が支えるべき実際のユーザーに直接アプローチしなければわからない部分はどこなのかを見極めることです。
