「良いこだわり」と「悪い固執」を見極めて、プロダクトマネージャーの意思決定を磨く

この記事の要約

プロダクト開発における「こだわり」と「固執」の違いを、顧客価値・学習可能性・リバーシビリティの3軸で考える
サンクコストの呪縛や確証バイアスなど、PdMが陥りやすい5つの心理的トラップとその対処法を解説

「この機能、本当にユーザーのためになってるのかな…」
深夜のオフィスで、利用率データやインタビューのログを見つめながら、そんな疑問が頭をよぎったことはありませんか？

僕がプロダクトマネージャーとして難しいと感じるのが「こだわるべきところ」と「手放すべきところ」の見極めです。ユーザーのために良かれと思って追求していたものが、いつの間にか独りよがりな固執に変わってしまう。

なぜ「こだわり」と「固執」の見極めが重要なのか？
「こだわり」と「固執」の本質的な違い
固執に陥る5つの心理的トラップ
実践的な判断フレームワーク「PIVOT」
ケーススタディ：実際の判断場面での応用
プロダクトマネージャーとしての成長へ
今日から実践できるアクション
Q&A
参考情報

なぜ「こだわり」と「固執」の見極めが重要なのか？

プロダクト開発の現場では、日々無数の意思決定が求められます。

機能を追加するか
UIを変更するか
既存機能を改善するか
機能を思い切って削除するか

これらの判断一つひとつが、プロダクトの成功を左右します。

成功事例：Slackの絵文字機能へのこだわり

良い「こだわり」の代表例として、Slackの絵文字機能があります。2013年のローンチ当初、多くの投資家やアドバイザーから「ビジネスツールに絵文字なんて不要」という意見もあったかと思います。しかし、創業者のスチュワート・バターフィールドは、「感情表現がコミュニケーションの質を高める」という信念を持ち続けました。

これは単なる機能へのこだわりではなく、「チームコミュニケーションに温かみを加える」という顧客価値への深い理解に基づいた判断だったのです。
（もちろん、slackの成功がスタンプによって実現した、とまで言うわけないですがイメージの1つとして）

失敗事例：Quibiの短尺動画フォーマットへの固執

一方、悪い「固執」の例として、2020年にサービスを終了したQuibiがあります。創業者のジェフリー・カッツェンバーグは、「10分以下の高品質な短尺動画」というコンセプトに固執し続けました。

17億5000万ドルもの資金を調達したにも関わらず、わずか6ヶ月でサービスを終了。

ユーザーは「テレビでも視聴したい」と要望 → モバイル専用に固執
コンテンツのシェア機能を求める声 → 著作権保護を理由に実装せず
無料プランの要望 → 有料のみのモデルに固執

Quibiの失敗は、「ビジョンへの固執」と「顧客ニーズへの柔軟な対応」のバランスを見誤った典型例と言えるでしょう。

判断ミスがもたらす影響

プロダクト開発における意思決定の遅れや誤りがもたらす影響は以下の通り

機会損失（競合に先を越される）
リソースの無駄遣い
チームモラルの低下
顧客離反

「こだわり」と「固執」の本質的な違い

では、良い「こだわり」と悪い「固執」は、何が違うのでしょうか？

こだわり＝「顧客価値を軸とした柔軟な執着」

こだわり（Good Obsession）とは、顧客に届けたい価値や体験に対する強い信念を持ちながら、その実現方法については柔軟に変化できる姿勢を指します。

例えば、Airbnbの創業者ブライアン・チェスキーは、「旅行者に『どこでも我が家』のような体験を提供する」という価値にこだわり続けています。しかし、その実現方法は時代とともに進化しています

2008年：エアマットレスの貸し出しから開始
2011年：プロフェッショナル写真撮影サービスを追加
2016年：「体験」カテゴリを追加し、宿泊以外にも拡大
2020年：コロナ禍で長期滞在向けの機能を強化
2024年：AIを活用したパーソナライズド検索を実装

手段は変わっても、「旅の体験を豊かにする」という軸はブレていません。これが健全なこだわりです。

固執＝「手段や形式への硬直的な執着」

一方、固執（Bad Stubbornness）は、特定の実装方法、デザイン、機能、あるいは自分のアイデアそのものに執着し、変化を拒む姿勢を指します。

象徴的な例が、かつてのBlackBerryです。物理キーボードへの固執が、結果的に企業の衰退を招きました

2007年：iPhoneがタッチスクリーンで革命を起こす → 「ビジネスユーザーは物理キーボードを求めている」と主張
2010年：Android端末が急成長 → 「セキュリティ面で我々が優位」と現状維持
2013年：市場シェアが20%から1%に急落 → ようやくタッチスクリーン端末を投入するも時すでに遅し

