【イベントレポート】ただ断るだけじゃない。飯沼さんに聞く「Noを伝える技術」

サムネイル

なぜ「No」が言えないのか
「No」の目的は、断ることではなく「より良いYes」を引き出すこと
「No」を伝えるのは「勇気」ではなく「戦略」
「No」を直接使わない。「Not」で分解する伝え方の技術
相手から「No」と言われたら、「牛歩」で進める
質疑応答（Q&A）
まとめ

こんにちは。DMM.comでプラットフォーム開発本部の副本部長をしている石垣@i35_267です。

今回は、プロダクトマネジメントの分野で著名な飯沼亜紀さん（@LoveIdahoBurger）をお迎えし、「Noを伝える技術」というテーマで講演をしていただきました。

職場で「No」と言うことに、ストレスや難しさを感じた経験は誰にでもあるのではないでしょうか。「人間関係が悪くなるかもしれない」「理由を説明するのが面倒だ」「責任を負いたくない」。こうした懸念から、つい安易な「Yes」を選んでしまうことは少なくありません。その結果、本来やるべきでないことにリソースを割き、チームが疲弊し、プロダクトの本質的な価値が損なわれてしまうこともあります。

しかし、もし「No」が単なる拒絶ではなく、より良い未来を築くための戦略的なコミュニケーションツールだとしたらどうでしょうか。対立を生むのではなく、建設的な対話の出発点になるとしたら。本記事では、まさにその視点から「Noを伝える技術」をレポートしていきます。

飯沼さんの書籍「Noを伝える技術プロダクトマネージャーが教える「敵を作らずに断れるようになる」作法」

トップ

なぜ「No」が言えないのか

まず、人々が「No」を言いにくい主な理由として、以下の3点が挙げられました。

嫌われたくない: 人間関係が壊れることへの懸念があるため
説明が面倒: 「No」を言う側には説明責任が求められてしまうため
責任を取りたくない: 「Yes」であれば失敗の責任をみんなで分散できるが、「No」は一人で責任を負うことになるため

特に、説明が面倒という点では、「Yes」と言う際は「いいよ、いいよ、やっておくよ」というようにすぐに終わります。一方、「No」と言った瞬間に「なんで？」という疑問が投げかけられます。「No」を伝える側には説明責任が求められてしまい、これが非常に面倒に感じることがあるという点は共感できるところです。また、3つ目の責任の観点で言えば、みんなで「Yes」と決めて失敗した場合、その責任はみんなで分散させることができます。一方、自分一人が「No」と言って断り、結果としてプロジェクトがうまくいかなかった場合、責任を一人で負うことになってしまうかもしれません。

飯沼さんは、自分のマインドや精神的な負担を考慮すると、「Yes」と言ってしまう方が楽に感じるシーンは多いと指摘しています。とはいえ、安易な「Yes」は、トータルコストとして開発チームの工数を含めたコストを低く抑えているのかを常に問い直す必要があるとも述べています。

「No」の目的は、断ることではなく「より良いYes」を引き出すこと

まずもっとも重要なのは、「No」に対する考え方を根本から変えることです。飯沼さんによれば、「No」を伝える最終的な目的は、断ること自体ではありません。本当の目的は、まずい提案に対して安易に「Yes」と言ってしまう事態を避け、提案の質を向上させることで、最終的に自信を持って 「より良いYes」が言える状態を目指すことです。

この視点に立つと「No」はコミュニケーションの終着点ではなく、むしろ始まりを意味します。それは、目先の要求を断ることで、より本質的な価値へとリソースを再配分する「未来の価値への投資」です。このマインドセットは、チームを疲弊から守り、プロダクト開発をより前向きで生産的なものへと導きます。この「No」を「投資」として捉える視点は、非常に新鮮で参考になりました。

「No」を伝えるのは「勇気」ではなく「戦略」

「Noと言うには勇気がいる」という言葉をよく耳にしますが、飯沼さんはこれを「スキルと戦略の問題」だと指摘します。感情的なハードルとして捉えるのではなく、誰でも習得可能なプロフェッショナルスキルとして位置づけるのです。その戦略は、主に2つの要素で構成されます。

プロダクトのぶれない軸 : プロダクトビジョンやロードマップといった、明確な価値判断基準のことです。これは「何をやるか」を定義すると同時に、「何をやらないか」を決めるための強力な理由付けとなります。この軸があれば、個人の意見ではなく、プロダクトとしての方針に基づいた客観的な説明が可能になります。
コミュニケーション戦略 : 決定を相手にどう伝えるか、という意図的なアプローチです。感情的な対立を避け、相手の学びや納得感につなげるための技術が求められます。

