チーム開発未経験の状態からスタートし、デザインプロセスを確立

2014年の9月に、大学に入るためにフランスから日本に来て、縁があってPlayer!チームに参加しました。Player!チームに入る前は、クライアントワークをひとりで行っていたので、チーム開発の経験はありませんでした。

そのため、チーム開発やスタートアップでの開発は、Player!チームの皆さんに全部教えてもらいました。バージョン管理ツール「GitHub（ギットハブ）」の使い方、スクラム開発の進め方、小さく早く失敗することの重要性、エンジニアとのコミュニケーションなど、ゼロから吸収していきましたね。

そこで学んだことをベースにして、GitHub、ラフスケッチ、「Prott（プロット）」、「Sketch（スケッチ）」、「Flinto for Mac（フリントフォーマック）」などを使ったデザインプロセスを確立しました。

仮説も含め、あらゆる情報の集約は「GitHub」に

Player!チームでは、GitHubに情報を集約し、開発を進めています。

まずメンバーが仮説（アイデア）をGitHubに上げます。ユーザーとのコミュニケーションや自分でアプリをさわっていて生まれた仮説を、どんどん貯めていくんですね。このときに使うフォーマットは、全員で統一しています。具体的に言うと、

1. 仮説の動機

なぜその仮説（アイデア）を実行したいのかを記載します。「〜という機能のアクティブ率を上げたい」というイメージです。

2. 仮説が出た経緯

どのような経緯で仮説が出てきたのかを記載します。例えば、「◯月◯日にユーザーテストをやった時に〜という意見をもらって出てきた」という感じです。

3. 実際に行うこと

具体的に行うこと（実装するもの）を記載します。「〜の画面に使い方のガイドを出す」といったことです。

4. 期待する効果

仮説によって期待する効果を記載します。例えば「〜の機能の利用率を◯％上げる」といったことです。期待する効果は数値化できることが望ましいですが、数値化できない場合は「〜の数値が上がる」といった「上がる、下がる」といったレベルでも十分です。

プロダクトオーナーと呼ばれるプロダクトのビジョンや実装の優先順位を決める人が、このフォーマットで書かれた仮説の一覧を見て、優先順位をつけます。

肝は、デザイナーの「巻き込み力」による共通認識の醸成

プロダクトオーナーが優先順位をつけ、取りかかる仮説を決めたら、デザインミーティングを開催します。デザインミーティングの目的は「仮説を実現するデザインのアイデアを集める」ことです。この時重要なのは、デザイナーがチームメンバー全員をミーティングに呼び、巻き込むことです。

デザインが完成した際に「イメージと違った」という意見が出て、手戻りが起こることはよくあると思います。実際にPlayer!チームでもデザインプロセスがしっかりと固まっていなかった頃は、そういった手戻りもありました。アイデア出しから全員を巻き込み、共通認識を作っていくことで、手戻りを減らすことができます。

絵は下手でも良い！ビジネスチームも、全員でラフスケッチを描く

全員でアイデアを出す時に重要なのが、言葉でなく「絵」で伝えることです。言葉ではAと言っていても、頭ではBを思い浮かべていることはよくあります。また、他の人はCを思い浮かべている可能性もあります。

そこで、Player!チームでは、デザイナーでなくても、下手でもいいのでラフスケッチを描いてアイデアを伝えるようにしています。

▼デザインミーティングで共有されるスケッチ

この取り組みをはじめてから、全員のアイデアを正確に理解できるようになりました。また、声の大きさで採用するアイデアが決まることもありません。

アイデアは全部受け入れない。デザイナーがラフなプロトタイプを作成

ミーティングで出たアイデアを参考に、デザイナーが画面のラフスケッチを作ります。この際に、デザインミーティングで出たアイデアをすべて採用することはありません。すべてのアイデアを採用しても、つぎはぎのUXやUIになってしまうからです。

アイデアはあくまでも参考にして、仮説を実現する最適なUXを設計し、UXを実現するUIのラフスケッチを書きます。ラフスケッチをプロトタイピングツールProttに取り込み、ラフなプロトタイプをデザインミーティングでメンバーに共有します。

▼実際のProttの画面

そこでメンバーの合意が得られなければ、デザイナーが持ち帰り、再度ラフなプロトタイプを作って持ってきます。メンバーの合意を得られれば、UIデザインツールSketchを使って、より本物に近いプロトタイプを作ります。

▼実際のSketchの画面

プロトタイプは短時間で作る。徹底検証はユーザーテストで

Sketchでプロトタイプを作る時は、短時間で作ることを意識しています。プロトタイプを検証した結果、ボツになることも多々あるので、この段階でこだわってもあまり意味がありません…。3画面であれば2〜3時間でさっと作ってしまいます。

デザインができたらProttに入れて、動きをつけプロトタイプを完成させます。そして、再度デザインミーティングを開き、仮説が正しいか検証します。この時、チームメンバーだけではなく、実際のユーザーやユーザー候補を呼んでさわってもらうこともあります。

▼ユーザーテストの様子

チームメンバーだけで話していると、どうしてもバイアスがかかってしまいます。ユーザーにさわってもらうと意外な発見があるんですよね。例えば、先日行ったユーザーテストでは、ユーザーの方から様々な意見をもらえました。

▼実際にもらうユーザーの意見の一部

・どの試合が過去のもので、どの試合がこれからのものなのか一目でわかりにくい

・コメントで試合のいつ盛り上がっているのかがわかると楽しい

・画面遷移のインタラクションが気持ちいい

ユーザーの要望はすべてを取り入れるわけではありませんが、仮説が正しいかを判断する材料になります。

ここで、仮説が正しくないという結論になれば、また最初に戻って新たな仮説をラフスケッチに落としていきます。仮説が正しくなくても落ち込むことはないです。実装してから気付くよりコストはかかりませんし、ひとつの発見になるので。仮説が正しそうだ、という検証ができたら、最後にインタラクションの検証を行います。

実装をしなくても、インタラクションの検証は可能

スマートフォンアプリで最適なUXを実現するためには、インタラクションが重要な役割を果たします。デザイナーが使っていて気持ちの良いインタラクションを設計し、エンジニアに正確に伝える必要があります。

インタラクションを伝えるのに「ここのボタンを押すとシュッと上にずれて〜」といったように口で伝えると、イメージのずれが起こり、実装後に「なんか違う」といったことが起こりえます。そこで、プログラミングなしでデザイナーがインタラクションを作れるツール「Flinto for Mac（フリントフォーマック）」が活躍します。

▼実際のFlinto for Macの画面

Flinto for Macを使えば、かなり細かいインタラクションをプログラミングなしで作ることができます。

▼細かい動きの設定もできる

動きを数値で定義してエンジニアに渡すことができるので、デザイナーのイメージと実装がずれることはありません。

また、Flinto for Macで作ったプロトタイプは見た目は本物とほとんど同じなので、チームメンバーにプロダクトの将来像を見せたり、投資家に説明をする時にもかなり役立ちます。

デザインプロセスの進化に終わりはない

僕がPlayer!チームに入った時と比べて、デザインプロセスは大きく進化しました。それにより、ビジネスチーム、デザイナー、エンジニアのコミュニケーションは円滑になり、使われない機能を作ってしまうことも減りましたね。

ただ、デザインや開発のツール、手法はどんどん進化するので、進化に終わりはないと思っています。今度も常に最適なデザインプロセスを追求し続け、ユーザーさんに愛されるアプリを作っていきたいです。（了）