BlackBerryは「効率的なビジネスコミュニケーション」という価値提供ではなく、「物理キーボード」という手段に固執してしまったのです。

Dead Media Beat: Blackberry

判断基準の3つの軸

こだわりと固執を見分けるために、以下の3つの軸で判断することをお勧めします

1. 顧客インパクト（Customer Impact）

問い：この判断は、顧客にとって明確な価値をもたらすか？

こだわり：顧客の声やデータに基づいて価値を定義している
固執：自分たちの思い込みや好みで価値を定義している

判断のポイント

定量データ（利用率、継続率、NPSなど）で効果を測定できるか
定性的なフィードバックで顧客の喜びの声があるか
競合と比較して差別化要因になっているか

2. 学習可能性（Learnability）

問い：この取り組みから、次に活かせる学びを得られるか？

こだわり：仮説検証のサイクルが回っており、失敗からも学んでいる
固執：同じアプローチを繰り返し、学習が停滞している

判断のポイント

明確な仮説と検証計画があるか
失敗した場合でも得られるインサイトがあるか
チーム全体で学びを共有する仕組みがあるか

3. リバーシビリティ（Reversibility）

問い：この決定は後から修正・撤回できるか？

こだわり：段階的な実装で、必要に応じて方向転換できる
固執：all or nothingで、後戻りできない決定をしている

判断のポイント

技術的な負債を最小限に抑えているか
ユーザー体験の一貫性を保ちながら変更できるか
投資規模が適切で、撤退コストが許容範囲内か

これらの3つの軸で評価することで、今の自分の判断が「健全なこだわり」なのか「危険な固執」なのかを客観的に見極めることができます。

固執に陥る5つの心理的トラップ

なぜ優秀なPdMでも固執に陥ってしまうのでしょうか。それは、人間である以上避けられない認知バイアスが働くからです。ここでは、特にプロダクト開発で陥りやすい5つの心理的トラップと、その対処法を解説します。

1. サンクコストの呪縛

サンクコストバイアス（Sunk Cost Bias）とは、既に投資した時間、お金、労力が無駄になることを恐れて、合理的でない判断を続けてしまう心理傾向です。

実例として、GoogleのGoogle+があります。2011年にローンチし、4年間で数百億円規模の投資を行いましたが、ユーザー数は伸び悩みました。それでも「これだけ投資したのだから」という理由で、2019年まで8年間もサービスを継続。結果的に、その間に投下されたリソースは、他のより有望なプロジェクトに使えたはずでした。

対処法：「ゼロベース思考」の実践

定期的なリセット会議：3ヶ月ごとに「今日この機能を初めて見たとしたら、開発するか？」という問いを投げかける
投資上限の事前設定：「〇〇までに△△の成果が出なければ撤退」というルールを最初に決める
外部アドバイザーの活用：利害関係のない第三者の意見を定期的に聞く

2. 確証バイアス

確証バイアス（Confirmation Bias）は、自分の仮説や信念を支持する情報ばかりを集め、反証する情報を無視してしまう傾向です。

例えば、ECサイトで、「ユーザーはより多くの商品情報を求めている」という仮説のもと、商品詳細ページに大量の情報を追加して、CVRが下がるようなケースです。

対処法：「悪魔の代弁者」システム

レッドチーム演習：チームメンバーが交代で「この機能が失敗する理由」を本気で考える
データの可視化ルール：ポジティブ・ネガティブ両方のデータを必ず併記する
反証KPIの設定：「この指標が悪化したら仮説が間違っている」という基準を事前に決める

3. NIH症候群（Not Invented Here）

NIH症候群とは、自分たちが作ったものに過度な愛着を持ち、外部のより良いソリューションを受け入れられない状態を指します。

マイクロソフトのInternet Explorerは、この典型例でした。独自の実装にこだわり続けた結果、Web標準から大きく外れ、開発者から嫌われるブラウザとなってしまいました。最終的に2022年にサービス終了し、Chromiumベースの新しいEdgeに移行することになりました。

対処法：「ベストプラクティス探索」の習慣化

競合分析の定例化：月1回、他社の優れた実装を学ぶ会を開催
オープンソース活用：車輪の再発明を避け、既存の優れたソリューションを積極採用
ユーザー視点の判断基準：「誰が作ったか」ではなく「ユーザーにとってどちらが良いか」で判断

4. 完璧主義の罠

完璧主義（Perfectionism）は、100%の完成度を求めるあまり、リリースが遅れたり、過剰な機能を盛り込んでしまう傾向です。

LinkedInの創業者リード・ホフマンは「初版の製品に恥ずかしさを感じないなら、それはリリースが遅すぎる」という名言を残しています。実際、LinkedInの初版は非常にシンプルで、今から見れば恥ずかしいほど機能が少なかったそうです。しかし、早期にリリースしたことで貴重なフィードバックを得られ、現在の成功につながりました。