「No」を伝える行為を、個人的な勇気の問題から、客観的な戦略の実行へと転換させること。これにより、拒絶は「あなた」対「私」という属人的な対立から解放されます。プロダクトという共通の目標に向けた、プロフェッショナルな対話の土台が築かれるのです。

「No」を直接使わない。「Not」で分解する伝え方の技術

前項で述べた「プロダクトのぶれない軸」と「コミュニケーション戦略」は、ここで紹介する具体的な技術によって実践に移すことができます。飯沼さんが提唱するのは、「No」という直接的な言葉を使わずにその意図を伝える 「Not」フレームワークです。これは、拒絶の理由を体系的に分解し、代替案や次善策を示すことで、対話を前進させる戦略的なアプローチです。

分解方法	内容	言い換えの例
Not Now (今ではない)	タイミングや優先順位、前提条件が理由の場合	「来月なら着手できます」「今の案件が終わり次第、取り組みます」
Not That Way (その方法ではない)	解決すべき課題は正しいものの、提案された解決策が最適ではない場合	他の方法を提案してみる
Not This Product (このプロダクトではない)	別のプロダクトやチーム、あるいは手動のオペレーションで対応する方が適切な場合	「他のプロダクト担当者を紹介します」
Not Aligned with Vision (ビジョンに合っていない)	要求がプロダクトの根幹をなすビジョンと矛盾している場合	曖昧な表現を避け、なぜビジョンと合わないのかを明確に説明し、はっきりと「No」と伝えることが相手の学びにつながり、より効果的である場合が多い

このフレームワークは、単に断るのではなく、なぜ断るのかという「理由」を構造化して提示します。これにより、相手は次に取るべきアクション（タイミングを待つ、方法を再検討する、適切な担当者を探すなど）を理解しやすくなり、対話が停滞するのを防ぎます。この「Not」で分解する技術は、実務で即座に活用できる点が印象的でした。

相手から「No」と言われたら、「牛歩」で進める

視点を変えて、自分が「No」と言われる側に立った場合はどうすればよいのでしょうか。ここでも戦略的な思考が求められます。飯沼さんは、過去のプロジェクトでの実体験を語ります。

当時、ある機能を実装しようとした際、現場オペレーションの複雑化を懸念するチームから強い抵抗、つまり「No」を突きつけられました。技術的には可能でも、現場で回らなければ意味がありません。そこで飯沼さんが取ったのは、「牛歩戦略」 でした。

まず、影響範囲が極めて限定的な最小ステップから始めました。そして、「これでもオペレーションに影響はなかった」という事実を一つひとつ積み重ね、徐々に対象範囲を広げていったのです。この戦術は、相手の懸念を最小化し、反論の余地がない小さな成功体験を共有することで信頼を築き、最終的に大きな変革へと繋げる強力なアプローチであることを示しています。

質疑応答（Q&A）

講演後、聴講者からの質問に対し、飯沼さんに回答してもらいました。Q&Aセクションでは、ふるじゅんさん（@design_oldriver）がファシリテーションを担当し、kyon_mmさん（@kyon_mm）もQ&Aから参加していただきました。
DMMの中に実際にPdMとして働いているメンバーから実務に直結する質問が多く寄せられ、飯沼さんの経験に基づく具体的なアドバイスが展開されました。

当日いただいた質問は以下のようなものがありました。

エンジニアからPdM/PMに変わったばかり。ここだけはしっかり持っていて欲しいという意識はありますか？
コミュニケーションスキルといった無形のアウトプットのティーチングに悩んでいます。実践されているティーチング方法はありますか？
PdMもやろうと思えばデザインまでできてしまう昨今、デザイナーとPdMの境界について今後どのようになっていくと思いますか？
上流工程（影響範囲調査、見積もり、基本設計）に時間がとてもかかる場合の対応経験はありますか？
2つ以上のプロダクト間のやり取りで「No」と言われる側に立ったとき、それでも「Yes」として進めたい場合のヒントはありますか？
RICEやMoSCoWといった優先順位付けのフレームワークのメリット・デメリットは？
プロジェクトメンバーに対する厳しさと優しさのバランスについて意識していることはありますか？
エンジニアリングチームで期待されるパフォーマンスを発揮できていないメンバーがいた場合、何が原因かを探りますか？またその後の期待値の再設定や育成計画をどのように行いますか？
タイパ重視の方へ遠回りしてみたい時の刺さる言い方や、テレワーク会議においてやっていいこといけないことはありますか？
AI導入の結果として、それまで人間が費やしてきた非効率なプロセスを特定できた事例があれば教えてください。AIが事業のボトルネックを解消した具体的方法に興味があります。
シニア PdM から思考回路を盗みたい。相手から思考プロセスを開示させるための質問やコミュニケーション方法があれば教えて欲しいです。
プロダクトマネージャーやそれに類する立場の人は、そのプロダクトチームの運営にどこまで関与し責任を持つべきでしょうか？
オペレーションとテクノロジーの組み合わせで、もっとも成功した事例あるいは失敗から学んだ事例を具体的に聞きたいです。
ビジョンを決めるにあたり、完璧主義と調査不足の境目はどこでしょうか？
プロダクトマネージャーとしてここはさすがに譲っちゃだめと思う点があった時、Notで分解する以外に意識されたり実践されていることはありますか？

