mixi engineer blog

*** 引っ越しました。最新の情報はこちら → https://medium.com/mixi-developers *** ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

ユーザーファーストを実現するmixiの開発プロセス

デザインユニットUXデザイン担当の酒井です。

mixiでは昨年来、最重要キーワードとして「ユーザーファースト」を掲げ、ユーザー様のご意見やご利用状況に基づいたサービス施策の実現を素早く行えるようになるために、開発プロセスの改善を継続的に行なっています。今回は、この「ユーザーファースト」なmixiを実現するための取り組みについて、具体的にご紹介していきたいと思います。

なぜ今、ユーザーファーストなのか?

昨年11月に開催した『ユーザーファーストウィーク』で笠原社長からもご説明させていただきましたとおり、mixiというサービスが大きく成長したこれまでの数年の間に、いつのまにかユーザー様と私達との間に「ギャップ」が生まれてしまったという強い反省があります。mixiを取り巻く外部環境の変化に対応していく中で、これまでもユーザー様にとっての「心地よいつながり」とは何なのかを真摯に検討し、時流に合わせ様々な施策を行なってきたのですが、時にはユーザー様に大きな戸惑いを与えてしまったり、厳しいお叱りの言葉を頂いたりすることもありました。

なぜこのようなギャップが生まれてしまったのかを改めて振り返ってみると、ユーザーの皆様の心の中にある本質的なニーズや、mixiに対するイメージと、私達が様々なデータや調査結果に基づいてニーズがあると判断した事柄との間に横たわる認識のずれに行きつくのだと思います。私達からユーザー様に向けての説明不足・コミュニケーション不足の側面もあったかもしれません。

ユーザー様と私達の間に生まれてしまったこうした「ギャップ」をなんとかして埋めていきたい、そしてもう一度皆さまに毎日愛用していただけるmixiに私達自身も変わっていきたい。「ユーザーファースト」というキーワードには、そのような思いが込められています。

ネット上では「いまさら」「これまではユーザーファーストではなかったということ?」など、厳しいお言葉を目にすることもあります。そういったお言葉の一つ一つを反省に変えて、日々の開発プロセス改善に活かしています。

ユーザーファーストな開発プロセスとは

昨年8月に行われた大規模な組織改編によって、mixiの機能ごと、プラットフォームごとに、小人数の開発ユニットを組む体制に移行しました。このユニット制では、各ユニットごとに細かな差異はあるものの、基本的にはアジャイル開発手法の一つであるScrumプロセスに基いて開発を進めています。

各ユニットは

  • プロダクトオーナー(ユニットの方向性やゴールを示し、開発するものについての責任を負う)
  • スクラムマスター(開発プロセスから障害となる要因を取り除き、生産性を高める役割を担う)
  • エンジニア
  • 企画者
  • デザイナー

といったメンバーによって組成される横断的なチームです。プロダクトオーナーには、これまでに比べて大きな裁量が与えられており、意思決定がより迅速に行えるようになりました。

このようなユニット制への移行と並行して、「ユーザーファースト」な開発プロセスを実現していくために、ユーザー様とのタッチポイントを開発プロセスの中でより多く設けられるように工夫を重ねています。

現在のmixiの開発プロセスを概略的に示すと下図のような流れになります。

uf_process.png

ここからは、この「ユーザーファースト」な開発プロセスを支えるために行なっている取り組みについて、図中の番号と対応させてご説明していきたいと思います。

1. ユーザーリサーチ

インタビューやアンケートなどの調査を通じて、ユーザー様の利用状況や行動パターンの背景にある本音、隠れている欲求、サービス上の課題などを理解します。ここで得られたインサイト(洞察)は、サービスの企画立案や改善へ生かすための指針となります。

uf_user_interview.png サービスへの効果
  • ユーザー様の本音や欲求・利用上の課題について「事実」を知り、これらが開発に関わるメンバー全体の共通認識となることで、その後の戦略および企画の立案からサービスコンセプト設計、UI設計の過程における意思決定の基準ができます。
