はじめに

ウォンテッドリーでプロダクトマネージャー（以下、PdM）をしているueyamaです。Wantedly Visitのプロダクト改善に日々取り組んでいます。

施策の企画・推進を担うPdMというポジション

「ウォンテッドリーのPdMって、実際どんなことをしているの？」という質問を受けることがあります。

PdMの役割について、私たち自身も以前は悩んでいました。一般的なプロダクトマネージャーは、プロダクト全体の戦略策定から施策の実行まで幅広く担うイメージがあるかもしれません。しかしウォンテッドリーでは、「適材適所」や「最適挑戦」といった考えから、PdMの中でもプロダクト全体の戦略や方向性を策定するポジションと、具体的な施策の企画・推進を担うポジションを分け、それぞれが自身の領域に集中できるような体制をとっています。

私はこのうち、後者にあたる”具体的な施策の企画・推進を担うポジション”で、toB向けプロダクトのグロースチーム（Client Growth Squad）に所属しています。

本来はこの切り分けによってポジションごとの役割が明確になるはずでしたが、実際に施策の企画・推進を進めていく中で、気づけば本来の役割以外のタスクも抱え、ウォンテッドリーのPdMとしてどこに注力すべきか迷うことも多くありました。こうした課題感から、Client Growth Squadでは「このままで本当に良いのか」という思いをきっかけに、ワークフローの見直しに着手しました。

この記事では、Client Growth Squadが取り組んだワークフロー改善と、その中で見えてきた企画立案と推進を行うPdMの役割についてご紹介します。

読んでほしい人

• ウォンテッドリーのPdMのお仕事に興味がある方
• プロダクトマネージャーの仕事に興味がある方
• すでにプロダクトマネージャーとして働いている方
• チームでのプロダクト開発に携わっている人

チームが直面していた3つの根本的な課題とその原因

私たちは、PdMの抱える課題をはじめ、チーム全体で直面していた問題とその背景にある原因を整理しました。その結果、次の3つの課題が見えてきました。

1. 本来やるべき施策立案に時間を割けない

まず1つ目は、PdMが本来注力すべき施策の企画・立案に十分な時間を割けていなかったことです。従来のワークフローでは、職種ごとの役割を厳密に分けず、メンバーが職種の枠を超えて柔軟に動ける体制をとっていました。この柔軟性はチームの強みでもありましたが、その一方でPdMがプロジェクト進行やタスクアサイン、QAテストなど本来の業務以外のタスクも多く担うことになり、結果として企画作成に十分な時間を確保しづらい状況が生まれていました。

2. ステークホルダーとの認識のズレで手戻りが頻発

施策を進めるチームとステークホルダーとの認識のズレによる手戻りが発生していました。これは、プロダクトオーナーやビジネスメンバーなどのステークホルダーと十分なコミュニケーションが取れておらず、情報共有が不十分だったことが主な原因です。その結果、ステークホルダーの期待と実際の開発内容にズレが生じ、開発が進んでから手戻りや仕様変更が発生し、双方に不要なコストや負荷がかかっていました。

3. 施策の進捗状況が見えず確認作業が増加

3つ目の課題は、施策の進捗状況が見えづらく、確認作業が増加していたことです。以前のワークフローでは、企画ごとの状態や要件レベルでの検討事項が明確に管理されていなかったため、バックログに積まれたまま進捗が分からない状況が発生していました。このことが、開発リソースがあってもすぐに着手できない、あるいはチーム内外で施策の状況を確認する作業が増える、といった問題につながっていました。

Client Growthの新しいワークフローの設計と導入

課題を洗い出した上で、私たちは「なぜPdMが本来の業務以外にも多くのタスクを抱えてしまうのか」「なぜステークホルダーとの認識齟齬が生まれるのか」「なぜ進捗や状態が見えづらいのか」といった点をさらに深掘りしていきました。現状の進め方を振り返り、実際のプロジェクトの流れやコミュニケーションのタイミング、役割分担の曖昧さなどを具体的に棚卸しした結果、共通して「プロセスの抽象度が高く、誰がいつ何を担当するのかがはっきりしていない」ことが根本的な原因であることがわかってきました。

