プロダクトマネジメントにおける調整

Transcript

1. プロダクトマネジメントにおける調整 株式会社TOKIUM 村上雅⼀
2. ⾃⼰紹介 名前：村上雅⼀ 所属：株式会社TOKIUM インボイス製品開発部 部⻑ ⼀⾔ 「結局、何を作るんだっけ？」という問いに、 毎日頭を悩ませています。
3. 我々PdMの毎⽇は、調整の連続 「正解」を探して彷徨う⽇々 営業からは「この機能がないと売れない」と⾔われ、 CSからは「使いにくい」と怒られ、 エンジニアからは「仕様が曖昧だ」と詰められる。 AIなら瞬時に正解を出せるこの時代に、 私たちが泥臭く⾏動し調整することに、 果たしてどんな価値があるのでしょうか？
4. 3つのケースとその解決策 ここからは私の半年で経験した体験を3つお話しします。 Case1：スピード重視 完璧を捨て、MVPを追求した結果 Case3：社内の複雑なオペレーション解読 複雑な社内オペレーションをどう紐解くか Case2：不確定要素への準備 SaaS導⼊⾒送りスクラッチ開発した話
5. Case1:スピード重視
6. 無茶ぶりから始まったスピード重視 YouTubeでの無茶振り ある⽇、代表がYoutubeの収録で宣⾔しました。 「今⽇からTOKIUMのAIエージェントが使えま す！」 現場のPdM（私）の⼼境 • 開発：まだチーム組成していない • 期間：放送開始まで残り1ヶ⽉ • 運⽤：社内オペレーション決まっていない
7. 開発しないという決断 期限は1ヶ⽉。「正しいシステム開発」をしている暇は1秒もなかった。 通常のロードマップ ‧完璧な登録フォームの実装 ‧⾃動課⾦システムの構築 ‧管理画⾯のUI整備 → 間に合わない（嘘になってしまう） 採⽤しない開発 ‧CRMのフォームを利⽤し既存SaaSの認証を利⽤しあ りものでセルフサインアップを実現 ‧課⾦基盤がないのならAIエージェントを無料で提供 ‧AIエージェント管理画⾯の提供は後回し → 放送⽇からサービス提供可能！
8. 結果：放送⽇から価値を届けられた 顧客は「裏側のシステムが綺麗か」なんて気にしませんでした。 求めていたのは「今すぐ課題を解決できるか」だけ。 スピードこそが、最⼤の価値だったのです。
9. Case2:不確定要素
10. 従量課⾦の開発開始 ‧運⽤で時間を稼いでいる間に裏では⾃動課⾦システムの準備を開始 ‧従量課⾦なんてSaaSがあるだろうと楽観視 ‧海外へ視野を広げ⾒つけたSaaS
11. 交渉開始 JPY対応可能でしょうか？ TOKIUM 営業 マスタの追加だけなので 1ヶ月くらいで対応可能です 契約するので進めてもらえますか？ その後Q&Aを通じて製品仕様への理解を深めました 営業 任せてください。 エンジニアに頼んでおきます。 TOKIUM
12. 2ヶ⽉後 企業名 企業名 （日本語訳） 社内で慎重に検討いたしました結果、現時点では、当面の製品ロードマップに「日本円」への対応を含める見通しが立っておりません。
13. ないなら⾃分たちで作るしかない 責務がきれいに分けられていた この部分を作れば良い そんな窮地を救ったのは、いままでの⾃分たちの準備と調整でした AIによる⾼速での開発
14. 転んでも⼤怪我しないようにリスク潰す SaaSの利⽤ができないことで、ビハインドは⽣まれてしまいました。 しかし、⾃社に最適化した請求基盤を⾼速で開発することにつながりました。
15. 結果：最悪の事態を回避し、影響を 最⼩限にすることができた 不確定要素があったとしても影響を極⼩化できるように 体制を調整しておくことが⼤事
16. Case3：社内オペレーション
17. 社内の複雑なオペレーション解読 これで安⼼とはならず、社内の請求のための複雑な業務が存在しました
18. 各ステークホルダーにヒアリング 請求フローには多くのステークホルダーが存在していました。 それぞれが⾃⾝の領域が存在し、お互いの責務の間に存在している課題もありました。
19. ヒアリングによるプロセスマップの書き出し 各ステークホルダーへのインタビューを通じてプロセスマップを作成 ‧10システムにまたがるプロセス ‧5⼈の登場⼈物
20. 社内認識がスムーズに 何も分からないのなら、⾃⾝の範囲とか関係なく越境して情報取り整理をする。 それが確実な開発につながるし、プロダクト価値提供の速度を上げることができる。
21. 結果：⾼速で機能開発ができた SaaSを使えなくなったとしても、 その前段で準備していたことは開発のための無駄にならない
22. 結論：PdMは道路整備を⾏う PdMが道を整えることでエンジニアは爆速開発ができ、ユーザー価値へ⼀直線に進むことができる
23. 泥臭い調整は最強の武器 調整仕事はプロダクト開発の武器 " "