スマートキャンプでPMをしている郷田です！ 10月に毎年恒例の開発合宿に行ってきました！
私たちチームは4日間で社員同士のコラボレーションを目的とした SPARK（スパーク） というプロダクトを作りました。
合宿記事第3弾として、この記事ではSPARKができるまでに行った課題抽出〜プロダクト立案までのプロセスをご紹介します！
▼過去の2本はこちら
チームのメンバー構成
私たちのチームでは、以下の4人で構成されています。
- 髙松（デザイナー）
- 入社時期：2019年1月
- 普段の業務：ボクシルやスマートキャンプ内のデザイン全般
- 合宿での担当： チームリーダー・コンセプト作り・デザイン全般
- 特徴：全体最適化が得意
- 井上（エンジニア）
- 入社時期：2018年1月
- 普段の業務：社内プロジェクトの推進・ボクシルのプロダクト開発
- 合宿での担当：技術の選定・開発
- 特徴：本質志向
- 郷田（PdM）
- 入社時期：2016年10月
- 普段の業務：Biscuetのプロダクトマネジメント
- 合宿での担当：プロダクト整理・開発
- 特徴：情報整理が好き
- 林（CMO）
- 入社時期：2015年11月
- 普段の業務：経営・ボクシルのプロダクトマネジメント
- 合宿での担当：課題整理・発表資料作り
- 特徴：必殺仕事人
チームの特徴は普段の業務からシステム開発を行っている人がエンジニアが1名のみであることでした。
あと謎に、ボードメンバーが所属しています。
SPARK（スパーク）とは
私たちのチームでは、社員数が急激に増えていくスマートキャンプ社内で、社員同士のコラボレーションがしづらくなる問題にフォーカスを当てました。
ひとりが深くコミュニケーションが取れる範囲を最大5人と仮定すると、社員数の少ない時代では5人と話せば会社の全貌をつかめましたが、今だと5人話してもたかだか1チーム分の状況しかつかめません。
SPARKでは質問・回答・蓄積により、その人の エモい社内用プロフィール を自動で作ることができます。特に新入社員に対してのオンボーディングを支援できるように考えてプロダクトを作りました！
合宿当日までの流れ
スケジュール
- 6月
- チーム結成
- 各自自由に合宿のアイデア出しをしていました
- 7月
- チームが活動開始
- 毎週のMTGを始めてアイデアの絞り込みを行っていました
- 8月
- 課題ヒアリング
- プロダクトイメージを煮詰めつつ、解決したい課題を絞り込んでいました
- 9月
- プロダクト決定
- 機能の絞り込みや技術の選定を行っていました
- 10月
- コンセプトとデザインの作成 ・合宿本番
- 発表に向けてのプロダクトの背景を煮詰めました
合宿当日以外は、通常業務の合間で準備やMTGを重ねていきます。話し合いを4ヶ月前から始めているものの、基本的に週に1時間（月に4時間程度）しか集まれませんでした。思うように進捗しない時間を乗り越えながら、当日に向けて準備を進めていきました。
プロダクトが解決する課題を定める
メンバーのアイデアベースで社内の課題定義を行いました。
アイデアの多くは、社内での取り組みを支援するものでした。
- サービス案の例
- 社内で図書を借り合える
- 部活動の活性を支援する
- 毎朝の朝会を面白くする
- 日報の効率化
- 社内の色々なことを依頼しやすくする etc
場に出たアイデアから「私たちはスマートキャンプのどんな課題を解決したいか？」をホワイトボードに書き出していき、課題の定義を行っていきました。
フォーカスする課題をオンボーディングや社内コミュニケーションといったHRに近い領域に絞ってからは、人事担当を呼んで現状の課題をヒアリングしながら、より具体的な課題を抽出していきました。
議論の末、解決する課題は新入社員のオンボーディングに決まりました。オンボーディングは社内で型化が進んでいない現状がありました。チームメンバーもオンボーディングで苦労した経験があったことから、取り組むべき課題に選定しました。
開発内容の決定
課題が決まってからは、元のアイデアから機能一覧の洗い出しをし、ユーザーストーリーマッピングを行い、MVPの開発要件を決めていきました。
MVPを定めた上で、Figmaによるプロトタイピングを行い、それをベースにチーム内での認識合わせと、実開発を進めていきました。
技術選定
今回の合宿で開発するSPARKでは技術的に特別なことをやる必要性はなかったので、開発工数があまりかからないような一番スモールな形にしました。
| 領域 | 技術・ツール |
|---|---|
| フロントエンド | Nuxt.js |
| フロントコンポーネント | Element UI |
| バックエンド | Ruby on Rails 6 |
| 認証系 | Auth0 |
Nuxt.js
Nuxt.jsの選定理由としては、開発スピードの削減とPWA対応が挙げられます。
開発チームである井上とPMの郷田はVue.jsを触れるメンバーであったこともあり、 実際の開発以外の設定周りはすべてNuxt.jsに任せることで開発工数を削減しました。
Element UI
後々のPWA対応のためにモバイル対応しているのと、 単純にシンプルで使いやすくて好きだったのでElement UIにしました。
今回の合宿チームはデザイナーと一緒ということもあり、Element UIをもとに全体のイメージや画面レイアウトを作成してもらいました。
Ruby on Rails 6
今回のプロダクトは技術的には特別やることがないため、Railsで十分だろうという判断をしました。ただ、触ったことのなかったRails6に挑戦することにしました。
Auth0
認証周りは技術的にやったことないことへの挑戦も含めてAuth0でJWT認証で行いました。
設計としてはAuth0のみでユーザー情報を保持し、DBではemailなどの情報は持たない設計にしました。JWTのdecodeはRails側からAuth0のAPIへリクエストを送信し行いました。
プロダクトコンセプト作り
コンセプトの不在
合宿の2週間前にはプロダクトの基本機能が決まり、ワイヤーフレーム制作と技術選定が進んでいました。
その中で、デザイナーの高松からプロダクトコンセプトが必要だという意見が挙がりました。
社内コミュニケーションを促進するための機能を質問しあえるプロダクトを作るに定めたものの、このプロダクトを触るユーザーはどのようなモチベーションで向き合えばいいのか、このプロダクトを使うことによって得られる体験や未来を想像させる説得力が欠けているように感じることがあったからです。
コンセプトがないことによる不具合はデザイナーとしての実作業にも現れていました。ワイヤーフレームからプロトタイピングを行うにあたり、
- ここに使うべき色はなんだろう
- UIでどんな印象を与えよう
- この機能、本当にこの位置でいいんだっけ...？
といった疑問が生まれては立ち止まることが増えてきていました。
作ってよかった3つのもの
コンセプトがない状況のままでは、作業の迷いが増えるうえにデザインや開発の方向がぶれていく可能性がありました。プロダクトのユーザーとなる社員にはこのプロダクトの機能、すなわちできることではなく実現したい未来を認識して使って欲しいという思いもありました。
これから合宿に向かう開発チームのためだけでなく、プロダクトとユーザーのモチベーションも統一するためにも、合宿までに3つのものを作ることにしました。
- 世界観となるプロダクトコンセプト
- コンセプトを表すプロダクト名 & ロゴ
- 世界観を支えるテーマカラー
SPARK - 火花のように質問が飛び交うプロダクト
合宿後に発表したプロダクトコンセプトがこちらです。
スマートキャンプには CAMPFIRE という社内イベントがあります。 会社の経営陣が何を考えているのか、社員同士が何を考えているのか、業務では関わりを持ちづらい社員同士のコミュニケーションを促進する目的で生まれたイベントです。
私たちのプロダクトも、新メンバーと既存メンバーのコミュニケーションを促進する目的で生まれています。コミュニケーション促進という同じ目的を持ったCAMPFIRE から火のテーマを抽出することにしました。
テーマを共通にした一方で、私たちのプロダクトでは特定の相手と焚き火を囲んでじっくりと話し合うのではなく、誰とでも気兼ねなく軽快に質問しあってほしいという思いから、プロダクト名は焚き火の火の粉からSPARKに決まりました。 コンセプトとプロダクト名が決まったあとは、カラーイメージも選びやすくなり、合宿最中にロゴも決定しました。
最短で固めたコンセプトでしたが、プロダクトのイメージがぐっと引き締まり、合宿中のディスカッションにおいてもプロダクト名とコンセプトが決まっていることで共通認識をとりやすくなるなど、多くのメリットを感じることができました。
（他にもあったプロダクト名の案）
社内発表後の反響
他の2チームも含め、エンジニア合宿で作られた3つのプロダクトは、合宿成果として社内で発表されました。
（発表会の様子）
どのチームのプロダクトも反響があり、その日の日報では社員がたくさんの感想を投稿してくれ、合宿に取り組んだエンジニアとしても嬉しい反応が返ってきました。
終わりに
社内の非効率を考えて解決する時間には、通常業務では得られない発見がたくさんありました。来年ももっと良いプロダクトを作り上げたいです。
そんなスマートキャンプでの開催のイベントが近々あります！B2B SaaSに関わる人はぜひ遊びに来てください！
