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
4
2k
リアルで価値を発揮するデジタルプロダクトを開発する
東京都のデジタル社会人材育成プログラムDay 3の講演資料です。
Aki / @LoveIdahoBurger
November 20, 2023
Tweet
Share
More Decks by Aki / @LoveIdahoBurger
See All by Aki / @LoveIdahoBurger
その失敗から何を学ぶ?不確実性をマネジメントして目標達成するための心得 #webtan
aki_iinuma
26
6.5k
プロダクトマネジメント組織立ち上げの課題と落とし穴と楽しみ #pmconf2022
aki_iinuma
24
16k
決済に関する地味な話 #地味PMmeetup
aki_iinuma
6
2.6k
Noを伝える技術 #pmconf2021
aki_iinuma
226
190k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
106
49k
Other Decks in Technology
See All in Technology
What's in a Postgres major release? An analysis of contributions in the v17 timeframe | Claire Giordano | PGConf EU 2024
clairegiordano
1
660
Measuring the Success of Developer Experience
nikokivela
1
130
AIを使って小説を書こう!【2024/10/25講演資料】
kamomeashizawa
0
160
CAMERA-Suite: 広告文生成のための評価スイート / ai-camera-suite
cyberagentdevelopers
PRO
1
130
現実のRuby/Railsアップグレード
takeyuweb
3
2.8k
失敗しないOpenJDKの非互換調査
tabatad
0
200
CI/CDやテスト自動化の開発プロジェクトへの適用
megascus
2
300
APIテスト自動化の勘所
yokawasa
2
150
30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法
ryosk7
2
230
Tokyo dbt Meetup #10 dbt Cloudユーザー会 & パネルディスカッション
dbttokyo
1
160
インシデント対応の 実践と品質文化の醸成
____rina____
2
1.4k
Apple/Google/Amazonの決済システムの違いを踏まえた定期購読課金システムの構築 / abema-billing-system
cyberagentdevelopers
PRO
1
140
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
131
8.9k
Being A Developer After 40
akosma
86
590k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Building Adaptive Systems
keathley
38
2.2k
The Invisible Side of Design
smashingmag
297
50k
Code Review Best Practice
trishagee
64
17k
Building Your Own Lightsaber
phodgson
102
6k
A Tale of Four Properties
chriscoyier
156
23k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
59k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Docker and Python
trallard
40
3k
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!