この中から抜粋して3つほど、Q&Aを紹介します。

Q: プロダクトマネージャーとしてここはさすがに譲っちゃだめと思う点があった時、Notで分解する以外に意識されたり実践されていることはありますか？

飯沼さんによれば、基本的には衝突を避けようとはあまり思っておらず、必要な衝突はするべきだと考えているというのが印象的でした。重要なのは、衝突をどれだけ生産的で意味のあるものにできるかであり、そのためには相手の見極め（ぶつかって良い相手か）と、日頃からの信頼関係の構築が大きく関わってきます。

一方、戦略的な回避とねじ曲げとして、ぶつかってはいけない相手（極端な例として大企業におけるトップマネジメントなど）からオーダーが来た場合は、いったん衝突をしないで「Yes」として受け入れる戦略を取る必要もあります。この場合、受けたうえでどうこちらの土俵に持ってきて相手と進め方をすり合わせていくのかというテクニックを磨くことが重要で、最終的に生産的な会話ができるよう、日々の関わり方や、ぶつかっていい相手かどうかの見極めが鍵となるという点も参考になりました。

Q: シニア PdM から思考回路を盗みたい。相手から思考プロセスを開示させるための質問やコミュニケーション方法があれば教えて欲しいです。

飯沼さんによれば、シニアPdM（プロダクトマネージャー）から思考プロセスを開示させるには、コンテキストを共有していない相手と会話するのが非常に有効であると推奨していました。質問者は、相手（おそらく身近な上司など）から「考えた結果の言葉」しか出てこず、その裏にある思考プロセスを引き出すのに苦労していることを指摘していました。飯沼さんは、上司と部下の関係性では、プロダクトの実務の話に寄り過ぎがちであり、結果として「考えた結果の言葉」が多くなってしまうため、思考プロセスを聞き出すのが難しいと感じているとのことです。

飯沼さんの戦略は、「他部署の人」や「他の会社の人」など、少し遠いところにいるシニアなプロダクトマネージャーに話を聞いてみる、というものです。

抽象化の強制 : コンテキストを共有していない相手と話す際は、自分の今の状況を抽象化したうえで話す必要があります。
抽象度の高い回答の獲得 : 質問が抽象化されているため、それに対する回答も抽象度の高いものが出てくる傾向があります。
具体的な質問による深掘り: 抽象度の高い回答が返ってきたら、聞き手（質問者）は「具体的にそれってどういうことですか？」「その時どういう風に行動したんですか？」といった具体的な質問を差し挟みます。
往復運動による思考の引き出し : この抽象と具体を行ったり来たりする（往復させる）ことによって、シニアPdMの思考のプロセスが引き出されやすくなるとしています。

この方法は、質問の仕方について「ユーザーインタビューに似ている」という指摘もありました。単に「どう思いますか？」と聞くと、相手はたくさん悩んだ末の「綺麗なロジック」だけを伝えるため、工程を一緒に追っていくような質問の仕方が有効であると考えられるとのことです。飯沼さんは、社外や他部署など、コンテキストを共有していない相手との会話の方が、このプロセスを開示させるのはやりやすいだろうと結論づけていました。この抽象と具体を往復させる質問のテクニックは、実務で即座に活用できる点が印象的でした。

Q: プロジェクトメンバーに対する厳しさと優しさのバランスについて意識していることはありますか？

飯沼さんは、リーダーシップにおける自分のスタンスを 「優しさ100%」 だと語っていました。しかし、その意味は一般的に考えられるものとは少し異なります。

飯沼さんがもっとも「残酷」だと考えるのは、メンバーに対して何でも「いいよ、いいよ」と受け入れ、厳しいフィードバックを避けることです。それは一見優しく見えても、相手の成長の機会を奪う行為に他ならないとのことでした。優しさがあれば、必要な厳しさは出せるという考え方で、優しさの中には、甘さではなく、相手のためを思っている利他的な愛情が含まれているべきだと考えているという点が印象的でした。