この気づきをもとに、チームリーダーが中心となり、会議体や管理ツールの見直しなどの表面的な解決策ではなく、根本的な課題解決に向けてワークフローの改善を実施しました。

新しいワークフローのポイント

新しいワークフローでは、まず「戦略の策定」から「施策評価」まで、各フェーズごとにやるべきことや目的を明確に定めました。「企画検討」フェーズでは施策の目的・背景（Why）と何をやるのか（What）を設定し、続く「仕様検討」フェーズでは、その目的を達成するための解決策の検討や、具体的な仕様・プロトタイプの作成（How）を行います。その後、優先度付けをした上で「開発」フェーズに進みます。リリース前には準備や社内外への周知を行い、最後に施策の効果測定と分析を実施して「施策評価」を行う、という流れです。

さらに、各フェーズの区切りごとに承認フローを設けることで、手戻りを最小限に抑え、ステークホルダーも安心してプロジェクトを見守れるようにしています。これにより品質も担保しやすくなっています。

承認フローはPdMの間で柔軟に運用しており、「承認待ちでプロジェクトが止まる」といったことはありません。状況に応じて承認の役割を移譲したり、形式的な承認ではなく「確認」に近い形で進めることで、スピード感を損なわずに進行できています。

また、PdM、デザイナー、エンジニアといった職種ごとに担うべき役割も明確にしました。PdMは企画の立案・推進やステークホルダーとの調整を主に担当し、デザイナーは仕様検討段階でのプロトタイプ作成やUIデザイン、エンジニアは技術的な検討や実装、品質担保を担います。

ただし、役割を明確にしつつも、実際の現場ではエンジニアが仕様やUIの提案を行ったり、PdMやデザイナーが技術的な観点から議論に参加したりと、職種の枠を越えて協力しあう場面も多くあります。役割分担を固定しすぎず、必要に応じて柔軟に他の領域にも染み出していくことで、最も早く・最適な方法でプロジェクトを進められる体制になっています。

各フェーズでのPdMの具体的な役割

ここからは、新しいワークフローによって明確になったPdMの役割を、各フェーズごとにご紹介します。

戦略策定：エピック（施策方針）の作成

POと戦略策定の役割を担うPdMが全体戦略を策定した後、すぐに具体的な企画立案へ進むことはほとんどありません。その間をつなぐ役割として、エピック（施策方針）を作成し、注力すべき領域を明確にしたうえで、次のフェーズで検討すべき企画の方向性を整理します。

エピックを作成する際は、POやPdM間で十分に対話を重ね、全体戦略への納得感を持つことが重要です。さらに、施策を通じて得られた知見やナレッジを共有し、全体戦略やエピックの継続的な見直しにつなげていきます。

企画検討：企画書の作成

このフェーズでは、エピックをもとに具体的な企画書を作成します。企画書の作成にあたっては、Why（なぜやるのか）/ What（何をやるのか）/ How（どうやるのか）のフレームワークを活用し、施策の目的や背景、解決したい課題、満たすべき要求を整理します。

企画書を書く際は、「誰が読むのか」「どこが論点になりそうか」といった観点を意識し、単に情報を網羅するだけでなく、読み手にとって分かりやすく伝わる内容にすることを重視しています。フォーマットに沿って情報を埋めることよりも、関係者が納得しやすく議論しやすい企画書となるよう心がけています。

仕様検討：外部仕様・プロトタイプの作成

このフェーズでは、企画書をもとにどのような解決策（How）が最適かを具体化します。デザイナーと協力しながら、外部仕様やプロトタイプを作成し、ユーザーの利用シーンやユースケースを整理しつつ、要件を明確にしていきます。

