人が欲しいと思うものを "見つける" プロダクト開発

Kento Jogo

2019年2月21日 12:38

#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として扱う場合、シートのアクセス権限や運用をしっかりしないと直接データをいじれてしまうため、容易にヒューマンエラーが発生するなどスケールを考えると不安な部分は多くあります。

・本開発へ抜け出すタイミングを見誤りやすい

これこそグラムがもっとも苦労したことです。使い勝手がよく、どんどん改善していった結果、クイックで検証するために使っていた機能が大きく膨らんでいく。そして本開発へ移行するタイミングを見失った結果、負債の返済のため多くの時間を要してしまいました。あくまでも検証のためと線引し、どこかで足を止めてでも負債を返済する覚悟が必要です。

ではこのような検証フローを挟めばすべてがうまくいくのか。