編集部注
本稿は、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の悪化につながる可能性が高まる」（荒井氏）
