プロダクト開発で「つくらない判断」を磨くために、つくる前にファクトを見直す

この記事の要約

リリースした機能の70%以上が使われていない現実を踏まえ、「つくらない判断」がPdMの重要スキル
「つくらない」と判断すべきシグナルは、顧客ファクトの有無と強度
ステークホルダーに納得してもらう「つくらない」コミュニケーション技術

プロダクト開発において、「何を作るか」と同じくらい重要なのが「何を作らないか」という判断。機能要求が日々舞いんだり、自分で見つけたりする中で、限られたリソースを最適に配分し、本当に価値のある機能に集中することが、PdMの腕の見せ所。

ただ実際には、多くのチームが「とりあえず作ってみよう」という姿勢で機能開発を進め、結果的に使われない機能を量産してしまうことも多いかと思います。今回は、この「つくらない判断」について深ぼってみようと思います。

なぜ「つくらない判断」スキルが必要なのか
「つくらない」と判断すべき機能のシグナル
ステークホルダーに「つくらない」と伝える技術
1. 基本原則：拒否でも関係を強化するコミュニケーション
  1. 対話例 – 営業チームからの緊急機能要求
Q&A
参考情報

なぜ「つくらない判断」スキルが必要なのか

機能の大半が使われていない

「Standish Group Chaos Report 2014」によると、“45 %の機能が一度も使われず、19 %がまれにしか使われない” = 実質 64 % がほぼ未使用だそうです。

この数字は決して他人事ではありません。皆さんも自社のプロダクトを振り返ってみると、「あの機能、誰か使ってるっけ？」と首をかしげる機能がいくつかあるはずです。

成功企業の「つくらない」戦略

一方で、成功しているプロダクトほど「つくらない判断」が徹底されています。
初期のBuffer（バッファー）の事例が分かりやすい例です。同社は創業初期、ソーシャルメディア投稿の予約機能のみに特化しました。分析機能、ソーシャルリスニング、広告管理など、競合が次々と追加する機能を一切作らず、シンプルな投稿スケジューリングのみを磨き続けた結果、現在では月間利用者数77万人を超えるプロダクトに成長。

Buffer: Social media management for everyone

Use Buffer to manage your social media so that you can create and share your content everywhere, consistently. Try our f...

「つくる」コストの全体像

機能開発のコストは、開発工数だけでは測れません。実際のコストは以下のように多岐にわたります

コスト分類	具体的な内容
直接コスト	– 開発工数（設計・実装・テスト） – QAコスト – デプロイ・リリース作業
間接コスト	– 既存機能の複雑化 – UI/UXの煩雑化 – 保守・運用コスト – ドキュメント作成・更新 – カスタマーサポート対応の複雑化
機会費用	– 他の重要機能の開発機会を失う – チームの集中力の分散 – プロダクトビジョンの希薄化

特に機会費用は見落とされがちですが、最も大きなコストとなることが多いです。限られた開発リソースを価値の低い機能に投じることで、本当にユーザーが求めている機能の開発が後回しになってしまう。

プロダクトチームへのメリット

また、「つくらない判断」スキルを身につけることで、PdMとして以下のメリットが得られます。

開発効率の向上：限られたリソースを高価値機能に集中
プロダクト品質の向上：機能数を絞ることでユーザビリティが向上
チームの生産性向上：明確な優先順位でチームの迷いが減る
ステークホルダーからの信頼獲得：論理的な判断力への評価
戦略的思考力の向上：全体最適の視点が身につく

「つくらない」と判断すべき機能のシグナル

判断基準：”基本的には”、実際の顧客の声やデータに基づかない機能は開発すべきではありません。

多くの機能開発の失敗は、「顧客が求めているはず」という思い込みから始まります。実際の顧客からのフィードバックや定量的なログ分析データがない状態で開発を進めることは、限られたリソースを無駄にするリスクが非常に高くなります。

❌ 開発を避けるべきパターン

🚫 競合対応の機能追加
「競合A社にあるから」という理由だけでの機能追加。自社の差別化戦略やターゲット顧客のニーズと整合性が取れない機能は、使われない可能性が高い。
🚫 社内の想像に基づく機能
「ユーザーはきっとこう思っているはず」という仮説のみで進める開発。実際のユーザー行動データやインタビューによる裏付けがない。
🚫 一般論に基づく機能
「業界では一般的だから」「トレンドだから」という理由での機能追加。自社ユーザーの具体的なニーズを無視している。

✅ 必要なファクトの種類

定性的データ

ユーザーインタビューの録音・記録
カスタマーサポートへの問い合わせ内容
ユーザーフィードバックの集計
NPS調査での具体的コメント

定量的データ（ログ分析）

既存機能の利用率・クリック率
ユーザーの行動フローデータ
離脱率・コンバージョン率の分析
A/Bテストの結果データ

🔍 検証方法：ファクトベース判断のチェックリスト

以下の質問に「はい」と答えられない場合、その機能開発は再考すべき

