ドッグフーディング — 自社製品を自分で使い倒して品質を鍛える

ドッグフーディング（dogfooding／"eating our own dog food"）とは、開発中あるいはリリース前の 自社製品を、自社の従業員が日常業務や実生活の中で能動的に使い、検証する組織的な実践だ。 単なるバグ検出を超えて、実際のユーザーと同じ文脈で製品を体験することで、机上のテストでは 決して見えない摩擦や潜在ニーズを浮かび上がらせる。

現代では、これは プロダクトマーケットフィット（PMF）の診断ツールでもある。製品が本当に 課題を解いているなら、従業員は指示されるまでもなく自然に使い続ける。逆に社内での自発的な 利用が進まないなら、それは「実在しない課題を解こうとしている」——PMF の欠如を早期に告げる 警告灯になる。この記事は、ドッグフーディングの歴史と原理、効果とリスク、そして 崩さず運用する型を押さえ、最後に このサイト自身がどう実践しているかを実例として開く。

語源と歴史 — 「犬はそのドッグフードを食べるか？」

言葉の起源は 1970〜80 年代前半、アメリカのドッグフード Alpo の TV CM に遡る。俳優 Lorne Greene が 製品の栄養価を称賛したうえで「自分の愛犬にもこれを与えている」と語った。Kal Kan の社長が株主総会で 自社の缶詰を実食してみせた逸話も、この概念の源流として知られる。

IT 業界の哲学として定着したのは、1980 年代後半の Microsoft だ。同社の Jim Harris は製品の成否を問う際、 「Yes, but will the dogs eat the dog food?（確かにそうだが、果たして犬はそのドッグフードを食べるか？）」 と繰り返した。どれほど精緻な技術説明よりも、実ユーザーがその価値を受け入れるかが最終試験だ、という 本質を突く問いだ。1988 年、ネットワーク市場で苦戦するなか、マネージャーの Paul Maritz が、LAN Manager の テストマネージャー Brian Valentine に「Eating our own Dogfood」という件名のメールを送る—— 「外部顧客を獲得できないなら、我々自身が最初の顧客になるべきだ」。Valentine は社内の主要ファイル サーバーを \\dogfood に改名し、全員にこの不安定な新サーバーを常用させた。

Windows NT と Exchange — 自ら危険に身を晒して信頼性を鍛える

Windows NT（1991〜）。 Dave Cutler の下、200 人超の開発者が、毎日ビルドされる最新の不安定な NT を 自らの開発ワークステーションに導入することを義務付けられた。ビルドを壊せば大きな不名誉、かつ同僚の業務を 止めるという強い社会的プレッシャーが働き、堅牢なコードを即座に出す動機付けになった。

Exchange（1993〜）。 社内メールを Unix 系（Xenix）から自社製 Exchange へ移す際、テスト環境自体に "Dogfood" のコードネームが付いた。出荷後も社内で使い倒すなかで 1997 年に起きた 「Bedlam DL3」（メール大量滞留・ システムダウン）という障害が、重複メールの自動処理やネットワーク復旧などエンタープライズ級の仕様を 組み込む契機になった。「自ら作った不完全さに身を晒して信頼性を担保する」——回転する鋸刃に自分の指を 入れて安全技術 SawStop が本当に効くことを自ら確かめた Steve Gass と同じ精神が、業界の標準文化になった。

同じ実践でも、組織の文化によって呼び名が変わる。粗削りな環境でも使い倒す不退転の姿勢を強調する 「dogfood」に対し、上質さを祝福とともに味わう「champagne」など、ニュアンスは対照的だ。

効果とリスク — 諸刃の剣として理解する

最大の恩恵は フィードバック速度の極大化だ。一般リリース後のフィードバックは、アンケートや 問い合わせ窓口を経由するため特定と分析に時間がかかり、外部ユーザーが本音の不満を言葉にしてくれるとも 限らない。同じ組織の従業員が検証者なら、使い勝手の悪さを生々しい言葉で即座に開発へ差し戻せる。 機能を凍結（フリーズ）する前に本質的な修正を入れられれば、手戻りの工数と設計変更コストを最小化できる。

一方、社内利用だけに過度に依存すると特有の歪みが出る。ここを理解せずに回すと、ドッグフーディングは たやすく逆効果になる。

