声にならない"声"の拾い方
こんにちは！
dely, Inc.でレシピ動画サービス「クラシル」のサーバーサイドエンジニアとProduct Managerをしている奥原 (@okutaku0507) です。いつもnoteにはポエムしか書いてないので、ちゃんと真面目な記事を書きたいと思います。想定読者はアプリケーション開発に携わっている方です。
突然ですが、声にならない"声"とはなんだと思いますか？
声にならない"声"とは
アプリケーション開発には「バグ」はつきものです。バグにも種類があると思っていて、アプリケーションがクラッシュするものであれば、Fabricが開発しているツールなどで検知することができたりします。Railsアプリケーションなどのサーバーサイドのバグであれば、サーバーエラーをSentryで検知することができるでしょう。しかし、アプリケーションをクラッシュさせないバグではどうでしょう。ユーザー体験を著しく損なっているけれど開発者が検知することができないバグはいたるところに存在します。意図しない動作と言った方が正しいですね。それを事細かに教えてくれるユーザーはそんなに多くありません。気がつかないまま時が経って、それが原因で小さなフラストレーションが溜まって他のサービスに移ってしまうかも知れません。顕在化してこない"声"を上手く拾いながら開発していく方法を、実例を元に紹介していきたいと思います。
紹介する順番は実際にバグを見つける頻度が多い順です。
CSと連携する
クラシルではCS (カスタマーサクセス) の体制があり、ユーザーさんと直に向き合う大切な役割を担っています。
レシピに寄せられたコメントを調理部と連携しながら返信をしたり、アプリの不具合の窓口になっています。アプリの不具合はEメールでお問い合わせいただくことになっており、その通知がSlackに来るようになっています。
ここで大切なことは、ユーザーはバグの原因を教えてくれないということです。例えば、こんなメッセージをもらったとします。
「消えた」
「動画が動かない」
「強制終了されます」
この一次情報だけでは、バグの特定をすることはできません。
一番上の「消えた」からは、何が"消えて"しまったのか読み解くことは難しいです。調査の結果、実はこれはアプリのアップデートをした際に、お気に入りが全て消えてしまったことだとわかったとします。クラシルにとってお気に入りは重要な機能であるため、直ちにアップデートを停止し、これ以上被害が及ばないように止血する必要があります。
基本的に、この調査にはかなりの時間を要することが多いです。なぜなら、このケースでクラッシュしないということは、正しい処理によってお気に入りが削除された可能性が高いからです。その場合はアプリケーション開発者の実装での条件分岐のバグが原因である可能性があります。加えて、このようなバグは全てのユーザーではないことが多いです。そして、悲しいことに開発環境では起きないバグであることが多いにあります。
特定の条件下でお気に入りが削除されてしまう、それは開発環境では再現されない。そんなバグをこの「消えた」というユーザーのメッセージから予測するには、このユーザーの詳細な情報が必要です。そのために私たち開発者はどんなログも自社のログ分析基盤に蓄積しています。実際に、ログを分析してみたらバグの原因を特定できたケースは多くあります。
データを見る
例えば、昨日のプッシュ通知の開封数が異様に少ないということがダッシュボードをみたらわかったとします。その場合、昨日のプッシュ通知周りで何かあったことが明確にわかります。
基本的には、日々の数値はテレビで盛大に取り上げられたとか、新規機能をリリースしたとか特別なことがない限りは変動の幅は少ないはずです。その前提から、昨日のある数値が大きく変動したら、アプリケーションのバグを疑った方が良いです。
また、それらの数値の見方を詳しく書きます。特定のOS由来、Androidのデータだけおかしいぞとなった場合、Androidに起因するバグであるとわかります。またアプリのバージョンも特定できるように、ログを設計しておくことが良いでしょう。一方で、iOSもAndroidも数値がおかしいとなれば、API側あるいは基盤系のバグである可能性があります。
ドッグフーディングする
ドッグフーディングは社内で自社サービスを自分たちで実際に使ってみて改善点などを出す手法です。
クラシルでも、ママリさんから着想を得て「クラシルタイム」という枠組みでクラシルを実際に使って改善点をSlackに投げるということを定期的に行なっています。その時に実際にこんな会話がありました。
社員「ここ、ずっと前から不便だと思ってたんですけど、仕様なんですか？」
エンジニア「えっ、、、把握してないです」
実装が正しいかどうかを把握しているのは、主にエンジニアが把握していると思うので、他の社員からみたら、それは仕様なのではないかと認識しており、そのことを話す機会がない場合に上記のようなことが起こりがちです。QAなどが整備されていない状況で、エンジニアが全ての場面を把握しきることは現実的ではないため、積極的にドッグフーディングして気になる点をあげてもらうのは一定の効果があると思います。
エゴサする
自分たちのサービスあるいは個人が世間ではどのように評価されているのか気になったりするとエゴサしてしまいますよね。弊社では、社長が今の規模でもエゴサしていることで有名です。ちなみに僕もエゴサしているので、クラシルってツイートすると確実に捕捉します。
例えば、「クラシル使えない」というツイートがあり、そのアカウントのツイートを遡るとスクショが貼られており、クラシルの特定のバージョンの特定の機能がタイムアウトで使えない状態であったことがありました。一つのツイートからその人の過去のツイートを遡り、その人がどのような意図でそのツイートしたのかを推測すると思わぬペインに遭遇することがあります。
アプリレビューを見る
アプリレビューにもアプリ改善やバグのヒントが隠されていることが多くあります。
クラシルでは、アプリのレビューを自動的に取得してSlackに流しています。ここでは、アプリのバージョンもわかるようになっているので、特定のバージョンで「動画が動かない」というレビューが多かった時に、実際に調べるとプレイヤーにバグあったというケースもあります。また、アプリのレビューには各々のストアから運営として返事をすることができるので、Eメールに誘導してバグの原因を突き止めるというような行動が迅速に行うことができます。
まとめ
本来なら、バグはない方が望ましいですが、僕らは人間なのでどうしてもバグを生み出してしまいます。クラシルでは、声にならない"声"を拾って、プロダクトの顕在化してこないバグと戦っています。プロダクト開発は一筋縄では行きません。様々な方法を模索しながら、良いと思った方法を効率的に取り入れつつプロダクトを改善していくことが大切です。他にもいい方法があったら是非教えていただければと思います。もしよければ、クラシルをさらにいいサービスにできるように、僕らと一緒に戦いませんか。
この記事が気に入ったらサポートをしてみませんか？