はじめに
私たちは、従業員数7,000名を超える人材会社に所属し、ダイレクトリクルーティングサービス「doda ダイレクト」のプロダクト開発を担当しています。
私たちのチームでは、ユーザーへの価値提供スピードを重視してスクラム開発を導入していましたが、「早くリリースすること」を意識するあまり、施策は「すでに決まった仕様」としてチームに共有され、そこからの改善提案は限定的な調整にとどまっていました。
その結果、実装段階で発覚する「技術的により良い実現方法」や「ユーザーにとってより直感的なUI/UX」といった貴重な気づきをプロダクトに反映しきれず、手戻りや機会損失が発生していました。
本記事では、そんな「スピードは出ているが、価値の最大化がしづらい」というジレンマを、PRD（プロダクト要求仕様書）を導入することでどう乗り越えていったのか、その具体的なプロセスと、得られた学びを共有します。
課題・背景
表面上は機能していた「パワポ企画書」プロセス
PRD導入以前（2024年7月以前）、私たちのチームでは施策立案にPowerPointの企画書を用いていました。
企画書はユーザーストーリー形式で書かれており、施策の概要自体は把握しやすいという利点がありました。しかし、その内容は作成者であるPdMのスキルに大きく依存しており、なぜそのストーリーに至ったのかという背景や、定性・定量の裏付けが十分に記載されているかは作成者によってまちまちな状態でした。
開発チームやデザイナーとの連携も、体系的なプロセスがなかったため、PdM個人の動きに依存していました。 部分的な相談はあっても、企画の全体像や「なぜやるのか」という最も重要な点がチームの共通認識となる前に、企画書だけが完成していく状態でした。
一見すると、このプロセスは機能しているように見えましたが、水面下ではいくつかの問題を抱えていました。
プロセスが引き起こしていた2つの問題
この「PdMが企画を固めて、終盤でチームに共有する」という進め方は、プロダクトとチームの両方に大きな歪みを生んでいました。
1. プロダクトの一貫性の欠如
各施策の背景にある思考プロセスが標準化されていなかったため、場当たり的な意思決定が増え、プロダクト全体で一貫性のない機能が乱立する事態を招きました。
「なぜこの仕様になったのか、誰も説明できない機能」が生まれ、こうした積み重ねが、プロダクトの一貫性を損ない、使いにくい機能を生み出す温床となっていました。
2. チームの受動的な姿勢
仕様がほぼ固まった段階で情報が共有されるため、エンジニアやデザイナーは「どう作るか（How）」にしか関わることができません。本来であればもっと早い段階で発見できたはずの技術的な懸念や、より良いUI/UXのアイデアを提案する機会は失われていました。
その結果、PdMへの仕様に関する細かな質問が日に日に増加し、PdMがボトルネック化。チーム全体には「仕様は決まったもの」という空気が生まれ、次第に受動的な姿勢を助長する環境となっていました。
変化のきっかけ
私たちは、こうした課題を認識しつつも、日々の業務の中で抜本的な改善に着手できずにいました。
そんな中、大きな転機が訪れます。プロダクト組織に新たな責任者が着任し、トップダウンで組織とプロダクトの改革を進める、という明確なメッセージと戦略が示されたのです。
これにより、私たちが長年抱えてきた構造的な課題に、正面から向き合うチャンスが生まれ、私たちは「なぜ作るのか」から全員で対話できる、新しいプロダクト開発の進め方を模索し始めました。
参照リンク：法人向けプロダクトのテクノロジー責任者が語る――プロダクト戦略とPdM - techtekt
具体的な取り組み
前章で述べた課題を乗り越え、「なぜ作るのか」からチームで対話できる文化を育むために、私たちは具体的な4つのアクションプランを立て、実行していきました。
1. ゴール設定：三位一体を実現する「共通言語」としてのPRD
まず私たちが目指したのは、プロダクト開発における「三位一体（PdM、デザイナー、エンジニア）での施策立案」という方針を、単なるスローガンで終わらせないことでした。
そのために、PRDを職種間のコミュニケーションを円滑にするための「共通言語」と位置づけました。PdMが一人で完成させる「指示書」ではなく、三位一体で議論し、育てていくための「たたき台」として活用することを最初のゴールとして定めました。
2. 環境整備：Confluence導入による「知の集約」
次に、物理的なドキュメントの分断を解消することから着手しました。
以前は、施策立案中の企画書は「PdM組織のSharePoint」に、開発着手後のドキュメントは「スクラムチームのSharePoint」に格納されるという二重管理状態でした。バージョン管理も、担当者がファイルをコピーしてファイル名を変えるといった属人的な運用で、最新のドキュメントがどれか分からない、似たようなファイルが乱立するというカオスな状況でした。
そこで私たちは、ドキュメントツールとしてConfluenceを導入。すべてのPRDをそこに集約し、誰もが最新の情報にアクセスできる「信頼できる唯一の情報源」としての一元管理を徹底しました。
3. プロセス標準化：誰でも品質を保てる「ディスカバリーフロー」の作成
ツールの導入と同時に、思考のプロセスそのものの標準化にも取り組みました。
私たちは、プロダクト開発における仮説検証のプロセスを「ディスカバリーフロー」として可視化したフロー図を作成しました。
これにより、在籍年数や経験に関わらず、フローに沿ってPRDを作成していけば、思考の質とドキュメントの品質が一定に保たれる仕組みを整えました。これは、かつての「作成者によって品質がバラバラ」だった課題への直接的なアプローチでした。
4. 浸透と改善：チームの反発を乗り越えた「対話」と「学習」
もちろん、こうした新しいルールやプロセスは、すぐには受け入れられませんでした。
一部のメンバーからは「書くのが面倒」「時間がかかる」「今までと何が違うの？」といった、もっともな反発や戸惑いの声が上がりました。
私たちは、これらの声を無視せず、むしろ改善のチャンスと捉えました。 まず、そうした意見をくれたメンバーに真摯に向き合い、何が負担になっているのかをヒアリングしました。実際に運用してみて分かった課題も考慮しながら、PRDのテンプレートを複数回にわたって改善し、より実用的な形へと磨き上げていきました。
さらに、経験豊富なPdMが講師役となり、PRDの書き方やその意義についての勉強会を主催。ツールやテンプレートを渡すだけでなく、その背景にある思想やスキルセットをチーム全体で学ぶ機会を設け、組織全体のレベルアップを図りました。PRDのテンプレート（目次）は以下になります。
[PRDの目次]
1 施策実施サマリー
1.1 概要（What is it?｜どういうものか）
1.2 背景（Why build it?｜なぜ創るか）
1.2.1 どの戦略・方向性に紐づいて実施するか？（なぜ今やるのか）
1.2.2 本 PRD で解決する課題
1.2.3 フェーズ展望（任意）
1.2.4 データやインタビュー結果（任意）
1.2.4.1 インタビュー
1.2.4.2 考慮した VOC
1.2.4.3 定量データ分析
1.3 顧客（Who's it for?｜誰のためにあるか）
1.3.1 ターゲットユーザーセグメント
1.4 ユーザーストーリー
1.4.1 ユーザーストーリーマッピング上の位置付け
1.5 期待されるアウトカム（ゴール）
1.5.1 検証目的・観点
1.5.2 定量アウトカム
1.5.3 定性アウトカム
1.5.4 ガードレールメトリクス
2 施策に関する詳細情報
2.1.1 検討したソリューション案
2.1.2 競合分析
2.2 スコープイン・アウト
2.3 要求情報まとめ
2.3.1 画面・機能（分析）要求
2.3.2 デザイン要求
2.3.3 シーケンス（任意）
2.3.4 要求漏れチェックシート
2.4 施策開発を円滑に進めるために
2.4.1 ステークホルダー一覧
2.4.2 スケジュール
2.4.3 影響事前調査
2.4.3.1 dodaX 会員への機能提供
2.4.3.2 法務確認
2.4.3.3 情報セキュリティ確認
2.4.3.4 広報（AB テストなし）
2.4.3.5 広報（AB テストあり）
2.4.4 リスク一覧
2.4.5 撤退ライン
3 振り返り・検証結果報告
3.1 サマリ
3.2 振り返り
3.2.1 定量アウトカム
3.2.2 定性アウトカム
3.2.3 投資効果 (ROI)
3.3 考察
3.4 NA 決定
結果・学び
取り組みがもたらした、確かな成果
この一連の取り組みは、チームとプロダクトに明確でポジティブな変化をもたらしました。
最も大きな成果の一つは、施策の立案からデプロイまでのリードタイムが短縮された（約116%改善）ことです。これは、デザイナーが早期から関わることでUIの品質が向上し、エンジニアも実現可能性などのリスクを早期に発見できるようになった結果、手戻りが大幅に削減されたことが直接の要因です。
しかし、それ以上に価値があったのは、チームの文化そのものの変化でした。これまで受動的だったチームから、「もっとこうした方がユーザーのためでは？」といった能動的な提案がエンジニアから次々と生まれるようになりました。
最大の学び：「完璧」ではなく「改善」を前提とすること
この取り組みを通して私たちが得た最大の教訓は、「完璧なプロセスを目指すのではなく、段階的な改善を前提に進めることの重要性」です。
もし、誰もが納得のいく完璧なPRDフォーマットや運用ルールを最初から目指していたら、きっといつまで経っても導入に踏み切れなかったと考えてます。組織として目指すべき理想の姿は常に意識しつつ、そこに至るまでの道のりは柔軟かつ段階的に進めていく。そのマインドをいかに組織の共通認識とできるかが、変革の成否を分ける鍵だと確信しています。
おわりに
私たちはPRDの導入をゴールではなく、新たなスタートラインと捉えています。
情報の質がまだ属人的になってしまう部分があるなど、新たな課題も見えてきています。今後は、チーム全体のリサーチや分析のスキル、そしてその結果を分かりやすくまとめるドキュメンテーションのスキルをさらに底上げすることにも挑戦していきたいと考えています。
この記事が、同じように悩むプロダクトマネジメント組織の皆さんにとって、一歩を踏み出すための参考になれば幸いです。
塩津 壱成 Issei Shiotsu
プロダクト&マーケティング事業本部 クライアントプロダクト本部 スカウトプロダクト統括部 dodaスカウトプロダクト部 dodaスカウトプロダクトマネジメントグループ リードディレクター
学生時代にバックエンドエンジニアとしてWEBアプリケーションの開発に携わる。新卒で医療系予約サイトのWEBディレクターを担当。その後、スタートアップでSaaS系プロダクトのプロジェクトマネージャー（PjM）を経験。2023年よりパーソルキャリアにて「doda ダイレクト」のリードディレクターを務める。
※2025年7月現在の情報です。
