人が欲しいと思うものを "見つける" プロダクト開発
#genbabito にてお話した内容の全文公開します！
ご来場いただいた参加者のみなさん、ご一緒させていただいたトランスリミット 松下さん・ヤプリ 梶原さん、運営スタッフのみなさん、どうもありがとうございました！
また今回スライド作成にあたり、友人であるきよえ氏のスライドデザインを参考にさせてもらいました。なんならこのnoteも真似させてもらってます(笑)ありがとう！
それでは始めます！
こんばんは！
はじめまして、グラム株式会社 プロダクトマネージャー の城後です。今日はよろしくお願いいたします！
僕は、「Jobgram」 という性格データとチャットボットを活用した転職サービスの機能やコンテンツの全般的な企画・運営、戦略の構築や事業計画の策定などを行っています。
Jobgramは、独自の性格診断に基づき、2,000パターン以上から性格を分類。向いている職種やマッチする会社、ポテンシャルと本人の希望を踏まえたキャリアプランのご提案を行う転職サービスです。
こちらは僕の診断結果です。合理的でサバサバしてるとよく言われます(笑)
昨年末にはTwitterを中心にちょっとしたバズが起こって、多くの方にJobgramの性格診断を利用してもらうことができました。「ストレングスファインダーと同じくらい当たってる！」「スラスラ回答できてストレスが少ない体験が気持ちいい！」など嬉しい声もいただけています。
まだやったことがない方はぜひ「Jobgram」で検索してやってみてください！
さて今回は、僕がこのJobgramのプロダクト開発をする経験から学んだことをベースにお話ししようと思うのですが、いろんな役割やポジション、様々な事業フェーズの方がたくさんあつまる場だからこそのテーマでお話してみたいと思います。
それでは、本日のテーマ「人が欲しいと思うものを "見つける" プロダクト開発」。
人もお金も時間も限られているスタートアップにおいて、いかに無駄な作業を減らし最速で進むのかが成長の鍵となっています。
しかしグラムでは、頑張って開発した機能がほとんど使われないということが度々ありました。
その原因は2つです。誰も必要としない機能を生み出していたこと。そして必要以上の機能を生み出していたことです。
すべてのプロダクト開発に携わる人は、ユーザーに対して新たな価値を提供し、ユーザーに利用してもらい愛されるプロダクトにしていくことで、結果としてに何かしらのビジネス上の成果を上げるためにプロダクトを作っています。
にもかかわらず、「誰も必要としないもの」を作ってしまってはユーザーに利用してもらうこともなく、当然ビジネス上の成果も上がらず誰も幸せになりません。
ただ一方で「リリースしてみないと必要であるかどうかわからない」という不確実性が存在します。この問題は長きにわたるグラムのプロダクト開発における課題でした。
ではどうしたら「スピードを落とすことなく、効率よく不確実性を減らしていけるのか」。
この課題を解決すべくグラムでは「最小単位での課題・解決策の検証」を実施することにしました。それではグラムのプロダクト開発プロセスの1つ目をご紹介します。
「無駄の多い・スピードが落ちる開発」をしてしまっている課題があるなか、これからやろうとしていることは「解くべき課題であるのか」「課題に対して適切な解決策なのか」を素早く確かめるため、必要最低限の機能のみをつくり、小さくリリース。
そして実際のユーザーにぶつけてフィードバックを得ていきます。小さくつくってその都度フィードバックを見ながら方向修正を行う。そうすることで大ハズレをするリスクを減らしながら「人が欲しいと思うものを "見つける"」プロダクト開発プロセスを踏んでいます。
Jobgramの開発現場での実例を踏まえてお話していきます。
Jobgramではまず性格診断を受けてもらうところから始まります。そして性格診断を受けたユーザーへ診断結果・経歴・希望をもとに、一人ひとりに合わせたスカウトメッセージを送ります。
ユーザーはスカウトに興味がある場合、送られてきたメッセージに対してボタン（クイックリプライ）で返信。エージェントとの面談希望の場合は日程調整へ進みます。
ここで問題がありました。エージェント側から候補日提案を行うのですが、空き日程を確認してから送るため、タイムラグが発生してしまい離脱が多くある状況にありました。
そこで「面談希望から候補日選択までを自動化することで、タイムラグがなくなり離脱率が減る」という仮説を立てました。
そして「先に希望日時をボタン形式で登録してもらえるよう自動化を実施。確定日は後ほど連絡する形式に変更することでタイムラグを失くす」という解決策を発案。それぞれ課題・仮説・解決策の検証をすべく、検証用開発をスタートしました。
このような検証の際、グラムではGoogle Apps Script（以下GAS）とGoogleスプレッドシートを活用した、本運用の開発環境とは別立てした環境で機能開発を行います。
Google Apps Scriptは、Googleが提供しているJavaScriptベースの開発環境です。
メリットとして大きく3つ。
・小回りが効く
GASとスプレッドシートを利用した開発を行う最大の理由は「そもそも仮説の正しさがわからない状態なのでスケールよりもスピードを優先する」ため。
GASは、開発環境のセットアップやサーバー構築が不要、様々な外部アプリケーションとの連携が可能、スプレッドシートなどGoogle関連サービスとの連携が抜群などの特徴があります。スピードを優先させた開発がしやすく、何よりも小回りの効く開発を重要視するフェーズでは向いているのではと考えています。
・検証・運用のアップデートもしやすい
実際にオペレーションに組み込み機能を使う際や、数値分析をして検証をする際はスプレッドシートを利用しています。
普段から利用しているスプレッドシートであればオペレーション側の学習コストがほとんど必要ないため導入ハードルが低く、またデータの取得や加工など検証も非常に簡単です。検証を経ての気づきを次の仕様に組み込める、リリース後のアップデートのしやすさはアドバンテージとなります。
・潰しやすく、負債となりにくい
「これだけ頑張ってつくったんだし、潰すのが心苦しい・・・」「いつか、いつか使うはずだから・・・」など、開発の現場では負債が溜まっていくなんてことはあるあるネタなんじゃないかと思います。もちろんGASでつくったものも潰すのが心苦しいのは変わらないのですが、クイックでつくった分その負担は軽く、負債を解消しやすいなというのがあります。
一方でデメリットもあります。
・スケールしにくい
GAS・スプレッドシートともに実行時間やデータサイズ・実行回数など様々な制限がある、GASのWEBエディターが扱いづらい、スプレッドシートをDBとして扱う場合、シートのアクセス権限や運用をしっかりしないと直接データをいじれてしまうため、容易にヒューマンエラーが発生するなどスケールを考えると不安な部分は多くあります。
・本開発へ抜け出すタイミングを見誤りやすい
これこそグラムがもっとも苦労したことです。使い勝手がよく、どんどん改善していった結果、クイックで検証するために使っていた機能が大きく膨らんでいく。そして本開発へ移行するタイミングを見失った結果、負債の返済のため多くの時間を要してしまいました。あくまでも検証のためと線引し、どこかで足を止めてでも負債を返済する覚悟が必要です。
ではこのような検証フローを挟めばすべてがうまくいくのか。
人生思い通りにはなりません。
ここで問題になってくるのが「機能の最小単位をどのように定義し、どのタイミングで本開発に移行するのか？」
というところで、2つ目の課題である「必要以上の機能を生み出していたこと」を解決するための「必要最小限の機能をどのように定義するか」について。
グラムでは「必要最小限の機能が揃った状態=適切なフィードバックを得られる状態」と定義しています。
もう少し具体的に紹介していきます。
・仮説に対して結果を出したことを検証できる状態
解決策によって改善したい課題、つまり事業上重要な数字（KPI）が評価でき、仮説に対して結果を検証できる状態です。解決策によって数字が落ちてしまうネガティブ結果も起こりうるため、ポジティブな影響がありうる指標だけでなく、ネガティブな影響がありうる指標も設けておきます。
ただし定量的に測れる指標だけでなく、肌感覚的に感じ取る「定性的なユーザー体験の変化」を見ることも意識しています。例えば「ユーザーの初回アクションから次アクションまでのスピードが上がった」といった、日々日々ユーザーを見ていないと気づけない変化も重要です。
一方で「仮説に対して結果を検証できる状態」を作れれば仕様が膨らまないかと言えばなかなか難しいのが現実。そこで実際に開発を進めながらよかったなと感じた具体的なポイントもご紹介していきます。
・特定のユーザーのみに対象を絞る
検証段階では特定のユーザーのみに対象を絞り、限りなく対象スコープを狭めていきます。このようにすると開発工数の削減だけでなく、検証・分析時にもクイックで数字を出せるのでラクです。
・変数は最小にする
表示する項目・テキストパターンなど、条件によって実行される変数は最小にします。検証時には決まったパターンを表示する場合であってもユーザーにとっては新しい体験であり、十分な態度変容が起こるため、ポジティブ・ネガティブな数字の変化は検証可能でした。
・ステップは短くする
検証によって新たなステップが追加される場合でも、限りなく短く設定します。本来であればその後追加したいステップがあったとしてもそもそも施策効果が見込めなければ無駄になってしまうので、余計なステップを追加しないのが吉です。
開発プロセス以外の特徴も少しご紹介します。
Jobgramの開発では、Facebook Messenger Platformを活用しています。
開発当初、自前のメッセージ機能をつくる話も上がりましたが、Facebook Messengerを採用した理由としては、
・ユーザーは使い慣れたMessenger上でコミュニケーションができるため、学習コストが低く、利用ハードルも低くなること
・APIやレファレンスが提供されているため開発がしやすいこと
・送受信の管理画面があるため、準備が整えば比較的すぐに運用開始できること
などのメリットがあったためです。
グラムで実践しているプロダクト開発のご紹介は以上となります。
僕たちは今回ご紹介したことを実践することで「いかに無駄な作業を減らし最速で進むか」に取り組んでいます。
でも僕たちもまだまだすべてを完璧にできているわけではなく、回り道をした開発をしてしまっているケースがあり、日々改善を続けています。
今回お越しのみなさんのより良い開発をするためのメソッドを教えてください！お待ちしています！
以上、「人が欲しいと思うものを "見つける" プロダクト開発」でした。
最後に告知です！
そして、グラムでは一緒に働いてくれるメンバーを募集しています！
エンジニア・デザイナー・ビジネスなど、様々なポジションで採用中ですが、特にサーバーサイドのポジションは採用強化中です。
技術スタック的にはRuby on Railsを用いた、Jobgramの開発となっています。
週1回リモートワーク可・12〜17時のコアタイムを採用しているなど、比較的フレキシブルな働き方ができるかと思います。
まずは副業からでもOKです。少しでもピンときた方は、Wantedlyからお気軽にご連絡ください！お待ちしております。
ありがとうございました！
🙏
🙏
🙏
初めてのLTでとても緊張しましたが、Twitter上の反応などを見ていると共感いただいている部分もあったようでよかったのかなと思います。
とても良い機会だったので、そのうちまたLTしたいです！
それでは！
いいなと思ったら応援しよう！
