コトラ（広報チーム） 
PdMは、プロダクトマネージャーの略称です。ユーザーにどのような価値を届けるかを考え、開発・デザイン・営業・サポートなどの関係者と連携しながら、プロダクトを成長させます。
ただし、PdMの仕事は企業やプロダクトの状況によって大きく異なります。会議中心の日もあれば、データ分析や企画書の作成に集中する日もあります。予定どおりに進まないことも多く、優先順位を見直しながら判断を続ける点が特徴です。
本記事では、一般的なPdMの1日の流れを例に、会議、分析、開発調整の実態を解説します。
PdMの役割と1日の業務が決まる要因
プロダクトの課題を見つけて優先順位を決める役割
PdMの中心的な役割は、ユーザーや事業の課題を見つけ、何を作るべきかを決めることです。新機能の企画だけでなく、既存機能の使いにくさの改善、解約につながる課題への対応、品質や安定性を高めるための改善も対象になります。
すべての要望を同時に実現することはできません。そのためPdMは、ユーザーへの影響、事業への効果、開発にかかる時間、実現の難しさなどを比較し、優先順位をつけます。
優先順位を決める際は、単に要望の数や発言者の立場だけで判断しないことが重要です。プロダクトの目標や提供価値に照らし、今取り組むべき課題を選びます。
開発・デザイン・営業などをつなぐ役割
PdMは、開発チームだけで完結する仕事ではありません。エンジニアやデザイナーには実装したい価値や背景を伝え、営業やサポート部門からは顧客の要望や失注・解約の理由を集めます。
たとえば、営業部門から特定の機能を求める声が上がった場合でも、そのまま開発に渡すわけではありません。どの顧客が、どの業務で、何に困っているのかを確認し、共通する課題として整理する必要があります。
PdMは、異なる立場の意見を集め、プロダクトとして一貫した判断にまとめる役割を担います。
開発段階や組織の規模で変わる業務の比重
立ち上げ直後のプロダクトでは、ユーザーの課題を探るための調査や仮説検証の比重が大きくなります。限られた機能で価値を確かめるため、インタビュー、試作品の確認、早期の利用データ分析などが中心になります。
利用者が増えたプロダクトでは、改善要望の整理、利用状況の分析、開発計画の調整、部門間の連携に時間を使う傾向があります。利用者や関係者が増えるほど、調整や意思決定に必要な情報も増えるためです。
また、小規模な組織ではPdMが企画、進行管理、営業支援まで幅広く担うことがあります。一方で組織が大きくなると、進行管理、販売戦略、ユーザー調査などを専門担当と分担するケースもあります。
毎日の予定どおりに進まない理由
PdMの予定は、急な仕様確認、不具合対応、顧客からの重要な要望、経営判断が必要な課題などによって変わります。開発中に技術的な制約が見つかり、当初の仕様を見直すこともあります。
そのため、PdMの1日は予定表どおりに進むとは限りません。大切なのは、予定を守ること自体ではなく、変化が起きたときに優先順位を見直し、チームが止まらないように判断することです。
PdMの1日の流れの例
始業後に確認する利用状況・開発状況・連絡事項
始業後は、前日からの変化を把握する時間です。利用状況を示す数値、問い合わせ、不具合報告、開発チームからの連絡、関係者からの依頼などを確認します。
確認する内容はプロダクトによって異なりますが、主に以下のような情報を見ます。
- 主要な利用指標の変化
- エラーや障害の発生状況
- 問い合わせや要望の内容
- 開発中の機能で発生している課題
- 当日中に対応が必要な連絡
すべての連絡にすぐ対応すると、重要な仕事に時間を使えなくなります。緊急度と重要度を分け、すぐに対応するもの、会議で確認するもの、後で整理するものに分けることが必要です。
午前に行うチーム内の会議と意思決定
午前は、開発チームとの進捗確認や仕様の相談を行うことが多い時間帯です。短時間の定例会では、進んだこと、次に進めること、困っていることを共有します。
PdMは、単に進捗を聞くだけではなく、判断が必要な論点を明確にします。たとえば、仕様の解釈が分かれている場合は、ユーザーに提供したい価値に立ち返って決めます。
会議の目的は情報共有ではなく、次の行動を決めることです。誰が何をいつまでに行うのかを確認して終えることで、会議後の手戻りを減らせます。
会議の合間に進める企画書作成と仕様の整理
会議と会議の間には、企画書、要求仕様書、画面案、開発チームへの説明資料などを作成・更新します。PdMの仕事では、考えた内容を他の人が判断・実装できる形にする作業が欠かせません。
仕様を整理する際は、機能の説明だけでなく、なぜ必要なのか、誰のどの課題を解決するのか、成功を何で測るのかを明確にします。背景が共有されていれば、開発途中に細かな判断が必要になった場合も、チームが目的に沿って判断しやすくなります。
午後に行う利用者分析と関係者との調整
午後は、利用データの分析、ユーザーへのヒアリング、営業やサポート部門との打ち合わせなどを行うことがあります。会議で集めた情報をもとに、要望の背景や課題の大きさを確認します。
分析では、数値だけで結論を急がないことが重要です。利用数が低い理由が、機能を知られていないためなのか、使い方が分かりにくいためなのか、そもそも必要とされていないためなのかを見極める必要があります。
数値による事実と、問い合わせやインタビューで得た声を組み合わせることで、改善すべき課題の解像度が高まります。
終業前に行う進捗確認と翌日の優先順位付け
終業前には、その日に決まったこと、残った課題、関係者への依頼事項を整理します。翌日に取り組むべきことを明確にしておくと、始業後に連絡対応だけで時間を消費しにくくなります。
特に、判断待ちの項目や確認期限がある項目は見落としやすいため、記録を残すことが重要です。PdMは複数のテーマを並行して扱うため、頭の中だけで管理せず、決定事項と次の行動を残す習慣が必要です。
PdMが出席する主な会議と目的
開発チームとの進捗確認会議
開発チームとの進捗確認会議では、作業の進み具合だけでなく、予定に影響する問題を早期に見つけます。技術的な制約、見積もりとの差、仕様上の不明点などを共有し、必要な対応を決めます。
PdMは開発の細かな作業をすべて管理する立場ではない場合もありますが、プロダクトとしての優先順位や仕様の判断を行うため、進捗とリスクを把握しておく必要があります。
仕様を決めるための企画・設計の打ち合わせ
企画・設計の打ち合わせでは、PdM、エンジニア、デザイナーなどが集まり、実現したい価値を具体的な体験や機能に落とし込みます。
この場では、画面の見た目だけでなく、利用者がどのような流れで操作するか、例外的な操作が起きた場合にどうするか、実装上の制約はあるかなどを検討します。
仕様を細かく決めることが目的ではありません。ユーザーに必要な価値を、無理なく実装できる範囲で届けることが目的です。
営業・サポート部門から要望を集める会議
営業やサポート部門は、顧客の声を日常的に受け取っています。PdMは定期的に情報を集め、失注、解約、問い合わせ、利用時のつまずきなどを確認します。
ただし、個別顧客の要望をそのまま開発計画に入れると、プロダクト全体の方向性がぶれやすくなります。要望の件数、対象となる顧客層、課題の共通性、事業への影響を整理し、取り組むべき課題に変換する必要があります。
経営層や責任者に判断を求める報告会
大きな投資、方針変更、優先順位の見直しなどは、PdMだけで決められないことがあります。その場合は、経営層や事業責任者に判断を求めます。
報告では、情報を多く並べるよりも、何を決めてほしいのかを明確にすることが重要です。選択肢、それぞれの効果とリスク、判断を急ぐ理由を整理して伝えると、意思決定が進みやすくなります。
会議を増やしすぎないための進め方
会議が増えすぎると、分析や企画を深める時間が失われます。会議の前に目的、参加者、決めることを明確にし、共有だけで済む内容は文書やチャットで済ませる工夫が必要です。
また、同じ論点を何度も話し合わないために、決定事項と保留事項を記録します。会議の回数を減らすことが目的ではなく、必要な会話に時間を使える状態をつくることが重要です。
会議以外にPdMが行う分析と企画業務
利用者の行動データから課題を探す
PdMは、利用者がどの機能を使っているか、どの段階で離脱しているか、継続して利用しているかなどを確認します。データを通じて、利用者が言葉にしていない課題を見つけられる場合があります。
たとえば、新機能の利用率が低い場合、機能そのものに価値がないとは限りません。機能の存在に気づかれていない、利用開始までの手順が多い、対象となる利用者が限られているといった原因も考えられます。
数値を確認する際は、変化の事実と原因の仮説を分けて考えることが重要です。
問い合わせやインタビューから要望を整理する
問い合わせには、利用者が困っている場面が具体的に表れます。同じ内容の問い合わせが繰り返されている場合、説明不足ではなく、プロダクトの設計に課題がある可能性があります。
インタビューでは、利用者が何を要望しているかだけでなく、なぜその要望が出たのかを聞くことが大切です。要望された機能を作ることが最適とは限らず、背景にある業務や不満を理解することで、よりよい解決策を考えられます。
競合や市場の変化を確認する
PdMは、自社プロダクトだけでなく、競合サービスや市場の変化も確認します。競合が新機能を出したからといって、同じものを急いで作る必要はありません。
重要なのは、自社の利用者にとってその変化がどの程度重要か、自社がどのような価値で選ばれているかを考えることです。競合の動きは判断材料の一つであり、開発テーマを決める唯一の基準ではありません。
改善案の効果と優先順位を検討する
改善案を比較する際は、期待できる効果、対象となる利用者、実現の確実性、開発にかかる負担を整理します。評価の基準を共有しておくと、関係者との議論が個人の感覚や立場に左右されにくくなります。
優先順位を決めるための方法に絶対的な正解はありません。重要なのは、プロダクトの目標と利用者の価値に沿った基準を持ち、判断理由を説明できる状態にすることです。
開発チームが実装できる形に要件をまとめる
企画を開発に渡す際は、アイデアだけでは不十分です。誰のどの課題を解決するのか、利用者が何をできるようになるのか、満たすべき条件は何かを整理します。
要件には、通常の利用手順だけでなく、入力漏れ、権限の違い、エラー時の対応なども含まれます。ただし、最初からすべてを作り込もうとすると開発が遅くなります。まず届けるべき価値を明確にし、後から改善できる部分は段階的に進める考え方も必要です。
開発調整で起こりやすい課題と対応
仕様変更と追加要望への対応
開発中に仕様変更や追加要望が発生することは珍しくありません。問題は変更そのものではなく、背景や影響を確認しないまま追加することです。
追加要望を受けた際は、なぜ今必要なのか、既存の目的にどう関係するか、納期や品質にどのような影響があるかを確認します。今入れるべきものと、次の改善候補として扱うものを分ける必要があります。
納期・品質・開発工数のバランス調整
短い期間で多くの機能を作ろうとすると、品質の低下やチームの負荷増加につながります。PdMは、納期、品質、開発に必要な時間の間で現実的な判断を行います。
期限を優先する場合は、機能を絞り込み、最初に必要な範囲だけを提供する方法があります。一方で、品質や安全性に関わる項目は安易に削れません。何を削り、何を守るかを関係者と合意することが重要です。
関係者ごとに異なる意見をまとめる方法
営業は受注につながる機能を求め、サポートは問い合わせを減らす改善を求め、開発は保守しやすい設計を重視することがあります。それぞれの意見には理由があり、単純にどちらかを優先すればよいわけではありません。
PdMは、意見の対立を調整する際に、プロダクトの目標、対象となる利用者、期待する成果に立ち返ります。判断の基準を共有することで、個人や部門の都合ではなく、プロダクトの価値を軸に議論しやすくなります。
開発中に見つかった問題への優先順位付け
開発中には、不具合、性能の問題、仕様漏れ、技術的な課題などが見つかります。すべてをすぐに解決しようとすると、予定していた価値提供が遅れる可能性があります。
利用者への影響の大きさ、発生頻度、回避方法の有無、今後の開発への影響を確認し、対応順を決めます。特に、利用できない状態につながる問題や、信頼性を大きく損なう問題は優先度を高く扱う必要があります。
決めるべきことを先送りにしない工夫
仕様や優先順位の判断を先送りにすると、開発チームは待ち状態になり、後から手戻りが発生しやすくなります。PdMは、いつまでに何を決める必要があるかを把握しておくことが重要です。
情報が不足していて決められない場合でも、必要な調査、相談相手、判断期限を明確にします。完全な情報を待ち続けるのではなく、現時点での仮説とリスクを共有しながら前に進める姿勢が求められます。
PdMの理想と現実を両立させる時間の使い方
割り込み業務に備えて予定に余白をつくる
PdMには、急な相談や障害対応、意思決定の依頼が入りやすい仕事です。予定を隙間なく埋めると、割り込みが発生した時点で重要な業務が後ろ倒しになります。
会議や対応業務だけで予定を埋めず、調査、企画、考える時間の余白を確保することが重要です。余白は無駄な時間ではなく、変化に対応するための時間です。
会議の目的と決定事項を明確にする
会議の前に、共有が目的なのか、相談が目的なのか、意思決定が目的なのかを明確にします。目的が曖昧な会議は、参加者が増えやすく、結論も出にくくなります。
会議後には、決まったこと、担当者、期限、保留になったことを残します。これにより、同じ確認を繰り返す時間を減らし、次の行動につなげられます。
分析・企画に集中する時間を確保する
会議や連絡対応が増えるほど、PdMは目の前の調整に追われやすくなります。しかし、利用者の課題を深く考えることや、次の改善を企画することもPdMの重要な仕事です。
集中が必要な業務は、会議の少ない時間帯に予定として確保します。通知を止める、短時間でもまとまった作業時間をつくるなど、自分で集中できる環境を整えることが必要です。
判断基準を共有して調整の負担を減らす
優先順位の基準がPdMの頭の中にしかないと、要望が来るたびに個別の説明や調整が必要になります。プロダクトの目標、重視する指標、優先順位の考え方を共有しておくと、関係者も判断の背景を理解しやすくなります。
判断基準を共有することは、PdMが一人で抱え込まないためにも有効です。チームが共通の目的を理解していれば、日々の細かな判断をより自律的に進められます。
1日の振り返りで次の行動を改善する
終業前に短時間でも振り返りを行うと、仕事の進め方を改善しやすくなります。予定外の対応に時間を使った理由、後回しになった重要業務、繰り返し発生している確認作業などを見直します。
PdMの仕事では、すべてを予定どおりに終えることよりも、限られた時間で重要な判断に集中できる状態をつくることが大切です。日々の振り返りを通じて、会議の進め方、情報共有の方法、優先順位の付け方を少しずつ改善していきます。
