年90回以上のアップデートを実現する、Backlogを使ったスクラム開発で紹介している顧客のニーズを集めて可視化するしくみについて詳しくご紹介します。
アジャイル開発とは、顧客にとって価値のあるプロダクトを素早く継続的に提供するための開発手法です。顧客にとって本当の課題とは何なのか。その課題をどうやって解決すれば価値につながるのか。その答えは自分たちではなく顧客の中にあると考えています。
目次
顧客からの要望の大切さに気づいたきっかけ
アジャイルを始めて10年。ようやくアジャイル開発の目的がわかるようになってきたでも書いていますが、1年かけて作った機能がほとんど利用されなかったという苦い経験があります。
顧客はこんな課題をかかえているのではないかという仮説を立て、1年かけてUIや機能を作り込んでいきました。いざリリースしてみたものの思ったほど使われなかったため、機能が不足しているのか、使い勝手が悪いのか、何か改善すべきポイントはないか顧客にヒアリングをしてみました。
ヒアリングでは機能としておおむね好意的にとらえていただきましたが、そもそもその機能を使うシーンが月に数件しか発生しない、その機能を使わなかったとしても1件の処理に5分ほどしかかかっていない、といった現状が浮かび上がってきました。
また、その機能を継続して使っていただけそうか聞いたところ「新規開拓営業に力を入れている会社さんだと活用できそうですね」「自分たちがBtoCのサービスをやっていたら使っていると思います」などの利用シーンはあげていただけるものの「これで自分たちの課題が解決しました！」という声にめぐり合うことはできませんでした。
もっと早くユーザーヒアリングを実施すべきでした。わたしたちは1年もの間、存在しないターゲットに対してプロダクトを作っていたのです。
ユーザーが熱望する機能がひと目で分かるニーズカウンター
この反省をふまえ、ユーザーが熱望する機能がひと目で分かるように「ニーズカウンター」をつくりました。
チャットサポートやアンケートを通して集められた要望は4,000件以上。これらの要望を機能ごとにとりまとめ、機能を開発したらどれくらいのユーザーに影響を与えるかを加味して総合的な需要度で要望を並べ替えたものがニーズカウンターです。
ユーザーからの要望の投票数が集計されているニーズカウンターを見ることで、開発の優先順位づけを客観的に判断できます。実際には開発工数やビジネス上の優先度もふまえて開発順を決定をしていますが、基本的には要望の多いものから対応しています。
そんなニーズカウンターはこうやって作っています。
１．顧客の課題をあつめる
日々チャットサポートやヒアリングを通して多くの要望が寄せられます。寄せられた要望はカスタマーサクセスやカスタマーサポートのメンバーを中心に、Backlogの「顧客ニーズ」というプロジェクトに課題として追加をします。
そのとき入力する項目は次のようにしています。
問い合わせURL
チャットのURLやメールのURLなど問い合わせの一時情報へのリンクをはります。ユーザーが具体的にどう言ったのか、どんな言葉を使って説明をしているのかは非常に重要な判断材料です。
ユーザー情報
利用期間や利用頻度、管理者か一般ユーザーかによって要望も変わってくるため、どのユーザーからの要望かも大切な情報となります。さらに詳しくヒアリングしたい場合や機能を先行リリースする時の案内先としても使っています。
要望
要望の具体的な内容を記載します。
要望が必要なシーン（業務フローや背景）、利用頻度、活用イメージ
業務フローや背景をヒアリングすることで本当の課題を洗い出します。誰が、いつ、どうやって使っているかを知ることで、より良い解決策につなげることができます。
２．顧客の課題をとりまとめる
複数の異なる課題も1つの機能を実装することで実現できることもあるため、プロダクトマネージャーが要望の取りまとめを行っています。
要望を取りまとめ、開発する機能に落とし込んだものはBacklogの「開発」プロジェクトにエピックとして登録します。エピックには課題、ユーザーストーリー、リリースゴールなどに加え、顧客欄を用意してそこに関連する顧客ニーズをまとめています。
プロダクトマネージャーは毎週Backlogの「顧客ニーズ」のプロジェクトに登録された新しい課題を確認し、エピックに顧客ニーズを取りまとめていきます。
まだ対応するエピックがなければ、顧客欄に課題のURLを記載して新しいエピックを作成します。すでに課題に応じたエピックがあればそのエピックの顧客欄に課題のURLを追記していきます。
このようにして要望の数に応じてエピックの顧客欄が増えていくようになります。
３．ニーズカウンターに反映する
それぞれの機能を開発するときはBacklogだけで事足りるのですが、全体を俯瞰して見るためにスプレッドシートを使ってユーザーからの要望の投票数を集計しています。
- Backlogからエピックをエクスポートしてスプレッドシートにインポートします。
- スプレッドシートでエピックごとの要望の数をカウントします。
- 機能ごとに利用ユーザー数が異なるため重み付けをして並べ替えます。
Backlogからエピックをエクスポートしてスプレッドシートにインポート
BacklogからエピックをCSVでエクスポートしたものをスプレッドシートにインポートします。完了したエピックも含めて全件をエクスポートして取り込んでいます。
スプレッドシートでエピックごとの要望の数をカウント
エピックの顧客欄の行数をカウントしています。
機能ごとに利用ユーザー数が異なるため重み付けをして並べ替え
同じ1つの要望でも「500人が使うA機能に対する要望」と「100人が使うB機能に対する要望」だと改善の影響を受けるユーザー数が変わってきます。なるべく多くのユーザーが機能改善のメリットを受けられるように重み付けをしてから並べ替えをしています。
このようにしてニーズカウンターをつくっています。
４．開発優先順位を決める
ニーズカウンターをもとに、開発工数やビジネス上の優先度もふまえて開発の優先順位をつけます。ニーズカウンターにリストアップされている要望は1,500件にのぼり、すべてに優先順位をつけることは現実的ではないため、まずは1年間の開発ロードマップを決めています。もちろんこれは今後の開発を確約するものではなく状況によって柔軟に優先順位を入れ替えています。
ニーズカウンターを軸にユーザーへのヒアリングからリリース後の利用状況の計測までを「ユーザーニーズフィット戦略」として定めています。ヒアリング手法や利用状況の計測についてはまた別の機会にまとめたいと思います。
プロダクトのビジョンも顧客からの声を軸に
2022年2月に中長期的なプロダクトビジョンを言語化しました。
このビジョンもプロダクトマネージャーやエンジニアが「こんな機能があったら便利そうだよね」とゼロから考えたわけではありません。上記ブログからの抜粋ですが、
長い年月をかけて多くのユーザーからの声を聞く中で、チームが生産性を上げ成果を出すためには、”誰がいつ何をしているか”という時間を起点としたコミュニケーションが最も重要であるということを再認識することができました。
時間を軸としたコミュニケーションの課題を解決していくために、これからのプロダクトがめざすべき姿として「カレンダーをすべての情報の集約の場としていく」という考えに至りました。
とあるように、顧客からの声や使い方を起点として中長期的なビジョンを立てています。
これからも顧客を中心に考えてプロダクトを成長させていきたいと思います。
一緒に働く仲間を募集しています。
新卒採用・中途採用を問わず、年間を通して、さまざまな職種を募集しています。「すぐに仕事がしたい」「話を聞いてみたい」「オフィスを訪問してみたい」など、ご応募をお待ちしています。共に未来をカタチにする仲間を待っています。
