プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術

プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術
pmconf2024登壇資料です。
https://2024.pmconf.jp/sessions/Ej1Am2MJ
---------------------------------
「プロダクト開発では、やらないことを決めるのが重要」 みたいな話は、プロダクトマネージャーの皆さんは耳にタコが出来るほど聞いていると思います。

ただ、頭では理解していても、「それって結局いつ何をすれば…？」という具体の方法については情報が少なく、実践が難しい感覚はないでしょうか。

本セッションでは、ビッグプレイヤーがひしめくバックオフィスSaaS領域の後発サービスながら、「作らない・削る・尖らせる」工夫により「使われないものを作らない爆速開発」を実現しているLayerX バクラクシリーズの機能企画例を通して、PMが実践できる具体的な取り組みをご紹介します。

Transcript

1. プロダクトの爆速開発を⽀える、 「作らない‧削る‧尖らせる」技術 2024/12/05 株式会社LayerX 加藤みちる
2. © LayerX Inc.　 2 ⾃⼰紹介 加藤みちる michiru_da 株式会社LayerX バクラク事業部 プロダクトマネージャー 略歴 • エンタープライズ 営業 • プロジェクトマネージャー • 新規事業企画‧⽴ち上げ • ⾃分が関わった⼈の⾏動を変え続けたいです • ⼤事にしていること: 「とにかくやる」 @applism118 • バクラク事業部 カスタマーサクセス • バクラク事業部 プロダクトマネージャー プロジェクト マネージャー エンプラ営業 カスタマー サクセス バックグラウンド #ラジオ #podcast #マヂカル.fm #バンドやってる #お笑い
3. © LayerX Inc.　 3 LayerX 事業紹介 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法⼈⽀出管理サービス「バクラク」や企業内業務のデジタル化を⽀援するサービスを提供 バクラク事業 企業活動のインフラとなる法⼈⽀ 出管理（BSM）SaaSを開発‧提供 Fintech事業 ソフトウェアを駆使したアセットマネジ メント‧証券事業を合弁会社にて展開 AI‧LLM事業 ⽂書処理を中⼼とした、LLMの活⽤によ るプロセスのリデザイン
4. © LayerX Inc.　 4 バクラクのビジョン AIの⼒で⼊⼒‧承認を簡単に⾃動化。 今までの「仕⽅ない業務」を撲滅
5. © LayerX Inc.　 5 「バクラク」シリーズラインナップ ‧年会費無料で何枚でも発⾏可 ‧カード利⽤制限で統制を実現 ‧すべての決済で1%以上の還元 法⼈カードの発⾏‧管理 ‧帳票の⼀括作成も個別作成も⾃由⾃在 ‧帳票の作成‧稟議‧送付‧保存を⼀本化 ‧レイアウトや項⽬のカスタマイズも可能 請求書発⾏ ‧スキャナ保存データも直接取込  ‧AI-OCRが⾃動読取＆データ化 ‧[取引先][取引⽇][取引⾦額]での検索 帳票保存‧ストレージ ‧直感的UIで従業員の負担を軽減 ‧Slack連携で打刻や⾃動リマインド可能 ‧わかりやすい残業 / 休暇管理レポート 勤怠管理 ‧AIが⾒積書‧請求書を５秒でデータ化 ‧スマホからも申請‧承認OK ‧柔軟な通知設定‧承認の催促機能 事前申請‧⽀払申請 ‧AIが領収書を5秒でデータ化 ‧スマホアプリとSlack連携あり ‧領収書の重複申請などミス防⽌機能 経費精算 ‧AIが請求書を５秒でデータ化 ‧仕訳 / 振込データを⾃動作成 ‧電帳法‧インボイス制度にも対応 仕訳‧⽀払処理効率化
6. © LayerX Inc.　 6 実業務に寄り添い、テクノロジーで圧倒的な使いやすさを実現 ⼀括アップロードでAI-OCR 横並びの画⾯で参照できる 読み取り箇所の⾊分け 複数のレシートを100枚まで同時にアップロー ド可能。AI-OCRが読み取りと同時進⾏で画像 処理を実施します。 対象の書類データの読み取り箇所と⼊⼒項⽬ を参照できる横並びの画⾯を採⽤。画⾯遷移 の⼿間がありません。 読み取り箇所が⾊分けされ、⼊⼒箇所も⾊が 紐づいているため、書類と読み取られた箇所 の確認が簡単です。
7. プロダクトの爆速開発を⽀える、 「作らない‧削る‧尖らせる」技術
8. 8 バクラクシリーズへのご評価 「使いやすい」「開発が速い」 出典:ITreview
9. © LayerX Inc.　 9 なぜ爆速で作れるのか 作らない、を諦めない
10. 10 やらないことを決めるのが⼤事 出典: パレートの法則を理解する なぜ爆速で作れるのか
11. © LayerX Inc.　 11 プロダクト開発でも、やらないことを決めるのが⼤事 ⼩さいサイズなら、 すぐにリリース‧改善できる • シンプルで⼩さい機能な ら、開発‧テスト⼯数も 最⼩限にリリースできる 作らなければ、 負債は増えない • 作った瞬間から機能は 負債になる • 作るほど、将来の開発速 度が落ちやすくなる • 10年後も使われると確信 が持てるものだけを作る フォーカスするほど、 インパクトを出せる • インパクトのある課題解 決だけに集中する • 全員に役に⽴つ機能は誰 にも刺さらない
12. © LayerX Inc.　 12 やらないことを決めよう！
13. © LayerX Inc.　 13 …頭ではわかってる！でも出来ない！！ 最初からやれたら困ってない！！！エーン🥺 そうはいうものの
14. © LayerX Inc.　 14 頭ではわかっているのに…失敗🥺🥺🥺 失敗 課題感はあったが、要望がすごく多い機能という 理由で過⼩評価し、⽴ち⽌まれなかった ユースケースを洗い出し、 それぞれに属するユーザのヒアリングを⾏い 意思決定すべきだった 複数案を作りpros/consを洗い出したうえで 最善のソリューションを決めるべきだった 課題の発⽣頻度が⾼いユーザーだけにヒアリング ⼤多数の「ぼちぼち困ってるユーザー」が 抜けていた 認知負荷が⾼い仕様があり 相当困っているユーザーでないと コスト < 価値にならなかった 前任担当者から引き継いだ1案だけをベースに ソリューションを検討してしまった あるべき 頭ではわかっている！仮説も⽴ててる！ヒアリングもしてる！なのに、やらないことを間違える 危うく⼤多数のユーザーに使われない機能が爆誕しかけた例
15. © LayerX Inc.　 15 作らない、を諦めないために • ユースケースの解像度を上げてセグメンテーションする • 機能であってもMinimum Valiableでありつづける • とにかく松⽵梅で選択肢を出す • 浅い‧深いヒアリングを使い分ける • 頻繁なデモと仕様バトルで、フィードバックサイクルを回 す 1. 作らないものを決める 2. 作るものを削る 3. 作るものを尖らせる
16. 1. 作らないものを決める 2. 作るものを削る 3. 作るものを尖らせる
17. © LayerX Inc.　 17 ⾏動からユーザーをセグメンテーションし、 救わないユースケースを決める 作らないユースケースを決める ユーザーの分類 • 実⾏動からセグメンテー ションすることで、 汎⽤的な機能にしやすい （結果、属性的なセグメントと⼀致 する場合もある） セグメントを評価 • ユーザー‧⾏動の 発⽣量からインパクトを 評価する • クエリを書き、 事象の発⽣頻度や量を可 視化する • ヒアリング‧お客様の実 データの共有で、ユース ケースを具体化する ⾏動の深堀り
18. 18 会社ごとでセグメンテーション 作らないユースケースを決める 1.会社ではなくユーザー単位で解像度を上げる 特定の業界の会社だから必ず同じ課題？ エンタープライズ vs SMB で要件が違う？ 特定の要望が多い会社？ 業界ごとにユースケースの特性はあるので、 逆に違いが⽣まれている‧例外ケースに着⽬ エンプラ独⾃の要件ももちろんあるが、 SMBのユースケースの集合体である傾向も強い 同じ会社の同じユースケースの中にも、 ユーザーから話を聞いているバイヤー、 課題⼤〜⼩のユーザーが存在 ユーザーごとのセグメンテーション 会社は複数ユーザーの集合体。 どのくらいのユーザーがこのユースケースにあてはまるか？で考えると、正しくインパクトの仮説がたてやすい。
19. 19 2.同じユーザーが同じ機能を別ユースケースで要望する場合がある 作らないユースケースを決める 利⽤⽤途に応じて 5個くらいのフォームを 作った きれいに並び替えたいが、 今の機能でもお困りなし 時々メンテナンスをしている 新しいフォームが増えると1 番上に作成されるので、 1番⽬にあるフォームの 順番を下げたい 時間軸、タイミングによっては同じユーザーでも違うユースケースで機能を要望する可能性がある。必要に応じてセグメンテーションに時間軸もいれる。 すべての稟議を寄せるため、追 加の申請サービスも契約、 ⾊んなフォームを作成 全部で30個になった、改めて 全体をきれいに並び替えたい 例：作成した稟議申請フォームの並び順を変更したい 1年⽬ 2年⽬ 3年⽬
20. 20 3.忙しくても⾯倒でも、パターンを⾔語化し⽐較できるようにする 作らないユースケースを決める 表で⼀覧にしておくと、新しく⾒つかった例外の考慮や、論点の評価がしやすい。 やらないことを決める=複数のユースケース優先度をつけることなので、とにかく⽐較すべきユースケースを書き出す。 書き出すと間違いにも気付ける。 業界 取引 ⼿作業 解決策1 企業例 IT hoge fuga 作業 poyo 機能 ◯◯ ⼩売 hoge2 fuyo 作業 puyo 機能 ◯◯ 流通 hoge3 funya 作業 piyo 機能 ◯◯ … なし‧ やらな い 仮説的に必要 意味合い ほげエラー 解消しないと先に進めないエ ラー ふがアラート 申請者が明⽰的にアクションす れば、解消しなくても申請でき るアラート ぽよアラート 申請者が何もしなくても申請で きるアラート パターンを洗い出し わかる範囲を定義 深堀り
21. 1. 作らないものを決める 2. 作るものを削る 3. 作るものを尖らせる
22. © LayerX Inc.　 22 • ⼩さいほうが早くリリースし価値を届 けやすい • ⼀度作った機能を消すのは難しく、あ とから作るほうがカンタン • 実データをみてアップデートする 迷ったら作らない Minimum Viable Productであり続けるマインドセットを持つ プロダクトはPMFを繰り返す。新しいユースケースに対応するときも、とにかく⼩さく速く出し続けるほうが、ユーザーの求めるものを当てやすい。 迷ったら作らない 本当にViableにできているか？ • ユーザーが⾃⼰解決できるかを基準に する • サポートへお問い合わせしないと解決 できない、課題が残ってしまうものは 対応する • 運⽤回避が可能であれば機能は削る
23. © LayerX Inc.　 23 機能の⼤⼩にかかわらず、仕様は複数案作り、pros/consを明記する 作るものを削る SmartHR社 たけまささんnote PMと開発チームで解決策の⼿戻りを防ぐ、松⽵梅フレームのススメ • 複数案を⽐較すると削る要素を ⾒つけやすい • 複数案のpros/consを並べると、 丁度よい解決策が⾒つかりやすい • PMが実現したいラインが 開発チームに伝わり、コスパがいい 代替案のアイディアも出やすい 松⽵梅を ⽐較 pros/consを ⽐較 理想と 最低ラインを 伝える
24. 1. 作らないものを決める 2. 作るものを削る 3. 作るものを尖らせる
25. 25 「御社はユーザーの気持ち、わかってますね」と⾔ってもらうために とにかくフィードバックループをまわす フィードバックの質をあげる • いわゆる60分のユーザーヒアリングの ような、深いリサーチ • そもそもユーザー理解のために必須 • 解決策じゃなくて発⽣している事実を 聞くなど、コツがたくさん。本や記事 を読んで実践しよう！ フィードバックの量を増やす • 課題そのものや、作る前の解決策の探 索ヒアリングが終わったあとも、不確 実性は出てくる • 実際のモノをベースに、短時間でもた くさんの⼈からフィードバックをもら い汎⽤的な使いやすさを実現する
26. © LayerX Inc.　 26 作るものを尖らせる • ユースケースの解像度を上げたいとき、電話で15分会話する • メールに、ご回答がお⼿数であればお電話くださいと追記しておく • 細かいUIで迷ったとき、要望いただいたお客様にメールでアンケートを送付 • 複数案UIを載せる＆サンプル回答例を載せておくと、 期待する粒度や観点の回答が得られやすい • ポイントをまとめた資料をセールス/CSに配布、商談時にご案内 • 不確実性を減らせるほか、商談の温度感も上げることができる ※お客様の期待値コントロールには注意 1.メールでの 簡易アンケート 2. 15分電話 ヒアリング 3. bizから 簡易ヒアリング 1.深いヒアリング以外に、浅いヒアリングで機会を増やす 弊社VPoP「専任プロダクトを持ってない僕でも⽉10社はヒアリングしている、それ以下だと少なすぎます（きっぱり）」
27. © LayerX Inc.　 27 作るものを尖らせる 2.開発チーム内で、モノが動いてからもフィードバックして仕様を変える localで動いた機能の動画をPM‧エンジニア‧ デザイナーで⾒た結果、翌朝の9時から議論し仕様 の変更を決定したときのSlack • 開発チームでの毎⽇の⼣会で、 部分的でも機能が動くようになったらデモ • 早いタイミングから素朴な質問や フィードバックを投げかけて修正 • 役割関係なく、少しでも違和感や迷いが あったらすぐにコミュニケーションを取る • ⾮同期のチャットだけではなく、実データ で動くものを⾒て同期で仕様を詰める 1. 完成前から ⾼頻度でデモ 2. 動いたあと も 仕様バトル
28. 最後に
29. © LayerX Inc.　 29 作らない、を諦めない
30. © LayerX Inc.　 30 作らない、を諦めない 作らないを決める Discovery （課題の発⾒） Decision （課題の定義） Develop （解決策の検討） Delivery （解決策の検証） プロダクト開発におけるダブルダイヤモンドフレームワーク: A guide to using the “Double Diamond” framework to score product home runs 作るものを削る 作るものを尖らせる
31. © LayerX Inc.　 31 作らない、を諦めない 作らないを決める Discovery （課題の発⾒） Decision （課題の定義） Develop （解決策の検討） Delivery （解決策の検証） プロダクト開発におけるダブルダイヤモンドフレームワーク: A guide to using the “Double Diamond” framework to score product home runs 作るものを削る 作るものを尖らせる ?
32. © LayerX Inc.　 32 作らない、を諦めない 実際の検証がきれいなサイクルになることはない（ぐちゃぐちゃ） • 作らない‧削る意思決定のタイミングはいつ来るかわからない • 序盤のほうがいいけど、中盤になってわかることもあるかもしれない • どんな規模の意思決定になるかもわからない 作らないを決める 作るものを削る 作るものを尖らせる 作らないを決める 作るものを尖らせる 作るものを削る 作るものを尖らせる 作らないを決める あるユースケースの課題を解決する
33. © LayerX Inc.　 33 • 新機能作るぞ！というチームのモメンタムが切れるかもしれない • エンジニアの技術検証が、サンクコストになるかもしれない • ⾃分への信頼が損なわれるかもしれない 作らないことで⽣まれる軋轢
34. 34 それでも、作らないを諦めない
35. © LayerX Inc.　 35 作らないことで、尖った価値がより速くユーザーに届く ⼩さいサイズなら、 すぐにリリース‧改善できる • シンプルで⼩さい機能な ら、開発‧テスト⼯数も 最⼩限にリリースできる 作らなければ、 負債を増やさない • 作った瞬間から機能は 負債になる • 作るほど、将来の開発速 度が落ちやすくなる • 10年後も使われると確信 が持てるものだけを作る フォーカスするほど、 インパクトを出せる • インパクトのある課題解 決だけに集中する • 全員に役に⽴つ機能は誰 にも刺さらない
36. 36 • 迷ったら、作らない意思決定をしよう • 作ると決めたら、すばやく⼩さく届けよう • ユーザーに、圧倒的に尖った価値で届けよう 作らない、を諦めない
37. 37 最後に「やらない」を決められるのはPMの勇気 作らない、を諦めない
38. © LayerX Inc.　 38 勇気を持って、世界を最速でよくしていきましょう