4000の顧客要望からプロダクトの未来を描いた話

Transcript

1. © 2024 Loglass Inc. 1 © 2024 Loglass Inc. 4000を超える顧客要望から プロダクトの未来を描いた話 株式会社ログラス　宮本 大樹 2024.12.05
2. こんなことありませんか？ この機能があれば受注できるんです！！！ この機能の◯◯をなんとかしてほしい・・・ お客様からここを直してほしいと言われまして。。
3. • プロダクトの目標はあるが、バックログはお客様から言われた要望で溜まっていく。。 • 事業として緊急度の高い案件を優先。将来的にどう価値に繋がるのかわからない。 • そんなことをしている間にも絶え間なく来る開発要望。その結果、何から手を付けるべき かわからなくなる。 • ChatGPTを活用して要望のサマリーを作成してみるものの、要望の背景まではわからな い。 ビジョン こんなことありませんか？
4. • 日々、顧客要望が押し寄せ、何を対応するのか、何を対応しないか 判断がつかずに、迷路の中にいるような状況。 • そして、どのようにロードマップを作っていくべきなのかが見えて いなかった・・ 私も同じ悩みを抱えていました
5. 要望からどのようにロードマップを描いたのか 本日のお話 • ロードマップはビジョンからバックキャストで作成するのが理想と言われいてる。 • でも、実際には、足元のお客様の意見も大切でバックキャストで描くのと、マーケットイン的に描くことが２つが 揃って、よいロードマップが描けると思っています。 • とはいいつつも、言われた要望をそのまま作るのはプロダクトとしては望ましくない。 • 今日はそういった部分に対して、どのように要望と向き合ったのかを話していきます。
6. 株式会社ログラス プロダクトマネージャー 宮本大樹 制作会社→エン・ジャパン→LINE→現職 speaker
7. 所属チーム 経営分析の「分析」の領域を担当するチームに所属 • データを収集して、意思決定のために必要な価値を定義していく • 表示に関わる部分のため、細かい見た目の要望からパフォーマンスにかかる部分まで、多岐に 渡る部分
10. ロードマップ作成において、 こんなことに悩んでいた。
11. • ビジネスサイドからの緊急度の高い案件に対応 ◦ 期日が定められていて、急ぎやることが求められることが多い。 • 目の前のことに手一杯でちゃんとしたロードマップを作ることができていなかった ◦ 「やらねば」という気持ちはあるが、実際どう作っていくべきか迷っていた。 • 何をやって、何をやらないのかもよくわからいので迷路状態に。 ロードマップちゃんと作れていない・・ ビジョン 悩み
12. とある日・・
13. 「ロードマップ全然わからない」 「優先度の判断ができていない」 こんなことを言われてしまう
14. この状況を変えなければ・・
15. 要望と共に歩むことにした
16. 「量」は「質」に転化。ロードマップを描くためにも「量」を重視。 why 要望？ • ログラスでは、日々slackを通じて、要望が届くという文化があった。 ◦ 主にお客様からいただいた声をビジネスサイド（CS・セールス）が入れてくれる。 • 毎日要望が集まった結果、その数は4000件にも及ぶ。 ◦ 要望は規模の大小関わらず来る • 全体を理解することで、課題を整理しようと思った。 ◦ 中途半端に要望を見て「わかった気」にならないようにする。 ◦ 全部見ることでやる・やらの判断 ◦ 今後改善していくべきネタ収集
17. どうしたのさ？
18. iceboxで要望・課題を見える化 課題と業務のマッピング 要望を収集するiceboxというDBを作 り、要望の一元管理を実施。 整理をした要望・課題を実際の業務と紐 づけることで全体感を可視化。 + ロードマップを描いた
19. 1. icebox整理のポイント
20. 要望DB 社内フィードバック icebox icebox icebox爆誕！元々slack→要望DBの流れはあったが、新概念を作り要望を精査していった。 要望DB 社内フィードバック Asis Tobe 要望DBの内容はslacｋの内容そのまま入っているので活用しにくい。 要望を柔軟に整理して課題に落とし込みたかったので、iceboxという概念を誕生させた。
21. • そもそも、要望は4000件もあるので、全部は見てられない。 • 要望DBに溜まった4000件の要望から、iceboxには絞って入れた。（手動） ◦ 自分の担当領域・注力している機能領域に絞り込むことで、整理していく課題を絞り込める。 ◦ 最終的には1000件くらいまでに絞り込めていた。 ◦ 更にその中でもちゃんと見たのは700〜800件。 ポイント① 全部は見ない！削尖で問題領域を狭めていく。 要望DB icebox 4000件 1000件
22. 量は正義！溜めることで見える世界は変わっていく。 • とにかくまずは、溜めていくことからスタート。 • 溜めていくと見える世界は変わってくる。 ◦ 100件を超える世界 ▪ 似たような要望がわかるようになる • グルーピングをしておく ▪ プロダクトのイマイチなところも点で見えるようになる ◦ 500件を超える世界 ▪ ほぼ全ての要望が把握できるようになる ▪ 課題も大体は把握できるようになる ◦ 1000件を超える世界 ▪ ここまで来ると、点の課題を線にすることができる。 ▪ 1つ1つの要望の関連性・業務上でどこで必要なのかも見えてくる。 ポイント② A B C
23. 要望はそのまま捉えない！課題へのリネーム。 • 要望はHowで来ることが多いので、一手間を加えて、要望をiceboxに入れるときに、チケットの タイトルを「課題」「要求」のような形式で整理を実施。 • 誰が見てもわかる状態に修正することで、自身の思考整理にも繋がる。 ◦ 例： ▪ 要望そのまま • 予算◯◯機能が欲しい ▪ リネーム後 • 予算・見込の明細に記載をされている◯◯や◯◯などの付随情報を 確認していきたい ポイント③
24. • ポイント③でリネームした課題をさらに抽象度高くしてiceboxで振り分け • 抽象化することで、要望同士の関連性がわかるようになる。 ◦ 一見すると違う課題が抽象化すると前後関係があったり、繋がっていることがわかる。 ▪ 例1 • 予算・ 昨年実績・今年度などの複数軸を並べたい • 設定する行・列の自由度を高めていきたい ◦ →そもそも作りたい帳票が作れない ▪ 例2 • 簡単に帳票を作れるようにしたい • 帳票を壊すことなく誰でも操作できるようにしたい ◦ →作れはするけど、作成・編集がしにくい 点で捉えない！全ての課題を抽象化。 ポイント④
25. ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ① ステータス管理 in progress‧doneなど ② 名前 要望を課題に落とす ③ 顧客要望 要望DBとの紐づけ ④ プロセス 業務プロセスとの紐づけ （例：予実差異特定・概要把握） ⑤ 課題 抽象化した課題を記載 ⑥ 機能分類 どの機能に該当するか ⑦ ユーザー 誰が課題に感じているのか ⑧ 対象画面 画面分類 参考：iceboxイメージ
26. iceboxのポイントまとめ • iceboxで要望・課題を見える化 ◦ 全部は見ない！削尖で問題領域を狭めていく。 ◦ 量は正義！溜めることで見える世界は変わっていく。 ◦ 要望はそのまま捉えない！課題へのリネーム。 ◦ 点で捉えない！全ての課題を抽象化。 • 課題と業務のマッピングを実施
27. 2.課題と業務マッピング におけるポイント
28. • iceboxで整理した課題をmiroで図示してマッピング ◦ 列に業務フェーズ・行に課題をマッピング ◦ この課題は、お客様の業務でここに位置しそうだなという点を考えていった。 • 今やってる案件の立ち位置がわかるようになる。 ◦ 例 ▪ 「作成しにくい・編集しにくい」という課題を注力していたが、実は「データが見れない」「作れない」 というような課題が多く、そこが重要なのではという仮説を立てることができる。 課題の地図を作る！業務フェーズと課題のマッピング。 ポイント①
29. • 実際の要望として、業務プロセスの後段の要望はめちゃくちゃ来てる。 • ただし、UX的な観点や業務プロセス的な観点を踏まえても、先に後段のフェーズを着手してしま うと、後々開発やデザイン時の手戻りが多く発生する可能性がある。 • だからこそ、図示して整理することで、先に取り組むべき課題が明らかになる。 今やるべきこと・そうでないことを明確にする。 ポイント②
30. 3.ロードマップ作成
31. iceboxで要望・課題を見える化 課題と業務のマッピング 要望を収集するiceboxというDBを作 り、要望の一元管理を実施。 整理をした要望・課題を実際の業務と紐 づけることで全体感を可視化。 + ロードマップを描いた 再掲
32. BigPicture さらにBigPictureという大きな地図を作成し未来を描いた。誰でも見れる状態に。
33. 実施体制
34. • 体制 ◦ QA・デザイナー・エンジニア連合軍 • 実施期間 ◦ 要望確認：毎日15分×半年（今も毎日やってるよ） ◦ icebox整理：毎日15分 ◦ 課題整理・ロードマップ作成：2〜3週間くらい
35. • 全ての要望は見ない ◦ 違うサービスや、今回注力すべき領域以外は目を通さない。 • 全ての要望は深ぼらない ◦ まずは、slackを通じて非同期で内容を確認 ◦ さらに深ぼる必要があれば、CSに依頼をしてヒアリングをする。 ◦ CSも忙しいので、取捨選択や事前情報は揃えておく。 • PdM一人でやらない ◦ QA・デザイナーなど、チームで動くことを意識 ◦ ヒアリングや要望の深堀りも一人では実施しない。 ◦ 気になる部分は、それぞれの判断で動いていくことに。 やらなかったこと 要望は大量にあるので、あえてやらないことは決めた。
36. 周囲からの声
37. • 開発 ◦ 実装をしていると目の前のことで手一杯になって近視眼的になるが、同じチームで担当機能領域の全体感 を整理してくれていたので、視野が広がった • デザイナー ◦ PdMとセットで動くことが当たり前の状況からスタートできるのはありがたい ◦ VOCが課題別に分類された状態でDB化されていくので、情報が豊富であった 周囲からの声 担当機能領域の理想状態をボトムアップで考えるきっかけに
38. お客様の反応 この取り組みの結果、優先的に対応した案件が大きな反響を呼ぶことに！
39. まとめと学び
40. • iceboxで要望・課題を見える化 ◦ 全部は見ない！削尖で問題領域を狭めていく。 ◦ 量は正義！溜めることで見える世界は変わっていく。 ◦ 要望はそのまま捉えない！課題へのリネーム。 ◦ 点で捉えない！全ての課題を抽象化。 • 課題と業務のマッピング ◦ 課題の地図を作る！業務フェーズと課題のマッピング。 ◦ 今やるべきこと・そうでないことを明確にする。 改めて、大事なポイント
41. • N=1の深堀り ◦ 要望収集プロセスは全体感を把握したり、課題の解像度上げには有効。 ◦ ただし、1社をがっつり深ぼっていく取り組みではない。 ◦ 全体感を把握した上で、N＝1の深堀りをセットで実施していくことで更に有効になる。 ◦ 以下は昨年登壇した、弊社CBDO斎藤のセッションで解説 要望収集では足りなかったもの
42. 学び 要望の収集は地道で、めんどくさい。 私もそう思ってました。 でもあえて面倒なことを地道にやることで、一つの道筋を描くことができたと思っています。 昨今、AIやChatGPTなどで効率化と言われているが、自分の目で見て、聞いて、 手を動かすことが大事だと再認識をしました。 今回は要望でしたが、ここは他の業務でも必ず通じるところなので、 私の一番の学びはこの部分だと思ってます。 遠回りこそ、近道。