TL;DR
- 「ユーザー中心主義」と「ユーザーの言いなり」は似て非なるもの。課題を中心に置くのが前者、解決案を中心に置くのが後者
- ユーザーの要望は「答え」ではなく「手がかり」。背後にある文脈と構造を見抜くのがプロダクトチームの仕事
- 言いなりがラクなのは短期だけ。長期ではプロダクトの一貫性・学習コスト・ロードマップ・ユーザー満足すべてが劣化する
- AI時代は「作れるか」より「入れるべきか」の判断がさらに重要になる
この記事について
OpenWork CPO室のShin氏（@shin_sasaki19）がX Article形式で公開した長文記事の要点抽出。元記事は約10,000字超のプロダクト開発論で、ブックマーク31・いいね16を獲得している（3/26時点）。プロダクトマネージャー、デザイナー、エンジニア、営業・CSなどプロダクト開発に関わるすべての職種に向けた内容だ。
核心：2つの「ユーザー中心」の違い
Shin氏の結論は明快だ：
ユーザー中心主義は「ユーザーの課題を中心に置くこと」であり、ユーザーの言いなりは「ユーザーの解決案を中心に置くこと」
ユーザーは困りごとについては一級の情報源。しかし、その困りごとをどう構造化し、どんな制約の中で、どの順序で解決策に落とすかはプロダクトチームの仕事だ。
| ユーザー中心主義 | ユーザーの言いなり | |
|---|---|---|
| 焦点 | ユーザーの課題 | ユーザーの解決案 |
| 要望の扱い | 手がかりとして分析 | そのまま採用 |
| 判断の主体 | プロダクトチーム | ユーザー（実質的に） |
| 距離感 | ユーザーの近くに立つ | ユーザーの席に座る |
| 結果 | 全体最適・長期価値 | 局所最適・機能の寄せ集め |
なぜ「言いなり」になるのか — 構造的な理由
Shin氏は、善意で間違えやすいからこそ危険だと指摘する。
短期的にラクだから
- 「お客様が言っていたので」は社内で通しやすい
- 営業との摩擦が減り、CSにも感謝される
- 開発も仕様が決まっていれば手を動かしやすい
代償： 「本当に正しい問いを立てたか」を誰も見なくなる。
組織設計の問題
- PMが「何を作らないか」に責任を持てない
- 営業・CSの評価が「要望を通した件数」に紐づいている
- 経営が「顧客の声を聞け」としか言わない
言いなりがプロダクトを壊す5つのメカニズム
| # | 壊れ方 | 具体的な症状 |
|---|---|---|
| 1 | 一貫性の崩壊 | 画面ごとに流儀が違う、似た機能が微妙に並存 |
| 2 | 学習コスト増大 | オンボーディング困難、サポート説明が複雑化 |
| 3 | ロードマップの短期反応化 | データ基盤・共通UI・検索品質など「地味だけど効く投資」が後回し |
| 4 | 責任のぼやけ | 「顧客要望」ラベルで思考停止、判断を放棄 |
| 5 | ユーザー満足の低下（皮肉） | 要望を入れたのに使いにくい。局所改善の積み重ね≠全体体験の向上 |
実務で使える3つのフレームワーク
1. 要望の3分類
要望を受けたら、まず3つに仕分けする：
- 課題は正しいが解決案が違うもの → 別の解き方を検討
- 課題も解決案も正しいもの → 優先度を判断して実装
- そもそも課題の普遍性が低いもの → 運用カバーまたは見送り
2. 要望の一段抽象化
| ユーザーの要望 | 抽象化した課題 |
|---|---|
| 承認フローを三段階に | 責任分界点をシステム上で明確にしたい |
| 検索条件を五つ追加 | 欲しい候補を探すまでの試行回数を減らしたい |
| レポートをPDFで出力 | 社内共有の標準フォーマットに乗せたい |
| CSV形式を変更 | 現行業務フローに載せ替えたい |
3. 声の4レイヤー分析
| レイヤー | 内容 | 重視度 |
|---|---|---|
| 事実 | 何が起きたか、どこで詰まったか | ★★★ |
| 解釈 | なぜ困ったと本人は感じたか | ★★★ |
| 要望 | どうしてほしいか | ★★（そのまま採用しない） |
| 示唆 | プロダクトとして何を学ぶか | ★★★（作り手の仕事） |
職種別の役割分担
Shin氏は、「ユーザー中心」の意味が職種ごとに異なることが混乱の原因だと指摘する。
| 職種 | 「ユーザー中心」の意味 | 本来の役割 |
|---|---|---|
| 営業・CS | 顧客要望への対応力 | 現場の温度感と文脈のセンサー |
| PM・PO | 事業と顧客価値の両立 | 構造化と意思決定（要望の転送者ではなく翻訳者） |
| デザイナー | 使いやすさ・認知負荷 | 体験の一貫性の守護者 |
| エンジニア | 技術的に作れること | 「作れる」と「入れるべき」を分ける判断者 |
AI時代に重要性が増す理由
AIを使うと「個別要望を高速で実装する」コストが下がる。すると「じゃあ入れてみよう」が増える。しかし、作るコストが下がっても、複雑性のコストは下がらない。
Shin氏のこの指摘は、AI時代のプロダクト開発における核心的な警告だ。Vibe Codingで実装が容易になるほど、「入れるべきか」の判断力が差別化要因になる。
断り方の設計 — 実務のポイント
要望を断るときに必要なのは「No」ではなく「Why not this, and why this instead」。
4つの意識：
- 要望を否定しない
- 課題理解を示す
- 代替案を出す
- 判断軸を共有する
実践Tips：
- 「要望管理票」を「課題管理票」に変える（項目：ジョブ、代替行動、発生頻度、影響範囲、標準化妥当性、副作用）
- 例外対応は隠れコスト（QA、サポート教育、営業説明、将来改修、設定増加）を可視化する
- 要望を聞いた瞬間に仕様の会話に入らない。まず課題確認→代替手段→発生頻度→影響範囲の順に見る
チェックリスト（元記事より）
要望を前にしたとき、以下を順に確認する：
- それは誰のどんな状況で起きた話か
- その困りごとは行動ログでも確認できるか
- 今の要望は課題の表現か、解決案の提案か
- 他のユーザーにとって概念が増えないか
- 学習コスト・運用コストはどう増えるか
- その打ち手は半年後の強みになるか
- 運用で吸収できないか
- 標準化に耐えるか
まとめ
Shin氏の論点を一言にすると：
プロダクトの仕事は、ユーザーの代弁者になることではない。ユーザーの現実を深く理解した上で、最も良い形を提案すること。「聞く」だけでなく「決める」仕事だ。
「ユーザー中心」は強い思想。「ユーザーの言いなり」は判断放棄。前者はときに不採用を含む。後者は一見やさしいが、長期的には不親切。この差を言語化しておくことが、善意でプロダクトを弱くしないための第一歩だ。
ソース:
- Shin氏のX Article「ユーザー中心主義とユーザーの言いなりは何が違うのか？」
- UX Magazine「User-Led Does Not Equal User-Centered」（参考：Alan Cooperの同テーマ論考）