4000件超の顧客要望をプロダクト改善に活かすためにログラスが取り組んだこと

「この機能があれば受注できる」「この機能を何とかしてほしい」＿＿。

ひとたびプロダクトをリリースすると、プロダクトマネージャーのもとには大小さまざまな顧客要望が寄せられてくる。緊急度の高い要望を優先するうちにバックログが顧客要望で溢れかえり、何から手を付けるべきか分からなくなることも少なくないだろう。

昨年12月に開催された「プロダクトマネージャーカンファレンス（pmconf）」で、株式会社ログラスのプロダクトマネージャー宮本大樹氏が「4000を超える顧客要望からプロダクトの未来を描いた話」と題した発表を行った。宮本氏は実際の経験を振り返りながら、顧客要望を整理して課題を可視化し、プロダクトの成長につなげる方法について語った。

• keyboard_arrow_down 顧客要望に追われ、ロードマップを見失う
• keyboard_arrow_down 大量の顧客要望を整理する4つのポイント
• keyboard_arrow_down 要望を整理できたら、業務フェーズと課題をマッピングする
• keyboard_arrow_down チーム全体で取り組んだ
• keyboard_arrow_down 周囲からの声と顧客の反応
• keyboard_arrow_down まとめ

宮本氏は当時、クラウドサービス「Loglass 経営管理」における経営分析の「分析」領域を担当するチームに所属し、押し寄せる顧客要望との向き合い方に悩んでいた。

「ロードマップはビジョンからさかのぼってつくることが理想だと言われていますが、お客様の意見を取り入れることも大切です。バックキャストとマーケットインの2つが揃ってはじめて、良いロードマップが描けると思っています」（宮本氏）

理想的なロードマップ作成を目指していた宮本氏だが、期日付きでビジネスサイドから日々舞い込む顧客要望の対応に追われ、本来取り組むべきロードマップ作成にまで手が回らない状態に陥っていた。その結果、チーム内から「ロードマップがわからない」「優先度の判断ができていない」といった指摘を受けるようになった。

宮本氏は「量は質に転化する」という考えのもと、この状況を打破するために当時集まっていた4000件超の顧客要望と向き合うことにした。

中途半端に要望に目を通して課題を把握した気になるのではなく、全体像を理解したうえで着手するかどうかを判断したり、改善点を集めたりするのが重要だと考えた。ログラス社内では、Slackを通じて要望が寄せられる仕組みがあったことから、当時集まっていたすべての要望を「icebox」という手法を用いて整理し、課題を可視化した。

なお、要望確認、icebox整理にはQA、デザイナー、エンジニアと連携し、毎日コツコツ15分、チーム全体で取り組んだ。ロードマップ作成には約2～3週間を費やしたという。

icebox整理に取り組んだ際に、宮本氏のチームで大事にしているポイントは以下の4つだ。

1. 1. 全部は見ずに問題領域を絞り込む
2. 2. 一定の量を溜める
3. 3. 要望をそのまま捉えず、課題としてリネームする
4. 4. 課題を抽象化する

 

1. 全部は見ずに問題領域を絞り込む

4000件全てに対応するのは現実的ではない。そこで宮本氏は自分の担当領域や注力している課題領域に絞り込み、要望を手動でiceboxへ登録。最終的には約1000件に絞り込み、700～800件を精査することができた。

2. 一定の量を溜める

ある程度の量の要望を蓄積することで、「点」に過ぎなかった個々の要望がつながって線となり、課題の全体像を俯瞰できるようになる。

「例えば、50件程度では単なる個別の要望の集まりに過ぎないが、100件を超えると似たような要望をグルーピングできるようになり、プロダクトの改善点が明確になります。500件を超えると、全体像の把握と背景が大体つかめ、1000件を超えると要望同士の関連性や前後の業務フローにおける位置づけが少しずつ見えてくるようになるんです」（宮本氏）

3. 要望をそのまま捉えず、課題としてリネームする

顧客要望は「How(方法)」として寄せられることが多い。ただ、そのまま溜め込んでも、具体的な解決策につなげられるのか見えてこない。そこで、iceboxに入れる前に、その要望は顧客が今解決したい「課題」なのか、新しい機能をつくってほしいなどの「要求」なのか、わかりやすくリネームしてから格納している。そうすることで、エンジニア、デザイナーを含めたチームメンバー全員にとって分かりやすい情報にする。例えば、「予算の機能が欲しい」という要望は、「予算・見込の明細に記載されている付随情報を確認したい」という課題に言い換えている。