また、不明点や技術的な不確実性がある場合は、早い段階でエンジニアに調査や技術検証を依頼し、リスクを低減します。こうしたプロセスを通じて関係者間で認識を揃え、次の開発フェーズにスムーズに移行できる状態を整えます。

開発：品質担保とチームサポートに専念

開発フェーズでは、主に品質担保とチームサポートに注力します。開発が始まると、エンジニアが内部仕様を詰めていく過程で新たな論点や仕様の調整が発生することが多く、PdMはその都度、要件やユーザー視点を踏まえた意思決定や調整を行います。また、開発中に発生する仕様変更や追加要件についても、関係者と連携しながら迅速に判断し、開発の停滞を防ぎます。

さらに、全体の品質が担保されているかをチェックし、必要に応じてQA観点でのレビューや、ユーザー体験の最終確認も行います。なお、進行管理やタスク管理などのプロジェクトマネジメントはPdMでは行わず、主に開発チーム内で担当していますが、必要に応じてサポートするケースもあります。

リリース：社内外へのリリース周知

リリースフェーズでは、Product Marketing Manager（以下、PMM）チームと連携しながら、リリース準備や社内外への情報発信を行います。ユーザーへの影響を最小限に抑えるための調整や、リリース後のサポート体制の構築もこのタイミングで実施します。

また、リリース直前には万が一のトラブル発生時にも迅速に対応できるよう、開発・ビジネス・サポートチームとの連携体制を整えます。特に、開発メンバー以外は新機能の詳細を把握していないことが多いため、ビジネスチームへの丁寧な周知・説明に注力し、現場での混乱を防ぐことを重視しています。

施策評価：定量・定性データによる効果測定と次施策への活用

このフェーズでは、リリースした施策がユーザー課題の解決やKPIへの貢献につながったかどうかを、定量データ・定性データの両面から効果測定します。施策を通じて得られた知見やナレッジはPOやPdM間でも共有し、今後の全体戦略やエピックの見直し、次の施策立案に活かしていきます。

また、施策の内容や目的に応じて適切な分析手法を選択しています。たとえば、UI改善や軽微な調整などは短期的な定量分析だけでは効果を判断しづらいため、長期的なモニタリングやユーザーアンケートなどの定性評価も組み合わせて総合的に判断しています。

ワークフロー設計がもたらしたチームの変化

ワークフローを導入したことで、以下のような変化が生まれました。

まず、PdMやチームメンバーの業務内容が可視化され、誰がどのフェーズで何を担っているのかが明確になりました。その結果、PdMが本来注力すべき施策の立案や仕様検討、そのためのユーザー理解に十分な時間を割けるようになりました。

役割が整理されたことで、チームメンバーやステークホルダーとの連携もスムーズになりました。これにより、誰に何を相談・依頼すればよいかが明確になり、コミュニケーションの齟齬や手戻りが減少しました。各自が自分の強みを活かしやすい環境が整いました。

さらに、ワークフローの各フェーズを明確に区切ったことで、チーム全体の進捗や課題が把握しやすくなり、プロジェクトの透明性が向上しました。承認フローも「止める」ためのものではなく、安心して次のステップに進むための「確認」として機能し、心理的な安全性や品質担保にもつながっています。

今後は、こうしたワークフローをさらに最適化し、他チームへの展開にも取り組んでいきます。

まとめ

この経験を通じて、プロダクト改善のワークフロー設計の重要性を理解することができました。単に「やれる人がやる」ではなく、明確なフェーズと役割分担を設けることで、チーム全体の生産性と品質が向上しました。特に、PdMが企画立案やユーザー理解に時間を割けるようになったことが、最も大きな成果です。

最後までお読みいただきありがとうございました。この記事が、プロダクト開発に携わる方々の参考になれば幸いです。今後もより良いプロダクトづくりに向けて、チーム一丸となって取り組んでいきます。