【要約】『嫌われる勇気』をプロダクトマネージャーが実践するにはどうしたら良いか?

PM関連本

はじめに:アドラー心理学がPMに与える影響

嫌われる勇気』(著:岸見一郎・古賀史健)は、オーストリアの心理学者アルフレッド・アドラーの考え方を対話形式でわかりやすく解説したベストセラー。

本書のメッセージの中心は、人間関係や自己実現において「他者評価に左右されず、自分の人生を生きる」ということ。タイトルにもあるように、「嫌われる」ことを恐れない姿勢が自由で幸福な生き方をもたらす、という逆説が多くの読者の心を打ちました。

僕はテック企業でプロダクトマネージャー(PM)をしていますが、この考え方は意思決定やチームマネジメントの現場でも有効だと感じています。PMは多くのステークホルダーを巻き込みながらも、あらゆる要望をすべて受け入れるわけにはいきません。時にはチームの不満や経営層の反対を覚悟のうえで、プロダクトの「本質」を貫く判断が求められます。『嫌われる勇気』のエッセンスを取り入れることで、不要な迷いや周囲の評価への過度な依存から抜け出し、筋の通ったリーダーシップを発揮できるようになるはずです。

created by Rinker
¥1,485 (2025/04/28 16:35:54時点 Amazon調べ-詳細)

アドラー心理学の核心:「目的論」と「課題の分離」

アドラー心理学の特徴としてよく語られるのが、「過去の原因」に注目するのではなく「未来の目的」に注目する、というスタンス。これは「目的論」と呼ばれます。たとえば「自分は過去に◯◯な経験をしたから上司と折り合いが悪い」という原因論的な捉え方をせず、「上司と連携しないほうが今の自分にとって都合が良いから、その態度を選んでいるのでは」という具合に考えるのです。意識・無意識にかかわらず、自分の行動には未来に向けた“目的”があるという見方が基本になっています。

観点 目的論(Teleology) 原因論(Causality)
定義 人間の行動は未来の目標や目的により方向づけられる 行動は過去の出来事・環境・生物学的要因によって決定される
行動の理解 「これから◯◯したい」
──意図が現在の行動を生む
「昔◯◯だったから」
──原因が行動を連鎖的に生む
過去の役割 目的を合理化するための素材として意味付け 行動を直接規定する決定因
未来・目標 未来志向:目標を再設定し行動を選択 過去志向:原因を特定し問題を理解
セラピーでの注目点 クライエントの望むゴールを明確化し、新しい行動を設計 トラウマや学習経験など原因の分析・再解釈
具体例 勉強しない子ども:
「失敗して自尊心が傷つくのを避ける」という目的
勉強しない子ども:
過去に厳しく叱責され学習=苦痛と条件づけられた
メリット / 限界 ◎ 変化志向でモチベーションを高めやすい
△ 過去の深層課題を見落とす場合がある
◎ 根本原因を理解し再発防止を図れる
△ 過去に囚われ変化が停滞しやすい

この考え方は、プロダクト開発でも役立ちます。チーム内の対立が起きたとき、表面的には「〇〇が期限までに実装を終えられなかったから問題が起こった」と原因論に終始するのではなく、「チームメンバーが積極的に助け合う仕組みを作らなかったのはなぜか? 実は誰もリードを取りたくなかったのでは?」と“目的”や“意図”に目を向けるほうが建設的です。

また、アドラー心理学では「誰の課題なのか」を区別する課題の分離というコンセプトも重視されます。プロダクト開発で言えば、エンジニアリングの課題はエンジニアが主体となって解決し、PdMはそれを尊重しつつサポートするという形が理想です。全力でサポートはするが余計な介入をせず、それぞれが本来の責任範囲をしっかり全うするための思考法として応用しやすいと感じます。

「嫌われる勇気」とは何か?:自由に生きるための心構え

書名にもなっている「嫌われる勇気」という言葉には、「他者に嫌われることを推奨する」意味合いはありません。むしろ、“自分が信じる価値観や目標に真摯であるならば、他者から否定されるリスクを恐れすぎなくていい”というメッセージです。多くの人が「嫌われたくない」という思いから、行動を制限したり自分の意見を殺したりします。しかしアドラーは、それでは自分の人生を生きているとは言えないと断じます。

プロダクトマネージャーの日常を振り返ると、

  • 「嫌われたくないから、経営層からの無茶なリクエストに対しても断れない」
  • 「チームメンバーの反発が怖いから、不要だと感じているタスクの一部を引き受ける」

