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
いま現場PMのあなたが、 経営と向き合うPMになるために 必要なこと、腹をくくること
Search
Takahiro Yamaguchi
January 18, 2025
Technology
1
440
いま現場PMのあなたが、 経営と向き合うPMになるために 必要なこと、腹をくくること
25.01.19 pmconf 2024の落選セッションお披露目会 / #落選お披露目 資料
https://product-deepdive.connpass.com/event/333654/
Takahiro Yamaguchi
January 18, 2025
Tweet
Share
More Decks by Takahiro Yamaguchi
See All by Takahiro Yamaguchi
ルクミーにおけるAI活用の現在地
hiro93n
1
1.3k
保育中心設計でつくる保育ICTの裏側
hiro93n
0
470
組織の仕込み方
hiro93n
1
330
同時8プロダクトの立ち上げと新PdMチームの構築をどう両立したか戦記
hiro93n
3
8.4k
ハードウェアの現場と繋がる世界のギャップを埋める開発指針
hiro93n
0
210
しなくていいUXを実現するための IoTサービス設計
hiro93n
0
390
ハードウェアは口数少ない - IoTサービス運営にとっての管理画面 -
hiro93n
0
640
ハードウェア設計開発者の腰が重いのではなく Webな自分たちが指摘するのが遅いのだ問題
hiro93n
2
650
日常中心設計 - IoT家電だけどアプリから脱却したい -
hiro93n
2
470
Other Decks in Technology
See All in Technology
Oracle Exadata Database Service(Dedicated Infrastructure):サービス概要のご紹介
oracle4engineer
PRO
0
12k
Godot Engineについて調べてみた
unsoluble_sugar
0
260
テストを書かないためのテスト/ Tests for not writing tests
sinsoku
1
160
ZOZOTOWN の推薦における KPI モニタリング/KPI monitoring for ZOZOTOWN recommendations
rayuron
1
1.1k
東京Ruby会議12 Ruby と Rust と私 / Tokyo RubyKaigi 12 Ruby, Rust and me
eagletmt
2
580
Cloudflareで実現する AIエージェント ワークフロー基盤
kmd09
0
260
Accessibility Inspectorを活用した アプリのアクセシビリティ向上方法
hinakko
0
160
2025年の挑戦 コーポレートエンジニアの技術広報/techpr5
nishiuma
0
120
ゼロからわかる!!AWSの構成図を書いてみようワークショップ 問題&解答解説 #デッカイギ #羽田デッカイギおつ
_mossann_t
0
1.3k
JAWS-UG20250116_iOSアプリエンジニアがAWSreInventに行ってきた(真面目編)
totokit4
0
110
WantedlyでのKotlin Multiplatformの導入と課題 / Kotlin Multiplatform Implementation and Challenges at Wantedly
kubode
0
220
When Windows Meets Kubernetes…
pichuang
0
280
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
222
9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Building Better People: How to give real-time feedback that sticks.
wjessup
366
19k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Into the Great Unknown - MozCon
thekraken
34
1.6k
Fireside Chat
paigeccino
34
3.1k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3.1k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Agile that works and the tools we love
rasmusluckow
328
21k
For a Future-Friendly Web
brad_frost
176
9.5k
Transcript
いま現場PMのあなたが、 経営と向き合うPMになるために 必要なこと、腹をくくること Takahiro YAMAGUCHI / @hiro93n 25.01.19 pmconf 2024の落選セッションお披露目会
/ #落選お披露目 1
発表者 is 誰 山口 隆広 ユニファ株式会社 執行役員CPO プロダクトデベロップメント本部 本部長 兼
AI開発推進部 部長 1981年生、福島県出身、子(5歳)の父。 HCD-net認定 人間中心設計専門家。 ね 大好 。ベーススキルは企画職。 @hiro93n 3
4 写真販売、連絡帳、午睡チェック等を提供する保育ICTプロダクト群を運営
5 昨年末 ら、みてねさんとの連携も開始
さっそ 本題 6
で、今CPOの人に「経営と向 合うって」言われても…… そもそも 膳立てされてるスタートじゃないの? 7
8 ここ らスタートなので 膳立てな 、結果的に「向 合う」着地 CEO 開発本部長 プロダクト部長 新規アプリPM
(ビジネス・ コーポレート部門) (開発他部署) 他プロダクトPM
今日来て ださった皆さんの多 は そら 「現場PMで、経営と向 合うPMに なりたい」という方 経営と向 合う、つまりは「経営に対して意見したり、話を聞いてもらえる、 案を採用してもらえるPM」という
とだと仮定。 *「経営」を、まずは経営チームと 経営者のつもりで使ってい ます。 9
現場PM 経営と話したいと思うと • 会社のプロダクトに対する意思決定 、世の中の書籍や講演で語られている 内容と比べて離れているように感じるので、ちゃんと伝えたい • プロダクトマネジメントの考え方 社内的にもあまり重視されていないよう に感じるので、改めて重要性を理解してほしい
• プロダクト組織と経営との間の距離 遠いと思って り、プロダクト 事業 の中でどの程度重要だと思われているの 不安だ • 会社はもっとプロダクトマネジメントに投資すべ なので、社外でいろいろ 学んでいる私の提案を聞いてほしい など…… 「会社としてプロダクト理解 足りなそうなので経営を説得したい」イメージ 10 注:特定の人や組織を指した事例ではなく一般論です
軸にある考え方 自社のプロダクトマネジメントを正し やれば、事業を今よりも伸ばせる (と思っているので、説得したい) 11
実は今日の話は、10年ちょっと前の自分にも向 てます。 12
10年ちょっと前の状況を振り返る 13
10年ちょっと前の自分の状況 • 担当しているToC向 エンタメサービス 好調 • 課長にもなった • (自分は)メンバーマネジメント で
ていると思い込んでいる • 周り 何もわ っていないと指摘ば りしている 14
10年ちょっと前の自分の状況と、実際どうだった • 担当しているToC向 エンタメサービス 好調 → 引 継 元のプロダクト 設計
良いだけであり、自分の実力の げではない • 課長にもなった → 体制の急拡大 必要だったのでとりあえず • (自分は)メンバーマネジメント で ていると思い込んでいる → ただの 御用聞 であり、全部を抱えてるだけでマネジメントに至ってない • 周り 何もわ っていないと指摘ば りしている → 言い方、伝わり方 完 全にダメで、視座も狭い 完全な勘違いなのだ ど、当時はそれに気づいていな った故の自信過剰 15
のと の自分は、経営にもの申したい企画職 16
10年前に、経営に何をもの申した (一部ぼや してます) • 経営戦略 らの要求プロダクト数 莫大だった と っ ◦
開発チームのキャパに対して現実的ではないと感じ、 つ品質担保にも 懸念を持った。い にそれ 無謀 を、数十ページにわたる資料で仲の 良いMGR間で整理した。 ◦ それに適する組織体制や人員配置も併せて入れ込んだ。 • 上記を経営に個別にプレゼンする時間をもらい、同僚のMGRにプレゼンし て てもらった。 最高のアウトプットを出してMGRとしての責任も果たしたという気持ち 17
後日 18
マネジメントラインは他本部中心に統合され 自分含め関係者はマネジメントとしては外された 19
突然です 質問です。 20
突然です 、この場の皆さんに質問① プロダクトマネジメントに 興味あります ? 21
今日 にいる方なら、当然ありますよね 22
突然です 、この場の皆さんに質問② リードナーチャリングに 興味あります ? 23
リードナーチャリング……? 24
Salesforce社のブログより https://www.salesforce.com/jp/blog/jp-lead-nurturing 25
専門外の専門用語、howに興味を持つ人は少ない 26
自分たちのようなプロダクトチームを除いて プロダクトマネジメントに興味ある人ってそんなにいない 27
10年ちょっと前の状況を再度見直してみる 28
当時の説得コミュニケーション 経営にプロダクトの現実を 伝えられている人がいない のではないか? 経営がプロダクトの現実を 正しく理解すれば この状況は解決するはずだ の時の「解決」とは、プロダクトチームの目線で妥当な開発プロセスや人員 計画 採用され、方法論として妥当な状況になる
と。 29
いわゆるプロダクトアウトっぽいコミュニケーションだった (そんな話は相手はまだ興味 ないし、求められてない) 30
今冷静になって経営の気持ちをエスパーする(裏取りはしてない) • 開発を進められる ら君たちを雇っているのであって、それ で ないのは そもそも自分のスキル不足じゃない? • 君たちの部門で解決すべ ことなのに、何で貴重な経営の時間を奪ってまで
なぜ話しに来るの? ◦ の時間 あったらもっと事業価値のあるアクション で たという話 • のあたりの理解 で ていない状況のマネジメント の体制の意思決定 をしている と自体 経営リスクだし、安心して任せられない 自分たち 思っていた理想とは別の方向に向 て「 の体制は今と変えた方 良い」と懇切丁寧に伝えただ 。 31
だ ら無駄に経営に提案なんてするな、という話ではもちろんない • 言うべ とを言わないで と 組織を不幸にするのは変わりない。 • 相手に対し、知りたいスコープとは外れた「他部門の専門性」に関わる話を 結果的に押しつけていたこと
問題だったと思っている。 • 体制を変えたとして、それに対する事業影響のリカバリの話題はなし。 ◦ リカバリは私たちの仕事ではありませんので考えて ださいというスタ ンスに見えていた可能性 ある。 • 経営 求めるのは「で ない との重厚な説明」ではな 、で るようにす るためのプラン。その施策とhowの組み合わせ よろし ないなら、他の同 等の期待値 ある組み合わせを知りたいはず。 の経験 今の自分にとって「経営に向 合うためのPM」の考え方の軸にある。 32
無謀だと分 りつつ見な った とにするのも違うので 当時の自分たちので る ととしては、結局はそれし な ったの もしれない。
33
課題と解決策 合ってないと、プロダクト同様に成果に つな らな ったという、みんな不幸だったと言う話。 (オトナになって分 った と) 34
さて、改めて本題へ ↩ 35
現場PMのあなた 経営に向 合うPMに なりたいと思った理由と、それ 実際ど の程度求められている話なの ? 36 あらためて考えてみる
会社は何を っ けにPMを雇用しはじめるの • 今までわ らない中でプロダクトを作って た • もっと他に見な ればならない
と 多 なって た • 想定通りに開発 進むように、自分の代わりに進捗管理してほしい • で ればプロダクトやデザイン、テクノロジーに詳しい人だといろいろ相談 で て良いはず ちょっとプロダクトわ りそうなので進めて いてほしい ら連れて た。 37
会社は何を っ けにPMを雇用しはじめるの • 今までわ らない中でプロダクトを作って た • もっと他に見な ればならない
と 多 なって た • 想定通りに開発 進むように、自分の代わりに進捗管理してほしい • で ればプロダクトやデザイン、テクノロジーに詳しい人だといろいろ相談 で て良いはず ちょっとプロダクトわ りそうなので進めて いてほしい ら連れて た。 38 これ 詳しいと開発 うま 進むんだろうなという期待値と、 会社としてここを細 知りたいという期待値は別。
プロダクトだけを良 するだけの提案は、今求められていない可能性 • プロダクトの意思決定 イマイチだ、もっとユーザーに向 合った開発の割 合を増やすべ だと思う、開発プロセスを変えましょう、様々なプロダクト マネジメントに関わる提案に対し、経営はそこまで関心は持っていない可能 性
ある。 • プロダクトマネジメントへの理解 事業にどの程度貢献する わ らな い、因果 描 ないので、現在経営とPM 向 合っていないのではない 、という解釈もで る。 39 プロダクトの課題というパッケージで持っていっても、いまはダメ。
40 BtoBの事業を進める上での経営面での関心事 セールス オペレーション プロダクト 営業(中小・エンプラ ・自治体など) カスタマーサクセス マーケティング カスタマーサポート
在庫管理・出荷管理 代金回収 プロダクト運用開発 顧客反応からの ニーズ発掘 ロードマップ管理 れ以外にもまだまだある 、少な ともプロダクトだ では成立しない。
41 BtoB事業で、経営と事業戦略を話すロールでよ 浮 ぶもの 共通点として、みんな事業を取り巻 状況の理解 で ている。 数字も分 る。用語も分
る。個別事情も分 る。 営業MGR 事業責任者 事業企画 経営企画
事業を取り巻 状況の理解 ある。つまりは 「 の前提 ら話さな ゃい ないの?」 ない。 42
前提 通じない状況でPMはその先の向 合いはで ないし、 提案しても「開発の人は分 ってない らね」 ら脱せない。 43
44 プロダクト事情だけじゃない提案に見られるための必要なステップ プロダクトを支える「プロダクトじゃ無い部署のメンバーなら 当然知っている言葉、前提」を把握する いきなり経営課題まで行かなくてもいいので、 営業やオペレーション現場での課題も理解する それらの課題と、今自分が感じているプロダクト体制や手法の課題の 両方に影響する大義名分を描けるか検討する プロダクトだ の事情ではな
、事業課題を含めた現状改善提案というパッ ケージになると、事業貢献に対するその提案の期待値は大 変わる。
そのパッケージを作るために必要なこと • 最低限、プロダクトの人としての信頼残高をつ る ◦ PMに話す とに意味を感じられな ても、既存の信頼残高 あればア クセスで
る情報源や、コミュニケーションラインは立てられる • 理解 進んだら、営業やオペレーションの課題 今どうなっていて、事業を 伸ばす上でのキー 何であり、どういった機会と脅威に対峙している の仮 説を関係者に当てて、理解度を上げる • 現場で解決で る課題には対処した上で「これは経営判断 必要であり、現 場でもんでいても仕方ない」という課題に目星をつ 、自分N=1ではな 事 業関係者との共通課題としての目線を入れ、パッケージにする。 45 最終的に、経営と向 合う大義名分 で て り、日頃経営と向 合っている 人も巻 込んでしまえば結果的に「向 合い」の機会にたどり着 る。
46 例:登壇者 経営と向 合う提案の前提理解に効果 あったと感じること 施策 効果 社内Slack巡回して各部門の背景理解 今何 熱い話題なの
分 り、特に 聞 な とも薄 広 理解 進む ふわっとしたプロダクト系疑問をslack で見 たら無理のない範囲で調べた り、ドキュメントにまとめ共有する。 ういう提案もPMに聞 るんだと認識 してもらえるため、より確度の高い類 似案件で直接頼られるようになる。 一見PMの持ち物じゃない(セールスや マーケ領域などの)案件で担当不在の ものを中継 として拾う 本来担当しうる部署に聞 る「大義名 分」 で るので、業務理解 進む。 意思決定の場に同席する数 増える。 全社の中で今重要視されている課題を把握していると、PMなら大体知っている 知見で貢献で そうな話題の見立て 進み、結果的に提案の場数 増える。
47 例:PM 倒す社内課題の例 お客さんにもらった要望、今 全然ない機能だし諦めるしか ないか… エンジニアに聞いたら1日で倒 せるレベルだったので月末に 倒しましょう。 ノープランではなく事前設計
し「で?どうする?」になら ないリサーチにしましょう。 プロダクトDBは共通なので、 あのチームに生成機能作って もらうと業務なくせます。 新しいことをやろう!明日と にかくヒアリングだ!! この管理シートはあれとこれ とそれの内容を毎日コピーし て作ってます PM 見たり聞いたりしたら、更に品質アップ&コスト 低いやり方を推薦で そうな課題 埋もれている と 多い 、現場では案外諦められている。
48 今日何度も出て る「大義名分」も、周囲を巻 込む上で重要 その案に乗ることに時間やコストを払う べ 理由 持てると、みんな 乗れる。 プロダクト部門は助
るんだろうな、やってあ たいな、だ では動 ない。 経営 好 嫌いでな 実利のために動いてると言えるための条件設定も大事。
49 その過程で様々な人を巻 込みな ら、不都合な真実にも出会う • 不安な らも活動を増やす上で、事業 担当プロダクトだけで回っていない ことを理解で るのと同時に、自分たちの知見やアウトカムの対象は、別に
今のプロダクトだ じゃない、場合によっては全然違うところで発揮した方 事業全体を伸ばせることに気づ 始める。 • 上記を前に進めようと思ったとして、仕組みやルール 足りなす るので作 らな てはい ない とにも気づ 。 今自分 頑張っている優先度「じゃない」気配 見えて る。
50 乗り けた船だと思って突 詰めてい と…… • さっそ 色々整理してみて、自分の見立てでは「良さそう」なシナリオだ • それ
事業戦略上も有効なの ?それはどのように検証するの ?必要な資 源を確保で るの ?という話を、それの最前線で意思決定している人とし た なる。 • 話す相手として適切なのは事業責任者であり、次第に経営になる。 経営を説得した った ら始めた となのに、目的 変わって る。
51 経営に向 合うルートにたどり着 ための理想と現実 理想 現実 プロダクトマネジメントの スキルを磨く スキルを活かして 担当プロダクトで成果出す
権限が増え、話せる人が増える 自分のタスクと並行して 全社の状況を把握する 自分の担当外でも良いので プロダクト関連課題を解決する 権限が増え、話せる人が増える プロダクト担当者をやる 、社内でプロダクト知見 ある人をやる の違い。 BtoBだと比較的 ういった路線になる と 多 なる。
52 この路線 続 と、立ち位置の理想と現実 こうなる 理想 現実 担当プロダクトの要求を整理し 良い感じの仕様に落とし込む プロダクトがリリースして反響も
良い!更なる新規登録も進む チームを更に増員して、次々に機 能をリリースしていく。 潜在課題の解決方針を固める 次の相談がやってきて、持ちきれ ないので既存の課題を引き継ぐ 来る相談の抽象度が上がってきて 訳分からないながらも走り続ける 信頼されて担当プロダクト内の権限 上 っていって…ではな 、次々に社内 の課題解決をPM知見で進める人になっていて、周辺知見 積み重なる。
こんなはずではなかった・・・・・・? でも、こんなはずになると向き合いの関係性が変わる 53
54 課題解決を進めるPMになると、経営もあなたと向 合う必要性を感じる • PMの〇〇さん 色々解決して れる、という事例を複数の事業責任者 ら 話される •
次々に仕入れられる経営課題や機会に対してプロダクトやテクノロジーで解 決しうるアイデアの引 出し ありそうで、実現可能性を語れたりする • 不確実性や抽象度の高い話題であっても、社内の体制などを考慮して考え得 る60点をす に打ち返すような ともまあある • 仮にあなたにアイデア な ても、社内で誰に何を頼ればいいの のパスを 知っていて、相談先捜索に悩まな ても良い あなた 意思決定や検討の場にいる方 、事業成長 より進むと思われ始める
55 向 合い 経営へ→経営 らに変わってい プロダクト開発プロセスをさ らによくできる方法を聞いて ほしいので経営へ話したい 経営課題に対し解決策が出せ そうなので経営から話したい
• プロダクトマネジメント知見を持つ人は経営課題の解決に貢献で るんだ な、という事例を積み重ねると、経営 頼る選択肢にPM 入って る。 ◦ 二匹目のどじょう案件。PMへの期待値 変わる。 ◦ もちろんプロダクトに向 合って伸ばすPM いる ら、 のパターン のPMも存在で る • 頼られる中で、ボトムアップな話題を出すこと自体は当然あって良い。
56 遠回りをしてるようで、実はプロダクト組織 強 なる近道になる • PM プロダクトに閉じず様々な場所で活躍する場面をみると、PMそのもの に興味 湧 、期待値
上 る • もっとPMに頼りたいと思ったと 「実はプロセスを改善するともっとPM 活躍で ますよ」となると、初めてPMのノウハウ、改善策に関心 高まる • プロダクトに接点のない部門 ら「PMは大事」と思ってもらえると、プロ ダクト組織強化に対する取り組みを応援されやすい。 経営と接点を持つために他部署の人の力を借りているうちに、組織強化施策に 必要な投資 受 やす ったり、協力されやすい状況を作れている。
PMとして「成果出るならOK」と、 の状況を受 入れる=腹を る 57
58 腹を る必要 あることの例 担当プロダクトにもっと 時間を使いたい 経営課題の理解のために 全社状況の情報収集や 解決提案にもっと時間を使う 自分以外の誰かに担当プロダ
クトの成長を託す 新しい組織や役割の導入を自 分で提案し推し進める 開発チームの環境を良くする ための施策を打ちたい プロダクトマネジメントの知 見が社内で飛び交うような勉 強会を開きたい プロダクト開発そのものではな 、プロダクト知見による仕組み化に関わる時 間 増えるし、それに対する期待 メインになって る。
59 腹を ってみた身として思ったこと • 転職ポータブルなスキル 身につ は分 らず。ただ、経営に対しプロダ クト組織に求められる と自体は案外ポータブルな気
している。 • プロダクトで成果出す方 キャリアとしても分 りやす 、そ ら外資で プロダクトを見てい などの方向性も見えやすい • やりたい結果 出るなら別にプロダクト開発である必要もない!位の割り切 り で るなら、その場のルール、変数に関わるチャレンジは面白い • そうはいってもリサーチもやるし、仕様書も書いているので言うほどプロダ クトの最前線 らは離れないし、その最前線の現場感も当然必要 PMのスキルは特定のプロダクトだ に活 すのはもったいないとも思っていて 実際は会社というプロダクトを強 する とにも十分貢献で る。
あえてミスリード的に書いた「経営」の件 60 プロダクトの立場だ で 経営を説得相手・対峙す る意味での向 合い プロダクトを伸ばすため に必要な課題に対し、経 営(と一緒に)向
合う こっちの意味ではな こっちの意味で向 合いたい 会社と 、経営と 、上層部と 、指示 来たり説得相手である概念ではな 、自分 当事者の一部としてどう振る舞う ?の方 面白いはず。
61 「経営と向 合う」ことも、PMのい つ のキャリア、手段のひとつ • いわゆる「みんな CPOをやる必要はない」的な話ではあり、人を選ぶ • 経営と頻度高
向 合うのは刺激的で、実際面白い • 単一プロダクトだけをコントロールで ても事業貢献で る部分は限られる (気もしている) • 自分 で ない とを誰 にやってもらうために悩む と 増える 、結果 的に自分だ ではで ないようなゴールにたどり着 る • 経営に向 合う と ゴールというより、向 合うために行うアクション 結果的に三方よしになる その結果我々はPMでな なる もしれない れど、課題解決 好 なPMとい う人種の「PM以外での可能性」 広 るのは っと素敵なこと。
あ まで目的に立ち返る。最終的には事業成果 大事。 純粋なPMの価値観の中で成果を出せる 場もある。今日は、そうじゃな ったら どうする?どう振る舞う?の一例。 プロダクト同様、ゴールへの登り方は様々。あるべ に捕らわれないのも大事。 62
63 今の自分はこれです
さあ、あなたはどう経営と向 合ってい ます ? 64
65 家族の幸せを生み出す あたらしい社会インフラを 世界中で創り出す