pmconf 2022での登壇資料です。
--- セッション内容 ---
難解な業界・顧客課題の解決には、ソフトウェアと人力オペレーション、それぞれの利点を活かし顧客課題を柔軟に解決する「広義のプロダクト」が有効です。しかしまだ見ぬ「あるべき姿」を目指してソフトウェア・オペレーションを同時にアジャイルに進化させるのは、ソフトウェア単体による進化とはまた違った独自の難しさが存在します。
「広義のプロダクトマネージメント」の勘所と落とし穴、Shippioの実例を交えながらご紹介します。
https://2022.pmconf.jp/session/0PpXLgfH
デジタル × オペレーション「広義のプロダクトマネージメント」の勘所Yasuhiko Mori
View Slide
「広義のプロダクト」とは？デジタルプロダクト だけではなく リアルオペレーション も持って、両面の力で業界・顧客の課題を解決する「プロダクト」例：• Amazon – 小売業というリアルオペレーションをデジタルの力で再定義。在庫持つ、倉庫持つ、物流もつ。• Shippio – フォワーダー（国際物流代行）のリアルオペレーションをデジタルの力で再定義。
森 泰彦CPOyasumoriShippioフリーランスラクスルMicrosoftProduct Management
(広義のプロダクトマネージメントの話の前に)Shippioが考えるプロダクトマネージメントとは？
unhappy todayhappy tomorrow1st step逆算で導き出す①高い解像度で解決すべき本当の課題を特定②課題を大きく解決する「あるべき姿」を描く③
unhappy todayhappy tomorrow逆算で導き出す3rd stepそして何が何でも前進する
unhappy todayhappy tomorrowで、結局寄り道することにはなる
「広義のプロダクトマネージメント」の場合…
unhappy todayhappy tomorrow1st step(digital)1st step(operation)逆算で導き出す
unhappy todayhappy tomorrow足並みを揃えて「あるべき姿」を目指す！1st step(digital)1st step(operation)
unhappy todayhappy tomorrow1st step(digital)1st step(operation)
落とし穴無駄なプロダクト開発が多発する。進化が遅くなる。
Who’s Shippio ??
フォワーダーとは??納品先（倉庫）配送通関海上輸送（航空輸送）荷主 (例：輸入者)見積 ブッキング 貿易書類スケジュール共有納期調整 請求フォワーダー
納品先（倉庫）配送通関海上輸送（航空輸送）荷主 (例：輸入者)見積 ブッキング 貿易書類スケジュール共有納期調整 請求フォワーダーデジタルフォワーダーとは??デジタルプロダクトデジタルプロダクト
納品先（倉庫）配送通関海上輸送（航空輸送）荷主 (例：輸入者)見積 ブッキング 貿易書類スケジュール共有納期調整 請求フォワーダーデジタルフォワーダーとは??デジタルプロダクトデジタルプロダクトオペレーションプロダクト（自動化 / オペレーション効率化）
無駄なプロダクト開発が多発する。1. オペレーションの進化で無駄になる2. 事業成長で無駄になる落とし穴 (再掲)進化が遅くなる。• デジタルとオペレーションはPDCAのスピード・リズムが違う。基本的にオペレーションが速い。• 中途半端なデジタルプロダクト化はオペレーションの進化の足枷になる。
無駄なプロダクト開発(オペレーションの進化起因)落とし穴
確かに深刻度高いですね。開発しますね！ありがとうございます！今は{xx} がオペレーションのボトルネックです。リリースしました！(仕様作成→開発）あ、オペレーションの仕方変えたので、もうあの機能使ってないです…(数か月後)Operation Product Manager (& Engineer)
Operation Product Manager (& Engineer)管理ツールでどの案件が遅延しているか一目で確認したいです。あ、自前でSQLで遅延案件をスプシに落とせるようになったのでもう使ってないです。(3か月後)ShippioのNG例：管理ツールの一覧で遅延のUI通知出るようにしました。
発展途上なオペレーションに対する早期のプロダクト実装は、実装が無駄になるリスクが高い
無駄なプロダクト開発(事業の進化起因)落とし穴
T2D3で伸びるとすると、2年後に顧客・案件数は 9倍。オペレーションのボトルネックの位置が変わる（課題、及び、課題の優先順位が変わる）。※顧客数とオペレーション人数は正比例はさせない。
顧客側のプロダクトオペレーション例：見積依頼→見積見積依頼 見積確認 → 発注見積設定見積依頼管理オペレーション管理ツールお客様がシステム上から見積依頼
顧客側のプロダクトオペレーション管理ツールオペレーションチャチャっと数クリック＋価格入力で完了Ope例：見積依頼→見積見積依頼 見積確認 → 発注見積設定見積依頼管理準備する必要のある見積が項目ごとブレイクダウンされてリストアップ
顧客側のプロダクトオペレーションチャチャっと数クリック＋価格入力で完了Ope例：見積依頼→見積見積依頼 見積確認 → 発注見積設定見積依頼管理オペレーション管理ツールシステム上で様々な条件で見積をシミュレーションできる
顧客側のプロダクト売値は担当セールス、原価はオペレーションが設定…オペレーションNG例：見積依頼→見積 (1年で案件数が数倍になったため…)TODOがわからなくなったので別ツールでTODOを管理OpeOpeSales見積依頼 見積確認 → 発注見積設定見積依頼管理オペレーション管理ツール
顧客側のプロダクトSalesオペレーション商談の流れで見積依頼貰ってくるOpeイレギュラーに対応できずに別ツールで全体を管理…NG例：見積依頼→見積 (1年で案件数が数倍になったため…)TODOがわからなくなったので別ツールでTODOを管理Ope見積依頼 見積確認 → 発注見積設定見積依頼管理売値は担当セールス、原価はオペレーションが設定…OpeSalesオペレーション管理ツール
顧客・案件の規模も、オペレーションの人数も、一気に伸びる時期。「今日の課題」は「明日の課題」ではない。「今日のオペレーション課題」にジャストフィットした「広義のプロダクト」設計は近い将来に破綻するリスク大。
勘所あるべき姿の時間軸を揃えるデジタルとオペレーションの役割分担の明確化
課題の可視化(定量){x}年後の課題の可視化オペレーションの変更可能性役割分担の明確化１ 2 3 4
課題の可視化(定量)2年後の課題の可視化オペレーション変更可能性役割分担の明確化本船動静トラッキング貿易書類作成請求書発行業務負荷1.5人 / 月1.2人 / 月1.5人 / 月1.5人 / 月1.8人 / 月0.5人 / 月案件管理ブッキング見積※実例を元に項目・データは可変しております。
一つの「業務」を切り取ってみても、どんなマイクロタスクに1日何分 / 何秒使っているか、それはどんな時に発生するのか、が可視化されております。
課題の可視化(定量)2年後の課題の可視化見積本船動静トラッキング貿易書類作成請求書発行業務負荷1.5人 / 月1.2人 / 月1.5人 / 月1.5人 / 月1.8人 / 月0.5人 / 月業務負荷 (2yrs)4.0人 / 月4.0人 / 月2.5人 / 月3.5人 / 月3.6人 / 月1.0人 / 月案件管理ブッキングオペレーション変更可能性役割分担の明確化※実例を元に項目・データは可変しております。
課題の可視化(定量)2年後の課題の可視化見積本船動静トラッキング貿易書類作成請求書発行業務負荷1.5人 / 月1.2人 / 月1.5人 / 月1.5人 / 月1.8人 / 月0.5人 / 月業務負荷 (2yrs)4.0人 / 月4.0人 / 月2.5人 / 月3.5人 / 月3.6人 / 月1.0人 / 月案件管理ブッキングOp変更可能性高い(顧客体験起因)高い(パートナー起因)低い低い高い(Ope起因)比較的低いオペレーション変更可能性役割分担の明確化※実例を元に項目・データは可変しております。
変わる確率が高いPDCA中の顧客体験・パートナー体験の対になるオペレーション管理・通知・ワークフロー等はオペレーション設計への依存性が高い。変わる確率が低い作業 (業界標準リアルオペレーション)例： 貿易書類作成、請求書作成、本船スケジュールチェックPDCAの末に編み出したオペレーション設計の「あるべき姿」※ やることやったので、変わってしまっても悔い無し
課題の可視化(定量)2年後の課題の可視化役割分担の明確化見積ブッキング本船動静トラッキング貿易書類作成案件管理請求書発行業務負荷1.5人 / 月1.2人 / 月1.5人 / 月1.5人 / 月1.8人 / 月0.5人 / 月業務負荷 (2yrs)4.0人 / 月4.0人 / 月2.5人 / 月3.5人 / 月3.6人 / 月1.0人 / 月解決方針Op変更可能性高い(顧客体験起因)高い(パートナー起因)低い低い高い(Ope起因)比較的低い役割分担の明確化※実例を元に項目・データは可変しております。
課題の可視化(定量)2年後の課題の可視化役割分担の明確化見積ブッキング本船動静トラッキング貿易書類作成案件管理請求書発行業務負荷1.5人 / 月1.2人 / 月1.5人 / 月1.5人 / 月1.8人 / 月0.5人 / 月Op変更可能性高い(顧客体験起因)高い(パートナー起因)低い低い高い(Ope起因)比較的低い業務負荷 (2yrs)4.0人 / 月4.0人 / 月2.5人 / 月3.5人 / 月3.6人 / 月1.0人 / 月解決方針プロダクト化(実装OK)プロダクト化(実装OK)プロダクト化(実装OK)役割分担の明確化※実例を元に項目・データは可変しております。
課題の可視化(定量)2年後の課題の可視化役割分担の明確化見積ブッキング本船動静トラッキング貿易書類作成案件管理請求書発行業務負荷1.5人 / 月1.2人 / 月1.5人 / 月1.5人 / 月1.8人 / 月0.5人 / 月Op変更可能性高い(顧客体験起因)高い(パートナー起因)低い低い高い(Ope起因)比較的低い業務負荷 (2yrs)4.0人 / 月4.0人 / 月2.5人 / 月3.5人 / 月3.6人 / 月1.0人 / 月解決方針ノーコードでOpが自前で対応プロダクト化(実装OK)プロダクト化(実装OK)ノーコードでOpが自前で対応プロダクト化(実装OK)役割分担の明確化※実例を元に項目・データは可変しております。
SQL + GASを駆使して、管理ツールを自作・改修。開発側の施策としては、• データ活用の土台作り• 利用しやすい形へのデータ設計の改修オペレーションの自前ツール
課題の可視化(定量)2年後の課題の可視化役割分担の明確化見積ブッキング本船動静トラッキング貿易書類作成案件管理請求書発行業務負荷1.5人 / 月1.2人 / 月1.5人 / 月1.5人 / 月1.8人 / 月0.5人 / 月Op変更可能性高い(顧客体験起因)高い(パートナー起因)低い低い高い(Ope起因)比較的低い業務負荷 (2yrs)4.0人 / 月4.0人 / 月2.5人 / 月3.5人 / 月3.6人 / 月1.0人 / 月解決方針リスクを取って、ツインでPDCAノーコードでOpが自前で対応プロダクト化(実装OK)プロダクト化(実装OK)ノーコードでOpが自前で対応プロダクト化(実装OK)役割分担の明確化※実例を元に項目・データは可変しております。
「課題の時間軸」の共通認識が大事！2年後の必要人数・業務工数・ボトルネックを可視化2年後の「あるべき姿」きっと間違えるので「余白」が大事
勘所 (再掲)あるべき姿の時間軸を揃えるデジタルとオペレーションの役割分担の明確化
リアルオペレーションを持つことのメリットテクノロジーの力「だけ」では解決できない課題も、リアルオペレーションと掛け合わせることで解決できる。「まず自分達で試してみる」が出来るので、ディスカバリーのスピードが速い。
Shippioのプロダクト戦略解像度 / 成功確度顧客数 / 取り扱い案件数デジタル +リアルオペレーションデジタルのみ (SaaS)デジタルフォワーディング
Shippioのプロダクト戦略解像度 / 成功確度顧客数 / 取り扱い案件数デジタル +リアルオペレーションデジタルのみ (SaaS)デジタルフォワーディング SaaS (Any Cargo)
Shippioのプロダクト戦略解像度 / 成功確度顧客数 / 取り扱い案件数デジタル +リアルオペレーションデジタルのみ (SaaS)デジタルフォワーディング SaaS (Any Cargo)(デジタル)通関
ご清聴ありがとうございました！Product Manager、絶賛採用中です！https://recruit.shippio.io
shippio
moritama1515
tenforward
devops_vtj
hosimesi11
mmclsntr
nsakki55
yoshidashingo
sakiengineer
optim
norimuraz
matsujirushi
bun913
chrislema
rocio
stephaniewalter
rasmusluckow
moore
gr2m
tenderlove
caitiem20
panda_program
bryan
nonsquared
kevinliebholz