フリマアプリ フリルはここ1年で2度の大規模リニューアルを行いました。 このトークではフリルでの経験を元に、ユーザーに受け入れられ、問題を起こしづらいリニューアルの進め方をエンジニア目線でお話しします。 リニューアルでありがちな大きなバグの発生や、星1レビューの嵐をいかにして防ぐか、開発チームの総力戦となる大規模プロジェクトをいかにスムーズに進めるかについてお話しします。
ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方
こんな会社です。
振り返ればユーザーが居る開発環境、実際にユーザーをサポートスタッフとして採用してすぐにユーザーテストやインタビューが出来る。
リニューアルの時こういうことありませんか？星1つのレビューが並んで辛い
リニューアル例
女性向けを男性向けに
Allジャンルをファッション特化に
好評価を維持しています。
かつては失敗していた
これから学んだのは大規模リニューアルに知見が必要ということ。 概要です。
リニューアルの成功失敗
リニューアルとは
と思っています。
ですが、
そもそもリニューアルとユーザーの話
ユーザーにストレスを与える。
慣れているユーザーほど無意識レベルの操作を崩されて使いづらいと思う。
たとえばキーボードが違うと困りますよね
使い慣れているものが少しでも変化すると使いづらさになる。
成功したらどうすると良いのか
ユーザー体験を犠牲にすることは分かっているので、それでも得たいもの＝成長だけである。なので成長を目指すと良い。数値で計測できるのが良い。エンジニアの心が保たれる。
これを見るより
数値が伸びることを見るほうが良い。
ユーザーに受け入れてもらう
ユーザーテストをしましょう。
企画とプロトタイプが終わった段階と実装が終わった段階で行うと安心してリリースできます。
リリース後の問題を予測して手を打てる。FAQを用意したり、機能を変更したり。
様子です。
僕の失敗談
エンジニアがテストするんですけどリリースしたらユーザーが激怒する。
エンジニアはユーザーではない。開発中のバージョンにも慣れてしまって、変化を受け入れられるかを検証できない。
リニューアル時は変化を少しずつする
3ヶ月から半年を書けてリニューアルすると大きな変化ではなく小さな変化に感じられる。
全部入りでリリースして怒られてバグ修正を出すより
個別に出す。
デザイン変更のタイミングでメジャーアップデートして機能は変わっていない形にする
これに対する道は一つだと思っている
実例です
画像編集機能があっていろいろ編集できたのですが、これがほぼ使われていない機能だらけで、UIが複雑になっていたので、ほとんどのユーザーが使う切り抜きと回転のみにした。
なくした機能も、画像を選び終わった後に、編集する際に加工するというメニューが出てきて、同じUIを利用することが出来る。
それでも消すなら利用者が例えば1％以下ならなど、数値で判断するのが良い。
バグは怒りを爆発させるトリガーになるのでそれはやめたほうが良い。
ユーザーとコミュニケーションを取って安心感を与える
これは僕が書いています
中の人を感じてもらって、こんなアップデートがあるということをアップデート分から見てもらう。読み飛ばしがちなので人間味を出したほうが読んでもらいやすいと思っている。
アップデート内容を事前にわかっていたらユーザーさんもびっくりしないはず。
絶対リニューアルが許せないユーザーさんはいる。レビューやSNSではなく、受け止められるところに投げてもらう
こうすることで評価が下がりづらくなる
要望フォームに寄って集計も可能になる。
リニューアルプロジェクトの進め方
リニューアルプロジェクトは総力戦
作り直しは修羅の道。
ボトムアップだと作りなおしてしまいがち。トップダウンでやる際のポイント
トップダウンだと社内も巻き込みやすい。総力戦なのでみんなで同じ目標を持って進むことが大切。
リニューアルは調整が多い。そういう調整コミュニケーションをスムーズに出来る必要がある。バグなどもかならず出るので共有しやすい空気を作る。
お互い思ったことを言えて、何を行っても関係が悪くならない関係を作ることができると良い。どう作るか？
最近フリルでやっているのは
こういう取り組み面でも関係性を改善できる部分があると思う。
お互い歩み寄って同じ目標にすすめるチームにしたい
動くプロトタイプを作ろう
プロトタイプはエンジニアが実際に作るのではなくてデザイナーさんだけで画像で作れたりする。実機で確認する方法をサポートしているので実機でユーザーテストをしたり出来る。
画像だけで実際のアプリのように操作できる
瞑想せず開発できる！
QAに力を入れる
主に開発者やエンジニアで最新開発版を使うのを日常的に行っています。
面倒で誰もやらなくなるので、大事なのは自動化することです。
テスト会を開く。エンジニア目線でバグを見つけたりデザイナ目線でズレを発見したりユーザー目線で混乱を予測したり。
大事なのが同時に同じテストをするということです。そうするとスムーズに問題発見が出来ます。
エンタープライズビルド＋DeployGateなら端末登録などの手間が不要で合言葉でみんな自由にダウンロードできる。それで社内全員に使ってもらうようにしている。テスト会で見つからなかった問題も発見できる。
さらに審査が通ってリリースする前にプロモーションコードで最終テストを行っている。
こうして落ち着いてリリースできる。
ユーザーの声は件数で分析する
感情を分離して件数で把握。個別の内容で見ると
こういうのはエンジニアとしては辛い。。。
リニューアルは影響するユーザーの数が膨大なので統計データとして見たほうが落ち着いて対策が取れる。
まとめ
QA
サービス成長を目標にするという話でしたが何を具体的な数値としていますか？
目標設定の際に設定したKPIでみて、それをみて成功失敗を判断しています。
過去に炎上されたという話がありましたが、評価は元に戻ったということですよね。どうやって戻したのか、もしなにかあれば
基本的にはユーザーさんが慣れてくれたのと、バグを少なくなるように継続的にリリースした。大きなアップデートの後にも問題がないようにアップデートを繰り返すことで評価が戻っていった原因だと思っている。バグ修正と時間の解決だと思います。
リニューアル載っ住め方で気兼ねなく言い合える環境を作るのは素晴らしいと思うが、人によって考え方が違うと思う。もともとの路線から脱線していくようなことは置きないのか。あるいは防止策は。
うちの場合ではリニューアルプロジェクトチームに事業責任者が付いており、議論が別れたら事業責任者が最終決定を行っている。
感想
— ino´・ω・`ue (@inoue0426) August 19, 2016twitter.com
twitter.comちょっと文章が見えてないけどMackerelのメールみたいな感じなのかな? #iosdc #a
— hamaco (@hamaco) August 19, 2016
twitter.comアップデートでレビュー下がるのつらいよね。#iosdc #a
— huin (koichisakata) (@huin) August 19, 2016
twitter.comドラッカー風エクササイズ - shizuto on languages | https://t.co/ugyEH9jVqV #iosdc
— haranicle (@haranicle) August 19, 2016
twitter.com納期にも負けず、プレッシャーにも負けない強い心を持ち、レビューの罵詈雑言に耐えられる、そんな強いエンジニアに私はなりたい。 #iosdc
— STUDIO SHIN (@studioshin) August 19, 2016
