こんにちは、宿泊事業本部でサービス開発をしている田中( 
id:kentana20 )です。
この記事は一休.comアドベントカレンダー2017の4日目です。
今日は弊社が運営しているサービスの1つである一休.comのUI改善に関して
- どのような体制で開発をしているのか
- ユーザ体験を向上させるために実施していること
を紹介したいと思います。
UIチームの体制
12/4(月) 現在、一休.comでは
- PM兼マーケティング: 1名
- デザイナー: 1名
- エンジニア: 3名
という体制でUI改善を行っています。
もともとは
- マーケティング部
- デザイン部
- システム開発部
と職種ごとに分かれていた組織でしたが、プロダクト開発をより円滑に、スピーディに行っていくために今春から現在の体制に移行しています。
このあたりの体制変更については 12/24(日) に予定している 
id:sisijumi の「開発組織の目的型組織への移行」にてお話があると思いますので、詳細は今回は割愛します。
どのように取り組むタスクを決めているか
大きめの案件については、CEOや事業責任者と議論しながら決めています。
- 事業の状況
- 市場環境
- 競合の取組み
などから、取り組んでいくタスクの大枠が決まります。
一方で、小規模な案件についてはCSやセールスからの改善要望に対して、チームで実施可否と優先順位について意思決定しています。
ユーザ体験向上のために実施していること
プロダクトの改善を精度高く行うために、チームで実施していることをいくつか紹介します。
プロトタイピングとデザインレビュー
今日ではプロトタイピングツールも充実し、企画の段階ではコードを書かずにアイデアをメンバー同士で共有する機会が増えてきていますが、一休でもプロトタイピングを実施して
- 解決したい課題に対して、適切なUIになっているかをレビューする
- チームメンバーで完成形に対する認識を揃える
ということを実施しています。
形式としては対面／オフラインでデザインレビューを行い、指摘事項をGitHub Issuesにまとめて議論しながらフィードバックループを回して目指すUIを決めています。
改善するページ／機能によっては、プロトタイピングツールで表現仕切れないケースもあるので、その場合はHTMLモックを作る場合もあります。
誰かが「こういう形で進めよう」と決めたサイクルではないのですが、いまはこのサイクルで改善が回っていて、徐々に精度が出てきているように思います。
リリース前QA
数日で終わるような改善の場合は実施しないこともありますが、チーム内でのQAをリリース前に実施しています。開発中の作業ブランチを デモ用環境 *1 にデプロイしておいて
- （初回のみ）その改善で実現したいこと、解決したい課題を改めて共有
- 各自、思い思いにデモ版を触って使用感を確認
- 改善したほうが良い内容を発表＆議論
- やる／やらないを決めて終了
という流れで実施しています。これは弊社のレストランアプリチームで実施している取組みなのですが、「良さそうだ」と思って宿泊UIチームでも導入しました。
機能の規模や重要度によりますが、このQAを2~3回実施してからリリースする、という流れがスタンダードになりつつあります。
- QA#1: 開発が一通り終わったところで実施
- プロトタイピング時に決めた仕様が適切か
- ユーザの課題を解決する改善になっているか
- 開発した機能にバグ、考慮漏れがないか
- QA#2: 前回QAでの指摘事項、BugFixを済ませたタイミングで実施
- 前回QAでの指摘が改善されているか
- リリースしてよいレベルに仕上がっているか
という形で実施しています。β → RC1 → RC2というイメージですね。
QAに関しては
- 若干コストをかけすぎでは
- 早く本番にリリースしてユーザの動きを見たほうが良いのでは
という意見もあり、今後も最適なやり方を模索していきたいと思っています。
ユーザの行動を体験する
一休ではGoogle AnalyticsとBigQueryを使ってユーザの行動ログを分析しています。このログを元に、課題感のあるページや機能に対して実際のユーザがどのような行動をしているかを、実際に体験するということをしています。
例えば、「主要な導線中のとあるページでの離脱が目立つ」という課題があった場合には
- 特定ページで離脱しているユーザ1人1人の行動ログを抽出
- 抽出した行動ログをもとにユーザの行動を1セッションずつトレースする（実際にサイトを動かして体験する）
- それをひたすら繰り返す
- ユーザが感じたであろうストレスを考える
- ストレスの共通点（離脱の理由）を探す
という流れで解決するべき課題を洗い出します。課題が発見できたら、解決策として改善のアイデアを議論します。
各ユーザのセッションを体験すると
- 離脱しているユーザの行動を幾つかのグループに分けることで傾向が見えてくる
- 当初考えていた課題／仮説の裏付けに使える行動を再確認できる
などの効果があり、Google Analyticsのサマリや、KPI／ファネルレポートなどを見るのとは違った課題が見えてくることも少なくありません。
すべての改善で実施しているわけではありませんが、「数字的に課題があるのはわかるけど、何を改善していけばよいかが見えてこない」という場合には有効なアプローチだと考えています。
おわりに
今回は一休.comにおけるUI改善の取り組みについてお話しました。いまのチーム体制になってから約8ヶ月くらいですが、徐々にチームとしての形が出来てきていると思う一方で、改善できる部分はまだまだあるので、社内のほかのチームや社外の事例を参考にUI改善の精度を上げる、開発スピードを上げる取り組みを進めていきたいと思っています。
「こんなやり方をしていて、良い具合です」という事例をご存じの方や知見をお持ちの方はぜひご連絡を! プロダクト開発に関して情報共有しましょう。
一休では、ともに良いサービスをつくっていく仲間（エンジニア／デザイナー／マーケティング）を積極募集中です。応募前にカジュアルに面談をすることも可能ですので、お気軽にご連絡ください!
明日は @minato128 さんによる「メール配信のモニタリングと障害リカバリーについて」です。お楽しみに!
