$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Noを伝える技術2025: 爆速合意形成のためのNICOフレームワーク速習 #pmconf2025
Search
Aki / @LoveIdahoBurger
December 04, 2025
Technology
1
110
Noを伝える技術2025: 爆速合意形成のためのNICOフレームワーク速習 #pmconf2025
pmconf2025の登壇内容です。(PM Jam)
Aki / @LoveIdahoBurger
December 04, 2025
Tweet
Share
More Decks by Aki / @LoveIdahoBurger
See All by Aki / @LoveIdahoBurger
プロダクトマネージャーのキャリアQUEST - pmconf2024 落選セッションお披露目会 #落選お披露目
aki_iinuma
5
6.5k
その機能、今作る必要ある?
aki_iinuma
9
3.2k
その失敗から何を学ぶ?不確実性をマネジメントして目標達成するための心得 #webtan
aki_iinuma
30
7.5k
リアルで価値を発揮するデジタルプロダクトを開発する
aki_iinuma
5
2.6k
プロダクトマネジメント組織立ち上げの課題と落とし穴と楽しみ #pmconf2022
aki_iinuma
25
17k
決済に関する地味な話 #地味PMmeetup
aki_iinuma
7
2.8k
Noを伝える技術 #pmconf2021
aki_iinuma
237
210k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
54k
Other Decks in Technology
See All in Technology
AIにおける自由の追求
shujisado
2
450
MCP・A2A概要 〜Google Cloudで構築するなら〜
shukob
0
140
[続・営業向け 誰でも話せるOCI セールストーク] AWSよりOCIの優位性が分からない編(2025年11月21日開催)
oracle4engineer
PRO
1
220
ページの可視領域を算出する方法について整理する
yamatai1212
0
160
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
3.3k
生成AIシステムとAIエージェントに関する性能や安全性の評価
shibuiwilliam
2
310
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
9.8k
Design System Documentation Tooling 2025
takanorip
1
880
生成AI・AIエージェント時代、データサイエンティストは何をする人なのか?そして、今学生であるあなたは何を学ぶべきか?
kuri8ive
2
1.1k
インフラ屋さんはAIコーディングエージェントとどう生きるか/How infrastructure engineers interact with Kiro
ozawa
2
110
一億総業務改善を支える社内AIエージェント基盤の要諦
yukukotani
9
2.7k
オープンデータの内製化から分かったGISデータを巡る行政の課題
naokim84
2
1.3k
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Facilitating Awesome Meetings
lara
57
6.6k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.3k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Code Review Best Practice
trishagee
73
19k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.2k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
The Cult of Friendly URLs
andyhume
79
6.7k
Scaling GitHub
holman
464
140k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.8k
Transcript
Noを伝える技術2025 爆速合意形成のためのNICOフレームワーク速習 飯沼亜紀
2 経歴 ソニーデジタルネットワークアプリケーションズ 経営企画→新規事業のプロダクトマネージャー ユニクロ / ファーストリテイリング プロダクトマネージャー、プロジェクトマネージャー、新規事業 日本マクドナルド プロダクトマネージャー
キャディ プロダクトマネージャー、プログラムマネージャー、 Head of Product Design 2024年10月に独立、2025年9月より現職 やっていること オペレーションとテクノロジーの両方を使って世の中を良い方向に 変えていこうとしている野良プロダクトマネージャー Aki Iinuma 飯沼亜紀 𝕏: @LoveIdahoBurger
過去の栄光(「Noを伝える技術」の元ネタ) ⭐pmconf2021 参加者アンケート 満足度 1位セッション 🎖 ⭐Speakerdeck 2021年に最も読まれたスライド トップ10入り🎖
本日のセッションについて 書籍「Noを伝える技術」より、NICOフレームワークを扱い ます。今日1日でNICOフレームワークを使いこなせるよ うになるのが目標です。 資料は後ほど公開しますので、文字の細かい部分は資料 公開時にご確認ください。 (細かい字がたくさん出てきます、許して!) 前半 理論パート 後半
実践パート 小休止 抽選応募タイム
必要な前提知識 • よいプロダクトをつくるためには必要な時にNoを伝えることが重要 • Noを伝えるには技術が必要 • Noを伝えるにはまずNotで分解して伝え方を考えるとよい Noは「拒否」ではなく、プロダクトの未来の価値を最大化するための「選択の技術」
理論編
これで万事解決じゃない?
実際に寄せられる相談・起こっている問題 Notで分解するという技術は広まったが、その判断を場で通す技術が足りていないかもしれない Notで分解しても相手が納 得してくれない もっと説明を求められる Notは正しく選べているの にYes以外の選択肢がな い Notを選んだ後、それをど う伝えるのがよいかわか
らない
Notは超強力だが、万能ではない 材料整理が下手だと 精度が落ちる 判断のラベルには最適だが 合意形成には軽すぎることがある 政治や感情を前にすると 押し通すのが大変 しっかりねっとり説明して Noを受け入れてもらうことができて、 しかも資料化しやすい整理によって重厚な説明責任にも対応できるような何かはないのか
…!?
今日は皆さんに新しい武器を持ってきました 伝わる内容に翻訳・伝達 NICO 判断・伝達方針の決定 Notでの分解 Notをロジックに変換 3C 直感 ロジック ストーリー
3C Notを正しい判断に着地させるためにまず3Cでロジックを整える C: Context 何が起きている? →事実を一言で C: Contrast 何が変化を生んでいる? →背景を数字や因果で見せる
C: Consequence Yes/Noそれぞれの未来は? →判断の結果を想像させる Notでの分解 Noと思ったらまずNotで分解 し判断・伝達の方向性を決定 NICO 次ステップのNICOで 伝わる形にする
理論武装に「伝わるストーリー」を与えるNICO Notでの分解 : 判断・伝達のラベルを選択 3C:判断材料を整える(ロジック) Context 状況をシンプルにまとめる Conrast 比較軸・仮説の整理 Consequence
Yes/Noの未来を並列化 NICO:判断を通す(ストーリー) Need:相手の目的 Insight:核心の気づき Choice-of-No:Not+代替案 Outcome:守れる価値
試してみましょう:3Cでの整理 3C の要素 内容 状況(Context) 何が起きているかを確認する ・毎月の食費が予算オーバー(平均で 10,000 円超過) ・デリバリーサービス利用が月
8 回 対比(Contrast) 背景を数字や因果で見せる ・スーパーの冷凍食品に置き換えると 40〜70% 安い ・大型スーパーへの往復と買い物で 2.5 時間/回 ・冷凍庫の空きスペースが現在 30% 程度 帰結(Consequence) Yes・Noそれぞれの影響を確認する ・No(行かない)→ 食費が減らない、時間ロスなし ・Yes(行く)→ 月 2 回で予算達成、所要 5 時間、冷凍庫に入り切らない恐れあり 家族から「食費の節約のために、来月から週末に郊外の超大型スーパーで食材のまとめ買いをしよう」という提案が あった時の3C
3C(ロジックでの整理)からNICO(伝わるストーリー)へ N: Need 依頼者が解決したいニーズ・期待 I: Insight データや定性調査から得た事実や 洞察 C: Choice-of-No
No の根拠とその代替案(条件付き 選択肢) O: Outcome Yes・No それぞれの判断によって守 れる価値・得られる効果・未来 C: Context 何が起きている? →事実を一言で C: Contrast 何が変化を生んでいる? →背景を数字や因果で見せる C: Consequence Yes/Noそれぞれの未来は? →判断の結果を想像させる
NICOが効くのは相手の世界と自分の判断の両方を踏まえるから N: Need 相手は何を求めている? →言われたことの真意を掴む I: Insight なぜそう判断する? →事実・因果関係理解 C:
Choice-of-No 最適なNotと代替案は? →選択肢の提示 O: Outcome Yes/Noそれぞれの未来は? →相手が動ける未来を描く 相手の世界 自分の判断 現状(理解) 未来(選択)
試してみましょう:NICOでの整理 NICO 内容 Need 依頼者が解決したい ニーズ・期待 • 毎月の食費が予算オーバーの傾向にある ◦ 直近
6 ヶ月の平均は +10,000 円 • 多少の手間や時間をかけてもいいので予算内に収めたい • デリバリーの利用(月 8 回、約 28,000 円)が予算に大きく影響していると思われるため、これをスーパーの冷凍食品に 置き換えて目標達成したい • 郊外の大型スーパーで業務用の大容量パックを購入することでコスト効率を上げたい Insight データや定性調査から 得た事実や洞察 • スーパーの冷凍食品の価格を調査したところ、デリバリーで注文するのと類似メニュー、同等のボリュームの食事が 40〜70% 安い価格で購入できそう ◦ コスト削減効果は月間約 15,000 円 • 大型スーパーへの往復と現地での買い物にかかる時間は 1 回あたり 2.5 時間程度 • 冷凍庫の空きスペースは 30% 程度 Choice-of-No No の根拠とその代替 案 (条件付き選択肢) • Not でのラベリング ◦ その方法ではない( Not That Way) ▪ 冷凍庫の空きスペースが不足しているので大容量の冷凍食品で代用するのは現実的ではない ◦ 今ではない(Not Now) ▪ 冷凍庫の空きスペースができてから再検討 • 代替案 ◦ 近所のスーパーで週 2 回、冷凍庫に入る分だけ冷凍食品を購入
試してみましょう:NICOでの整理 NICO 内容 Outcome Yes・No それぞれの判 断によって守れる価値 ・得られる効果 • やる場合
◦ 郊外の大型スーパーへの月 2 回の買い出し ▪ 食費削減効果 15,000 円程度 ▪ 買い物所要時間 月 5 時間 ▪ 冷凍庫のスペース不足で十分なまとめ買いができず想定どおりのコスト削減効果が出ないリスク • やらない場合 ◦ 近所のスーパーで週 2 回買い物 ▪ 食費削減効果 10,000 円程度?(まだ価格調査をしていないので保守的に算定) ▪ 買い物所要時間 月 4 時間 ▪ 必要な分だけこまめに買い出しをするため冷凍庫スペースの心配なし • 再評価条件 ◦ 近所のスーパーで購入した冷凍食品に置き換えて 2 週間のコスト削減幅を確認し、 5,000 円以上の改善が見 られない場合、自炊などさらに低コストな方法を検討 ◦ 冷蔵庫のスペースを整理し空きを広げる余地があるか確認、 60% 以上の空きスペースが確保できそうであれ ば大型スーパーでの買い出し案を再評価
練習問題 普段から向き合っているプロダクトに関連する題材でのトレーニングがベストですが、咄嗟 に出てこない人のために… • 義母から突然の「今週末お邪魔するわ」 • 友人からの「飲みに行こうよ!」の誘い • PTAでの係の依頼 •
友人に「この商品、買うべき?」と相談される • チームメンバーからの明らかに筋の悪い相談 • 仕事が立て込んでる時に上司からの「皆でランチ行こうよ!」の誘い
小休止の間に…アンケート&抽選企画があります 回答時に「プレゼントを希望する」を選択した方から抽選で 10名様に書籍「Noを伝える技術」(著者 サイン入り)のプレゼントがあります。 当選発表はこのセッションの最後に実施します!
実践編
PM Jamとは「問いを中心にPMが互いの思考を磨き合う場」 Why(目的) • 検索できない知を言語化し、継承・再構築するため の実験 • プロダクトマネジメントの「判断の背景」を共有し深 めるための仕組み •
個人の学びを全体の知に変換する仕組み How(仕組み) • 月1の1on1セッション(録画共有)で他者の問い・思 考過程を観察 • Slackでの非同期Jamによる日常的な学び • 外部発信(note等)で思考を構造化し知を還流 特徴 • 師弟でも講義でもない「相互作用による知」 • 準備・即興・観察による思考の循環 • 小さなコミュニティが生む成長の加速度 プロダクトマネージャーの学び方を再発明す る実験場 詳しくは: 🔎学びのデザインパターン
メンバー紹介 山下 大智 株式会社リクルート プロダクトマネージャー 主な仕事 • スタディサプリのプロダクトマネジメント • 学習ゲーミフィケーション機能と学校向けテスト
システムを担当 野田 遥 株式会社 LITALICO プロダクトマネージャー 作業療法士 &研究者 =>PMに LITALICO発達特性検査 / LITALICO健診ソフトの プロダクトマネジメント・事業開発・研究開発を担 当 右田 涼 株式会社カミナシ プロダクトマネージャー 2024年にカミナシに入社。 工場 DX サービス『カミナシ 設備保全』のプロ ダクトマネージャー。元データ人材。
NICO 目的・内容 Need 依頼者が解決したいニー ズ・期待 • 友達と対戦したい/クラス同士で競わせたいという要望 • 競争要素を加えて生徒の学習意欲をさらに高めたい Insight
データや定性調査から得 た事実や洞察 • データや定性調査の事実として、サプモンの長期継続利用率は 高くないことが分かっている • 機能の設計思想が「 3〜6ヶ月で卒業していくこと」を前提として おり、長期継続を想定していない Choice-of-No No の根拠とその代替案 (条件付き選択肢) • Not Aligned with The Vision(ビジョンと合っていない) • サプモンの機能ビジョンは「学習への入り口としての楽しさ」であ り、最終的には「学ぶこと自体の楽しさ」へ動機をシフトさせるこ とにある。対戦機能で "遊び"を強化しすぎると、このビジョンから 逸脱してしまう Outcome Yes・No それぞれの判 断によって守れる価値・ 得られる効果 • Yesの場合:短期的な数値向上は見込まれる • Noの場合:学習モチベーション設計の本質(内発的動機への移 行)を見失わない • 再評価条件:特定のユーザーセグメントで、学習ゲーミフィケー ションを主要戦略へ変更する場合 事例:Noと言えた例 スタディサプリの動機づけ機能「サプモン」 学習と連動してサプモンを入手・育成できる
NICO 目的・内容 Need 依頼者が解決したいニーズ・ 期待 • 30人 × 複数クラスを担当する講師・先生が、生徒ごとの学習状況を正確に把握す るのが難しい
• 労力なく生徒の学習状況を把握でき、生徒にも同じ画面を見せることでモチベー ションアップしたい Insight データや定性調査から得た事 実や洞察 • かねてより講師用プロダクトへの VoC が複数存在していた • Figma で画面を作って講師に見せると反応はいい Choice-of-No No の根拠とその代替案(条 件付き選択肢) ※もし、あの時に戻るなら その方法ではない(Not That Way) • 「データを集計するのが手間」「学習状況を把握したい」を実現するのであれば、 ダッシュボードではなく、CSVのダウンロードやスプレッドシートでも小さく試すこと はできたはず • ダッシュボードという機能名や Hi-Fi なプロトタイプ画面が一人歩きしていた。社内 から「いつリリースされるのか」と声が上がるほど期待感があった。プロジェクトに着 任したてで、ここで No が言えなかった。 Outcome Yes・No それぞれの判断に よって守れる価値・得られる 効果 Noを選べなかったことで... • 数ヶ月かけてリリース→ログを見ても使われない・利用定着しない • 現場訪問すると、想定シーンで見られていない • 検証期間を経て、機能クローズを判断 • Hi-Fiなプロトタイプに引っ張られてしまった。違和感が合った時に、小さく試す ことを考えて、小さく No ということもできたのではないか? • 本来ならば他の開発に使えた時間を失ってしまったのが痛手だった 事例:Noと言えなかった例 講師向けアプリ:生徒の学習進捗画面 ( ※ 画像は AI で作成したもので実際のものではありません )
NICO 目的・内容 Need 依頼者が解決したいニーズ・期 待 • 製品版の1stリリースに向けた開発( 0→1フェーズ) • 顧客「園から回答を受け付けられるフォームが欲しい」
Insight データや定性調査から得た事 実や洞察 • 所感としては今すぐの対応でなくとも契約は可能そう • ロードマップには既に載っていたが、翌年度開発を想定 • 対応すると工数面でのデリバリーリスクが大きい状態 Choice-of-No No の根拠とその代替案 (条件付き選択肢) Not Now(今ではない) • 次フェーズでの実装を提案 Not That Way(その方法ではない) • Opsサポートによる運用が可能と判断 Outcome Yes・No それぞれの判断に よって守れる価値・得られる効 果 • Yesの場合:顧客満足度確保、ただしデリバリーリスクが上昇 • Noの場合:価値提供は先送りになるが、リソースを他の重要機能に集 中でき、より計画的なデリバリーが可能 • 再評価条件:最重要顧客のため、作らないと失注する場合のみ検討 が必要 事例:Noと言って失敗した例 野田「園向けフォームは翌年度対応で顧客と合意!良かった」 取りこぼしのない 「発達のチェックポイント」を持続可 能にする 5歳児健診用の 自治体向けSaaS (BtoGtoC)
NICO 目的・内容 Need 依頼者が解決したいニーズ・期 待 • 製品版の1stリリースに向けた開発( 0→1フェーズ) • 顧客「園から回答を受け付けられるフォームが欲しい」
Insight データや定性調査から得た事 実や洞察 • 所感としては今すぐの対応でなくとも契約は可能そう • ロードマップに既に載っていたが、後のフェーズを想定 • 対応すると工数面でのデリバリーリスクが大きい状態 Choice-of-No No の根拠とその代替案 (条件付き選択肢) Not Now(今ではない) • 次フェーズでの実装を提案 Not That Way(その方法ではない) • Opsサポートによる運用が可能と判断 Outcome Yes・No それぞれの判断に よって守れる価値・得られる効 果 • Yesの場合:顧客満足度確保、ただしデリバリーリスクが上昇。 • Noの場合:価値提供は先送りになるが、リソースを他の重要機能に集 中でき、より計画的なデリバリーが可能 • 再評価条件:最重要顧客のため、作らないと失注する場合のみ対応検 討が必要 事例:Noと言って失敗した例 野田「園向けフォームは翌年度対応で顧客と合意!良かった」 取りこぼしのない 「発達のチェックポイント」を持続可 能にする 自治体が実施する 5歳児健診向け プロダクト 開発を進めて数ヶ月後、顧客から連絡が・・・ 「他社の機能をふまえて、やっぱり園向けフォームは 初年度から必要になりました」
NICO 目的・内容 Need 依頼者が解決したいニーズ・期 待 • 製品版の1stリリースに向けた開発( 0→1フェーズ) • 顧客「園から回答を受け付けられるフォームが欲しい」
Insight データや定性調査から得た事 実や洞察 • 所感としては今すぐの対応でなくとも契約は可能そう • ロードマップに既に載っていたが、後のフェーズを想定 • 対応すると工数面でのデリバリーリスクが大きい状態 Choice-of-No No の根拠とその代替案 (条件付き選択肢) Not Now(今ではない) • 次フェーズでの実装を提案 Not That Way(その方法ではない) • Opsサポートによる運用が可能と判断 Outcome Yes・No それぞれの判断に よって守れる価値・得られる効 果 • Yesの場合:顧客満足度確保、ただしデリバリーリスクが上昇。 • Noの場合:価値提供は先送りになるが、リソースを他の重要機能に集 中でき、より計画的なデリバリーが可能 • 再評価条件:最重要顧客のため、作らないと失注する場合のみ対応検 討が必要 事例:Noと言って失敗した例 野田「園向けフォームは翌年度対応で顧客と合意!良かった」 取りこぼしのない 「発達のチェックポイント」を持続可 能にする 自治体が実施する 5歳児健診向け プロダクト 最重要顧客の契約に必要・・・ エンジニア増員により ロードマップを前倒して開発することにした
NICO 目的・内容 Need 依頼者が解決したいニーズ・期 待 • 製品版の1stリリースに向けた開発( 0→1フェーズ) • 顧客「園から回答を受け付けられるフォームが欲しい」
Insight データや定性調査から得た事 実や洞察 • 所感としては今すぐの対応でなくとも契約は可能そう • ロードマップには既に載っていたが、翌年度開発を想定 • 対応すると工数面でのデリバリーリスクが大きい状態 Choice-of-No No の根拠とその代替案 (条件付き選択肢) Not Now(今ではない) • 次フェーズでの実装を提案 Not That Way(その方法ではない) • Opsサポートによる運用が可能と判断 Outcome Yes・No それぞれの判断に よって守れる価値・得られる効 果 • Yesの場合:顧客満足度確保、 ただしデリバリーリスクが上昇 =>実は作らないと失注するリスクがあった • Noの場合:価値提供は先送りになるが、リソースを他の重要機能に集 中でき、より計画的なデリバリーが可能 • 再評価条件:最重要顧客のため、作らないと失注する場合のみ対応検 討が必要 事例:Noと言って失敗した例 当時の判断として 悪くはない しかし後になって考 えるとベストではな かった
Noを伝える技術だけでなく、Noの根拠を疑う技術も大事 反省:根拠をもとにNoを伝え、顧客も一度は納得した。でも失敗だった。 プロダクトマネージャーとしてはトラブル対処以上に予防が大事 現在だけではなく未来 をみるべし 「あるべき姿(未来)」より 「現状の声(現在)」を優先した 失敗要因 2: 近視眼的な判
断 顧客の要望が将来も変化しないと 静的に捉えた予測の甘さ 失敗要因 1: 変化への楽観 視
まとめ