プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management | Udemy
PM の仕事とは
プロダクトビジョンの作成
- ProductVision とは
- 会社の Misson を達成したい
超長期的ゴールから導出される - プロダクトの長期的なゴール ( 1~2年スパン )
- 例: 「次の1年で解決すべき顧客の課題は〜〜〜だから、プロダクトは〜〜〜となる必要あり」
- 会社の Misson を達成したい
- 初めに会社が考えているゴールを確認 ( CxO 役職と調整 )
- PM チーム全体で ProductVision を導出
- 作成時期は、6ヶ月 ~ 1年スパン
- 各担当 PM の担当領域でゴールを決定
- 担当領域の中で、解決すべき問題は何か
リサーチ
- リサーチとは
- 顧客が「良い」と思うプロダクトを作る視点を持つ
- なぜ、ユーザは〜〜〜という問題を抱えるのか？
- プロダクトが解決しようとする問題は何か？
- プロダクトが世の中に存在する時の全体像を掴む
- 顧客および周辺人々のネットワーク
- プロダクト周辺のテクノロジーやトレンド
- 顧客の行動や導線、感情
- 使用場所やタイミング
- プロダクトがビジネスとして成立するか
- ProductMarketFit が存在するか仮説を立てる
- マーケット規模、潜在ユーザ規模
プロダクトプランニング
- 自分の中で5つの質問に対する解を用意
- ユーザが直面する問題に対して、自分の立ち位置や業界の流れは何か
- プロダクトを通して、たどり着きたいゴールはどこか
- そのために、どのような機能やプロダクトを継続リリースすることで、たどり着くのか
- その際に想定できるリスクは何か
- リスクを乗り越えていけると信じられる理由は何か
ロードマップ
- ロードマップとは
- 新機能や新プロダクトのマーケット投入時期を示す
- マーケティング部門は GoToMarketプラン、営業部門は Salesプランを策定
- PM は常にアップデートを続ける
- 会社全体として、方向性と戦略の意思統一を作り、KPI として定量的に設定 ( 3ヶ月後 ~ 1年後 )
- KPI に一番効果のあるプロダクトの機能やアイデア、その前提となる仮説を洗い出し
- アイデアが発生させる KPI へのインパクトとリソース配分から、優先順位付け
- 優先順位に基づき、タイムライン毎に設定 ( 月毎、四半期毎、半年毎 )
- 開発とユーザ向けテストを頻繁に回し、仮設検証しつつ、プロダクトをリリース
- ロードマップに更新あれば実施
PM とアジャイル開発プロセス
- すべての開発は、投資でありコストである
- どのような開発投資を決めることをスプリントプランニング
- スプリントは決定した方向で、投資効果を最大化すべく全速力で動く
- スプリント半ばにおける機能改善要求は、多大なコストが発生する
機能改善による実現見込み利益 >> スプリント中止による損失を見て判断
開発プロセス
- プロダクトバックログ（ 主担当: PM ）
- PRD に基づき、開発するプロダクトの機能一覧をハイレベルで抽出
- 各機能に対して、優先順位を設定
- プロダクトの実装目的を記述
- スプリントプランニング（ 主担当: PM・PG ）
- 開発機能に対する担当者を決定
- 開発機能に対する工数を見積もり
- PRD の抜け漏れを PM に確認
- スプリントバックログ（ 主担当: PG ）
- 開発機能について、エンジニアリングタスクに分解
- タスクに対する工数を見積もり
- タスクに対する優先順位を設定
- スプリント（ 主担当: PG ）
- 2~4 週間単位の開発期間
- 毎日 or 週3回程度、チーム内で MTG 実施 ( 進捗報告、担当間のタスク依存関係を元に調整 )
- バグ発生時、即座の修正 or 後回しか相談
- インクリメント（ 主担当: PM ）
- スプリント期間中の PM 対応
- 次のスプリントで対応する事項を調整
- バグの対応優先順位付け
- スプリントレビュー
- QA を通し、リリース可能な機能を確認
- 開発中に発生したバグの対応時期を確認
- スプリント振り返り
- スプリント期間中に発生した、プロセス改善案等のフォローアップ
非開発部門との関わり
- 他チーム内で、機能改善要求をまとめ、リストにして優先順位を設定
- 他チーム代表は、PM に対して定期的に共有
- PM は、既存の開発ロードマップを鑑みて優先順位を設定
- 要求事項は、ユーザに対して価値を提供できるか
- 要求事項は、他の開発を停止してでも、会社に利益をもたらすか
- ロードマップとは、
今後の実装プロダクトや機能をリリース見通し( 必ず実装する性質の計画でなく、あくまで変化する可能性を加味した見通し )
実行と意思決定
開発中の PM の役割
- PRD の段階で、技術仕様書に落とし込み時に要件定義が甘い場合、都度、詳細の詰めを追加実施
- 初期の開発見積もりより、ボリュームが多いことに気付く
- API ドキュメント通り動かない
- 技術的負債(バグ)が開発スピード落とす
- 開発担当のエンジニアが転職等
- PM の役割: タスクの優先順位付け
- バグ修正の優先順位付け
- どのデザインパターンで進めるか
- 想定通り動作しない場合、ワークアラウンドオプション出しと、リスク評価および選択
- 実装機能の優先順位付け
- PM の役割: コミュニケーション
- 開発メンバーが障害にぶつかってないか確認
- 当初予定の PRD の通り進めるか、スコープ変更した場合は影響範囲との調整
- 上層部への調整 ( 進捗・投資効果・メンバーのモチベーション維持 )
- PM の役割: プロダクトリリース時
- クリティカルなバグは全て潰す
- ユーザに対する UI/UX は、期待値に届いているか
- GoToMarket 戦略は、実行可能な状態か
- KPI のモニタリング準備はできているか
- PM の役割: プロダクトリリース後
- KPI のモニタリング
- ユーザからのフィードバック確認
- クラッシュやバグの発生率を確認
PM の姿勢
- 失敗の可能性がある限り、初期段階では小さく試す
- 事前に失敗時の手打ちをする
- 失敗は隠さず、学ぶ
- 失敗を共有し、組織全体の「知見」に昇華
PM を生かせる組織形態とは
- 組織文化
- PM がプロダクト開発に集中できる仕組みを整える
- ロードマップの変更が許容できる文化を整える
- 失敗をネガティブ感覚から、組織への学びの感覚を持つ
- チーム構成
- 最小構成
- PM
- Dev ( 兼QA )
- Designer
- 標準構成
- PM
- PjM
- DataAnalyst
- Dev
- QA
- Designer
- 最適構成
- PM
- PjM
- DataAnalyst
- Web/Mobile Dev
- Backend Dev
- QA
- Designer
- 最小構成
- 会社側によるチームへのサポート
- 自律的に動けるよう、Vision や KPI を決めたら、会社はチームに委ねる
- 意思決定をしやすくして、意思決定ラインを短く簡潔にする
- 構成単位を小さく ( 例: Amazon はピザ2枚で賄える人数程度を設定 )
