PdM(プロダクトマネージャー)のフリーランス案件の仕事内容|案件の種類と働き方
公開 2026-10-29 監修:株式会社エージェントベスト
フリーランスのPdM(プロダクトマネージャー)の仕事は、利用者と事業の情報を集めて「何を作り、何を作らないか」を決める材料をそろえ、開発とデザインに渡し、出した後に結果を確かめることです。業務委託では最終的な決定権を発注側に残したまま、この流れの一部または全部を任される形が多くなります。
同じPdMでも、案件の種類によって日々の仕事の比重はかなり違います。この記事では、案件の種類ごとの仕事の中心、1週間と1か月の流れ、関わる相手、作る成果物を整理します。報酬の決まり方はPdMの報酬の記事、求められるスキルはPdMのスキルの記事で解説しています。
案件の種類ごとの仕事の中心
案件の型の全体像はPdMがフリーランスになるにはで紹介しています。ここでは、それぞれの型で「実際に毎日何をしているか」に絞って見ていきます。
新規プロダクトの立ち上げ
まだ作るものが固まっていない段階です。仕事の多くは、作る前の確かめに使われます。
- 想定する利用者へのインタビューを設計し、話を聞き、記録を整理する
- 試作品や画面の案を見せて、反応を確かめる
- 最初に出す機能の範囲を絞り、開発の見積もりと突き合わせる
- 事業責任者に、続けるか・方向を変えるかの判断材料を出す
コードがまだ少ないため、エンジニアとの会話は「作れるか」「どこまで簡単に作れるか」が中心になります。
既存プロダクトの改善・グロース
利用者はいるものの、伸び方に課題がある段階です。数字を見る時間が増えます。
- 利用データを見て、離脱や伸び悩みの箇所を探す
- 改善の案を並べ、効果と開発の手間で優先順位をつける
- A/Bテストなどの検証を設計し、結果を読んで次の施策を決める
- 営業やカスタマーサポートに届いた要望を整理し、取り込むかを判断する
社内向け業務システムのプロダクト化
事業会社が自社の業務システムを、作って終わりではなく育てるプロダクトとして扱う案件です。
- 業務部門の担当者に作業の流れを聞き、困りごとを洗い出す
- 部門ごとに違う要望を並べ、全社として先にやることを決める
- 新しい画面や機能を、現場が使い始めるまで見届ける
利用者が社内にいるため、話を聞く機会は作りやすい一方、部門間の利害の調整に時間を使います。
PdM機能の立ち上げ・社員PdMの支援
社内にPdMの役割が根づいていない会社で、進め方を整える案件です。
- ロードマップやバックログの運用の型を作る
- 要望の受け付けから優先順位の決定までの流れを決める
- 社員のPdMと一緒に案件を回しながら、判断の仕方を引き継ぐ
自分が判断するより、判断できる仕組みと人を残すことが成果になります。
1週間の流れ(週5日の例・架空)
改善・グロースの案件に週5日で参画した場合の、1週間の例です。スプリント(短い開発の区切り)を2週間で回すチームを想定した架空の例で、実際の進め方は現場によって違います。
| 曜日 | 主な仕事 |
|---|---|
| 月 | 先週リリースした機能の利用状況を確認し、チームに共有する。今週の優先順位をエンジニアのリーダーとすり合わせる |
| 火 | 利用者インタビューを2件行い、要点を記録する。デザイナーと次の画面案を検討する |
| 水 | 次のスプリントで扱う機能の要求文書を書き、関係者のコメントを受け付ける |
| 木 | スプリントの計画会議で、作る範囲を決める。営業・サポートから届いた要望を整理する |
| 金 | 事業責任者との定例で、指標の動きと次の施策を報告し、判断を仰ぐ。判断の記録を更新する |
会議が多く見えますが、PdMの仕事の質を左右するのは会議の合間の「調べて考える時間」です。参画の初めに、どの会議に出て、どの会議は文書での共有で済ませるかをチームと決めておくと、考える時間を確保しやすくなります。
1か月の流れ
1か月の単位で見ると、PdMの仕事は次のような周期で回ります。
- スプリントごとの周期:作る範囲を決め、出来上がったものを確かめ、振り返る
- 月ごとの指標の確認:決めた指標の動きをまとめ、施策が効いたかを事業責任者に報告する
- ロードマップの見直し:月末や四半期の区切りで、先の計画を入れ替える。新しくわかったことを反映し、やめる施策も決める
- 調査の積み上げ:インタビューや問い合わせの記録を月ごとに見返し、繰り返し出る困りごとを探す
立ち上げの案件では、この周期がもっと短く、1〜2週間ごとに方向の見直しが入ることもあります。
関わる相手と、やり取りの中身
PdMは、立場の違う人の間に立つ仕事です。誰と何をやり取りするかを見ると、仕事の輪郭がつかみやすくなります。
| 相手 | 主なやり取り |
|---|---|
| エンジニア | 何をなぜ作るかの説明、実現の方法と手間の相談、優先順位のすり合わせ |
| デザイナー | 利用者の困りごとの共有、画面や体験の案の検討、テストの設計 |
| 事業責任者・経営層 | 目標と指標の合意、施策の報告、続ける・やめるの判断の材料出し |
| 営業・カスタマーサポート | 顧客の要望や問い合わせの受け取り、出す機能の説明 |
| データ分析の担当 | 指標の定義、集計の依頼、結果の読み方の確認 |
| 利用者・顧客 | インタビュー、テストへの参加の依頼 |
| 法務・セキュリティの担当 | 個人情報や規約に関わる機能の確認 |
外部から入るPdMは、このうち事業責任者と開発チームの両方から信頼を得る必要があります。片方とだけ近いと、「事業の要望を通すだけの人」か「開発の都合を代弁する人」に見えやすくなります。
作る成果物
PdMの成果物の多くは文書です。業務委託では、これらが「業務を行った」ことの記録にもなります。
- 要求文書(PRD):何を、誰のために、なぜ作るか。成功をどの指標で確かめるか
- ユーザーストーリー・受け入れ条件:開発が作るものを判断できる粒度に分けたもの
- ロードマップ:数か月先までに取り組む課題と順番
- 調査の記録:インタビューの要点、テストの結果、分かったことと分からなかったこと
- 指標の定義:何をどう数えるか。ダッシュボードの要件
- 判断の記録:何を、どの情報で、誰が決めたか。やめた施策とその理由
- リリースの説明:営業やサポート向けに、新しい機能の内容と狙いをまとめたもの
仕様書や調査資料の権利がどちらに帰属するかは、契約で決めておく点です。確かめ方はPdMの案件の選び方で整理しています。
業務委託ならではの働き方
業務委託のPdMは、社員のPdMと同じ会議に出て、同じツールを使うことが多くなります。ただし、雇用ではないため、働き方の前提が違います。
- 決定権の範囲:最終判断は発注側の責任者が持ち、PdMは提案と材料づくりを担う形が多い。どこまで自分で決めてよいかは案件ごとに違う
- 指示の受け方:業務委託では、発注側から勤務時間や作業の手順を細かく指示される形は、雇用に近い働き方として問題になることがあります。線引きは偽装請負の記事をご覧ください
- 契約の形:PdMの業務は、成果物の完成ではなく業務の遂行に報酬が払われる準委任で結ばれることが多い。違いは準委任と請負の違いで解説しています
- 引き継ぎ:契約が終われば抜ける前提なので、判断の記録と文書を、自分がいなくても読める形で残すことが仕事の一部になる
週2〜3日の案件では、上で見た仕事のうち任される部分が絞られます。どう絞られるかはPdMの週2〜3日・副業案件の記事で解説しています。
よくある質問
フリーランスのPdMは、仕様書を書くことが仕事の中心ですか?
案件によります。要求文書や仕様の作成が中心の案件もあれば、指標の分析や優先順位の決定、事業責任者への報告に多くの時間を使う案件もあります。募集の説明だけでは分かりにくいため、1週間の時間の使い方を面談で確かめておくと、参画後の食い違いを避けやすくなります。
PdMは開発チームの進捗管理もするのですか?
進捗の管理はPMやスクラムマスターが担うことが多いものの、小さなチームではPdMが兼ねる場合もあります。兼ねると、何を作るかを考える時間が削られやすくなります。どちらの役割を求められているかは、契約前に確かめておきましょう。PMとの違いはPdMのスキルの記事のよくある質問でも触れています。
ユーザーインタビューはPdMが自分で行うのですか?
自分で設計して話を聞く案件が多く見られます。社内にリサーチの担当やデザイナーがいる場合は、一緒に進めて、PdMは問いの設計と結果を判断に結びつける部分を担うこともあります。利用者に直接会えるかどうかは、仕事の進め方を大きく左右するため、参画前に聞いておきたい点です。