編集部注
本稿は、CodeZineに掲載された、ソフトウェア開発者向けカンファレンス「Developers Summit 2022（デブサミ2022）」のセッションレポートを転載したものです。プロダクトづくり、プロダクトマネジメントに近しいテーマを選りすぐってお届けします。
「せっかく作ったのに使われない」悲劇を生まないために
株式会社フライルは、2021年6月にシードラウンドでの資金調達を行い、プロダクトマネジメントクラウド「Flyle（フライル）」の正式版をリリースしたばかりのスタートアップだ。
プロダクト開発のフェーズには、アイデア創出・検証・企画を行う「ディスカバリー」と、開発・実装する「デリバリー」の2段階がある。Flyleは、この「ディスカバリー」のフェーズをカバーするプロダクトであり、「機能アイデアの管理」「ユーザーフィードバック、ユーザーインタビュー管理」「顧客セグメンテーション」などの機能を用いながら、社内の声を機能アイデアとひもづけて、内容の精査や優先度決めに活用することができる。
荒井氏は、なぜこのFlyleを作ろうと思ったのか。それは「時間をかけて作った機能やプロダクトが、ユーザーに全然使われなかったとき」に感じた、開発者としての苦い過去があったという。
「自分自身も、過去に開発に関わったプロダクトの中に、今ひとつ顧客に刺さらなかったため開発を止めたり、ピボットが必要というもどかしい経験をした」（荒井氏）
その後、同様のペインを抱える人がいるかを調査するため、約100名のプロダクトマネージャーを対象に、インタビューを実施した。「顧客に使われない機能を作ってしまった経験はありますか？」と尋ねたところ、90%以上の人が「はい」と回答した。その理由として、「納期に間に合わないため、十分に検証ができなかった」「重要顧客からの要望だったので、そのとおりに開発した」「CEOなど、影響力のある人の意見をそのまま仕様に反映した」「自分もユーザーだったので、いいと思って作った」といったものが挙げられたという。
プロダクト開発に携わっていると、「MVP（Minimum Viable Product）」や「リーン開発」の言葉に触れる機会は多い。これらのセオリーとして「顧客を理解して、課題を解決できる最小のプロダクトから始めなさい」と説かれるが、いざ実践しようとすると、限られたリソースの中で最小のプロダクトや機能を定義するのはたやすいことではない。この理想と現実とのギャップが、顧客に使われない機能を作ってしまうという悲劇につながっていると荒井氏は分析する。
そもそも、今回のテーマであるBtoBのプロダクト開発では、次のような特徴が挙げられる。
- 組織で利用の意思決定をする
- ユーザー数が数百〜数千と少ない
- 費用対効果や効率化など、論理的なメリットが求められる
- 各社、業務フローが異なる
- 1社あたりの売上が異なる
こうした特徴から、「機能開発における重要な情報は、『ターゲットとする顧客セグメント』『顧客フィードバック』『N1インタビュー』の3つになる。BtoBでは、定量データに加えて定性情報に重きが置かれることが多い」と荒井氏は説く。
加えて、BtoBならではの特徴として、プロダクトの成長のヒントとなる情報が社内で分散しがちである点を挙げた。「失注／成約理由・製品への期待値」に関する情報は営業部門が持っているのに対し、「顧客セグメント情報・競合情報」はマーケティング部門が持っており、「利用状況・製品フィードバック・解約理由」の情報はカスタマーサクセス部門が握っているといった具合だ。
プロダクトマネージャーは、これらの情報を駆使しながら、ROI（Return on Investment：投資収益率）の高いプロダクト開発を実施することが求められる。「とはいえ、売上・利益や費用といったビジネス部門が着目する直接的なアウトプットではなく、開発者特有のRとIを意識しなければならない」という。その上で、荒井氏は開発者視点で考えたRとIを次のように整理した。
Return：機能がユーザーに与える価値
対象となるユーザー数・解決できる課題の大きさ・改善の幅。
Investment：リリースまでの工数
要件定義／ステークホルダーとの調整／実装／テストなどにかかる時間。
「網羅的に顧客情報を把握して、ニーズの把握や要件定義ができれば、効率よく顧客の課題解決ができるので、“R（リターン）”は大きくなる。逆に、断片的な顧客情報をもとにプロダクト開発を行うと、個社最適の機能となってしまいROIの悪化につながる可能性が高まる」（荒井氏）
ROIの高いプロダクト開発を実現するには？
続いて荒井氏は、ROIの低い開発と高い開発の違いをより鮮明に伝えるべく、自身が過去に経験した失敗談と成功談を紹介した。
まずは失敗談から見ていこう。Flyleには、顧客のフィードバックと顧客情報をひもづける機能がある。その機能に対し、Flyleの利用者から「Salesforceの顧客情報をFlyleに自動で連携させたい」という要望が多く寄せられていた。
そこで、「条件に合致するSalesforce上の取引先／商談情報を“リアルタイムで”Flyleに同期できるようにしよう」と荒井氏は考えた。しかし、いざふたを開けてみると、Flyleの利用者が求めていたのは、あくまでも自動で連携することであり、そこにリアルタイム性は求められていなかった。その結果、想定よりも多くの技術調査や設計の工数をかけてしまった。
そこには顧客と開発者の認識のズレがあった。「何を実現すべきなのかを深掘りせずに、『リアルタイムでデータを取り込む必要があるだろう』と、思い込みで進めてしまった。開発者は自分で作れてしまうからこそ、オーバースペックな機能開発に陥りがちだ」（荒井氏）
一方、成功談はどのように生まれたのか。FlyleのSlack連携機能を開発したときのことだ。「Slackに投稿された顧客のフィードバックをFlyleに飛ばしたい」という要望があった。当該の顧客の業務フローをしっかりと理解できていたことから、「取りあえず任意のSlack投稿をFlyleに飛ばせるだけで良さそうだ」と判断した。結果、顧客が求める最小要件でリリースした後、実際に使ってもらった上でフィードバックをもらい、継続的に改善するという理想の形につながった。
「人は満足したときよりも、不満がある時のほうが、具体的な要望を語ることができる。多少、作り込みが甘かったとしても、実際に使ってもらってから得られるフィードバックを活用して、徐々に顧客が満足する要件に近づけるアプローチのほうが、トータルのコストを下げられると考えている」（荒井氏）
そんなフライルでは、顧客の解像度を上げるための取り組みとして、「顧客フィードバックデータベース」を運用しながら、日々の機能開発に活かしている。ここには、顧客と接点をもつビジネス部門によって「どの顧客セグメントの」「どの顧客が」「どんな業務中に」「何に困っていて」「どんな要望を話していたか」といったデータが蓄積されている。
プロダクトマネージャーである荒井氏が、これらの蓄積された「顧客の声」を参照することで、表面的な顧客の要望だけでなく、要望の背景にある顧客の課題まで知ることができる。結果として、顧客のニーズを満たすソリューションを素早く、精度高く企画立案することができるのだ。
この顧客フィードバックデータベースのポイントは、“フィードバックの発言者が特定されている点”だ。発言者が不明なフィードバックは、発言の背景を理解できないため基本的には扱わない。また「文面だけでは正確な情報をつかみきれず、顧客に直接ヒアリングして、より深掘りしたいケースが出てくる。その際に、発言者が特定されていることで、ユーザーインタビューのリクルーティングがとても容易になる」と荒井氏は明かす。
そして、この仕組みを回すには、フィードバックを蓄積する仕組みの他にビジネスチームの協力を得て、顧客からフィードバックを収集するというプロセスが欠かせない。そのためには、売上の創出と顧客の成功には、エンジニア・プロダクトマネージャー・デザイナーが担う「製品力」と、セールス・カスタマーサクセス・マーケティングが担う「コミュニケーション力」の掛け算が重要であると組織全体で理解しておく必要があるという。
荒井氏は、ビジネス部門からフィードバックを集めるための取り組みとして、次の4つのステップを示した。
- Step1：ビジネス部門からフィードバックを上げる場（ツール）を用意する
- Step2：内容の良しあしに関係なく、フィードバックを伝えてくれたことに感謝する＆リアクションする
- Step3：書き方や内容が良いフィードバックをお手本として取り上げ、注目を集める
- Step4：リリースした機能の参考になったことをフィードバックする
「ツールやフレームワークを導入したからといって、いきなりフィードバックの文化ができあがるわけではない。地道な意識づけと改善、そして時にはトップの意思決定が必要だ。一度仕組みが出来上がってしまえば、全社で顧客のニーズに向き合い、継続的に『顧客に喜ばれる機能』を提供できるはず」（荒井氏）