社内的な効果
  • ユーザー様との対話の中からサービス改善を行う意識が醸成され、ユーザー様を中心においたサービス開発スキルの向上にも生かされています。
mixiならではの工夫
  • 専門の調査会社に業務を依頼し、調査参加者の抽出と調査設計、実査を行っている企業も多いのですが、私たちはこの一連の手続きをmixiのサービス上で行える仕組みを構築し、スピーディーな調査設計、調査実施から実査の司会までを、社員が一貫して担当できるようになりました。この仕組みによって、リサーチで得た現状把握の情報や、インサイトを迅速かつ効果的にサービス開発にフィードバックできるようになりました。

2.ユーザーストーリーのプロダクトバックログ化

Scrumによる開発では、提供するべき価値となる開発項目を「プロダクトバックログ」として管理します。管理対象となる開発項目は、「ユーザーストーリー」として記述します。

ユーザーストーリーは、ユーザーリサーチで明らかになったユーザー様のニーズや、未充足の価値を実現するために次のような形式で記述するように心がけています。

uf_user_story.png サービスへの効果
  • ユーザーストーリーを用いることで、常に「ユーザー様にとっての価値やメリットを実現する」ことを意識して開発が行われるようになりました。
社内的な効果
  • 開発関係者の誰もが、開発プロセス全体にわたって『誰のために』『何を』『どうして』提供するのか意識しながら作業や議論を行うようになりました。
mixiならではの工夫
  • いくつかの開発ユニットでは、いわゆる『インセプションデッキ』に相当する中長期的な開発ロードマップの検討期間を定期的に設け、そこでの議論と決定事項に基いてユーザーストーリーの作成やプロダクトバックログ化を行っています。これにより、細かな継続的改善を目的とした開発と並行して、より大きな課題を解決するためのサービス企画や機能開発が行いやすい開発プロセスに変化しはじめています。

3.プロトタイピング

開発プロセスのなるべく早い段階で、開発コンセプトが具体的に体験可能な模型(プロトタイプ)づくりを行い、そのコンセプトの価値やユーザビリティ上の問題について、検証と修正を短い期間で繰り返し行います。

紙やホワイトボードにラフスケッチする場合もあれば、デザイン画をHTMLに落としこんで簡単にクリックできるようにしたものや、実際に動くプログラムなどで試すこともあります。

uf_prototyping.png プロトタイピングの効果
  • 関係者が同時に参加し、目の前で同じ物を見ながら作業を進めていくので、コンセプトの評価とその実現のためのUI設計がよりすばやく行えるようになりました。
  • 仕様上の抜け漏れやユーザビリティ上の問題もプロトタイピング作業の中で早期発見できるようになりました。
mixiならではの工夫
  • 短い時間で基本的なUI設計とリリース計画を同時に実現するために、企画者、エンジニア、デザイナーなど、様々な立場のメンバーが参加して、ユーザーストーリーマッピング※1とスケッチボーディング※2を組み合わせたUIプロトタイピング手法の実施を試し始めています。これにより、これまでと比較してもかなり素早くUI設計を済ませて開発作業に着手できるようになってきました。
uf_user_story_mapping.png 参考URL
※1:ユーザーストーリーマッピング
※2:スケッチボーディング

4.ユーザーテスト

プロトタイプや製品を実際のユーザー様に使ってもらうところを観察し、具現化したコンセプトに本当に価値があるのか、ユーザビリティ上の問題は残っていないかを評価します。

uf_user_test.png ユーザーテストの効果
  • リリース前でも、ユーザー様からのフィードバックを得ることができるようになりました。
  • 開発に関わるスタッフが製品の改善ポイントを明確に絞れるようになりました。
mixiならではの工夫
  • ユーザーテストのノウハウを内部化し、リクルーティングと設備・機材の問題を解決して、短期間・低コストでユーザーテストをできるようにしました
  • 専用ラボはありませんが、Webカメラとビデオチャットなど既存のツールを組み合わせて、会議室を簡易ラボとしてすぐ使えるようにしています。

