ウェブの Dogfooding

ウェブ開発では dogfooding の重要性、というか特異性が際立たなくなったと感じていた。ただ今のチームはウェブ開発と違うところが多く、dogfooding を見直した。

ウェブ開発での dogfooding は簡単である。開発中のソフトウェアを配るのに特別な仕組みがいらず、適当にホストした dev.example.com みたいなバージョンにアクセスすればいいし、開発もインクリメンタルでリリースが頻繁なため開発版とはいえそれほど派手に壊れない。使いはじめるバーも、使い続けるバーも低い。

そしてユーザの行動履歴を集めて集計するのが簡単。なので自分で使って良し悪しを判断するよりたとえばベータ版やインクリメンタルなデプロイ, dark launch などを使い実際に撒いて試す方が良い部分が増えていく。エッジケースでのクラッシュでもユーザにちょっと配るだけですぐわかる。逆にテストについても、dogfood とか言う前に自動テストでカバーしといてくれや、という空気がある。

もちろん実際のユーザに配る時点でわかっても手遅れな問題は沢山あるし、自動テストでは捕獲できずデプロイしないと現れないバグも沢山ある。だから dogfood に意味はあるし、やったほうがよい。ただなんというか、騒ぐような特別なものではない感じがする。「ドッグフードしてます！」とか言われても、あっそう、くらいにしか思えなかった。自分は勤務先アカウントでさわる職場のウェブアプリはすべて dogfood 版なはずだが、だからどうという感じもしない。UI が刷新されたとき、たまにオッとなるくらい。

OS の Dogfooding

自分のチームが開発しているのは OS 付属品というか特定電話機付属のアプリで、いちおう Play Store 経由でアップデートできるがそれでも年に数回しかリリースしない。そして下で動いているOSは基本的に年に一回しかリリースしない。フォローアップのマイナーリリースが追加で一回くらいとセキュリティパッチはあるけれど、とにかくリリースが少ない。そして複雑な割に自動テストが手薄。これらせいだけではないけれど、リリースから遠く離れた時期の開発バージョン OS は割と派手に壊れる。

テストがしょぼいのはさておき、リリース頻度が低いのはスマホの OS という性質を考えると割と仕方なく、同情の余地はある。更に OS とアプリ群の interaction はアプリ単体とは桁違いに複雑なので、ちょっとプログラマが自動テストを追加したくらいでは全然カバーできない。

ちょっとではなく沢山自動テストするというアプローチはありうる。たぶん Windows のような歴史のある OS は色々とがんばっていることだろうし、他の OS も成熟の過程で同じ進化を遂げるだろう。でもここはまだ進化の手前というか途中。

そういう世界では dogfooding が未だに特別な意味を持っている。つまり、テストではカバーできない問題を見つけてくれる。そして被験者として dogfood に手を染めるは普通に大変である。よく壊れるから。ウェブとは違うし、単体のアプリとも違う。自分のいるチームが作っているのは単体のアプリだけれど hardware への依存が高い上に resource intensive なので OS の人々と協力して問題にとりくむ機会が多い。

Be Good At Dogfooding

アプリほど気楽に撒けない制限だけが dogfooding の価値を高めているわけでもない。プライバシーやら帯域やらの理由で、ユーザから集められるデータには限りがある。そしてクラッシュみたいなわかりやすい問題のデータは集めることができるけれど、なんか遅いだとか UI がおかしいみたいな相対的に小さいが無視はできない問題のデータを集めるのは不可能ではないにせよ難しい。

Dogfooding はこうした自動で見つけたり集めたりするのが難しい問題をみつけるのに役立つ。Dogfood をしておかしな挙動に気づいた時、開発者はすかさず bugreport 情報をダンプし、あわよくば Systrace もキャプチャしてバグを file する。

これも「ユーザフィードバックの UI つければいいじゃない？」と思うかもしれないけれど、Dogfood ビルドの OS は一般のユーザからは集められない sensitive な情報をたくさん bugreport につっこむし、Systrace に至っては問題を再現しなおさないといけない。そして dogfooder は file した bug を通じて議論に参加し、必要に応じて追加の情報を提供することを期待されている。こういう込み入ったやり取りは、自動化されたエンドユーザからの情報だけでは実現できない。

個人的にはもうちょっとちゃんとデータを集め解析インフラも整備して dogfood への依存を減らした方が良いと思っているけれども、とはいえ dogfood でないと見つからず、直せない問題はあるとも思う。

Dogfooding には上手い下手がある。普段から奥の方のコードをいじって性能バグなどと戦っている人は傾向として dogfood がうまい。つまり、目の前で問題がおきたときにすかさず必要な情報を集めて適切な bug を file できる。練度の低い dogfooder は bugreport をとらずに曖昧な bug を file し、triage の質疑のなかで不完全なデータをもたもたと提供して開発者を疲れされる。もっと質が悪いのは社内 social media 上に文句を書くだけで bug を fileしないひと。おまえはなんのために dogfood してんだ、という気分になる。そんな troll はごく少数だけどね。

組織の VP みたいのがビシっとわかった感じの bug を file してくるとそうした exec への評価は高まる。モバイル OS 部門の higher management が管理職としてどのくらい立派なのかここでの評価を控えるけれども、少なくとも bug の filing ability はみなおしなべて高い。その点はすごく偉いなと思っている。

見方を変えると、制度としての dogfooding にだって出来不出来があると言える。参加者に対する適切な onboarding 教育はあるか。bug reporting を支援するツールは充実しているか。Bug tracker に何かを投稿するというのは、たとえばスマホのバグならモバイルの開発経験がないとプログラマであっても敷居が高いし、まして開発部門の外から参加している人にとっては恐怖さえあるかもしれない。開発者は未熟な dogfooder による bug を appreciate し、親身になって参加を encourage しているだろうか。

など、モバイルでの dogfooding は難しく、しかし得るものもあり、その運用を目の当たりにすると発見がある。先に書いたとおり自分はもともと dogfood をそれほど重視していなかったけれど、考えを改めた。私物の電話機に開発版 OS をインストールした。アプリも手元でビルドして入れた。

そしてインストールの前に二段階認証のバックアップをとりわすれておたおたする火曜日。