といったケースがあるかもしれません。でも、こうした迎合は短期的には波風を立てませんが、長期的にはプロダクトの方向性を歪める原因になります。“自分の信念に基づく決断を恐れない姿勢”は、PdMがビジョンを守り抜くうえで重要といえます。プロダクト全体や新機能のコンセプトを揺るがない軸に設定するためにも、周囲への過剰な迎合を捨てる勇気が必要です。

競争優位を築く「プロダクト全体や新機能のコンセプト」のつくり方
はじめに――コンセプトが曖昧だと何が起こるのか「コンセプトづくり」を蔑ろにすると、リリース後に「なぜユーザーは使ってくれないんだろう…」という残念な結果を招く可能性が高まります。どんなに技術的に優れていても、UIが綺麗でも、「なぜ作るのか」...

「承認欲求」からの解放がチームを強くする

アドラー心理学では、承認欲求を否定しようとします。人は誰しも他者から認められたいという思いを持ちますが、それが大きすぎると自分の軸を失い、他人の評価ばかりを気にしてしまうからです。書籍の中では「人からほめられることは必要ない。むしろ、自分の成長や行動を自身で評価することが大切」という考えが繰り返し強調されます。

この点はプロダクト開発の現場でも示唆に富みます。エンジニアやデザイナーのモチベーションを高めるには、上司の評価を待つだけでなく、自分たちで何を達成したかを客観的に振り返る仕組みが重要です。たとえば、プロダクトリリース後のユーザーインタビューやNPS調査をチームで共有し、「ここまで顧客体験を改善できた」という成果をメンバー自身が実感できるようにする。承認欲求に縛られないチームほど、純粋にプロダクトの価値向上に集中できることは想像に難くないはずです。

「協力」を促すアドラー流コミュニケーション

アドラーは“すべての対人関係を「横の関係」で考える”ことを推奨します。これは「上か下か」ではなく、「同じ目線で対等に話す」という姿勢。上司だからエンジニアを指示・管理するのではなく、互いの業務範囲を尊重し、情報共有しながらプロジェクトを進めることを重視します。アドラー心理学では、人を支配するでも服従するでもなく、あくまで仲間として協力する態度がベストだと説かれます。

プロダクトマネージャーとしては、いかにチームをまとめて成果を出すかが勝負です。しかし、声が大きいだけのトップダウンでは、メンバーの自主性を削いでしまい、結果的に生産性を落とす可能性があります。「横の関係」を意識しながら、メンバー各自に課題の所有権を持たせ、PMはサポーターとして動く姿勢が理想です。こうしたアドラー流コミュニケーションは、特に多様なバックグラウンドのメンバーが集まるチームでは大きな効果を発揮します。

具体的な活用法:タスク分離・早期エスカレーション・OKR導入

『嫌われる勇気』のエッセンスを踏まえて、プロダクトマネージャーが実務でどう活かせるか、いくつか具体例を挙げます。

1. タスク分離と責任範囲の明確化

アドラーの「課題の分離」は、プロジェクト管理にも応用しやすいです。誰が何を決定し、どこまで責任を負うのかを明確にすることで、他者の仕事に過干渉しないチーム文化を築けます。PMはプロダクト方針や優先度づけに責任を持ち、エンジニアは実装方法を決める。デザイナーはUI/UXの品質にコミットする。こうしたラインを引くことで、相互干渉のリスクを下げ、スピード感が上がります。フレームワークとしてはRACIチャートなどがおすすめです。

2. 問題を早期に指摘する

嫌われる勇気の要素を踏まえると、「この問題を指摘したらどう思われるだろう」という遠慮を減らせます。プロダクト開発では、一見些細な不安でも早めに共有して対策を講じるほどトラブルが大きくなる前に防げる。個人の内面に抱え込まずチーム全体で協力して解決する姿勢を促すのが大切です。

3. OKR(Objectives and Key Results)でチームを真の仲間に

承認欲求に惑わされず、横の関係で協力し合うチームを作るには、共通のゴールを明確にし、そこに向けた成果指標を共有する仕組みが有効です。OKRはまさに「全員が同じ方向を向いて、各自のタスクを主体的に遂行する」ためのフレームワーク。承認を得るためでなく、プロダクトのミッションや顧客価値を実現するために動く文化を育みやすいと感じます。

ユーザーリサーチドリブンでOKRを設定・運用の記事でもOKRは紹介しているのでぜひご覧ください。

ユーザーリサーチドリブンでOKRを設定・運用して組織とプロダクトを成長させる
OKR(Objectives and Key Results)は、組織やプロダクトチームが「何を目指すのか」を明確にし、成果を可視化するためのフレームワーク。しかし「OKRを導入したけれど、結局数字だけ追う形で形骸化してしまった…」という状...

