【freee開発研修2022】0→1でのプロダクト開発の話
こんにちは、freee株式会社でデザイナーをやっているyoshikiです。
この記事はfreee Designers Advent Calendarの16日目の記事です。
noteの更新は去年のfreee Designers Advent Calendar 以来になります。（もう1年たったのか…）
私は今年（2022年）の4月、新卒でfreeeに入社しました。
freeeでは毎年、新卒のエンジニアとデザイナーでチームを組んでwebサービスを作る開発研修が行われます。
今回は、その開発研修で行った0→1でのプロダクト開発についての記事を書きたいと思います。
はじめに
freeeの開発研修は4月〜6月の約2ヶ月間で行われます。チーム構成はエンジニアとデザイナー4〜5人です。僕らのチームはエンジニア4人、デザイナー1人の構成でした。
テーマは毎年変わるのですが、今年のテーマは「ハイブリッド出社時代に必要なwebサービス」を作ってくださいでした
※ハイブリッド出社の定義：最低週２回はオフィスに出社する働き方
freeeではコロナの急拡大を受け2020年2月25日から全社リモートワークを開始しました。現在は、8月にオフィス移転があったこともあり現在は、出社とリモート勤務を組み合わせる働き方であるハイブリッド出社スタイルを採用しています。
ハイブリッド出社は、出社とリモート勤務のいいところ取りができる一方で、オンライン×オフラインの会議問題などさまざまな課題を抱えています。
今回はそれらの課題を解決するためのサービスを開発することがゴールになります。
リサーチ・企画編
アンケート
さて、テーマは発表されたものの、自分自身ハイブリッド出社の経験がある訳ではないのでまずは企画のタネを探すべく、社内の方々に自由記述型の「お困りごとアンケート」を実施しました。
のべ60件ほどの回答をいただいたのですが、なかなかリアルな声を集めることができて、多くの気づきがあったと同時に単純に面白かったです。
回答一部抜粋
・出社したけど会議室確保されてなかった
・二日酔いで体が動かない時も出社日なので会社に行かないといけない
・新しく入った方を知る機会が無い
・（しょうがないけど）PCを持ち歩くのが地味につらい。
・あの人とあの人が出社している日に出社したい（≒会って話したい）みたいなのを、都合つけるのがめんどい
次に、集まった回答を分類していきます。
カテゴリに分類した上で眺めてみることで、それぞれのカテゴリの課題感、傾向などが見えてきます。
このあたりで課題感の強さ、実現可能性などを加味しながらどのカテゴリを攻めるのか当たりをつけます。
僕らのチームでは出社するモチベーション、出社した時に偶発的に発生するコミュニケーションといったカテゴリに軸をおくことにしました。
理由は、ハイブリッド出社ならではの課題であることかつ、比較的課題感が大きそうだったからです。具体的には、出社すると、同僚の人と一緒にランチに行ったり、気軽にコミュニケーションを取れたりするというメリットがある一方で、ハイブリッド出社だと誰が出社してるのかしてないかがわからないので、行ってみたら誰もいなくて寂しいみたいな体験があったりします。
インタビュー
さて、アンケートである程度課題を絞り込み、仮説を作ったところで次はその課題を深堀り、検証するためにインタビューをしていきます。
今回のターゲットは、入社歴が浅くてまだ社内に知り合いが少なく積極的にコミュニケーションを取りたい（が現状難しい）と思っている人が良さそうだということで、チームメンバーがインターンなどでお世話になっていた先輩やアンケートを回答してくれた方の中からピックアップして計4名の方にインタビューを行いました。
ちなみに僕らのチームではエンジニアの4人もインタビュースクリプトの作成やモデレーターなどリサーチの部分も積極的に関わってくれたので、チーム全員で共通認識を持ちながらリサーチを進めることができました。
インタビューの結果としては、以下のことがわかりました。
1. 同期や同僚とランチする予定があるので出社する
freeeにはチームや業務に関係なくても同僚と一緒にランチする時に、補助がでるshall we ランチ？という制度があり、それを活用したランチによるコミュニケーションが頻繁に行われている。
2. ランチに誘われることはあるが、自分から誘うことはあまりない
誘われたらいくけど自分から誘うのはハードルが高く感じる。断られるリスクがある。あまり出社してないので会社周辺の飲食店を知らない。日程調整が面倒。
さて、だいぶインプットが増えてきました。
これらの気づきを元に、企画アイデアをあれやこれや考えていきます。
具体的に考えたアイデア
出社日共有サービス
誰がいつ出社するのかわかる
すれ違いランチGo
オフィスですれ違った人とランチにいける
shall we Coffee、shall we 散歩
ランチよりライトな交流の機会
ランチマッチングサービス
新しい人との関係性を増やせる
そして、今回はこの中からランチマッチングサービスを作ることに決めました。
具体的には、会社近くの飲食店一覧があって気になるお店をお気に入り登録しておくことで、同じ店をお気に入りしている人同士でマッチングしてランチにいく予定を立てることができるサービスです。
このアイデアを選んだ理由としては、ランチに行くことが出社するモチベーションになりえるが、現状は、新しいfreeers※と知り合うきっかけがない。ランチは元々知ってる人と行くことが多い。さらにそもそもランチに誘うこと自体のコストが高いことがわかったので、それを解決すれば、もっとカジュアルにいろいろな人とランチにいくことができて、出社の醍醐味である対面でのコミュニケーションを楽しめる機会が増えるのではと思ったからです。
※freeeで働く人の総称
このサービスの肝は、誘う誘われるという体験になっていないところです。
マッチング形式にすることで、誘う誘われるの関係を無くし、誘う側のリスクやコストを下げると共に、断りにくいといった誘われる側の課題も同時に解決します。
設計・デザイン編
体験の整理
さて、ここまでで大枠のコンセプトははっきりしました。
ここからは具体的な体験を考えつつ、優先度付けをやっていきます。
今回はUSM（ユーザーストーリーマッピング）というfreeeでもよく使われる手法を使って、体験を整理していくことにしました。
まずは、ユーザー目線で「◯◯として△△したい。（なぜなら△△だから）」という形式でタスクを書き出していきます。
そうして出てきたタスクを時系列に並べていき、フェーズごとに切り分けて整理していきます。
今回考えた体験をざっくり書くと以下のようになります。
飲食店をお気に入り登録する
同じ店をお気に入り登録した人同士でマッチが発生する
システム側で日程候補をいくつかピックアップして両人に提案する
お互いの日程があえばマッチ成立、日時や場所、集合場所などが送られてくる
次は優先度付け、出てきたタスクを一気に全て実現しようとするとリリースまでにものすごく時間がかかるので、それぞれのタスクに優先度をつけていきます。今回はタスクを色分けして表現しています。
文章にすると、意外とさらっとできたかのように見えますが、実際はここが重要で集中すべきポイントです。
タスクを眺めているとあれもこれもできた方がいいと思えてきて、全部やりたい！になりがちですが、ここで優先度の設定を間違えると後々痛い目をみます。今回は開発期間1ヶ月というかなりタイトな開発スケジュールだったこともあり、かなり意識して行いました。（が結局ギリギリの開発になってしまった…）
この作業はワークショップとしてチームメンバー全員でやることで目線が揃うので、みんなを巻き込んでやることが重要だと思いました。
モデリング
次はモデリングです。
UIデザインの前に、今回のサービスはどんなオブジェクトを扱うのかを整理していきます。
freeeではオブジェクト思考UIデザインをよく採用していて、基本的にはよりモードレスな体験を設計することが良いとされています。
そのためには、レイアウトやUIを考える前にモデリングをして情報設計を行う必要があります。
これが作成したモデル図です。
今回はエンジニアと一緒にモデリングを行いました。
左は僕がデザインの参考にする程度の粒度に落としたモデル図で、右はエンジニアが実際にDB（データベース）を設計することを考えて作成したモデル図です。こちらはプロパティや主キー外部キーなどまで詳細に考えられていますね。
本来ならデザインをするためにここまで考える必要はないと思うのですが、エンジニアと一緒にモデリングをすることで、デザイン側とエンジニアリング側で齟齬が起こってるところはないか、漏れてる要素などはないかを確認しながら進めることができました。
今回はマッチという概念をオブジェクトとして扱うことにしたところが重要なポイントでした。このマッチをUI上でどのように見せていくかが鍵になりそうです。
UI検討
さて、ここまできてUIを作る準備が整いました。
先ほど設計したモデル図を元に画面を形作っていきます。
マッチ画面は左にマッチ一覧、右に詳細がある2ペインのデザインを考えたり。
ステッパー式にして自分のフェーズ（自分が日程を選ばないといけない、相手の日程入力を待っている、日程調整が完了）がわかりやすいようにしたり
飲食店画面はマップスタイルにして、会社からの距離と方角が一発でわかるようにしつつ、クリックすると詳細が確認できるようにしたり。
ジャンルで絞り込めたり、検索ができるようなものを考えたり（結局これは工数たらずで実装できませんでしたが…笑）
サービスの全体像を最初にチュートリアル的に見せてお気に入り登録をしておくとマッチングが発生することをちゃんと理解してもらえるように工夫したり。（イラストは同期のデザイナーが作ってくれました！）
そんなことを考えながらいろんなパターンのUIをせっせと作っていきました。
ロゴ作成
そして今回はサービスのロゴも作成しました。
飲食店マップに表示されるピン、そこをきっかけにして繋がりが生まれるという意味で手を繋いでるイメージ、そしてそれらをマッチングする仲介者という意味を込めて少しキャラクターチックなロゴを制作しました。
ついでに、飲食店マップに表示されるピンもステータスごとにオリジナルで作成しました。
実装編
さて、あとは実装あるのみです。
この時点で残り1~2週間、もちろんエンジニア達がデザインと並行して開発を進めてくれていたのですが、やりたいことはいっぱいあり、全然手が足りていない状況でした。
僕は、HTML,CSSをそこそこ、プログラミングはちょっとやったことがある程度のレベルだったんですが、React※の勉強を半年前ぐらいからしていたこともあり実装にもチャレンジしました！
※https://reactjs.org/
今回は僕が実装を手伝った部分を少し紹介します。
ダイアログ実装
先ほどご紹介したチュートリアルダイアログの実装を行いました。
freeeにはvibesというデザインシステムがあるので、1からコーディングしたわけではないですが、ページ送りの制御や何回も出てこないようにユーザーあたり1回しか表示されないように制御するところがプログラミングっぽくて楽しかったです。
マップスタイル変更
飲食店一覧のマップのスタイルを変更しました。
マップはGoogle Maps APIを使用しているのですが、デフォルトのマップスタイルだと飲食店以外の情報や、道路や線路などの情報が表示されていて、肝心の飲食店のピンが強調しづらいという問題がありました。
そこで、リファレンスを参考にしながら今回いらない情報を削ぎ落としたマップスタイルを実装しました。
こういう細かいところの実装をシュッとできると、ほんとはこだわりたいんだけど優先度が下がりがちなタスクをちょこちょこ消化していけるのはいいなあと思いました。
さいごに
そうして出来上がったサービスのデモ動画がこちらになります。
まだまだやりきりたかったことはありますが、
飲食店をお気に入りする→お気に入りした人同士でマッチング→日程調整→日程確定
というコア体験を実現することができました。わいわい
今回一番大きかった学びとしては、実現したい体験の優先度をちゃんと決めておくことがすごく大事ということです。（当たり前）
どうしても体験をデザインを作ったりしている段階だと、あれもこれもあった方がいいんじゃないかと思いついてしまい全部やりたくなりますが、当然ながらそんな時間はありません。
最速でユーザーに価値を届けるために最低限必要な要素ってなんなんだっけ？を常に自問自答しながらチームで認識を合わせてプロダクトを作っていくことが大事だと学びました。
今後もこの研修で得た学びを肝に命じながらいいものを最速で作れるように頑張っていきたいと思います。
ここまで読んで下さったみなさまありがとうございました。
明日は、freeeのタコスマスターことgenさんから「freeeデザイナーズファイル#1 Shinichi Kambe」が公開されます！
この記事が気に入ったらサポートをしてみませんか？