ドッグフーディングとは何をすることか

自社のプロダクトを自分たちで使ってみる。この取り組みは「ドッグフーディング」と呼ばれ、多くの開発組織が取り入れています。しかし実際には、「一度使ってみたが特に問題なかった」で終わる例が少なくありません。原因の多くは、言葉の理解そのものにあります。

本記事では、ドッグフーディングが何をすることを指すのか、社内での試用とどこが違うのかを整理し、検証手段として成立させるための条件を確認します。

「社内で使う」だけでは検証にならない

ドッグフーディング（dogfooding）は、自社が提供するものを自社で消費するという意味の表現です。ここで誤解が生じやすいのは、「社内で使う」という部分だけが伝わってしまうことです。

社内の何人かに配って感想を集める取り組みは、試用（トライアル）です。これはこれで有用ですが、得られるのは「触ってみた印象」であり、使い続けた先に現れる問題は見えません。画面が分かりにくいといった一目で分かる欠陥は拾えても、「毎日使うと3回に1回だけ引っかかる」「月末になると処理が間に合わない」といった、頻度と時間に依存する問題は表に出ません。

もう一つの落とし穴は、感想を求められた社内の人が親切に振る舞うことです。作っている同僚の前で「これは使えない」と言うのは気が重く、「いいと思います、慣れれば大丈夫そうです」という評価に落ち着きがちです。試用の枠組みでは、この善意が検証の精度を下げます。

業務の本番として使う、という条件

ドッグフーディングを検証として成立させる条件は、対象のプロダクトを業務の本番として使うことです。つまり、そのプロダクトで作った成果物が実際に外部へ出ていき、そのプロダクトに入れたデータが実際の記録になる状態を指します。

• 実際の顧客への提案資料を、そのプロダクトで作る
• 実際の請求や勤怠の記録を、そのプロダクトに入れる
• 実際の問い合わせ対応を、そのプロダクトの画面で行う

この状態になると、使う側にとって不具合は「報告すべき事項」ではなく「今日の仕事が止まる事態」に変わります。指摘の質と速度が一段変わるのはこのためです。

想定例：社内の稟議申請を自社ツールに載せた場面を考えます。試用段階では「申請の入力が少し面倒」という感想だけでしたが、本番として運用に切り替えると、承認者の不在時に申請が完全に止まること、月末に申請が集中すると一覧の並び順が実用に耐えないことが初日から問題になりました。どちらも試用では出てこなかった論点です。

退路を断つ、という設計

もう一つの条件は、旧手段への退路を断つことです。新しいツールと並行して従来の表計算ファイルや紙の運用を残しておくと、人は不便を感じた瞬間に慣れた方へ戻ります。戻れる限り、不便は「使わない理由」にはなっても「直すべき課題」としては積み上がりません。

退路を断つとは、次のような状態を指します。

ここで注意したいのは、退路を断つことと、逃げ道を一切用意しないことは違うという点です。業務が完全に止まったときの復旧手順（手作業での処理、データの退避先、旧システムを一時的に戻す判断者）は必ず決めておきます。決めた上で、「面倒だから戻る」を許さないのが退路を断つという意味です。

何を確かめるために使うのか

ドッグフーディングで得られるものと、得られないものを分けて考えます。

得られるのは、継続利用でしか現れない情報です。毎日の操作のうちどこが摩擦になるか、どの機能が結局使われないか、データが溜まってきたときに何が破綻するか、例外的なケースがどのくらいの頻度で発生するか。こうした情報は、仕様書の段階では書きようがなく、短時間の試用でも見えません。

一方、得られないものもあります。自社が対象顧客と異なる場合、業務の前提が違うため、判断を誤らせる恐れがあります。この境界については、ドッグフーディングの限界と誤判断で詳しく整理します。

使えないなら、やらない方がよい

ドッグフーディングは万能ではありません。次の場合は、無理に行わない方が結論を誤りません。

• 自社にその業務が存在しない：使う必然性がないため、形だけの利用になります
• 対象利用者が自社と大きく異なる：たとえば高齢の利用者向けサービスを若手中心の社内で検証しても、操作の難所を見誤ります
• 業務を止められない：基幹に近い業務で代替手段を用意できない場合は、対象を周辺業務に限定します

この場合は、UXリサーチの手法で外部の利用者に使ってもらう検証や、限定公開での試験運用に切り替えます。自社で使えないことは失敗ではなく、検証手段の選択の問題です。

定義を揃えることが最初の一歩

ドッグフーディングとは、自社プロダクトを業務の本番として使い、不便でも旧手段に戻らない状態で使い続けることです。「社内で使ってみる」との差は、成果物が実物であること、退路を断っていること、そして期間と判断の日が決まっていることの三点にあります。

この定義をチームで揃えないまま始めると、「やったが何も出てこなかった」という結果になりがちです。定義を揃えた上で、始め方についてはドッグフーディングの始め方を参照してください。

自社プロダクトの検証の進め方や、Webシステム開発・AI活用開発における検証設計についてご相談がありましたら、お問い合わせからお気軽にご連絡ください。