「嫌われる勇気」を持つPMが直面する2つの壁

一方で、『嫌われる勇気』をそのまま実践すると、PMとして以下のような壁にぶつかるかもしれません。

1. 経営層や顧客からの圧力

PMが「嫌われる勇気」を持って「その要望はプロダクトの方向性と合わないのでやりません」と言ったとしても、社内外から大きな反発を受ける可能性があります。

そこは当たり前ですが、勇気だけではなく「なんでやらないか」をデータやユーザーインサイトと共に根拠を示し、丁寧に説明する姿勢が必要です。嫌われる勇気は「説明を省略してもいい」という意味ではないことに注意です。むしろ、筋の良い仮説や顧客理解をしっかり固めたうえで、堂々と断るのが理想です。

ユーザーインタビュー前に「筋の良い仮説」をチームで設定する具体的な方法やフレーム
本記事では、ユーザーインタビュー前に「筋の良い仮説をチームで設定する」ことの重要性と、具体的な仮説の設計方法を解説します。仮説が緩い、ぶれぶれだと、「インタビューしたはいいが、で、どうする?」状態になりがち。ここでは、私が培ってきた経験と多...

2. チーム内の“衝突”とどう向き合うか

横の関係を尊重していても、現実として意見の対立は起こります。アドラー的には衝突を恐れず「建設的に議論しよう」というスタンスですが、現場のPMとしては摩擦の後始末をどう進めるかが大事です。問題を個人批判にすり替えず、あくまで「プロダクトを良くするための衝突だ」という共通認識を浸透させるとスムーズに収束しやすくなります。

created by Rinker
¥1,485 (2025/04/28 16:35:54時点 Amazon調べ-詳細)

参考情報

・岸見一郎、古賀史健 (2013) 『嫌われる勇気』 ダイヤモンド社
・Alfred Adler (1927) The Practice and Theory of Individual Psychology, Harcourt Brace.
・Harvard Business Review (2020) “Power and Influence in Organizations.” Harvard Business Review, 98(5).
・当サイト関連記事:競争優位を築く「プロダクト全体や新機能のコンセプト」のつくり方
・当サイト関連記事:【2025年】ユーザーインタビューで起こるバイアスを徹底攻略!
・当サイト関連記事:ユーザーインタビュー前に「筋の良い仮説」をチームで設定する具体的な方法やフレーム
・当サイト関連記事:ユーザーリサーチドリブンでOKRを設定・運用して組織とプロダクトを成長させる

今日から実践できるアクション

1. 自分の“嫌われたくない”行動を見直す
周囲の要望を無条件に受け入れていないか、「断ると嫌われるかも」と過度に恐れていないかをチェックしてみる。もし思い当たるなら、それは本当に必要な妥協かどうか自問する。

2. 課題の分離でチームの責任範囲を整理
エンジニア、デザイナー、PdMなど役割ごとに「何を誰が決めるのか」を明確化する。干渉すべきでない領域をあらかじめ設定しておくと、意見の食い違いを防ぎやすい。

3. “横の関係”を意識したコミュニケーションの練習
次のミーティングで、無意識に「上から目線」になっていないかを振り返る。メンバーの提案に対して早まって否定せず、相手の視点を尊重したうえで持論を述べる。意外と少しの心がけで関係性が変わる。

Q&A

Q1: 「嫌われる勇気」を実践すると、周囲との摩擦ばかり増えませんか?
A1: 一時的に衝突が起こるかもしれませんが、本当に必要な場面での断固たる判断は、長期的にはチームやプロダクトのためになります。摩擦を避けたいなら、データやユーザー調査など裏付けを用意し、筋の通ったコミュニケーションを心がけることが重要です。

Q2: 課題の分離がうまくいかないときはどうすればいい?
A2: まずは書き出すのが有効です。プロジェクトのタスクや意思決定事項をリスト化し、「最終責任者は誰か」を一つひとつ明確にする。PdM以外でもエンジニアやデザイナーがリーダーを担う領域を作り、他メンバーはそこに干渉し過ぎないようにします。

Q3: 「承認欲求」を捨てるのは難しく感じます。
A3: 完全に捨てる必要はありません。誰しも認められたいという欲求は自然なものです。ただし、それに振り回されて行動を決めるのではなく、プロダクトのゴールや自分の成長を軸に意思決定できるよう意識を変えてみると良いです。

コメント

タイトルとURLをコピーしました