はじめまして、TalentXでPdMをしている佐久間です。
今回は、私がPdMになりたての頃に経験した「要件検討の失敗」と、そこから試行錯誤して辿り着いた具体的な実務アクションについてまとめてみました。
一人のPdMが失敗から学んだ「思考のアップデート」の記録として、読み進めていただければ嬉しいです。
そもそもなぜエンジニアからPdMになったのか
エンジニアの仕事は、純粋に楽しかったです。新しい技術に触れ、難解なロジックを解き明かす達成感は何物にも代えがたいものでした。
ただ、エンジニアとして実装に向き合う中で、次第に「この機能が解決する課題の背景」をもっと深く知りたい、自分もその定義から関わりたいという好奇心が抑えられなくなっていきました。
提示された仕様を形にするだけでなく、その一歩手前にある「なぜこれを作るのか」という意思決定のプロセスに自分も責任を持ちたい。その想いが強くなったことが、PdMへの転向を決めるきっかけでした。
当時は「エンジニア経験があればPdMもいけるのでは？」と甘く見ていた部分もありましたが、いざその役割に立ってみると、これまで見えていなかった「決めること」の圧倒的な難しさに直面することになります。
網羅性を優先しすぎて失敗した、PdM就任直後の苦い経験
PdMとしてジョイン後、初めてとなるプロジェクトを担当することになりました。当時の私は「設定項目は多ければ多いほど、ニーズに応えられるはずだ」と考え、以下のような進め方をしていました。
- 営業やCSから届く「〇〇社から要望があったので対応したい」という断片的な情報を、そのまま受け取ってしまう
- 「この機能があれば要望に応えられるだろう」といった、浅い推測だけで仕様を決めてしまう
- 他社プロダクトにある機能を、自社での必要性を精査せず「一般的だから」という理由だけで取り入れる
結果、完成したのは、あらゆる可能性を詰め込んだ 「全部入りフルカスタマイズ仕様書」 でした。本来は必要のない細かな設定まで可能にしたり、優先順位を整理しないまま「あった方が良さそうな機能」を根拠なく詰め込んでしまったのです。
開発MTGでエンジニアから投げられたのは、あまりに本質的な問いでした。
- 「なぜ、この設定項目まで変更できる必要があるんですか？」
- 「この機能を足すことで、かえってユーザーの利便性を損なうリスクはありませんか？」
- 「そもそも、この課題は実際どれくらいの頻度で発生しているんですか？」
当時の私は、明確な根拠をもって答えられませんでした。理由はすべて「他社がやっているから」「要望があったから」。そこにはデータも、PdMとしての意志もありませんでした。
仕様書を埋めながら感じていた微かな違和感の正体は、「誰の、どんな課題を解決するか」を突き詰めるのではなく、単に仕様を漏れなく揃えること自体が目的（ゴール）になってしまっているという、PdMとして最も避けるべき思考停止の状態でした。
「機能を揃えること」はゴールではなく、あくまで手段。手段が目的化した瞬間にプロダクトは本来の価値を見失ってしまう。そのことを身をもって痛感した、苦い経験です。
検討の精度を上げるための「仕組み化」
こうした失敗を経て、現在は「なんとなく」で仕様を決めることを一切やめました。単に意識を変えるだけでなく、二度と「思考停止」に陥らないための具体的な仕組みとして、検討プロセスに以下の3つのアクションを組み込んでいます。
1. Factに基づく要件検討と「データの解像度」
「おそらくこうだろう」という憶測での議論を排し、常に事実（Fact）を共通言語としてチームと向き合うことを大切にしています。 プロダクトの要件を深掘りするフェーズでは、既存のダッシュボードだけでは見えてこない「解像度の高いデータ」が必要になる場面が多々あります。そうした際、自らSQLを書いて必要な数値を直接抽出し、議論の確かな材料として提示するスタンスを取っています。
また、単にデータを出すだけでなく、その「根拠」をセットにすることでコミュニケーションの質を上げる工夫もしています。具体的には、抽出したシートに実行したクエリをメモとして添えておくことで、数値に違和感が生じた際も、それがロジックによるものかプロダクトの真実なのかをエンジニアと共に即座に検証できるようにしています。
このようにデータの透明性を高めることは、効率化はもちろん、チーム全員が納得感を持って「次のアクション」に集中するための重要な土台になっています。
2. AIツールを活用した調査の効率化
限られた時間内で調査を完結させるため、AIを実務に組み込んでいます。具体的には「Devin」にコード解析を任せて実装と仕様の整合性を瞬時に確認したり、「Gemini」で新領域の要点を短時間でキャッチアップしたりしています。AIを補助として使うことで、PdMが本来注力すべき「判断」に充てる時間を最大化させています。
3. 「やらない理由」の言語化
優先順位を決める際、最も重視しているのは「選ばなかった理由」の説明です。 機能を削る判断をする際は「工数不足」ではなく、「管理者の操作が複雑になる」などユーザー視点の理由を添えてチームの納得感を作ります。
また、単に「やらない」と決めて終わるのではなく、リリース後の効果検証を精度高く行うための「検証の仕込み」をセットで行うようにしています。具体的には、特定の機能をリリースする際、それがどのような意図や経路で利用されているかを把握できるよう、DB側に判別用のフラグを設けるといった計測に必要な最小限の対応を、あらかじめ要件に含めてもらうようにしています。
UIや機能自体は最小限の構成でリリースしたとしても、裏側で「実際の使われ方の事実」を拾える状態を確実に作っておく。この仕込みを開発メンバーに相談しておくことで、リリース後に「次はここをさらに強化すべきか、それとも別の領域にリソースを割くべきか」という判断を、憶測ではなく確かな数字に基づいて行えるようになります。
「迷い」をなくし、開発のリズムを作るための工夫
要件の解像度を上げた後は、それをどう「決断」し、チームを動かしていくか。エンジニアが実装に集中できるよう、コミュニケーション面で徹底しているポイントです。
「納得感があり、後退しない決断」を下す
私自身が最も避けるようにしているのが、一度下した判断を後から覆す「ひっくり返し」です。これを防ぐため、単に早く答えることよりも、「納得感があり、後退しない決断」を下すためのプロセスを重視しています。具体的には、相談を受けた際に以下の3点を徹底しています。
- 判断軸の整理： 「今回の最優先はUXか、それともリリース速度か？」といった判断の物差しを明確にします。
- Pros/Cons（利害得失）の検討： 開発工数、将来の拡張性、ユーザーへのインパクトを比較し、複数の案をフラットに並べます。
- エンジニアとの対話： 「実装の観点からの懸念」など現場の知見を材料に加え、一緒にベストな着地点を探ります。
100%の正解がない場面でも、こうしたプロセスを経て導き出した根拠とともに、判断の責任を自分が引き受ける。一度決めたらブレない姿勢を示すことで、チームが安心して実装に集中できる環境を作りたいと考えています。
「案出しのまとめ」で、意思決定を加速させる
自分一人で決めきれない重要な判断が必要な際は、上長が瞬時に決断を下せるための「判断材料」の用意を徹底しています。単に「どうしましょう？」と相談するのではなく、複数の案について開発工数、顧客インパクト、将来の柔軟性を比較したPros/Consを事前に整理します。その上で、「自分は〇〇の理由で案Aがベストだと考えますが、いかがでしょうか？」と、常に自分の意志をセットにした提案を行うことで、意思決定の待ち時間を最小限にしています。
「1MTG・1発言・1笑顔」のノルマを課す
MTGの雰囲気作りも、良いプロダクトを作るための大切な実務だと考えています。実際に手を動かしてカタチにしてくれるエンジニアへのリスペクトを忘れず、真剣な議論の中でも笑顔を絶やさないこと。無理難題をお願いしなければならない場面でも、まずは否定から入らず「どうすれば実現可能か」を一緒に探る。そんな些細な姿勢を継続することで、心理的安全性を高め、チーム全体のパフォーマンスを最大化させることを意識しています。
最後に
振り返ると、PdMになりたての頃の自分は、どこかにあるはずの「正解を探す人」でした。今は少しだけ、「集めたFactをもとに、チームを信じて決断を下す人」に近づけた気がしています。
文言ひとつ、仕様ひとつをとっても、それが「誰の、どんな課題」に繋がっているのか。エンジニアが迷わずコードを書けるだけの解像度を、泥臭く追求し続ける。そのプロセスの積み重ねこそが、プロダクトに血を通わせるのだと感じています。
もちろん、課題はまだまだ尽きません。これからも現場へのリスペクトを忘れず、データの裏側にある「ユーザーの体験」を最大化できるようなモノづくりを追求していきたいです。
この記事が、同じように日々「何を作るべきか」に葛藤しているPdMの皆様の、少しでもヒントになれば嬉しいです。最後まで読んでいただき、ありがとうございました！
一緒に働く仲間を募集しています
TalentXでは現在、新しい仲間を募集中です。
talentx.brandmedia.i-myrefer.jp
カジュアル面談も実施しておりますので、ぜひお気軽にご応募ください！
i-myrefer.jp
