読者です 読者をやめる 読者になる 読者になる

ドッグフーディング会をはじめました

こちらはピクシブ株式会社Advent Calendar 12/12分の記事です。


f:id:devpixiv:20141212201938p:plain

こんばんは。Androidエンジニアの@RooandQooです。好きな飲み物は烏龍茶です。

今日はピクシブスマホアプリ開発チームの中で「ドッグフーディング会」が流行し始めた、というお話をしたいと思います。

ドッグフーディングとは

一言で言うと、「開発中のアプリケーションを、ユーザになりきって使うこと」です。

モバイルアプリに限らず、開発者は一度動いているアプリケーションを自分で触ると思いますが、テストがしっかり動いていたりして、バグが発見される可能性が限りなく少ない(と思われる)環境での動作確認は、「まあちゃんと動くだろう」とおざなりになりがちです。(体験談)

また、一口に「ユーザになりきる」と言っても、自分のプロダクトはかわいいもので、多少なりとも開発者の目線でものを見てしまうものです。

そこで、「色んな人にドッグフーディングしてもらう」の出番です。

ここからは、ピクシブでの実例を紹介します。

ピクシブでのドッグフーディング会

最近、新規でモバイルアプリを開発する案件があり、そこで実験的に「毎日動くアプリを社内リリースして、ドッグフーディング会を開いて意見を集める」という試みが @edvakf の提言で行われました。

実際に行われた会のフローはこんな感じです。

  • 毎日17時頃、4〜8人に声をかけ、1人1台端末を配布し、実際にアプリを触ってもらう
  • 実際にアプリを触る時間は20〜30分。その間、気になったことを列挙してもらう
  • アプリを触る時間が終了後、一人ずつ「気になったこと」を全体に発表していく
  • 得られた意見を元に、翌日のドッグフーディング会のために実装する機能などの検討を行う

これはプロトタイプをスクラップ&ビルドする中で生まれたフローなので、実際にリリースされたアプリに対して毎日ドッグフーディングをすることは難しいかもしれません。

会の参加者は基本的には「興味ある人は自由に来てください」というスタンスでしたが、会を追うにつれ、今まで参加した事のない人にこちらから声をかけて参加してもらう、ということもありました。

良かったこと

締め切り感

「毎日この時間にドッグフーディング会がある」という意識が刷り込まれることによって、この時間までにバリューを出すこと、忙しい日でも拘束時間が予測できることが徹底され、プロトタイピングのサイクルが速まったように思いました。

誰でも参加できる

端末をこちらで用意するので、参加者が普段使っている端末のOSに依存せずに参加してもらうことができます。

「毎日使うユーザ」と「新規ユーザ」それぞれの考え方が見えてくる

ドッグフーディング会に参加する頻度は、参加者によってまちまちでした。これが良くて、頻度が高い人からの変更に対する敏感な反応と、新規参加者からの新鮮な反応が毎日得られるので、アプリが進むべき道を考える上で非常に参考になりました。

会話がある

その場で感想を発表しあうことで、ユーザと開発者だけでなく、ユーザ同士の会話が生まれることが良かった点であると思います。 複数人が同じ感想を抱いていれば、その意見は強く拾い上げなくてはいけないという意識が根付きますし、「ここはこうしたほうがいいんじゃないか?」といった意見が出た時に、「それって実際にどういう状況で困ってるの?」という話を引き出すことができ、活発な議論が毎日生まれることに良さを感じました。

悪かったこと

良いこともあれば悪いこともあります。

単純に大変

毎日締め切りに追われることになるので、シンプルに疲れます。

「毎日行う」ために、複数日にまたがりそうな大きな変更ができない

ドッグフーディング会を繰り返す中で、大きな機能追加や、仕様変更の提案が発生することがあります。 しかし、「毎日行う」という要件を満たすためには、1日の中で開発に使える時間が相対的に短くなり、巨大な変更にはなかなか踏み出せないという問題が発生しました。 その場合、前提を破り「2日おき」「1週間おき」というスパンを設定することで対応できそうですが、今回は「毎日行う」前提を守ることにしました。

ドッグフーディング会そのものへの準備が不足

「毎日17時頃に行う」という前提があるため、時間ギリギリまで開発を行うこともしばしばあります。ドッグフーディング会を行うために、端末にアプリをインストールしたり、メモ用のシートを整備したり、といった時間が必要となるのですが、会の直前にそれに追われて焦る、という場面もありました。

(アプリのインストールにはDeployGateを、メモ用シートにはGoogleDriveを使ってできるだけ手間を減らしていましたが、使用する全ての端末内のアプリを更新したり、といった作業が結構大変でした)

導入してみて

今までのモバイルアプリの動作確認テストは、DeployGateやTestFlightに載せたアプリを、端末を持っている人にダウンロードしてもらい、問題のある部分をスプレッドシートに書き下して、それを見た開発者が修正を加える……というフローで開発が行われていました。 この方法は一見効率的なのですが、端末を持っている同僚がアップデートの度に必ず触ってくれるわけではありませんし、バグ報告を文字で伝えるだけでは、再現するのが難しかったり(結局、どういう状況でどういう操作をした、というのを直接聞きにいくことが多い)して、本来発揮できるはずのバリューを100%発揮できていないことが多かったように思えました。

ドッグフーディング会という「場」を設けることで、アプリをテストしてくれる人員を確実に確保でき、 また複数のユーザ、開発者が一同に会してアプリに向き合うことで、日々の開発では見えてこない問題、改善点が見つかりました。 ドッグフーディング会の導入は、効率的に、高品質なアプリを開発する助けになるのではないかと思います。

今回は新規案件での例を取り上げましたが、今後既存のアプリに機能追加、デザイン変更などを行う際にも、積極的にドッグフーディング会を行っていきたいです。

まとめ

リリース前に動作確認を行うことは、開発の現場では当然発生する場面ですが、忙しい時などはついつい開発者だけで済ませてしまいがちです。 しかし良いプロダクトをリリースするには、できる限り時間をとって、ユーザの気持ちになってそれに向き合うことが重要です。 別のチームや別の部署、理想的にはユーザーの方を集め、触れてもらうことで、開発者だけでは見えないものが見えてきます。皆さんもよいドッグフーディングを。

明日は @geta6 がたのしい話をしてくれると思います。ご期待ください。