Product Managerとは #
Product Manager(PdM)は、会社やユーザーにとって価値を生み出すプロダクトを発見し、実現できるようにチームを導きます。 良い機能をリリースするための意思決定をチームを巻き込みながら進めていきます。 ユーザーは誰なのか、何を必要としているか、プロダクトはビジネスにどんな影響をあたえるのか、ステークホルダーは誰かを、明確に理解する必要があります。また、チームと密接に連携する必要があります。
バランスチームの中では、リーンの方法論をもって Viable（ビジネス価値） の視点を持ってプロダクトの成功に貢献します。
優先順位付け #
Product Managerは、多くのところから出てくるさまざまなアイデアをフィルタリングして、何から開発するか、いつ開発すべきかを決めます。
プロダクトの中長期的な戦略からストーリー単位の粒度までそれぞれ優先順位の判断を行います。
チームのメンバー、他チーム、ステークホルダー、ユーザーなどから様々な情報を収集して積極的に内容を理解するように努め、裏付けするデータと情報に基づいて総合的に判断して優先順位を決めていきます。
優先順位をつける手法として、ユーザーへの価値を提供するかとビジネスとしての価値を２つの軸にとって2×2を利用する、などがあります。
優先順位をつけた結果は、プロダクトロードマップ、ユーザーストーリーマップ、バックログなどで可視化します。
優先順位付けにあたっての検討項目
- ビジネス価値
- ビジネスゴールの達成に対して前進するのに役立つか
- ユーザー価値
- ユーザーのニーズや要求を満たすか
- 多くのユーザーに共有・利用されるか
- 実現可能性
- チームが開発できるか
- 素早くデリバリーすることができるか
2×2 プロダクトロードマップ ユーザーストーリーマップ バックログ
バックログ管理 #
バックログとは、優先順位に基づいて整理した開発作業のリストです。 Product Managerはバックログの管理に責任を持ち、効率的かつ柔軟に開発作業を進められるようにします。
バックログの作業の種類 #
ユーザーストーリー（ストーリー）
ユーザーに価値を提供します。 通常、機能を実現する機能ストーリーと見た目を整えるデザインストーリーに分けてバックログ管理します。 機能ストーリーはProduct Managerが作成しますが、デザインストーリーはプロトタイプなどを作っているDesignerが作成するのが効率的です。
バグストーリー
既に受け入れ済の機能の不具合を修正する作業です。 バグを検出したメンバー、開発するメンバー（Developer）、受け入れするメンバー（Product Manager/Designer）のいずれかが作成します。
chore
ユーザーに直接価値を提供することはありませんが、Developerにとって必要な作業です。 リファクタリング、新規機能のSPIKE、開発環境の構築、CI/CDパイプラインの改善、また、ユーザー追加に伴う環境の追加設定や、インシデントの調査などの保守作業はchoreとしてバックログ管理を行い、ユーザーストーリーとバグを含めてDeveloperの作業を一元管理できるようにします。 技術的な内容となることが多いためDeveloperが基本的に作成しますが、作業を実施するタイミングはその優先度を考慮してProduct Managerが判断するようにします。
バックログ管理のポイント #
小さくわかりやすい作業
一つ一つの作業を小さく分割することで、作業に集中しやすく、進捗状況を管理しやすくなります。 また、作業の依存関係には注意が必要ですが、独立した作業であれば、柔軟に作業の順序を入れ替えることができます。
ユーザーストーリーはINVESTモデルに従って作成することを心がけます。 また、choreとバグは内容が様々となるため、わかりやすい内容で詳細に記載されていることを確認するようにします。優先順位付け
ユーザーの価値、ビジネスの価値、開発リスク、お互いの依存関係を考えて優先順位を決定します。 ユーザーストーリーのみではなくバグやchoreについても優先順位を判断してチームで合意して作業を進めます。
IPMで新たなストーリーを見積もった時、バグを検出した時、choreが追加された時、見込み通りに作業が進んでいない時、ユーザーから新たな学びを得た時、など様々なタイミングで作業順序が適切か確認し、優先順位の見直しを行います。
Developerはバックログの一番上（最優先のもの）から順に作業を進めることに集中します。ベロシティによる分析
ベロシティは直近の数イテレーションで完了したポイントの平均値を測ったものです。 イテレーション期間でチームがどのくらいのポイントのストーリーを開発してユーザーに価値を提供できるかを示す指標となります。
ベロシティを見て、作業が不足する心配がない程度（1〜2イテレーション分）に維持できるようストーリーの作成、イテレーションの計画を行います。
また、あるイテレーションで完了したポイントがベロシティと比べて大きな差異がある場合には原因を追究し、対処を行います。ユーザーに価値を提供し続けることが重要であるため、直接価値を提供する作業でないバグやchoreにはポイントを付けません。 （バグやchoreはある程度継続的で比較的変化のないコストであるという考えもあります）
バグやchoreがやむを得ず特定のイテレーションに集中してしまうような場合には、イテレーションを計画する時もベロシティを基準として作業進捗を確認する時も、バグやchoreにかかる時間を注視するようにします。ストーリーのグループ管理
大きな機能を複数のストーリーで実現する際、それらのストーリーをグループ（エピック）化します。 優先順位を決める時やリリースタイミングを計る時には、エピック単位で見えるようにすることで管理がしやすくなります。
作業状況の記録・可視化
バックログのどの作業を誰がいつ開始していつ終了したかを記録し、常にチームのメンバーやステークホルダーが見えるようにしておきます。 リアルタイムな情報を常に記録し見えるようにすることで、コミュニケーションを効率化し、状況の把握や分析を行うことができます。
リリース管理 #
プロダクトのゴールの達成のためにはユーザーにプロダクトを提供することが必要であり、また、ユーザーが使ってみて初めて適切な機能・デザインを上手く実現できたかが真にわかります。 プロダクトの方向性を継続的に検証しリスクを小さくできるように、ユーザーへの価値の提供とそれに対するフィードバックの受領というサイクルはできるだけ短くすることが望ましいです。
リリースの決定は、Product Managerが中心となってビジネスの観点でチームとして決めるべきであり、出すためのコストとリスクに照らして、提供できるユーザー価値を比較検討する必要があります。 リリースを決めるために以下の内容を確認するようにします。
機能の充足性
ユーザーのニーズを満たす、または、検証を行うのに十分な機能やデザインを実装できているか？
プロダクトの品質
ユーザーに提供するのに十分な品質を確保できているか？必須となる一連のストーリーを全て完了できているか？
ユーザーのニーズ
ユーザーが新しい機能・洗練された機能デザインをどの程度（市場の参入の必須条件など）必要としているか？
ユーザーの業務変更
新しい機能の提供によってユーザーの業務やシステムの変更が必要となる場合にユーザーが変更を受け入れる準備ができているか？
ステークホルダーのサポート
マーケティング、販売、顧客サービス、他のチームなどを含め提供機能をサポートする準備（問合せ対応やユーザーの参入手続きなど）ができているか？
他のチームのサービス変更
他のチームのサービスに依存している場合、それらの準備（I/Fや機能の追加変更など）が整っているか？
組織としてのリリース判断
組織においてリリースのための要件を充足できているか？必要な手続きを完了できているか？
リリースを頻繁に繰り返しできるようにするために、リリースのプロセス全体を、反復可能で、定期的で、成功し、信頼性が高く、費用対効果の高いものとなるようにすることが必要不可欠です。 プロダクトのリリース作業はDeveloperを中心に、ユーザー対応や手続きなどについてはProduct ManagerとDesignerがステークホルダーと協力して進めるようにし、リリースを繰り返すたびに学びを得て改善することを意識します。
情報共有 #
チームのメンバーや関係者と密にコミュニケーションを取って強い関係を築くことは、組織内でプロダクトを守り、トレードオフに向き合い、チームでの決定を行うのに効果的です。 Product Managerはプロダクトの関係者について誰がどのような情報に興味があるかを知り、お互いに情報を共有するようにしていきます。
コアチーム
同じ場所で働いて、ステークホルダーなどから、各メンバーが得た情報を素早く共有するようにします。 ただし、適切なタイミングか本当に必要な情報かを確認し、情報量の負荷からチームを守る必要があります。
Infraチーム
インフラ作業への影響があるかを確認できるよう、プロダクトの方向性や各機能のリリースタイミングを共有するようにします。 必要であれば、毎朝スタンドアップで一緒にタスクの状況の共有を行うなど、より技術的な内容を詳細に連携するためにDeveloperとInfraチームの担当者が密にコミュニケーションを取れるような環境や場を準備するようにします。
他のチーム
関連する機能への影響があるかを確認できるよう、プロダクトの方向性や各機能のリリースタイミングを共有するようにします。 関連度の強さや詳細の詰め具合に応じて、定期的な情報共有の場を準備したりします。
PMO
コアチームの活動の計画や状況を頻繁に共有し、必要な情報や協力を得られるようにします。 CLミーティングでイテレーション毎に状況を共有したりするようにします。
プロジェクト管理者
いかに最終的な収益を増やすか、実際にどの程度の収益を得られているか、ビジネス的な意義を確認してもらうために戦術目標とKPIとその経過状況を共有し、理解を得るようにします。 プロジェクトの区切りとしてInceptionやOutceptionを開催し、一定の間隔でコアチームから直接情報を共有し意見を伺う場を作ります。
営業
営業はユーザーにプロダクトの追加機能を説明をしたりユーザーが抱えている課題について会話したりします。 プロダクトの方向性と具体的なリリースする機能の内容と時期や、コアチームから直接ヒアリングを行っているユーザーについてはその会話の状況について共有しておく必要があります。 また、営業がユーザーから得た情報からコアチームが新たな学びを得ることもできます。 営業とコアチームで情報共有する場（営業確認会議）を作るようにします。
情報共有のポイント #
ストーリーを語る
エピソード、ユーザージャーニー、プロトタイプ、ビデオ、その多の成果物を使ってプロダクトのストーリーを伝えることで、リアルに感じ理解を得やすくなります。
全体像を説明する
ビジョン、戦略、ロードマップを共有し、アウトカムや成功指標を関係者全員が理解するよう促します。
信憑性を生み出す
論理、経験的なエビデンス、熱意をもって、ユーザーに価値を提供してビジネスの価値を生み出すことに集中していることを伝えるようにします。 また、DesignerとDeveloperがそれぞれデザイン上の決定と技術上の論拠を伝えるようにします。
聞き手にメッセージとコンテンツを合わせる
聞き手が何を知りたいかを理解し、意思決定をして行動をとるために必要な情報を重点的に共有します。
正直に話す
問題やリスクになるような情報でも、勇気をもって新しいデータとインサイトを伝え、計画の作成と見直しを促進します。
積極的に機会を得る
信頼関係を構築するためにも積極的にアップデートした情報を共有します。
よく耳を傾ける
自身から発信するのみではなく、他者から学ぶことに興味を持つようにします。 相手のことを理解することで強固な関係を築き、また、プロダクトを改善するための新しい洞察を得るのに役立ちます。