#iosdc 2016 前夜祭 A-1 ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方

twitter.com

フリマアプリ フリルはここ1年で2度の大規模リニューアルを行いました。 このトークではフリルでの経験を元に、ユーザーに受け入れられ、問題を起こしづらいリニューアルの進め方をエンジニア目線でお話しします。 リニューアルでありがちな大きなバグの発生や、星1レビューの嵐をいかにして防ぐか、開発チームの総力戦となる大規模プロジェクトをいかにスムーズに進めるかについてお話しします。

iosdc.jp

speakerdeck.com

ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方

f:id:niwatako:20160819174050j:plain

こんな会社です。

f:id:niwatako:20160819174114j:plain

振り返ればユーザーが居る開発環境、実際にユーザーをサポートスタッフとして採用してすぐにユーザーテストやインタビューが出来る。

f:id:niwatako:20160819174150j:plain

リニューアルの時こういうことありませんか?星1つのレビューが並んで辛い

f:id:niwatako:20160819174207j:plain

f:id:niwatako:20160819174217j:plain

リニューアル例

女性向けを男性向けに

f:id:niwatako:20160819174225j:plain

Allジャンルをファッション特化に

f:id:niwatako:20160819174239j:plain

好評価を維持しています。

f:id:niwatako:20160819174258j:plain

かつては失敗していた

f:id:niwatako:20160819174320j:plain

これから学んだのは大規模リニューアルに知見が必要ということ。 概要です。

f:id:niwatako:20160819174344j:plain

リニューアルの成功失敗

f:id:niwatako:20160819174400j:plain

リニューアルとは

f:id:niwatako:20160819174406j:plain

f:id:niwatako:20160819174428j:plain

f:id:niwatako:20160819174433j:plain

と思っています。

ですが、

f:id:niwatako:20160819174454j:plain

f:id:niwatako:20160819174504j:plain

そもそもリニューアルとユーザーの話

ユーザーにストレスを与える。

f:id:niwatako:20160819174523j:plain

慣れているユーザーほど無意識レベルの操作を崩されて使いづらいと思う。

たとえばキーボードが違うと困りますよね

f:id:niwatako:20160819174550j:plain

使い慣れているものが少しでも変化すると使いづらさになる。

成功したらどうすると良いのか

f:id:niwatako:20160819174628j:plain

f:id:niwatako:20160819174644j:plain

ユーザー体験を犠牲にすることは分かっているので、それでも得たいもの=成長だけである。なので成長を目指すと良い。数値で計測できるのが良い。エンジニアの心が保たれる。

これを見るより

f:id:niwatako:20160819174723j:plain

数値が伸びることを見るほうが良い。

f:id:niwatako:20160819174733j:plain

ユーザーに受け入れてもらう

f:id:niwatako:20160819174756j:plain

f:id:niwatako:20160819174758j:plain

ユーザーテストをしましょう。

f:id:niwatako:20160819174807j:plain

企画とプロトタイプが終わった段階と実装が終わった段階で行うと安心してリリースできます。

リリース後の問題を予測して手を打てる。FAQを用意したり、機能を変更したり。

f:id:niwatako:20160819174858j:plain

様子です。

f:id:niwatako:20160819174849j:plain

僕の失敗談

f:id:niwatako:20160819174911j:plain

エンジニアがテストするんですけどリリースしたらユーザーが激怒する。

f:id:niwatako:20160819174929j:plain

エンジニアはユーザーではない。開発中のバージョンにも慣れてしまって、変化を受け入れられるかを検証できない。

リニューアル時は変化を少しずつする

f:id:niwatako:20160819175009j:plain

f:id:niwatako:20160819175012j:plain

3ヶ月から半年を書けてリニューアルすると大きな変化ではなく小さな変化に感じられる。

全部入りでリリースして怒られてバグ修正を出すより

f:id:niwatako:20160819175043j:plain

個別に出す。

f:id:niwatako:20160819175116j:plain

デザイン変更のタイミングでメジャーアップデートして機能は変わっていない形にする

f:id:niwatako:20160819175156j:plain

f:id:niwatako:20160819175215j:plain

f:id:niwatako:20160819175221j:plain

f:id:niwatako:20160819175229j:plain

これに対する道は一つだと思っている

f:id:niwatako:20160819175254j:plain

実例です

f:id:niwatako:20160819175318j:plain

画像編集機能があっていろいろ編集できたのですが、これがほぼ使われていない機能だらけで、UIが複雑になっていたので、ほとんどのユーザーが使う切り抜きと回転のみにした。

なくした機能も、画像を選び終わった後に、編集する際に加工するというメニューが出てきて、同じUIを利用することが出来る。

f:id:niwatako:20160819175353j:plain

それでも消すなら利用者が例えば1%以下ならなど、数値で判断するのが良い。

f:id:niwatako:20160819175421j:plain

バグは怒りを爆発させるトリガーになるのでそれはやめたほうが良い。

f:id:niwatako:20160819175458j:plain

f:id:niwatako:20160819175530j:plain

f:id:niwatako:20160819175519j:plain

f:id:niwatako:20160819175541j:plain

f:id:niwatako:20160819175549j:plain

ユーザーとコミュニケーションを取って安心感を与える

f:id:niwatako:20160819175610j:plain

