ドッグフーディング
追記 (2023/7/11)
ドッグフーディングという言葉について作者と同じ使い方をする人がいる一方で、違う使い方もあるとのことでした。（細かい説明はtwitter紹介のあとに記載してます）
『闘うプログラマー』という本があって、そこでは、DECからきたカトラーさんが、DECのOSのノウハウをもとに、Windows NTをつくるまでが描かれているのですが、その中で、作りかけのOS（WinNT）を使ってWinNTの開発を進めることをドッグフィーディングって言っています。https://t.co/7Ap9ERTo1o
— あきやま🪴 (@akiyama924) 2023年7月9日
Wikipediaが正しいかどうかは兎に角、日本のWikipediaにはたしかに、WNTで開発を重ねた事例ものってますね。https://t.co/HgaLzYhoxc
— higuchi_masaki@jurilog (@jurilog) 2023年7月10日
一方で、英語のWikipediaですと、WNT開発中に、自分たちで使った事例が載っています。なので両方の言い方ができるのかもしれませんね。https://t.co/HCpRB1l5dG
自分はまつさんと同じ捉え方をしてました。
— broccoli (@nihonbuson) 2023年7月10日
WNT開発中もWikipediaに書いてありますが、Paul Maritzの話も書いてあるし、そっちの方が由来になのかなと。
むしろWNT開発の話は、派生かと思いました。
なので、「社内運用テストとドッグフーディング」の勘違いとは言い切れなさそう。
私の理解でのドッグフーディングは「実際にユーザーとして使う」かなー。（闘うプログラマーも読みました）
— Yoshiki Ito/伊藤由貴 (@yoshikiito) 2023年7月9日
例えばバーチャルオフィスサービスの会社とかタスク管理ツールの会社とかが、リリースの前に自分たちの業務で実際に使って、機能不備見つけたり使い勝手についてフィードバックしたり。
ドッグフーディングが紹介されている「闘うプログラマー」では、WindowsNTを開発する際に、実際にプロダクトを使いながら開発を進めることを「ドッグフード」と呼んでいます。
カトラーがスケジュールをふりかざして、「自分たちがつくったドッグフードを食べる」よう指示した。カトラーは、半分は男らしさをみせるために、半分は常識的な判断から、「ドッグフード」を食べることを重視していた。つまり、「自分でつくったプログラムをつかう」べきなのだ。ドッグフードを食べていれば、NTの欠陥や不十分さから目をそむけることができなくなる。プログラマーは、自分の担当部分に没頭している間にも、NTの欠陥にぶつかる。プログラマーのコンピューターをNTで制御するようにすれば、NTのでき具合でプログラマーの仕事の環境が決まる。当初は、ドッグフード程度の味でしかないのであれば、ますますこれを食べるべきだ。プログラマーは、早急に品質をあげなければならないと実感し、すぐにコードのエラーを修正し、もっと信頼性の高いコードを書くようになるだろう。
出典：『闘うプログラマー[新装版] ビル・ゲイツの野望を担った男たち』Gパスカルザカリー著 山岡洋一役
これらのことから、ドッグフーディングの大枠としては
「自分たちのプログラムや製品を自分たちで使い、改善に活かすこと」
と言えそうです。
そこから適用方法として
- 日常的に使いながらプロダクトの改善に活かすのか（日常使いし改善しながら開発進行）
- 特定のタイミングで使ってプロダクトの改善に活かすのか
という違いがありそうです。
これは、どちらが正解でどちらが間違っているではなく、現場によって実施方法が異なると言えます。
「ドッグフーディングしよう」と話が上がってきたら「どのように実施しますか？」とみんなで認識合わせをしっかりとする必要がありそうです。
※
ちなみにマンガは一方の使い方を「これ！」と言ってしまうのも燃えそうなので、同人誌や本にはこの話の掲載は控えます。
ちょっと変更して「こういう適用方法があるよ」という紹介にすればよさそうだけど、悩みどころ。
----
ドッグフーディングは、自分たちが作ったアプリやサービスを主にリリース前に実際にユーザーとして使ってみることです。
ドッグフード販売会社の社員が、開発したドッグフードを実際に食べて製品の良し悪しを確認していたことが由来とのことです。
自社のモノを実際に使ってみることを言うのでやり方は無数にあります。
ですので、作者が経験した方法を記載しておきます。
自社の肝いりアプリ/サービスのリリース前の最終段階で、全社員に「使ってみてください～」で使ってもらって、アンケートで情報収集する、といった形でした。
メリットとしては、多種多様な実際の利用環境と利用タイミングで、社員の数だけある実際の使い方で使ってもらうことで、想定通り使ってもらえるのか、改善点や問題点は何かわかることです。
デメリットというか注意点としては……意外とみんなやってくれずにアンケートが集まらないことです(^-^;
他の社員も当然手伝ってくれるはず、と考えていると痛い目に遭います。
この場合は、例えばご褒美をつけるとか（この場合、次からご褒美がないとやってくれなくなる可能性も…)、上長に言って上層部が集まるMTGに議題を持って行ってもらって、各組織長からメンバーに「できるだけやってね」と言ってもらうような「政治」を行うことが考えられます。
大きな問題が見つかることも
なんでこんな大きな問題を見逃してた！？が見つかることもあります。
例えば、作者はその昔スマートスピーカーのQAを行っていたのですが、社員の皆様にドッグフーディングをしてもらったところ「子どもの声が認識されない（認識されにくい）」がありました。
これは単純に、子どもにテストをしてもらっていなかったからです。
（今思えば観点として挙がって当然なのですが、申し訳ないとしか言いようがない……）
他、例えば利用規約のような「出来上がるまでダミー入れておきます」部分の実装忘れなんかもあります。
テストをしていると「ここはモノが上がってくるのが当分後ですがどうします？」があるのですね。
そういったところはテスト項目にBlockを入れて飛ばしたりします。
そうするとチーム間で「そこはおかしくなってても一旦スルーの場所」という暗黙の了解になるのですね。
そうなったら最後、特に言及されなくなります。
ちゃんとタスク管理がされていたり、テストケースの管理がされていれば防げる問題なのですが、大きなプロジェクトは後半大体炎上しててテンパって放置されていることもあったりします。
そんなときドッグフーディングをするとチャットで「ここってこれであってます……？」なんて飛んできて気づいたりします。
あと、思い込みの使い方での見逃し、もあったりします。
ずっと開発、テストを続けていると「この機能はこう使う！」みたいな思い込みの使い方や手順になっている場所があったりします。
例えばゲームであれば、必ずこのアイテムを取ってからこの敵に挑むなど、
アプリであれば、設定項目は必ず上から設定するとか、必ずカメラロールに写真を準備してからプロフの編集をするなど。
そうすると、順番を変えるとバグる、に気づかないなどがあります。
先ほどの例え話で言えば、プロフ編集中にアプリをバックグラウンドにしてカメラを起動、ちいかわの写真を撮ってからプロフ編集画面に戻したら画面真っ白……などでしょうか。
これは使えば使うほど罠にハマります。
こういった思い込みの部分は気づくことが難しいのですが、ドッグフーディングでユーザーとして使ってみると意外と見つかったりします。
