Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
リアルで価値を発揮するデジタルプロダクトを開発する
Search
Aki / @LoveIdahoBurger
November 20, 2023
Technology
5
2.5k
リアルで価値を発揮するデジタルプロダクトを開発する
東京都のデジタル社会人材育成プログラムDay 3の講演資料です。
Aki / @LoveIdahoBurger
November 20, 2023
Tweet
Share
More Decks by Aki / @LoveIdahoBurger
See All by Aki / @LoveIdahoBurger
プロダクトマネージャーのキャリアQUEST - pmconf2024 落選セッションお披露目会 #落選お披露目
aki_iinuma
4
5.3k
その機能、今作る必要ある?
aki_iinuma
8
2.8k
その失敗から何を学ぶ?不確実性をマネジメントして目標達成するための心得 #webtan
aki_iinuma
29
7.3k
プロダクトマネジメント組織立ち上げの課題と落とし穴と楽しみ #pmconf2022
aki_iinuma
25
17k
決済に関する地味な話 #地味PMmeetup
aki_iinuma
7
2.7k
Noを伝える技術 #pmconf2021
aki_iinuma
235
210k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Other Decks in Technology
See All in Technology
製造業の課題解決に向けた機械学習の活用と、製造業特化LLM開発への挑戦
knt44kw
0
160
金融サービスにおける高速な価値提供とAIの役割 #BetAIDay
layerx
PRO
1
760
Claude Codeが働くAI中心の業務システム構築の挑戦―AIエージェント中心の働き方を目指して
os1ma
9
1.6k
Oracle Cloud Infrastructure:2025年7月度サービス・アップデート
oracle4engineer
PRO
1
120
Amazon Q Developerを活用したアーキテクチャのリファクタリング
k1nakayama
2
200
KubeCon + CloudNativeCon Japan 2025 Recap
donkomura
0
190
마라톤 끝의 단거리 스퍼트: 2025년의 AI
inureyes
PRO
1
700
Google Agentspaceを実際に導入した効果と今後の展望
mixi_engineers
PRO
3
350
Kiroでインフラ要件定義~テスト を実施してみた
nagisa53
3
310
マルチプロダクト×マルチテナントを支えるモジュラモノリスを中心としたアソビューのアーキテクチャ
disc99
1
350
風が吹けばWHOISが使えなくなる~なぜWHOIS・RDAPはサーバー証明書のメール認証に使えなくなったのか~
orangemorishita
15
5.6k
Jamf Connect ZTNAとMDMで実現! 金融ベンチャーにおける「デバイストラスト」実例と軌跡 / Kyash Device Trust
rela1470
0
170
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
Visualization
eitanlees
146
16k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Writing Fast Ruby
sferik
628
62k
The Cost Of JavaScript in 2023
addyosmani
51
8.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Side Projects
sachag
455
43k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
790
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.5k
Gamification - CAS2011
davidbonilla
81
5.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Transcript
リアルで価値を発揮する デジタルプロダクトを 開発する Day 3 デジタル時代のアイディア具体化 飯沼亜紀
Aki Iinuma 飯沼亜紀 Product Manager, CADDi Inc. 𝕏: @LoveIdahoBurger 経歴
慶應義塾大学 環境情報学部卒業(専攻:人間工学) ソフトウェア開発企業 経営企画→新規事業のプロダクトマネージャー アパレル企業 プロダクトマネージャー、プロジェクトマネージャー、新規事業 飲食企業 プロダクトマネージャー 2022年9月より現職 やっていること オペレーションとテクノロジーの両方を使って世の中を良い方向に 変えていこうとしている
Agenda 01 02 03 04 リアルな世界を含めたプロダクト設計をする プロトタイプをつくってみる 仮説検証結果を反映する まとめ
01 リアルな世界を含めたプロダクト設計をする
プロダクトマネジメントとは • プロダクトを育てること全般 ◦ ときに「撤退」の意思決定をすることもある ビジョンの実現 ユーザー価値の実現 ビジネス価値の実現
デジタルとリアルにまたがるプロダクト設計 デジタルプロダクト リアルな世界での オペレーション プロダクトによる体験 プロダクトの外にも体験を左右する要素が存在するため、プロダクトそのものだけではなくオペレーションなどの リアル世界での体験を含めた全体的な体験設計が重要 +
リアル体験がガッカリだと全てガッカリ(なことが多い) 例えばどんなに使い勝手のよいフードデリバリーアプリも、モノが届かなければ素晴らしい体験にはなり得 ない
リアル体験をリッチにすることで軽めのプロトタイピングができ る リアル側でリッチな体験を用意することはユーザー観点だけでなく開発観点でもメリットが ある • 例えばオンライン決済の構築には時間がかかるが、対面で現金の受け渡しをするな ら今すぐできる • 重要なのは「対面ならではの体験」をいかに演出して「オンライン非対応」のネガティ ブ要素を払拭するか
◦ 「おもてなし」を感じてもらう? ◦ 細やかなカスタマイズに応える? ◦ そこでしか手に入らない何かを用意する?
02 プロトタイプをつくってみる
プロダクトを設計する ゴールを設定する 必要なことを整理する プロダクトや オペレーションの設計を する WHY WHO, WHAT HOW
検証する
ゴールを設定する プロダクトマネジメントの最重要事項 = Why の特定 なぜそのプロダクトを つくるのか ・誰の何の課題を解決するのか ・誰にどういう状態になって ほしいのか
これを考えないまま機能について考え始めると結果として誰の課題も解 決できないことになりがち
ゴールに至るために何が必要かを洗い出す • この段階ではWhatを考え、Howは考えない ◦ 例:「支払う」「受け取る」は OK、「オンラインでカード決済」「商品が自宅に届く」は NG 予約する 施術を受ける 口コミを
共有する ポイントを 受け取る 商品を選ぶ 支払う 受け取る 食べる 美容関連のレビューサービスの場合 飲食店の場合 ここをなくしてレビューに振り切るという可能性もある
一旦全部人力で頑張る方向に寄せて考えてみる 大体のことは(デジタルのほうが優位性があったとしても)オフラインで実現可能 写真出典:まいどなニュース( https://maidonanews.jp/article/12222821)
なぜリアルに寄せるのか • プロトタイピングの基本は仮説検証と検証結果反映の高速サイクル ◦ 一般的にオフラインのオペレーションのほうが柔軟に変更ができるので仮説検証に向いている • プロトタイプをなるべく小さく始めることが成功確度と成功へのスピードを上げてくれ る プロトタイプ 1
プロトタイプ 2 プロトタイプ 3 プロトタイプ 1 プロトタイプ 2 vs 小さく始めて早く検証することを繰り返すことでより良いプロダクトを目指す
デジタルの力が必要な場合も作るものは最小化できる どうしてもデジタルの力が必要な場合でも、ゼロから作ることが唯一のオプションではなく 既存のデジタルプロダクトを活用するという方法がとれる場合が多い 例: • LINEやメールで通知を送る • Notionで情報を公開する • PayPayで支払いを受ける
• Trelloでタスク管理をする • Google Spreadsheetで簡易ダッシュボードをつくる
テストして結果を振り返ってみる テストでは仮説を検証していくが、検証するべき項目のひとつがデジタルとリアルの配分 これを何度か繰り返すとデジタルとリアルの配分がいいバランスになっていく リアルで成立しないことが ないかの検証 ジャーニーやゴールの 妥当性検証 リアルで成立しないことがあれば デジタルに寄せてみる 成立はするが体験が十分に良くない場合な
どは必要に応じて見直しを実施
03 仮説検証結果を反映する
仮説検証からの学びを反映する 事実の収集・整理 深掘りと分析 うまくいったことは何か うまくいかなかったことは何か 何が要因と考えられるか どうすればより良い結果が 得られそうか 検証結果から新たに 導き出される仮説は何か
• 次はどんな仮説をどのように検 証するのか決める • 仮説検証を経て不確実性が十 分に排除されたものはプロダク トに反映する 次の方針の決定
どちらを選ぶか デジタル リアル モノを動かす オンラインで完結はできない 適切な教育と業務プロセスがあれ ば対応可能 定型業務をする 素早く正確に行うことができるが、 始めるまでの準備に時間がかかる
ことが多い 学習に多少の時間を要する スピードや正確性は人に依存する 判断をする ロジックに基づく判断は得意だが イレギュラーケースのハンドリング は苦手 顧客や状況など様々な変数をもと に判断することができるが、人や役 割に依存する 単純な◯✕での判断ではなく、同じ業務の中でも得意不得意があるため「今このシチュエーションで何が求めら れているのか」を考慮した上で判断する
04 まとめ
まとめ • デジタルとリアルに跨るプロダクト開発をする場合、デジタルプロダクトだけではなくリ アル世界も含めた体験設計が重要 • リアル側になるべく寄せることで最小規模のプロトタイプで仮説検証ができるようにな る ◦ 高速な仮説検証によってよいプロダクトに近づけることができる •
デジタルとリアルそれぞれの特性や各ユースケースの前提を理解した上で、どのタス クをどちらが担うかを決定する
Thank You!