対処法：「MVP思考」の徹底

機能の優先順位マトリクス：「顧客価値」×「実装コスト」で機能を分類し、高価値・低コストから着手
タイムボックス開発：「2週間でできる範囲」という制約を設けて開発
早期アクセスプログラム：完璧でなくても、一部のユーザーに使ってもらいフィードバックを得る

5. 権威への服従

権威への服従（Authority Bias）は、上司や偉い人の意見を無批判に受け入れてしまい、自分の判断を放棄してしまう傾向です。

例えばよくあるのは、「CEO/VP/POがこの機能/コンテンツを気に入っているから」という理由だけで、データが示す問題を無視し続けるケース。

対処法：「データドリブンな対話」の確立

意思決定の透明化：すべての決定に「根拠」を必須とし、「〇〇さんが言ったから」を理由にしない
実験文化の醸成：「試してみてダメなら戻す」という柔軟性を組織に埋め込む
建設的な異議申し立て：心理的安全性を確保し、データに基づいた反対意見を歓迎する

これらの心理的トラップは、誰もが陥る可能性があります。重要なのは、自分がこれらのバイアスに影響されていることを認識し、意識的に対処することです。

実践的な判断フレームワーク「PIVOT」

日々の意思決定で「こだわり」と「固執」を見極めるために、「PIVOT」フレームワークを紹介します。これは、5つの観点から素早く判断できる実践的なツールです。

P – Purpose（目的）：なぜこれにこだわるのか？

核心的な問い：このこだわりは、プロダクトのミッションと整合しているか？

チェックポイント：

プロダクトビジョンとの関連性を説明できるか
「なぜ」を5回繰り返しても、顧客価値に行き着くか
チーム全員が目的を理解し、共感しているか

実例：Spotifyの「Discover Weekly」

目的：「ユーザーに新しい音楽との出会いを提供し、音楽体験を豊かにする」

この明確な目的があったからこそ、技術的な困難（数億曲から毎週パーソナライズ）を乗り越えられました。

I – Impact（影響）：顧客にどんな価値をもたらすか？

核心的な問い：この機能で、ユーザーの生活はどう変わるか？

測定方法：

定量的インパクト：利用率、継続率、NPS、収益への影響
定性的インパクト：ユーザーインタビューでの感情的な反応
波及効果：この機能が他の体験にもたらす影響

インパクト測定マトリクス

インパクトレベル	定量指標	判断基準
High	主要KPIが10%以上改善	継続推進
Medium	主要KPIが5-10%改善	改善して継続
Low	主要KPIが5%未満の改善	pivot検討

V – Validation（検証）：仮説は検証されているか？

核心的な問い：思い込みではなく、事実に基づいているか？

検証のレベル：

仮説段階：まだ検証していない（危険信号）
定性的検証：ユーザーインタビューで需要を確認
プロトタイプ検証：Fake Door等で反応を測定
定量的検証：A/Bテストで効果を実証
スケール検証：全ユーザーで効果を確認

検証が不十分な場合の危険サイン：

「きっとユーザーは〜」という推測が多い
都合の良いデータだけを見ている
反対意見を「理解していない」と片付ける

O – Options（選択肢）：他にどんな方法があるか？

核心的な問い：現在のアプローチが唯一の解決策か？

選択肢を広げる方法：

ブレインストーミング：「How Might We」セッションで代替案を出す
競合分析：他社はどう解決しているか
異業種からの学び：全く違う業界の解決策を参考にする
制約の緩和：「もし〇〇という制約がなかったら」と考える

実例：Instagramのストーリーズ

Snapchatの一時的投稿に対抗する選択肢：

同じ機能をコピー（実際の選択）
永続的だが後から編集可能な投稿
24時間後に自動アーカイブ
友達限定の投稿機能

複数の選択肢を検討した上で、ユーザーニーズに最も合う形を選択しました。

T – Timing（タイミング）：今が適切な時期か？

核心的な問い：なぜ今なのか？もっと良いタイミングはないか？

タイミングを判断する要素：

市場の成熟度：ユーザーはこの機能を受け入れる準備ができているか
技術的実現可能性：必要な技術は利用可能か、コストは妥当か
競合の動向：先行者利益 vs 後発の優位性
リソースの可用性：チームは他の重要なことを犠牲にしていないか
ビジネスサイクル：繁忙期、決算期などの影響

タイミングマトリクス

緊急度/重要度	高い重要度	低い重要度
高い緊急度	すぐ実行（ただし固執注意）	delegate or drop
低い緊急度	計画的に実行（理想的）	backlogへ

PIVOTフレームワークの実践例

