こんにちは。エンジニアの島川です。
昨日、A/studyの第1回勉強会「エンジニアとデザイナがいかにサービスデザインに取り組むか」を開催致しました。 平日にも関わらずご来場頂きました皆様、まことにありがとうございました。 会場キャパの都合上、ご参加頂けなかった皆様、大変申し訳ありませんでした。
以下、講演の内容を簡単にではありますがご紹介したいと思います。
Rollcake Inc. 伊野亘輝氏
まず最初に、「両親が喜ぶカレンダー便り」作成サービス『レター』を開発・運営するRollcake Inc.の伊野さん（@memocamera）から「ユーザー体験設計を軸にすすめるサービスデザイン」というタイトルにてご講演頂きました。
伊野さんのサービスデザインの仕方を一言で表すと「地図を捨てて、コンパスを使う」ということだそうです。
しっかりと道順を決めて地図を引く（きっちりとすべてを計画する）という方法が必ずしもうまくいかないことが多い、ということは、おそらくWEBサービスの開発に携わったことがある方なら「確かに」と思われる方も多いのではないでしょうか（例えば、WEBサービスを入念に設計して、たくさんの機能を、苦労して作っても、実際にユーザーはそのうちのほとんどの機能を使わないというような）。
では、なぜ地図の代わりにコンパスを使うのかと言えば、サービスデザインは霧の中を進むようなものだからだそうです。霧の中を進むには、一歩一歩手探りに少しずつしか進めず、だからこそ、迷わないようにゴールに向かってチーム全員でしっかりと「コンパス」を持って一歩ずつ進んでいく方法をとっているとのことです。Rollcakeさんでは、ユーザーの「（ユーザーが得る体験）ゴール」・「（ゴールに向かって行動する）動機」・「（実際のユーザーの）行動」という3つの要素で構成されるサイクルをコンパスと見立てており、そのサイクルがうまく回っているかどうかを常に確認しながら、少しずつサービスを作っているとのことでした。
今回の講演では、レターをローンチするまでに行った、4週間で4回のβ版の開発で、その都度ユーザーテストを行いながら徐々にサービスをブラッシュアップしていった事例をご紹介頂きました。β版を作っては、ダウンロード数やカレンダーの購入数等の数値的に計測可能な指標を用いて想定した結果になっているか確認しつつ、想定通りにユーザーが行動していないことがわかれば、ユーザーインタビューを行い、その原因を深堀し、改善策練り、サービスに反映する、というプロセスを繰り返したとのことでした。
伊野さんご自身は必ずしもこの方法がどのような場面でもうまく行く物ではなく、特にスタートアップ向きなのではないか、とおっしゃっていましたが、私自身としては既存サービスでも、大きな分岐点になるような開発（ピボット）を行う際にも非常に有効な手法ではないかと感じました。
株式会社リブセンス 島田喜裕氏
リブセンスの島田からは、転職会議の開発の変遷から、サービスデザインに必要なチームビルディングについてお話させて頂きました。
サービス開発の変遷を辿りながら、少人数、トップダウンによってうまく機能していた時期から、サービスの成長、チーム規模の拡大によって生じる問題を解消しながら、現在はエンジニア・デザイナ・ディレクタがより有機的に連携できるようなチームに変えてきたとのことでした。そして、この変遷を経験して得たチームビルディングにとっての3つの原則として要約しました。
第一に「リズムとルール」。小さな決断と勝利を細かく繰り返してモチベーションを維持すること、また、小さなルールを作って最低限の規律をもって開発することが、チームとしてサービスを継続的に作り上げていくには必要とのことです。
第二に「フラットな関係」。相手を知りつつ、自分を知ってもらうこと、良い結果が出たときには相互にほめ合う文化をつくることで、フラットに意見を言い合える関係を構築がなければならない。
第三に「デメリットではなく、メリットの追求」。「目に見えないメリット」よりもついつい「目に見えるデメリット」に気を取られがちですが、マイナスをゼロにするよりもゼロをプラスにする方向に集中する方が良い結果につながるとのことでした。
株式会社リブセンス 植村建太氏
最後に、転職会議チームのフロントエンドエンジニアである植村からは具体的なサービス開発の事例を通じて、デザイナとエンジニアがどのようにコラボレーションして開発を行っているかについて以下のように紹介しました。
まず、エンジニア・デザイナがそれぞれの専門領域で作業を開始する前には、全員参加でデザインスタジオ等の認識共有の場を作り、何が目的で、どんな懸念があるのか、を把握し合い、認識のぶれをなくします。
その上で、それぞれが専門領域の作業をほぼ同時に作業開始するようにすることで、ベルトコンベア式に作業をリレーしていた頃よりも完成までの時間が圧縮しつつ、動くものをベースに素早くチーム全体でレビューして、そのフィードバックを取り入れ、リリースまでにブラッシュアップを行っているとのことです。
そして、リリース後は、作り手自身も事前に共有した目的の指標や懸念点への影響を数値ベースで確認し、結果をふまえ次のサービス作りにつなげるようにしているようです。
リーンUXのプラクティス等も積極的に取り入れつつ、上記のようなフローを現在採用しているとのことです。
もちろん、この手法は必ずしもいいことばかりではないそうで、議論の時間が長くなりがちだったり、人的リソースの偏りが課題になることも多々あるそうです。ただし、それ以上に、認識のずれやコンテキストのズレによって作った物が無駄になるという状況を少なくできることや、サービス作りに関わるエンジニア/デザイナのサービスへのコミット意識が強く芽生えること、等のメリットがある、と説明しました。
あわせて読みたい
昨日の勉強会終了後すぐに、@yukio_andoさんに講演ログレポート「ROLLCAKE * LIVESENSE」を作成して頂きました！ありがとうございます！