f:id:niwatako:20160819175633j:plain

f:id:niwatako:20160819175644j:plain

f:id:niwatako:20160819175657j:plain

これは僕が書いています

f:id:niwatako:20160819175712j:plain

中の人を感じてもらって、こんなアップデートがあるということをアップデート分から見てもらう。読み飛ばしがちなので人間味を出したほうが読んでもらいやすいと思っている。

アップデート内容を事前にわかっていたらユーザーさんもびっくりしないはず。

f:id:niwatako:20160819175801j:plain

f:id:niwatako:20160819175808j:plain

絶対リニューアルが許せないユーザーさんはいる。レビューやSNSではなく、受け止められるところに投げてもらう

f:id:niwatako:20160819175827j:plain

こうすることで評価が下がりづらくなる

f:id:niwatako:20160819175856j:plain

要望フォームに寄って集計も可能になる。

f:id:niwatako:20160819175914j:plain

リニューアルプロジェクトの進め方

リニューアルプロジェクトは総力戦

f:id:niwatako:20160819175956j:plain

f:id:niwatako:20160819180002j:plain

f:id:niwatako:20160819180018j:plain

作り直しは修羅の道。

f:id:niwatako:20160819180034j:plain

ボトムアップだと作りなおしてしまいがち。トップダウンでやる際のポイント

f:id:niwatako:20160819180041j:plain

トップダウンだと社内も巻き込みやすい。総力戦なのでみんなで同じ目標を持って進むことが大切。

f:id:niwatako:20160819180126j:plain

f:id:niwatako:20160819180133j:plain

リニューアルは調整が多い。そういう調整コミュニケーションをスムーズに出来る必要がある。バグなどもかならず出るので共有しやすい空気を作る。

f:id:niwatako:20160819180147j:plain

お互い思ったことを言えて、何を行っても関係が悪くならない関係を作ることができると良い。どう作るか?

f:id:niwatako:20160819180245j:plain

最近フリルでやっているのは

f:id:niwatako:20160819180313j:plain

こういう取り組み面でも関係性を改善できる部分があると思う。

f:id:niwatako:20160819180339j:plain

お互い歩み寄って同じ目標にすすめるチームにしたい

動くプロトタイプを作ろう

f:id:niwatako:20160819180347j:plain

f:id:niwatako:20160819180400j:plain

f:id:niwatako:20160819180422j:plain

プロトタイプはエンジニアが実際に作るのではなくてデザイナーさんだけで画像で作れたりする。実機で確認する方法をサポートしているので実機でユーザーテストをしたり出来る。

f:id:niwatako:20160819180457j:plain

画像だけで実際のアプリのように操作できる

f:id:niwatako:20160819180508j:plain

瞑想せず開発できる!

QAに力を入れる

f:id:niwatako:20160819180544j:plain

f:id:niwatako:20160819180548j:plain

主に開発者やエンジニアで最新開発版を使うのを日常的に行っています。

f:id:niwatako:20160819180557j:plain

面倒で誰もやらなくなるので、大事なのは自動化することです。

f:id:niwatako:20160819180630j:plain

テスト会を開く。エンジニア目線でバグを見つけたりデザイナ目線でズレを発見したりユーザー目線で混乱を予測したり。

大事なのが同時に同じテストをするということです。そうするとスムーズに問題発見が出来ます。

f:id:niwatako:20160819180728j:plain

エンタープライズビルド+DeployGateなら端末登録などの手間が不要で合言葉でみんな自由にダウンロードできる。それで社内全員に使ってもらうようにしている。テスト会で見つからなかった問題も発見できる。

さらに審査が通ってリリースする前にプロモーションコードで最終テストを行っている。

f:id:niwatako:20160819180806j:plain

こうして落ち着いてリリースできる。

f:id:niwatako:20160819180839j:plain

ユーザーの声は件数で分析する

f:id:niwatako:20160819180845j:plain

感情を分離して件数で把握。個別の内容で見ると

f:id:niwatako:20160819180909j:plain

こういうのはエンジニアとしては辛い。。。

リニューアルは影響するユーザーの数が膨大なので統計データとして見たほうが落ち着いて対策が取れる。

f:id:niwatako:20160819180943j:plain

まとめ

f:id:niwatako:20160819180953j:plain

QA

サービス成長を目標にするという話でしたが何を具体的な数値としていますか?

目標設定の際に設定したKPIでみて、それをみて成功失敗を判断しています。

過去に炎上されたという話がありましたが、評価は元に戻ったということですよね。どうやって戻したのか、もしなにかあれば

基本的にはユーザーさんが慣れてくれたのと、バグを少なくなるように継続的にリリースした。大きなアップデートの後にも問題がないようにアップデートを繰り返すことで評価が戻っていった原因だと思っている。バグ修正と時間の解決だと思います。

リニューアル載っ住め方で気兼ねなく言い合える環境を作るのは素晴らしいと思うが、人によって考え方が違うと思う。もともとの路線から脱線していくようなことは置きないのか。あるいは防止策は。

うちの場合ではリニューアルプロジェクトチームに事業責任者が付いており、議論が別れたら事業責任者が最終決定を行っている。

感想

twitter.com

twitter.com

twitter.com

twitter.com

twitter.com

まとめ

togetter.com