習慣化支援アプリで「ソーシャル機能（友達との習慣共有）」を例にしたPIVOT分析

P（目的）：ユーザー同士の励まし合いで習慣継続率を向上させる ✓
I（影響）：30日継続率が15%から35%に向上する見込み（競合データより） ✓
V（検証）：100名のユーザーインタビューで「誰かと一緒なら続けられる」という声が60%以上 ✓
O（選択肢）：AIコーチ、リマインダー強化、ゲーミフィケーション強化も検討したが、人との繋がりが最も効果的 ✓
T（タイミング）：年始の習慣化需要期に向けて、3ヶ月前の今が実装の最適期 ✓

ケーススタディ：実際の判断場面での応用

理論を実践に移すため、プロダクト開発でよく直面する3つのシナリオで、どのように判断すべきかを詳しく見ていきます。

ケース1：機能追加の要望が多いが、シンプルさを保ちたい場合

状況：
BtoBのタスク管理ツールを運営。ユーザーから「ガントチャート」「タイムトラッキング」「予算管理」など、多数の機能要望が寄せられている。しかし、「シンプルで使いやすい」というコアバリューを大切にしたい。

こだわりvs固執の判断ポイント：

固執のサイン：

「うちはシンプルさが売りだから」という理由だけで、すべての要望を却下
競合が機能を追加して市場シェアを奪われているのに、現状維持
「シンプル」の定義が曖昧で、チーム内でも認識がバラバラ

健全なこだわりのアプローチ：

要望の構造化
- すべての要望をJobs to be Doneで分類
- 「なぜその機能が欲しいのか」の本質的なニーズを抽出
段階的アプローチ
- コア機能：全ユーザーが使う基本機能（シンプルに保つ）
- オプション機能：必要な人だけが有効化（複雑さを隔離）
- 統合機能：他ツールとの連携で実現（自社で作らない）
実装例：Notionの解決策
- 基本はシンプルなノート機能
- データベース機能は使いたい人だけが使う
- テンプレートで複雑な使い方をサポート

判断基準：「シンプルさ」は手段であり、目的は「誰でも迷わず使える」こと。この目的を達成できる範囲で、柔軟に機能を追加する。

ケース2：技術的に優れた解決策 vs 既存ユーザーの慣れ親しんだUI

状況：
5年運営しているECサイト。技術チームから「React + Next.jsでSPA化すれば、表示速度が50%向上する」と提案。しかし、既存の100万人のユーザーは現在のUIに慣れており、大幅な変更には抵抗がある可能性。

PIVOTフレームワークでの分析：

観点	技術的解決策の評価	リスクと対策
Purpose	ユーザー体験の向上（速度改善）✓	技術のための技術になっていないか確認
Impact	表示速度50%向上、離脱率の改善見込み	UI変更による一時的な混乱
Validation	技術的検証は完了	ユーザー受容性は未検証
Options	段階的移行、A/Bテスト、現状維持	複数の選択肢あり
Timing	競合も高速化を進めている	年末商戦前は避ける

推奨アプローチ：段階的移行戦略

Phase 1：見えない部分から改善
- バックエンドの最適化
- 画像の遅延読み込み
- キャッシュ戦略の改善
Phase 2：限定的なUI改善
- 新規ユーザーの5%でA/Bテスト
- 最も影響の少ないページから開始
- 詳細なメトリクス監視
Phase 3：学習に基づく展開
- ユーザーフィードバックを反映
- 段階的にロールアウト
- 旧UIへの一時的な切り替えオプション提供

教訓：技術的な優位性は重要だが、既存ユーザーの体験を守ることも同じくらい重要。両立できる道を探ることが、健全なこだわりの証。

ケース3：短期的な収益 vs 長期的なブランド価値

状況：
フリーミアムモデルの生産性アプリ。投資家から「有料プランへの誘導を強化し、ARRを倍増させろ」とプレッシャー。一方で、「誰でも無料で使える」というブランド価値を大切にしたい。

よくある固執パターン：

収益への固執：無料プランを極端に制限し、ユーザーが離反
理想への固執：収益化を拒否し、サービス継続が困難に

バランスの取れたアプローチ：Figmaの事例

Figmaは以下の戦略で、ブランド価値を保ちながら収益化に成功：

価値の明確な差別化
- 個人利用：永久無料（3ファイルまで）
- チーム利用：コラボレーション機能で有料化
- 企業利用：セキュリティ・管理機能で高額プラン
成長とともに課金する設計
- 学生・個人クリエイター：無料で学習・練習
- フリーランス：必要に応じて有料プラン
- 企業：当然のように有料プラン
ブランド価値の強化
- 「民主的なデザインツール」というメッセージ維持
- コミュニティへの積極的な貢献
- 教育機関への無料提供