プロダクト価値を引き上げる、「課題の再定義」という習慣

2025/01/29 プロダクトエンジニア ~ユーザー価値を支える技術~ に登壇した際の資料です。

https://estie.connpass.com/event/340354/
X: https://twitter.com/moeka__c

Transcript

1. プロダクトエンジニア〜ユーザー価値を支える技術〜 LT プロダクト価値を引き上げる 『課題の再定義』という習慣 Jan. 29 2025 - リードプロダクトエンジニア 松本萌花
2. 2 ロジックスの紹介 2
3. 3 自己紹介 3 1995年生まれ 山口県出身 2017年4月 新卒でSIer NSSOLに入社 BEエンジニア 美容向けBtoBtoCサービス 2022年5月~ アセンド株式会社 プロダクトエンジニア 物流向け運送管理SaaSを開発 松本 萌花 Matsumoto Moeka リードプロダクトエンジニア 感想ポスト してくれると嬉しいです！
6. 6 アセンドのプロダクトエンジニア組織 6 プロダクトエンジニアの役割は、Howのプロフェッショナルであること PdMとPdEの役割分担 プロダクトマネージャー 「誰の、どの課題を、 　どの順番で解決するか」を設計 （することで価値を最大化する） プロダクトエンジニア 「どうやって課題を解決する 　プロダクトにするか」を設計 （することで価値を最大化する）
7. 7 7 私達は、顧客の声やニーズを元に、 周りが驚くような新しい価値を提供するプロダクトを 市場に送り出す存在。 ここが、私達
8. 8 8 私(プロダクトエンジニア )がいるからこそ価値が上がった！ と思えた瞬間、どれくらいありますか？ 顧客の課題は解決しているはずだけど、 ちゃんとプロダクトの価値になっているんだろうか？
9. 9 9 機能を開発する前に課題を再定義 すれば、 プロダクト価値を上げられる。 今日、お伝えしたいこと
10. 10 10 それはそう Solution とは、 みんながなんとなく思いつく暗黙的な想像仕様 のこと。 『それはそう Solution』とは、なにか 問題点 • 70点くらい。Wowではない。 • それはそう Solution をイテレーティブに改善しても、 80点にはなるが Wow にはならない。
11. 11 11 それはそうSolutionの厄介な点は、 みんなの固定観念から生まれたも のであること。 『それはそうSolution』 認知の問題を乗り越えて120点の機能にするには、 課題の再定義 が必要！ 固定観念を振り払い、よりプリミティブな課題に定義し直すことで 本質的かつエレガントな課題解決＝ Wowソリューションへと繋げること
12. 12 12 課題の再定義から Wow への流れを、 我々は「屈伸」と呼び、大切にしている。 『屈伸』とは プロダクトエンジニアの介在価値 • 技術の専門職として、小さくまと まってしまったソリューションに対 して技術の天井をアンロックしたソ リューションを見出す。 • PdEが課題を正しく定義することに よって、技術を最大限活かしたソ リューションを見いだせる。 再定義
13. 13 13 でも、やってみると屈伸って、結構難しい。 私がどうやってるか、紹介します。
14. 14 14 まず、『屈伸』の心理的ハードルを超える。 屈伸を妨げるものたち 過去仕様へのリスペクト という名の遠慮。 自分が昔作ったものの場合は、 今まで積み上げてきたものを否定する辛さもある。 エンジニアの性 課題を聞くと、 すぐに解決策やどう実現するかを 考え出しちゃう 納期意識 困り事があるなら、なるべく早く解決したい… これならすぐできそうだし… 受託意識 既に言語化された課題があるなら、 それを解いておけばとりあえず間違いなくない？ そんなそもそも論から考える必要ある？ （という周りや自分自身からの圧）
15. 15 15 まず、『屈伸』の心理的ハードルを超える。 屈伸を妨げるものに抗うには 周りを巻き込んで 「想い」を出し切る。 ほんとは、もっとこうしたいとか 後悔してることとかみんなにもあるかもしれない。 話していると、やるか！！という気持ちになる。 PRDに再定義を組み込む テンプレに 「これはWowか！？！」と書いて そこで絶対考えるようにする。 「創造的衝動」が 掻き立てられる課題にする 納期とか一旦置いといて、 「これは確かにちゃんと解きたい！！」 と心から思える課題にする 第三者に意見をもらう 最近入ってきて機能をあんまり知らない社員さん、 思い切って社長とか。
16. 課題再定義のプロセス 課題 探索 課題 認識 課題 再定義 仕様 決定 時間の経過 選 択 肢 発 散 収 束 発 散 収 束 課題を見つける 解決策を見つける ソリューションを考える中での、屈伸ポイントとアイデア 屈伸！ 屈伸！
17. 課題再定義のプロセス 屈伸① 馳せる思い一覧 • 何かしら思っていることがありそうな人 たちに、最初にとりあえず全部吐き出し てもらう。とにかく、まだ言語化されて いない想いを言語化する。 • 構造化されてなくてもOK。 これ関係ないかな？ってことでもOK。 • 一度、全員分の思いや視点を自分の中に インストールすることで、アンラーンし 直せる。 なにする？ 何ができる？
18. 課題再定義のプロセス 屈伸② ざっくり概念図をひたすら書く • 世界観やコンセプトを図にして書く。 • 課題に限らず、会社のミッションや、 「顧客」「事業」「業界・社会」の観点 などなど、形を変えてひたすら書く。 • 手書きでも、Figmaでも、Notionで も、なんでもいい。 • 「課題を解決すること」を超えて、「課 題を解決する仕組みを作ること」という 視点で大きく描けるようになってくる。 なにする？ 何ができる？
19. アセンドで実際に屈伸した話 再定義 請求書の一括作成 請求書の自動作成 大量の請求書を１件ずつ整理して 作成するのが手間 コンパウンド故に 請求案件のコンテキスト があるから 自動で案件を整理して 請求書作成できるのでは 案件情報から 請求をシームレスに繋ぐ
20. • どんなに小さなことでも、あなたが「外から与えられた課題」を解いて いる限り、そこには必ず再定義の余地がある。 • 課題の再定義には、「屈伸して取りに行く」所作が必要。 ◦ 課題の再定義は、自己否定にも近くて辛いけど、がんばろう。 • Howのプロフェッショナルとして、プロダクトの価値を引き上げられる エンジニアになろう！！ 20 まとめ 20
21. We are hiring !!! 21 プロダクトエンジニアを切実に求めています。 生産性高く Full Stack TypeScript で開発したい プロダクトエンジニア募集！ 松本 萌花の 𝕏 (@moeka__c) お気軽にフォローください。