こんにちは、kickflowのPMチームでPMM（プロダクトマーケティングマネージャー）を担当している許です。
kickflowでは、お客様の課題を解決するために日々新機能の開発や改善を行っています。
多くのSaaSプロダクトがそうであるように、私たちのもとにもお客様から「こんな機能がほしい」「ここを改善してほしい」といったご要望が数多く寄せられます。「次に何を作るべきか？」という意思決定は、プロダクトの成長において非常に重要です。今回は、私たちが多数のご要望の中からどのように開発する機能を決定し、優先順位付けを行っているのか、そのプロセスをご紹介します。
はじめに: kickflowの機能開発における考え方
ワークフローという市場は、突飛な機能で競合製品と差別化を図るというよりも、
いかにお客様の業務/課題に向き合い、地道にお客様の課題を解決し続けられるかが重要となる市場と認識しています。
そのためkickflowでは、お客様からいただく声を最も重要なインプットと位置づけ、PdMとPMMで構成されるPMチームを中心に開発の優先順位を決定しています。
具体的なプロセスは、大きく分けて以下の3つのステップで構成されています。
1. ユーザーの声（フィードバック）を集める
2. 課題を解決するソリューションを検討し、フィードバックと紐付ける
3. ソリューションの開発優先順位をつけ、開発バックログに反映する
各ステップを詳しくご説明させていただきます。
1. ユーザーの声（フィードバック）を集める
このステップではユーザーの「課題」を徹底的に集めることを意識しています。
すべての起点となるのは、お客様や社内から寄せられる声です。
私たちはこれらの声を一元的に収集・管理するために、フィードバック管理ツールであるFlyleを活用しています。
フィードバックは、主にフィールドセールス（FS）、カスタマーサクセス（CS）、サポートといったお客様と直接コミュニケーションを取るチーム経由でFlyleに投稿されます。
フィードバック収集で重視している3つのポイント
質の高いフィードバックは、質の高い機能開発に繋がります。そのため、フィードバックを投稿してもらう際には、以下の2つの点を特に意識してもらうよう周知しています。
① 「What（何が欲しいか）」ではなく「Why（なぜ欲しいか）」を記載する
最も重要なのがこの点です。「〇〇機能が欲しい」という要望（What）は任意、その背景にある課題（Why）をマストとしています。
解決策は一つとは限らないため、私たちは常に根本的な課題を捉えることを目指しています。
簡単な例ですが、
-
悪い例: 「従業員情報をCSVでインポートする機能が欲しい」
-
良い例: 「介護施設を運営しており毎月50人分の従業員の入退社を手入力で更新しており、作業に2時間かかっている。入力ミスも発生しやすく困っている」
このように課題を具体的に記載してもらうことで、CSVインポート以外の解決策（例: API連携、より効率的なUIの提供など）も検討のテーブルに乗せることができます。
② 深堀りした一次情報を記載する
「お客様がこう言っていた」といった単純な伝聞ではなく、実際にお客様がどのような状況で、どのような言葉で課題を語っていたのか、という深堀りした一次情報を重視しています。これにより、課題の解像度が格段に上がり、より的確なソリューションの検討に繋がります。
またお客様の直接の声とは別に四半期に一度、社内からのプロダクト改善要望も提出いただいています。
お客様と直接コミュニケーションを取るにあたり、商談化・ご契約・運用の課題となっている点をビジネス本部の各チームからまとめていただいています。
提出いただく際には、上記の2つに加えて、下記も合わせて特に意識してもらうよう周知しています。
③ 「私が考える最強の機能」にならないようにする
ワークフローとして当たり前にある機能など特定の個人の思い込みや、極端にニッチなユースケースに基づいた要望は、SaaSとして多くのユーザーに価値を届けるという観点からは慎重に扱わなければなりません。個別の要望を尊重しつつも、それがより普遍的な課題に起因するものなのかを見極めるようにしています。
2. 課題を解決するソリューションを検討し、フィードバックと紐付ける
集まったフィードバック（課題）をもとに、それを解決するための機能（ソリューション）を検討します。
このフェーズでは、週に一度PMチームで集まり、新しく届いたフィードバックを確認し、議論する場を設けています。
検討の際には、特に以下の点に注意しています。
-
SaaSとしての汎用性: 特定のお客様だけが利用する機能ではなく、多くのお客様にとってメリットがある機能になっているか。
-
課題解決の広さ: 一つのソリューションで、できるだけ多くの関連する課題をまとめて解決できないか。
- A、Bの2つ課題が寄せられた際に、それぞれA、Bに対し個別の機能で対応するのではなく、両方を包含するような「Cという機能」を設計できないかを常に考えています。これにより、プロダクトが複雑化するのを防ぎ、ユーザーにとっても分かりやすい状態を維持できます。
フィードバックの内容だけでは意図が掴みきれない場合は、投稿してくれたビジネスチームのメンバーと直接コミュニケーションを取り、お客様の状況などを詳しくヒアリングして深掘りを行います。
こうして検討されたソリューションは、Flyle上で関連するフィードバックと紐付けられ、管理されていきます。
3. 開発の優先順位を決定する
最後に、検討されたソリューションの中から、実際に開発に着手するものの優先順位を決定します。
優先順位付けの基本軸は「フィードバック件数（ニーズの広さ）」 です。
上記に加えて下記の観点を補助的に考慮しています。
-
ビジネス的な観点: 競合機能の有無・商談/解約確度などへの影響度合い
-
開発工数: 現状「優先度を上げる指標」というよりは実現可能性・他の開発への影響度などを考慮しスクリーニングするため
これらの評価をもとに、3ヶ月という四半期の単位で開発計画を立て、開発バックログに反映しています。
このプロセスを定期的に繰り返すことで、市場やお客様のニーズの変化に柔軟に対応できる体制を整えています。
一方でフィードバック件数偏重だと、長期的なプロダクト方向性を十分に考慮できないなどの課題もあるため、
- 機能別利用頻度などのプロダクト指標面の拡充
- RICEのようなフレームワークを参考にスコアリング導入
など優先度決定の透明性と再現性を高めることを検討しています。
おわりに
今回は、kickflowの新規機能開発におけるバックログ選定プロセスについてご紹介しました。
このプロセスの最大のメリットは、お客様との繋がりを強化できる点にあると考えています。
フィードバックをくださったお客様には、関連する機能がリリースされた際に積極的にお知らせしています。
これにより、kickflowがしっかりとお客様の声に耳を傾けていること、そしてそれをスピーディーにプロダクトへ反映していることを実感していただける一つになっていると思っています。
派手さはないかもしれませんが、お客様一人ひとりの課題と真摯に向き合い、地道に課題解決し続けることが、kickflowが最も大切にしているプロダクト開発の姿勢と考えています。
kickflowでは、ユーザーの課題解決に真摯に向き合い、一緒にプロダクトを成長させてくれる仲間を募集しています！
改善点の構築含め、ご興味のある方はぜひ採用サイトをご覧ください。
careers.kickflow.co.jp