• 開発者バイアス。 社内の人間は前提知識とリテラシーを最初から持つため、初見ユーザーの認知負荷や 「迷い」を客観視できなくなる。致命的なユーザビリティの盲点が生まれる。
• ワークアラウンドの常態化。 技術者は欠陥に無意識で回避策を編み出して適応してしまう。繰り返すと 使い勝手の悪さが「仕様」として社内で正当化され、直すべき摩擦が放置される。
• モノカルチャーと NIH シンドローム。 自社製の利用を強制する環境では、競合の優れた代替ツールを 比較評価する機会が失われる。最悪の場合「自社製でない技術は信用しない」（Not Invented Here）に陥り、 適応力を落とす。
• 超初期の強制はデモラライゼーションを招く。 品質が安定しないうちから使用を強いると、日常の生産性を 著しく削り、疲弊とモチベーション低下を生む。

だからこそ、社内ドッグフーディングと外部テストは役割が違う。片方でもう片方を代替できない。

崩さない進め方 — 二段階検証と継続デプロイ

リスクを抑える定石は、いきなり全社適用せず、評価範囲を段階的に広げることだ。

1. 個別機能検証。 システム全体は安定版で動かしつつ、新しく設計した特定機能だけを開発チームなど ごく狭い範囲に追加し、部分的な動作と UX を徹底検証する。
2. 複合統合検証。 単体を通った複数の新機能を 1 つのプレリリースビルドに統合し、より広い社内へ 段階的に公開して、相互作用と全体の耐久性を評価する。

もう一つ効くのが CI/CD による継続デプロイだ。Atlassian のアジャイルなドッグフーディング論によれば、 検証ビルドは「数ヶ月に一度の一括ダンプ」ではなく、社内サーバーへ常に自動で継続デプロイされる仕組みが 不可欠だ。四半期に一度、未完成のシステムを目の前に置かれると、同僚は混乱し「不便の押し付け」として 拒絶反応が起きる。小さく・頻繁に流し続けることが、受け入れられるドッグフーディングの条件になる。

事例 — Facebook の droidfooding、サイボウズの発見、DoorDash の現場体験

• Facebook（現 Meta / 2012）。 従業員の多くが快適な iOS 版を使い、世界の大半を占める Android ユーザーの劣悪な体験に無自覚だった。そこで同社は「Do you 'droidfood'?」と掲げた社内キャンペーンで iPhone から Android への乗り換えを従業員に呼びかけ、端末を振るだけで不具合を報告できるツール 「Rage Shake」を配った。強制ではなく自発を促す形で、当時 iOS 版に見劣りしていた Android 版を 社員自身に使い倒させ、当事者としての危機感から UX 改善につなげた。
• サイボウズ（kintone）。 自社の全業務基盤として kintone を全面利用するなかで、ある管理者が フィールドコードを変更しても API がエラーを返さず「無言で通過」し、下流の DWH に一部データが連携 されない不整合を発見。この自社運用のトラブルが、仕様とエラーハンドリングを洗練させる契機になった。
• DoorDash（WeDash / 2015〜）。 CEO を含む事務職全員が原則 月 1 回（時期により頻度は調整）、実際に配達員（Dasher）として稼働する 制度。コードやアルゴリズムの変更が現場のスマホでどう見え、受け渡しでどんな摩擦を生むかは、オフィスからは 見えない。エンジニアの反発を受けつつも、身体感覚でユーザー視点を掴む方針として維持されている。
• トヨタ自動車。 試作車から量産直前の車両まで、経営幹部やトップエンジニア自らがステアリングを握り、 日常の所用や限界テストで乗り味と安全性を身体で評価する。

運用の 7 原則 — 「不満の押し付け合い」にしないために

ドッグフーディングは、放っておくと「感情的な不満」や「無価値なフィードバックの乱発」に崩れる。 それを防ぐ実践的なフレームワークが、次の 7 原則だ。

