顧客の要望を消化する開発から脱却して本質的な課題を探す開発へ | Geppoプロダクトブログ
こんにちは。Geppoの鹿島(@kashitaka)です。今回はエンジニアの私がプロダクトマネージャーとして悩みながらも機能開発の企画を変えてきた話です。
※この記事はHR Tech Advent Calendar 2019の1日目の記事です。
リクルートとサイバーエージェントのジョイントベンチャーである弊社は、従業員のコンディション管理ツール「Geppo」を作っています。
私は以前のプロジェクトではエンジニアとして作る側をやってきたのですが、今年の4月にこの事業に参画して半年ほど、開発責任者としてプロダクトマネージャー(PdM)の役割もこなす事になり、「機能開発の企画」というプロダクト開発における重要な工程に悩みつつも少しずつ試行錯誤して変えてきました。
今回はそんなGeppoの機能開発の企画の変遷について書きます。私と同じく、エンジニアとして小規模ベンチャーのプロダクト責任者になり、案件の企画に悩んでいる方の助けになれば幸いです。
※12/27追記：本記事は「B2B SaaSエンジニアMeetup」のLT会で発表させていただきました。スライド化したので貼っておきます。
はじめに: 機能開発の企画の苦悩
機能開発の企画は簡単にいうと「次に何を作るか？」を考えることですが、この難しさは「無駄なものを作らない」というところにあります。
無駄なものを作ってしまうと、次のような恐れがあります。
・プロダクトが複雑になったり使いづらくなって顧客の不満に繋がる
・デザインや実装作業、セールス、CSの運用変更など多くの工数を割く事になる
特に小規模ベンチャーはリソースに余裕がなく、回り道している時間もないため、なるべく最短で価値のあるものを作っていかないと会社の成長に及ぼす影響も大きいです。
そんな重要な機能開発の企画の手法を試行錯誤しながら、次の順でレベルアップしてきました。以降の章で順番に紹介していきます。
Lv1: 顧客の要望を消化する開発
Lv2: 顧客の課題を解決する開発
Lv3: 課題の目線合わせ
Lv1: 顧客の要望を消化する開発
私が参画した当初の機能開発の企画は、次のような流れで決められていました。
1. セールスなどが顧客要望を聞いたら起票してリスト化
2. PdMが要望リストに優先順位をつけて分類する
3. PdMが優先順位と工数を考えて次回の開発予定に要望を積む
シンプルでやりやすい運用ですが、2,3回ほど開発サイクルを回すとすぐに気がつくのは、機能が複雑化する方向にしかプロダクトが進化しないというものです。
例えば、要望として「表に〇〇の列を追加してほしい」みたいなものがあり、この要望を叶えると今度は「××の列、△△の列も追加してほしい」という要望がきます。結局全部の要望を叶えていると横に長い表ができてしまったり、横に長い表をカスタマイズする機能が必要になり、結果として何を見ていいのかわからない表ができてしまうという具合です。
さすがにこういった手法は長期で見たときに価値に繋がらないとすぐにわかりましたし、実際、要望をもとに機能追加しても要望していた顧客すら使わない機能もありました。また、PdM関連の書籍などでも
「顧客というのは、根本的な問題そのものよりも、自分がイメージできるソリューションという点から問題を語るものだ 」
「顧客に向かって、何がほしいか、と単純に訪ねることができればいいのに、と思う。でもそう問いかけたところで、(中略)間に合わせの機能を手当たり次第に寄せ集めたようなものができるだけだ」
※いずれも『Inspired: 顧客の心を捉える製品の創り方』より引用
と書かれているので、すぐに脱却しようと思いました。
Lv2: 顧客の課題を解決する開発
次に始めたのは顧客要望を抽象化して課題を設定する手法でした。具体的には次のように進めました。
1. セールス、カスタマーサポートには顧客要望と一緒にその背景も詳しく説明してもらう。背景が足りないもの、重要だと思うものは自分で顧客にヒアリングしに行き、課題の仮説をもつ。
2. データで仮説を検証する。Google AnalyticsやDBをみて似たような課題を持っていそうな顧客を探す。共通の課題を持ってそうな顧客にはヒアリングしにいく。
3. 課題を特定し、解決策としてプロダクトとして何ができるかを考える。
実際には1~3を行き来しながら課題の証拠探しと、課題と解決策がマッチしているかの確認をします。
また、参画して3ヶ月たてば事業の目指す方向やプロダクトの価値観が自分の中で徐々に言語化され、プロダクトの現状と理想のギャップがわかるようになってくるので、それらも考慮しつつ課題の優先順位づけや、取り扱わない課題を決めていきます。図にするとこんな感じです。
この手法は課題から解決策を導くので、「顧客の要望解消開発」よりも本質的な課題を解決する打ち手を打てますし、機能追加だけでなくシンプル化の方向にプロダクトを改善することもできました。
一方で次のような問題が起きるようになります。
「え、それって課題なの？」問題
自分なりに考えて抽出した課題から機能開発を企画をすると、社内の色々な立場から「待った」が入ります。
マーケティング担当「Web広告出せるような課題解決が先でしょ」
セールス担当「競合と差別化できるような課題解決が先でしょ」
経営メンバー「それってそんな重要な課題なの？」
開発メンバー「この課題も重要だけど、もっと重要な課題がある」
PdM「うるせーーーーーーー！！！！！」
と言いたくなりますが、その指摘はどれも的を射てるものが多く、この手法の問題点を考えました。それは全プロダクト課題のうち、私が抽出できている課題はそのごく一部ということです。さらに、私が抽出した課題はそもそも課題でないことだってありえます。図にするとこんな感じになります。
私はPdMとして自分がプロダクトを一番理解しているつもりでしたが、私が捉えているプロダクト像はあくまで一視点から見たものであり、顧客を知っているセールスや、売り方を考えるマーケ担当者はプロダクトの課題を違った視点で捉えていることを見落としていました。
Lv3: そして課題の目線合わせへ
そこで次のステップでは、主要メンバーで課題の目線合わせをすることにしました。改めて整理するとLv1 ~ 3で向き合う課題は次のように変わってきました。
この章では目線合わせのために開催したミーティング「目線合わせ合宿」の手法を紹介します。（「合宿」は泊まる訳ではなく、がっつり時間をとった会議の意味）
■ 事前準備
セールス担当者、マーケ担当者、経営など事業の主要メンバーを呼び、主旨を説明し、「最終的には下記のようなプロダクトの課題が優先順位がつけられて1つのスプレッドシートになっているものが得たい」ということを説明しました。
最終的にこういうものを作りたい
■ 宿題
宿題として、1週間で各自が普段考えている課題をスプレッドシートに書き出してもらいます。ここでのポイントは機能案ではなく、課題を書いてもらうことです。どう機能に落とし込むかは開発チームが考えることなので、あくまで課題を出す場にします。
締め切りになったら各自が出した課題をPdMが印刷して地獄の付箋化作業をします。これは超手間がかかりますが、議論を活発に行うためと割り切ってやりました。付箋なので裏には両面テープも貼って壁に貼り付けられるようにしています。
■ ミーティング本番
はじめに、各自が出した課題を一つ一つ説明します。付箋にした課題を各自に渡し、自分の言葉で課題を語ってもらいながら、ホワイトボードに付箋を貼っていきます。
次に、各自の課題で似たものがあれば集めて分類していきます。この時点で付箋が多いものは、ある程度優先度が高そうであるといことがわかってきます。また分類されないで孤立した課題は1人だけが意識していた課題で、それほど重要な課題ではないか、そもそも課題ではないといことがあります。
最後に分類した課題に優先度を付けていきます。ここが議論が一番活発になります。今のプロダクト上の重点課題は何なのかが、各自の立場から議論をすることで目線が合ってきます。
最後にホワイトボードに書かれた課題の分類とその優先度は模造紙に転記します。これはオフィスの壁に貼っておき、メンバー全員にも課題の背景や優先順位の理由を説明しました。
課題・優先度マップはリフレッシュスペースに貼ってます。
(左がCS責任者の林、右が筆者です)
以上で得られた、「課題・優先度マップ」をもとに優先度が高いものから取り組み、ベストな解決策をPdMが責任を持って考えることができるようになりました。また、PdM以外のメンバーもこれをみて「こういう解決策があるんじゃないか」という議論をしたり、CSは今後取り組む重点テーマを顧客に伝えることができるようになりました。今後は半年に一度くらいの頻度で同じ手法で課題・優先度マップをアップデートしていこうと思っています。
最後に
エンジニアだった私が機能開発の企画を任され、本当に価値があるもの作るため「顧客の要望解消開発」を抜け出し、悩みながらも課題の出し方を変えてきました。機能開発の企画は解決策を出すよりも課題設定が難しいと感じており、今後もベストな方法を探しながらプロダクトの価値を向上していきたいです。
今後取り組む問題として今考えているのは「課題解決 = システム開発」問題です。下記がイメージです
現状(左)は課題解決となるとすぐに機能開発の話になりがちで、この構造では顧客の課題を解決するために多くの開発工数が必要になりますし、顧客の課題が解決されないとCSやセールスから開発組織への不満が溜まり続けます。
機能開発は課題解決の強力な手段ですが、システムである以上どうしても融通が効かず、変更に時間がかかりますし、個別のケースまでは拾いきれません。一方で、人の得意分野は複雑な個別の事象を柔軟に扱うことであり、プロダクト + 社内の機能組織をうまく組み合わせて課題解決を考えていきたいです。この組み合わせを考えられるのは、「どこまでが機能で解決可能で、どこが苦手か」を知っているPdMの役割だと思います。今後は社内のリソースを組み合わせて顧客の課題解決を提案できるような開発手法を探りたいです。
最後に、弊社では「個と組織が共に輝く社会を実現する」というビジョンの実現に向けて、まだ取り組めてない課題が山ほどあります。ここで取り上げた課題・優先度マップにはまだまだたくさん課題が貼ってあります。これらの課題を一緒に解決しつつ、さらに良い価値開発プロセスを探っていくプロダクトマネージャー、バックエンドエンジニアの仲間を募集しておりますので、事業に興味がある方はお気軽にDMなどお待ちしております！！👋