4. 課題を抽象化する

リネームした課題をさらに抽象化することで、要望同士の関連性が分かるようにする。

例えば、「複数軸で予算データを並べたい」「行・列の設定自由度を高めたい」という要望は、「そもそも作りたい帳票が作れない」というように抽象化した課題の枠組み内でグルーピングできる。そして、抽象化によって要望を俯瞰するようになると、課題の重要度を判断しやすくなる。

溜まった要望を抽象化し、宮本氏が次に取り組んだのが「業務フェーズと課題のマッピング」だった。ここでのポイントは以下の２つ。

1. 1. 業務フェーズごとに課題を並べて地図をつくる
2. 2. 今やるべきこと・そうでないことを明確化する

1. 業務フェーズごとに課題を並べて地図をつくる

1つ目のポイントは、iceboxで整理した課題をmiroで図示してマッピングすること。

横軸に大まかな業務フェーズを並べ、各課題を該当する業務フェーズに紐づけて配置していく。これにより、それぞれの課題が顧客の業務フローのどの段階で発生しているのか、また現在進行中のプロジェクトがどのフェーズに位置しているのかが一目でわかるようになる。

例えば、「（項目の）作成・編集がしにくい」という課題に、UX改善の角度から取り組んできたが、課題をマッピングしてみるとより上流のフェーズに「そもそも必要なデータが見られない・作れない」という課題が多く存在していたことが明らかになった。これにより仮説を立てながら課題に取り組むことができたのだ。

2. 今やるべきこと・そうでないことを明確化する

実際、クラウドサービスとして提供するデータ分析から結果報告までの業務プロセスのうち、「報告資料を容易に作れるようにしたい」といった後段フェーズへの顧客要望が来るケースもある。

一方、先に後段の課題から着手すると、データの依存関係が崩れるなどして、UXの悪化やデザイン時の手戻りの発生につながる可能性がある。そのため、先に前段の分析フェーズの要望から取り組むことが根本的な課題解決につながる。宮本氏によると、分析から報告までの一連の流れで各業務プロセス同士が密接に関連する経営管理領域では、この傾向が顕著に現れるという。

宮本氏はマッピングをもとにロードマップを作成。そして全体像を俯瞰できる「Big Picture」をつくり、プロダクトの現状と将来像を可視化した。Big PictureはプロダクトのOKR（Objectives and Key Results）と紐づけられており、目指すべき状態、現状とのギャップを埋めるための課題を示している。

このように視覚的に課題のつながりを把握することで、上流工程から順番に課題解決に取り組む判断が容易になる。宮本氏は、この課題マップを開発チームにも共有することで、2クオーター先までの注力ポイントを示すことができた。

「BigPctureを使うことで、開発チームにいるエンジニアを含め、社内の色々な関係者との共通言語になると思います」（宮本氏）

大量の要望に直面し、「全ての要望は見ない」「全ての要望を深掘りしない」「プロダクトマネージャー1人でやらない」ということを徹底し、チーム全体で課題に取り組んだ。
まずはSlackを通じて非同期で内容を確認し、深掘りする必要があればCS（カスタマーサクセス）、場合によっては顧客に直接聞くようにしていたという。

社内の関係者からは「担当領域の理想状態をボトムアップで考えるきっかけになった」との好意的な声が上がり、近視眼的になりがちな開発担当者の視野を広げる効果もあった。

優先的に対応した案件は顧客から高い反響を得て、「使いやすいです」「使いたいです」といった声が寄せられた。利用状況の改善を示す定量的な成果もあり、課題の可視化と優先順位の見直しによる効果が実証された。

要望収集では足りないものもある。全体見ることができても、課題の解像度という意味では、N=1を深掘りする必要はまだまだあるという。

「地道な作業をあえてコツコツやることが結果的に近道になると思っています」（宮本氏）

宮本氏は最後に、今回の取り組みで得られた最大の学びとして「遠回りこそ近道」を挙げた。地道な作業ではあるが、1つ1つ丁寧に課題と向き合うことで、結果的に最短ルートで目標達成に近づけるのだ。