1. 対象と事実の厳密な定義。 指摘は「どこで／何をしようとして／何に躓いたか」の 3 要素で客観化し、 用語集で呼称を揃える。そして**要件（表面的な変更案）ではなく要求（最終的に何がしたかったか）**を 抽出する。解決策を考えるのは専門家の仕事だ。
2. 感情を排したフラットな記述。 「イライラする」「最悪だ」を排し、動作の結果を無機質に列挙する。 作り手の心理的安全性を守り、共に磨くパートナーの関係を保つ。
3. 架空ニーズの排除と多様化。 「初心者ならこう感じるだろう」という憶測は却下し、自分が体験した事実 だけを扱う。レビュワーには営業・法務・総務など前提知識の薄い他部門も入れる。件数ベースの KPI は 廃止する（ノイズを量産させないため）。
4. レビュワーを「顧客」にしない。 社内の声は「必ず実装する特注要求」ではなく、顧客体験を代弁する 生データにすぎない。最大多数にとっての理想を追う。
5. 専門性のリスペクト。 ユーザー視点の重視と、プロの判断の軽視は別物だ。「ユーザーが言うから全部その 通りに」というしろうと信奉は、プロダクトの整合性を壊す。素人の意見と専門家の設計を対等に議論させる。
6. デザインの引き算（KISS）。 使いにくさの指摘に、説明文やヘルプ、例外設定を足すと、視覚要素が 増えて認知負荷はむしろ上がる。原因になっている要素を**引く（削る）**ことをまず検討する。
7. 一括回収と事後フィルタリング。 ルールを厳格にしすぎると気軽に投稿できなくなる。初期は制約なしで 何でも書き留めてよいことにし、モデレーターが後から重複統合・事実確認・架空ニーズ除外を行う二段構えにする。

ソユーズ vs スペースシャトル。 徹底して機能を削ぎ落としたソユーズは、半世紀以上も基本設計のまま 高い信頼性で現役だ。対して約 250 万点の部品を積んだスペースシャトルは、その極端な複雑さが脆さに直結し、 5 機中 2 機を事故で失い早期退役した。指摘のたびに機能を「足す」と、プロダクトはシャトル化する—— 引き算（原則 6）は、長く愛されるシステムの背骨だ。

このサイト自身のドッグフーディング

ここまでの原理は、抽象論ではない。このサイト（apps/web）と SUZ-LAB の作り方そのものが ドッグフーディングでできている。

1. 行動原則が、そのままドッグフーディングだ。 SUZ-LAB の Strategy は 「一次情報で語る」を掲げ、Tactics の行動原則は 「まず、やってみる」「体験を、正直に語る」を置く。借り物ではなく自分で確かめた体験だけを発信する ——これは「自ら作ったものを自ら使い、その一次体験を差し戻す」というドッグフーディングの定義と重なる。 理念のレベルで、このラボはドッグフーディングを前提に設計されている。

2. 「やってみる」は、機能の検知器でもある。 ショーケースを作った実験ログで、記事に表を書くまで ログ基盤が GFM テーブルに対応していないことに気づかなかった、と正直に記録している （制作物ショーケースを組む）。書いて出して初めて分かる欠けがある—— これはまさに開発者バイアスを、自分で使うことで突破した瞬間だ。この記事の表組みが崩れず読めているのは、 その一次体験が基盤の改善につながったからにほかならない。

3. 「自分の器」を、自分の仕事に使っている。 このサイトは SUZ-LAB の VMOST を Roadmap・Log と一本の線でつなぎ、自らの生き方の設計図を運用する道具として 日々使われている。器を作って放置するのではなく、器で自分の営みを回す——self-hosting に近い再帰だ。

4. 記事が、題材を自ら実演する。 JSON-LD の解説記事は、 JSON-LD の理論を説きながら、そのページ自身が JSON-LD で構造化されている。「動いている実例として見せる」 という姿勢は、ドッグフーディングの本質——自分の主張を、自分で使って証明する——の情報設計版だ。

ただし、このラボは一人の実践の場でもある。原則で言えば 開発者バイアスとモノカルチャーが最も効きやすい 環境だ。だからこそ「体験を、正直に語る」で難しさもそのまま出し、外の一次情報（読者の反応や外部の ベストプラクティス）と突き合わせることを、意識して運用の型に組み込んでいる。

---

まとめ。 ドッグフーディングは、最も厳しく最も協力的な「最初の顧客＝自分」に製品を渡し、 速いフィードバックループで品質を最高に引き上げる手法だ。効くのは フィードバック速度、崩すのは 開発者バイアス・回避策の常態化・NIH。だから外部テストと役割を分け、二段階＋継続デプロイで 安全に広げ、7 原則で形骸化を防ぎ、迷ったら**引き算（KISS／ソユーズ型）**を選ぶ。SUZ-LAB は 「まず、やってみる」「体験を、正直に語る」という行動原則そのものとして、このサイトを自ら使い倒している。 考え方の全体像は VMOST とは、実際にやってみた記録は 実験ログ にある。