ソフトウェア開発における「ドッグフードを食べる」とは、ソフトウェアの開発者もしくはその会社が、自分たちが開発したソフトウェアを実際に業務などで使用することです。要は自らを実験台にするわけです。有名なのはマイクロソフトのドッグフードです。どこよりも早く MS 製品を使い始めるわけですから、命がけ（？）ですね。(^^;　それゆえあれだけ複雑な製品をそれなりの品質で提供できているともいえます。

ソフトウェアをドッグフードしなければいけない理由より

ソフトウェアのドッグフードというのは、開発を継続できる最大の武器だよね。自分がアプリを開発していけるのは、自分で日常的に使ってるから、というのが大きい。バグだってどんどん見つかるし、改善すべき点も見えてくる。自分は使わずに誰かの為に開発しているソフト、なんてものを私は信じない。何年何十年と粘着的に考え続け使い続け、開発するからこそ見えてくる何かがあるはずだ。

自分は使わずに誰かのために開発しているソフト、例を挙げると「オーダーメイドの業務アプリ」です。システムを内製できる会社はそれほど多くないので、業務システムは外部の企業に発注するわけですが、そうした請負の会社でドッグフードして実業務で使用してから納品なんて話はあまり聞きません。（「あまり」と書いたのは、システムそのものをドッグフードしないのであれば、たとえばソリューションのドッグフードなどは行われているケースがあるからです。）

---

「自分のこだわりを形にしたソフトを他の人に広めていく」という話は優れた開発者、とりわけセンスの良い開発者には許されるかもしれませんが、私のような平凡なエンジニアにとっては、もう少し「エンジニアリング」に落とし込む必要があります。言い方は悪いですが、「自分のスキル・モチベーションではこだわりようのないシステム」でさえ、いい品質で開発しなくてはプロとは言えません。

ドッグフードには、ユーザビリティの改善という意味以上に致命的なバグの発見などといった意味合いがあります。それゆえ、自身が一番のヘビーユーザになってリスクを取るというのは非常に良い戦略です。しかし、開発者が一番のヘビーユーザにならないケースというのは枚挙にいとまがないほどあります。オーダーメイドシステムでなくても、オフィスソフト、ウィルスやスパム対策ソフト、ブログ、ソーシャルブックマークなどなど、きりがないのでこの辺にしておきます。

そもそも、開発者が一番のヘビーユーザになるようなソフトはそれほど多いのでしょうか。

致命的なバグの回避という意味では「テストに関するエンジニアリング」、使い勝手の向上では「ユーザビリティテストに関するエンジニアリング」などによって、属人性を排した方法も徐々に進歩しつつあります。ドッグフードもテストに関するエンジニアリングアプローチの一つでしかありません。

ドッグフードはいい戦略です。しかし、どれくらい良い戦略であるかを心意気以外の理由で説明できる人は多くありません。知識ゼロから学ぶ ソフトウェアテスト（p129、表2：手法によるバグの発見率）によると、小規模なベータテストは統合テストに匹敵するほどのバグ発見率を持っているようです。ドッグフードはこの辺に相当するでしょうか。

はてな界隈には優れた開発者がたくさんいます。こうした開発者の中にはソフトを一人で作るということで示されるようなメンタリティを持った人がいます。（割合はわかりませんし、私も持っています。）ドッグフードもまた、こうした文脈で理解されるため、エンジニアリング的な側面よりも優先される何か「心意気」のようなものを感じてしまいます。

でも、私はエンジニアなので、ソフトウェア開発はエンジニアリングを通して見つめたいと強く感じました。だから、ドッグフードを語るのならエンジニアリングで語ります。ソフトウェア開発の世界ではこれはあまりに難しいのだけど。