「LIVESENSE A/study Vol.1 エンジニアとデザイナがいかにサービスデザインに取り組むか」に参加してきました。 #livesense
はじめに
「LIVESENSE A/study Vol.1 エンジニアとデザイナがいかにサービスデザインに取り組むか」に参加してきました。セッションの内容をレポートいたします。
イベント概要
第一回のテーマはエンジニアとデザイナのコラボレーション。
素晴らしいコンセプトのサービスがあるとします。そのサービスを実現するために、デザイン要素もエンジニアリングの要素も必要になりますが、それぞれの専門家を揃えれば、素晴らしいサービスが出来るでしょうか？ 決してそんなことはありません。それぞれの専門家が適切にチームとして連携できてこそ初めてサービスを育てていけるものだと我々は考えています。そこには、それぞれが適切に機能し、良い仕事をするためには、工夫が必要であり、仕組みが必要だと考えます。
今回は、ゲストスピーカーとして、Voyage Group、Cookpadを経て現在ROLLCAKE Inc.の取締役・デザイナとしてご活躍されている伊野亘輝氏をお迎えし、サービス開発においてデザイナとエンジニアが意識すべき原則についてお話をしていただきます。リブセンスからは転職会議の開発チームリーダーとフロントエンドエンジニアがそれぞれの立場から転職会議の開発事例を通じて、デザイナとエンジニアのコラボレーションについてお話します。
目次
「ユーザー体験設計を軸にすすめるサービスデザイン」
発表者
ROLLCAKE Inc. 取締役・デザイナー 伊野亘輝さん
概要
サービスデザインは常に霧の中での手探りの宝探しのようなもの。進むべきたしかな方向も分かりにくく、チームメンバーに個性があるほどそれぞれの意見にわかれ混乱しやすい。そんな状態では必要な機能に絞ることもままならず、知らず知らずのうちに機能盛りだくさんのマッチョサービスができ上がってしまいます。そうなってしまうと大事な指標がなんなのかも見失いがちです。そうならないように、サービスの方向性を見すえつつ、手探りではあるけれども確実に進んでいくためのデザイン手法をとして、ペルソナを軸にした体験設計と、小さなテストを回していく方法を実際の「レター」開発にからめてお話します。
写真カレンダー送付サービス「レター」を開発されている伊野亘輝さんの発表でした。
「コンパス」について
- サービスのデザインは答えのない霧の中を歩いて行くようなものだった
- そんな中を進んでいくには、地図ではなくコンパスのほうが有効だった
コンパス
- 以下の3つの要素をいつでも確認、軌道修正できるサイクルのことをコンパスと呼んでいる
| ユーザーゴール | サービス全体を通してユーザーが達成するもの(短期・中期・長期) ゴールから動機づけをする |
| 動機 | 動機が行動を後押しする |
| 行動 | 行動によってゴールを達成できる |
- 「レター」は2ヶ月でリリースした
- その間にコンパスを４周回した
- ミニマムな製品を作って、一般の十数人に試してもらってテストした
1周目
- 体験(ゴール)設計をもとに要件を絞った
- スタートから２週間で、対象ユーザーに向けたテストリリースを行った
- コアな部分だけ実装してテストした
- 実際に購入してくれた人は0%
- しかし、ユーザーの反応がスタートから2週間でわかったことはいいことだった
- この結果をもとにインタビューを行った
- インタビュー結果：レターを使うことでやれることはわかったけど、それを通してどうなるかが伝わってなかった(体験できることが伝わっていなかった)
2周目
- 2週目:「サービスを通した体験を伝える」ことに注力した
- ランディングページ、アプリのウォークスルー画面において、写真とわかりやすい言葉で、体験できることを説明した
- 結果：購入者5%
- 再びヒアリングを行った
- 理想的な価格と実際の価格との間にギャップがあることがわかった
- PSM分析を行って価格を再設定した
3周目
- サービスを使いはじめるときのハードルを下げた
- お試し無料
- 結果：購入者12%
- (このころからチームの空気が暗くなってしまった...)
- またインタビューを行った
- 「いいものを送っている気がしない、実物っぽくない..」
- 「ほんとは、デジタルサービスなんじゃないの?」
4周目
- 「実物のイメージを伝える」ことに注力した
- UIの質感を変えた
- 「作っている」ことを伝えようとした
- 結果：購入者40%
- 「いけるかも？」という雰囲気になった
まとめ
- いまもコンパスを活用している
- 方法を改善しながら、試行錯誤しながらやっている
- 小さくテストしながら、進んでる
- これは１つの方法であり、方法は他にもある
- ROLLCAKEでは、今回の方法がマッチした(スタートアップに向いてるかも)
- みんなで考えることができた
- 今回ゴールを変えることはなかった(ゴールを決めるとこに時間をかけたので)
- しかし、動機付けの部分にミスがあった
伊野さんおすすめの書籍
- About Face 3 インタラクションデザインの極意
- リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす
- Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン
- ユーザビリティエンジニアリング ―ユーザエクスペリエンスのための調査、設計、評価手法
「転職会議のプロダクト開発の変遷 〜野球型組織からサッカー型組織へ〜」
発表者
株式会社リブセンス エンジニア 島田喜裕さん
概要
転職会議は2009年のオープン以来サイトの成長と共にプロダクト開発の体制も徐々に変化してきました。
プロダクトの初期フェーズにはディレクタ、エンジニア、デザイナの適切な分業によってスピーディーに開発を進められましたが、プロダクトの規模が膨らむにつれて、その開発体制は限界を迎えることになり、その反省から、開発に関わるメンバー全員が一体的にプロダクト作り全体に関わるコラボレーティブなプロセスを推進してきました。
転職会議の開発の歴史を振り返り、今日のサービス開発に求められるプロダクトのチームのあり方について、オープン時から開発をリードしてきた立場からお話したいと思います。
転職クチコミサイト『転職会議』の開発体制がどのように変わっていったかについてのお話でした。
フェーズ１
- フェーズ1は2010年頃の話
- サービスリニューアルを機に開発を内製へと切り替えるタイミングだった
- リニューアル内容は、デザインの一新、機能追加など
- ディレクター、デザイナー、エンジニアが一人づつの３名体制
- ウォーターフォール的な流れで開発
- この頃は人数が少なかったので、リニューアル作業の優先順位を変えたりできた
- 意識合わせのためのミーティングを始めた
フェーズ２
- サービスは順調に成長していた
- ディレクター2人、デザイナー１人、エンジニア３人という体制
- ディレクターの下に他の人が付くフォーメーション
フェーズ３
- ディレクター2人、デザイナー2人、エンジニア8人という体制
- プロジェクトごとにチーム編成
- うまく行ったチームもあったが、問題が起きたチームも
- サッカーのチームのように有機的に動ける組織がいいのではと思った
現在
- 定例ミーティングで、みんなでビジョンを共有
- 朝会の実施
- 10分ほど
- 昨日何やったか、今日なにやるかを話す
- 他の人の動きがわかるように
- ホワイトボードで進行管理、カンバン
- ミーティングの形式
- バックログミーティング：週一で、施策を決定
- イテレーションミーティング：バックログミーティングで決めたものを分割してメンバーをアサイン
- イテレーション振り返りミーティング：KPTを行う
まとめ
- 小さな勝利を繰り返し、リズムを作り、モチベ持続させる、いくつかのルールを設定(まずはライトなルールを設定)
- フラットな関係が大事
- 自分を知ってもらって相手を知る、褒める文化、フラットな関係
- メリットの追求
- マイナスをゼロではなくゼロをプラスに
- 共通の目的、達成すべきゴールを共有
「エンジニアとデザイナのコラボレーションで変わったプロダクト開発」
発表者
株式会社リブセンス フロントエンドエンジニア 植村建太さん
概要
転職会議ではデザイナ、ディレクタ、エンジニアの垣根をなるべくなくし、時にお互いの役割や作業領域をカバーしあいながらプロダクトを開発を行っています。
この発表では、フロントエンドエンジニアである私が、デザイナやサーバーサイドエンジニアとのどのように連携しながらサービスを開発しているのか、また、事例を通じて、転職会議チームのコラボレーティブなサービス開発がどのように機能し、どのような効果があるのかをお話したいと思います。
転職会議の通知機能の改善を行った際に、開発作業の進め方をどのように変えたかについてのお話しでした。
背景
- 求人ページヘの誘導をスムーズにしたい
- 転職会議には、口コミ投稿以外にも「転職会議ジョブサーチ」などの求人ページがある
- そのために、ユーザーへの通知機能を改善する
実装前
懸念事項
- 「今回の修正で求人への誘導を増やせば、スカウトメールへの誘導(既存の機能)が減るのではないか」
やったこと
- デザインスタジオを行った
- メンバー全員で、UI・機能名などについて、意見出しあう
- デザイナーがファシリテーターになって場を作る
- 非デザイナーも率先して意見を出す
- 全員で作戦会議、認識のブレをなくす
実装 〜 リリース
- 実装を始める前の段階で、デザイナー・エンジニアがどういう作業を行うのかがだいたいわかっていた
- やることが決まっていたので、それぞれ並行に作業できて、作業の短縮につながった(今まではディレクター → デザイナー → エンジニアの流れだったが)
- コミュニケーションが活発になった
- 作業が平行していたので、質問などもお互いにしやすくなった
- デザインやコードの調整を口頭で伝達できた
- UI改善のアイディアが生まれた
- 「同時に１つのものを作ることに集中!」という文化が芽生えた
リリース後
- リリースした後に効果測定を行うようにしている
- 作りっぱなしにしない、フィードバックを元に進める
- 今回の修正の効果
- 求人への誘導は２倍になった
- スカウトメールへの誘導も微増した
まとめ
まとめ
- 全員で作戦会議を行い、認識のブレをなくす
- 同時に１つのものを作ることに集中する
- 作りっぱなしにしない
長所や短所など
- しかし、いいことばかりではない
- 議論に費やす時間が増える
- 課題もたくさんある
- フロントエンジニアが少ない
- 社内でHTMLの勉強会をやったりしている
- 無駄は無くなってきている
- 「リレー形式」ではないので
- プロダクトへのコミットの意識が良くなった
- モチベーションが下がっていた時期もあったが、プロダクトのことをみんなで考えるようになった
- 「一丸となって点をとりにいく」
まとめ
今回のイベントのテーマは「エンジニアとデザイナのコラボレーション」でした。チーム内のメンバー同士をうまく連携させる方法やサービスの改善サイクルをうまく回す方法などについて、実際の経験を基に語られており、勉強になりました。
「LIVESENSE A/study Vol.1」というイベント名の通り、今後も定期的に開催していくそうです。 主催者の皆様、発表者の皆様、及び参加者の皆様、ありがとうございました!