5.A/Bテスト

A/Bテストとは、Webページ改修の効果を客観的に測定するためのテスト手法の一つです。ユーザーごとに異なるパターンのWebページを利用してもらい、その結果を元に施策をどうするか決定できることが最大のメリットです。

A/Bテストを用いれば、「このキャッチコピーどっちに決める?」といった、なかなか結論を出すことが難しい議論や会議を重ねる必要はなくなります。 ユーザー様に実際に使っていただき、効果の高かった案を選ぶだけでよいからです。

uf_ab_test.png mixiならではの工夫
  • mixiでは、UserBranchと呼ばれる独自の仕組みを用いることにより、公平にサンプリングした自由な割合のユーザーで簡単にA/Bテストを行うことができます。
  • 例) 5%のユーザーにはA案のテスト、他の10%のユーザーにはB案のテストを出し分けるなど。

万能のように見えるA/Bテストですが、この方法だけにとらわれていると、以下のような問題に遭遇することもあります。

  • A/Bテストの結果に大差がなく、どっちにするか決められない
  • 小さな差にばかりこだわってしまい、抜本的な改革を忘れてしまう

A/Bテストの良い点・悪い点の両方をうまく活用しながら、ユーザーの皆様が使っていて楽しくなるようなmixiをお届けしていきます。

6.解析基盤/アクセス解析

アクセス解析とは、ユーザーの行動ログから有意義な情報を見つけだし、その結果をサービスにフィードバックする一連のプロセスのことです。

アクセス解析を効果的に用いることで、ユーザーに人気のコンテンツをアクセスしやすい位置に移動したり、今は人気がないけれど、今後人気が出そうなコンテンツを見つけたりと、夢は無限大に広がります。

mixiならではの工夫
  • mixiには千台以上のサーバーがあり、1日あたり数百GB以上のログデータが集まってきます。このように、サーバー台数が非常に多く、DBやログの種類も多様なため、データを扱うためには効率的な仕組みが必要になってきます。mixiでは、データを容易に分析できる環境を整備するために、DBダンプツール、Hiveクエリ実行のフレームワーク(Honey)などを活用しています。
  • 上記のツールを使うことにより、一部のデータは全て自動で解析基盤にのり、また、その他必要なデータは、簡単な設定を書けば解析基盤にすぐにのせることが出来るようになっています。

今後は、これらの解析基盤を用い、昨年開催したユーザーファーストウィークでいただいたご意見や、「本当に必要とされているコンテンツ」を重点的に改良していく予定です。これからのmixiにご期待ください!

アクセス解析基盤(Hadoop, Hive)の話についてのより詳細な説明は、弊社エンジニアが書いた以下の関連ブログ記事もあわせてご参照ください。

まとめ

ユニット制によるユーザーファーストな開発プロセスはまだ始まったばかりですが、私達も実感として、以前よりユーザー様の視点により近いところから発想し、ご意見を積極的に取り入れながら迅速に開発し、お届けできるようになってきたと感じています。

今のところ、多くはユーザー様の目には見えない裏側の仕組みについての改善が多いのですが、これは開発コンセプトとして実現したいユーザー様にとっての価値を提供する上で、まずは仕組みとして改善が不可欠と判断されたものです。これらの積み重ねによって、近い将来、目に見える形での改善や新しい価値を、より早く、より多く、お届けできるようになっていくのではないかと感じています。

何かお困りのことやサービスへのご要望がありましたら、機能要望の画面から、ご意見をお寄せ頂ければと思います。ユーザーファーストに変わりつつあるmixiを、これからもどうぞよろしくお願いいたします。



本記事の執筆に当たっては、次の皆さまにご協力をいただきました。

  • リサーチグループ 白岩さん (ユーザーリサーチ)
  • デザインユニット 馬場さん (ユーザーテスト)
  • 解析グループ 篠原さん (A/Bテスト・解析基盤/アクセス解析)