# ドッグフーディング — 自社製品を自分で使い倒して品質を鍛える > ドッグフーディング（自社製品を従業員自らが日常で使う実践）とは何か——語源（Alpo の CM と Microsoft の Paul Maritz）、Windows NT / Exchange で品質を鍛えた歴史、フィードバック速度という最大の恩恵と「開発者バイアス／NIH シンドローム」という副作用、二段階＋CI/CD で崩さない進め方、Facebook・サイボウズ・DoorDash・トヨタの事例、そして運用を形骸化させないための 7 原則までを一気に押さえます。最後に、このサイト自身がどうドッグフーディングされているかを実例として開きます。 - 出典: SUZ-LAB（解説トピック） - URL: https://suz-lab.co.jp/topics/dogfooding - 公開: 2026-07-07 - 更新: 2026-07-07 - タグ: #ドッグフーディング #プロダクトマネジメント #品質保証 #PMF #一次情報 #SUZ-LAB --- **ドッグフーディング**（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（1991〜）。** Dave Cutler の下、200 人超の開発者が、毎日ビルドされる最新の不安定な NT を 自らの開発ワークステーションに導入することを義務付けられた。ビルドを壊せば大きな不名誉、かつ同僚の業務を 止めるという強い社会的プレッシャーが働き、堅牢なコードを即座に出す動機付けになった。 **Exchange（1993〜）。** 社内メールを Unix 系（Xenix）から自社製 Exchange へ移す際、テスト環境自体に "Dogfood" のコードネームが付いた。出荷後も社内で使い倒すなかで 1997 年に起きた **「Bedlam DL3」**（メール大量滞留・ システムダウン）という障害が、重複メールの自動処理やネットワーク復旧などエンタープライズ級の仕様を 組み込む契機になった。「自ら作った不完全さに身を晒して信頼性を担保する」——回転する鋸刃に自分の指を 入れて安全技術 SawStop が本当に効くことを自ら確かめた Steve Gass と同じ精神が、業界の標準文化になった。
同じ実践でも、組織の文化によって呼び名が変わる。粗削りな環境でも使い倒す不退転の姿勢を強調する 「dogfood」に対し、上質さを祝福とともに味わう「champagne」など、ニュアンスは対照的だ。 | 呼び名 | 提唱・出所 | ニュアンス | | --- | --- | --- | | Eating our own dog food | Microsoft / Paul Maritz | 粗削りで過酷な環境でも自ら使い、品質を現場で鍛える不退転の姿勢 | | Drinking our own champagne | Pegasystems ほか | 誇れる上質な「シャンパン」を祝福とともに自ら楽しむ前向きな姿勢 | | Icecreaming | Microsoft / Tony Scott | 顧客が喜んで消費したくなる「美味しいアイス」のような魅力の追求 | | Eating our own cooking | IBM 等レガシーテック | 自ら調理した味を確かめ、微調整する職人的な品質保証 | | Self-hosting | OS／コンパイラ開発 | 作ったコンパイラや OS を、次バージョン自体の開発環境に使う再帰的検証 | ## 効果とリスク — 諸刃の剣として理解する 最大の恩恵は **フィードバック速度の極大化**だ。一般リリース後のフィードバックは、アンケートや 問い合わせ窓口を経由するため特定と分析に時間がかかり、外部ユーザーが本音の不満を言葉にしてくれるとも 限らない。同じ組織の従業員が検証者なら、使い勝手の悪さを生々しい言葉で即座に開発へ差し戻せる。 機能を凍結（フリーズ）する前に本質的な修正を入れられれば、手戻りの工数と設計変更コストを最小化できる。 一方、社内利用だけに過度に依存すると特有の歪みが出る。ここを理解せずに回すと、ドッグフーディングは たやすく逆効果になる。 - **開発者バイアス。** 社内の人間は前提知識とリテラシーを最初から持つため、初見ユーザーの認知負荷や 「迷い」を客観視できなくなる。致命的なユーザビリティの盲点が生まれる。 - **ワークアラウンドの常態化。** 技術者は欠陥に無意識で回避策を編み出して適応してしまう。繰り返すと 使い勝手の悪さが「仕様」として社内で正当化され、直すべき摩擦が放置される。 - **モノカルチャーと NIH シンドローム。** 自社製の利用を強制する環境では、競合の優れた代替ツールを 比較評価する機会が失われる。最悪の場合「自社製でない技術は信用しない」（Not Invented Here）に陥り、 適応力を落とす。 - **超初期の強制はデモラライゼーションを招く。** 品質が安定しないうちから使用を強いると、日常の生産性を 著しく削り、疲弊とモチベーション低下を生む。 だからこそ、社内ドッグフーディングと外部テストは**役割が違う**。片方でもう片方を代替できない。 | 観点 | 社内ドッグフーディング | 外部テスト | | --- | --- | --- | | 対象 | 開発者・各部門の従業員 | 一般モニター・事前登録ユーザー | | 開始時期 | 開発初期〜機能凍結直前の任意フェーズ | 動作が安定した最終ビルド（RC）以降 | | フィードバック | 迅速・率直・仕様の根本に及ぶ | 市場ニーズに沿うが断片的、エラー報告が主 | | 主目的 | 開発効率・UX の直感的改善・信頼性 | 市場適合性の最終検証・スケーラビリティ | | 最大のリスク | 自社技術への盲信・リテラシー乖離・回避策の常態化 | 情報漏洩・ブランド毀損・バグによる離脱 | ## 崩さない進め方 — 二段階検証と継続デプロイ リスクを抑える定石は、いきなり全社適用せず、評価範囲を段階的に広げることだ。 1. **個別機能検証。** システム全体は安定版で動かしつつ、新しく設計した特定機能**だけ**を開発チームなど ごく狭い範囲に追加し、部分的な動作と UX を徹底検証する。 2. **複合統合検証。** 単体を通った複数の新機能を 1 つのプレリリースビルドに統合し、より広い社内へ 段階的に公開して、相互作用と全体の耐久性を評価する。 もう一つ効くのが **CI/CD による継続デプロイ**だ。Atlassian のアジャイルなドッグフーディング論によれば、 検証ビルドは「数ヶ月に一度の一括ダンプ」ではなく、社内サーバーへ**常に自動で継続デプロイ**される仕組みが 不可欠だ。四半期に一度、未完成のシステムを目の前に置かれると、同僚は混乱し「不便の押し付け」として 拒絶反応が起きる。小さく・頻繁に流し続けることが、受け入れられるドッグフーディングの条件になる。
- **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](/vmost#strategy) は 「一次情報で語る」を掲げ、[Tactics](/vmost#tactics) の行動原則は 「**まず、やってみる**」「**体験を、正直に語る**」を置く。借り物ではなく自分で確かめた体験だけを発信する ——これは「自ら作ったものを自ら使い、その一次体験を差し戻す」というドッグフーディングの定義と重なる。 理念のレベルで、このラボはドッグフーディングを前提に設計されている。 **2. 「やってみる」は、機能の検知器でもある。** ショーケースを作った実験ログで、記事に表を書くまで **ログ基盤が GFM テーブルに対応していないこと**に気づかなかった、と正直に記録している （[制作物ショーケースを組む](/logs/building-showcase-gallery)）。書いて出して初めて分かる欠けがある—— これはまさに開発者バイアスを、自分で使うことで突破した瞬間だ。この記事の表組みが崩れず読めているのは、 その一次体験が基盤の改善につながったからにほかならない。 **3. 「自分の器」を、自分の仕事に使っている。** このサイトは SUZ-LAB の [VMOST を Roadmap・Log と一本の線でつなぎ](/logs/connecting-vmost-roadmap-logs)、自らの生き方の設計図を運用する道具として 日々使われている。器を作って放置するのではなく、器で自分の営みを回す——self-hosting に近い再帰だ。 **4. 記事が、題材を自ら実演する。** [JSON-LD の解説記事](/topics/json-ld-structured-data)は、 JSON-LD の理論を説きながら、そのページ自身が JSON-LD で構造化されている。「動いている実例として見せる」 という姿勢は、ドッグフーディングの本質——**自分の主張を、自分で使って証明する**——の情報設計版だ。 ただし、このラボは一人の実践の場でもある。原則で言えば **開発者バイアスとモノカルチャーが最も効きやすい 環境**だ。だからこそ「体験を、正直に語る」で難しさもそのまま出し、外の一次情報（読者の反応や外部の ベストプラクティス）と突き合わせることを、意識して運用の型に組み込んでいる。 --- **まとめ。** ドッグフーディングは、最も厳しく最も協力的な「最初の顧客＝自分」に製品を渡し、 速いフィードバックループで品質を最高に引き上げる手法だ。効くのは **フィードバック速度**、崩すのは **開発者バイアス・回避策の常態化・NIH**。だから外部テストと役割を分け、二段階＋継続デプロイで 安全に広げ、7 原則で形骸化を防ぎ、迷ったら**引き算（KISS／ソユーズ型）**を選ぶ。SUZ-LAB は 「まず、やってみる」「体験を、正直に語る」という行動原則そのものとして、このサイトを自ら使い倒している。 考え方の全体像は [VMOST とは](/topics/vmost)、実際にやってみた記録は [実験ログ](/logs) にある。