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