顧客の声：過去3ヶ月以内に、5人以上の顧客から同様の要望やファクト分析からの要求がありましたか？（直接的な要望に限定しない」）
データ裏付け：その課題が存在することを示す定量的データ（離脱率、エラー率など）はありますか？
現状分析：顧客が現在その課題をどう解決しているか把握していますか？
影響範囲：全ユーザーの何％がこの機能から恩恵を受けるか計算できますか？
成功指標：機能リリース後の成功を測る具体的なKPIを設定していますか？

覚えておくべき原則
「思い込み」や「推測」ではなく、「顧客の実際の声」と「データ」に基づいて判断する。ファクトがない機能は、70%の確率で使われない機能になる。

ステークホルダーに「つくらない」と伝える技術

論理的に「つくらない」判断を下せても、それをステークホルダーに納得してもらえなければ意味がありません。ここでは、関係性を維持しながら効果的に拒否を伝える技術を解説します。

基本原則：拒否でも関係を強化するコミュニケーション

4ステップコミュニケーション法

感謝
「貴重なご提案をいただき、ありがとうございます」、と相手の貢献意欲を認めることから始める
理解
「〇〇の課題を解決したいというお気持ち、よく理解できます」など相手の意図や背景への共感を示す（大袈裟にやりすぎないように）
拒否理由
「ただ、現在の状況では△△の理由で対応が困難です」と感情ではなく事実に基づいた理由を提示
代案
「代わりに□□はいかがでしょうか」と建設的な代替案を提示

対話例 – 営業チームからの緊急機能要求

営業：「顧客から要求された機能を今すぐ作ってほしい」

PdM
「お客様のニーズを拾ってきていただき、ありがとうございます。売上に直結する案件を大切にしたいお気持ち、よく分かります。ただ、現在のスプリントでは来四半期のOKR達成に必要な機能開発にリソースを集中しており、新規機能の着手が困難な状況です。今回のご要望は要望リストに追加させていただき、次四半期の計画時に優先度を検討させてください。
すぐにできることとして、既存機能での回避策をご案内できますが、いかがでしょうか？」

また、以下のように定量的に示す方法も相手の納得度を高める上で有効です（前提として相手の要望を”かわす”ためではなく、それが事業にとって最善だと信じられる判断である必要があります）

「この機能開発に2週間かかりますが、同じ2週間で○○機能を開発すれば、月間アクティブユーザーが15%向上する見込みです。」

Q&A

Q1: 「つくらない判断」を重視しすぎて、イノベーションの機会を逃すのではないでしょうか？
A1: 確かにリスクはありますが、実際は逆です。リソースを分散させずに本当に価値のある機能に集中することで、より大きなイノベーションが生まれやすくなります。Appleが iPhone開発時に物理キーボードを「作らない」と判断したからこそ、タッチ革命が実現しました。重要なのは、革新的なアイデアとリソースの無駄遣いを区別することです

Q2: 経営陣からの強い要求を断るのは現実的に難しいのですが、どうすればよいでしょうか？
A2: 経営陣との対話では「反対」ではなく「より良い選択肢の提案」として位置づけることが重要です。「この機能ではなく、○○機能に投資することで、より大きな事業成果が得られます」という代替案を、具体的な数値とともに提示しましょう。また、「試験的に最小限の機能で検証してから本格開発を判断する」という段階的アプローチも効果的です。

Q3: チームメンバーから「PdMが何でも拒否する人」と思われるのが心配です
A3: 拒否の際は必ず「なぜ拒否するのか」の論理的な説明と、「代わりに何ができるか」の代替案をセットで提示することが重要です。また、拒否した機能のうち実際に必要だったものの割合を定期的に振り返り、判断精度を向上させていることをチームと共有しましょう。透明性と学習姿勢を示すことで、信頼関係を維持できます。

Q4: スタートアップなど小規模チームでも「つくらない判断」は重要でしょうか？
A4: むしろ小規模チームほど重要です。限られたリソースでPMF（プロダクトマーケットフィット）を見つける必要があるため、集中が生命線となります。小規模プロダクトにおけるPdMの意思決定プロセスでも触れているように、小さなチームだからこそ一つ一つの判断の影響が大きく、「つくらない勇気」が成功を左右します。

小規模プロダクトにおいてPdMが大切にすべき意思決定プロセス

「上司がいない」環境でプロダクトを伸ばすPdMも多いのではないでしょうか？小規模スタートアップやフリーランスチームなどは典型的な例ですよね。こうした“組織レス”な状態では、決裁フローが曖昧である反面、自分のリーダーシップ一つで組織が動くワク...

Q5: 顧客からの直接要求があっても「つくらない」場合はありますか？
A5: あります。重要なのは「誰からの要求か」と「どれくらいの規模の要求か」です。全ユーザーの1%未満からの要求に対して、90%のユーザーが使っている機能の改善を後回しにするのは適切ではありません。また、ユーザーがコストを払っていない課題は課題ではないという視点で、本当に解決すべき課題かどうかを見極めることも重要です。