この記事の要約
- ユーザーやステークホルダーの「具体的な要望」をそのまま開発に渡してしまい、機能が肥大化・複雑化する「伝書鳩PdM」から脱却する
- 『具体と抽象』が説く「抽象化＝情報を捨てて本質を抜き出すこと」をプロダクト開発プロセス（N=1分析→コンセプト設計→仕様策定）に適用する
- ユーザーの「不満（具体）」を「課題（抽象）」に変換し、再び「解決策（具体）」に落とす『往復運動』が必要
プロダクトマネージャー（PdM）として働いていると、日々大量の「具体」を浴びせられます。
- 「このボタンは赤くしてほしい」
- 「Excelへのエクスポート機能が絶対に必要だ」
- 「競合のA社にあるあの機能をつけてくれ」
これらを一つひとつ丁寧に聞いて、そのままエンジニアに「これ作って」と伝える………..。これはPdMの仕事ではありません。ただの「伝書鳩」です。
伝書鳩になってしまうと、プロダクトは悲惨なことになります。
機能はつぎはぎだらけで複雑化し、メンテナンスコストは肥大化し、最終的には「何がしたいのか分からない」巨大なシステムが残る。
優れたPdMは、この「具体」の波に飲み込まれません。
一度「抽象」の世界に潜り、本質を掴んでから、再び「具体（解決策）」の世界に戻ってくる。この「具体と抽象の往復運動」こそが、PdMが付加価値を出すために必要な思考です。
本記事では、思考法のベストセラー『具体と抽象』（細谷功 著）の概念を、プロダクトマネジメントの現場でどう実践するか、その具体的な技術について解説します。
なぜ、優秀なPdMは「抽象」と「具体」を行き来するのか？
「伝書鳩」と「アーキテクト」の違い
なぜ「言われた通りに作る」のがダメなのでしょうか。
それは、ユーザーやステークホルダーが見ているのは「自分の目の前の困りごと（局所最適）」だけだからです。
- 伝書鳩（具体→具体）：
「検索できないから検索窓をつけて」と言われて、検索窓をつける。
→ 解決策が「検索窓」に固定されてしまう。 - アーキテクト（具体→抽象→具体）：
「検索できない」という声を、ユーザーリサーチの具体を集めて「ユーザーは目的のデータに辿り着くのに時間がかかっている（探索コストの問題）」と抽象化する。
→ 解決策は「検索窓」だけでなく、「履歴の表示」「レコメンド」「フィルタリング」など、よりスマートな選択肢（具体）が見えてくる。
このように、一度抽象化することで、解決策の自由度が爆発的に上がり、より汎用的で本質的な機能を設計できるようになるのです。
抽象化とは「情報を捨てる」勇気である
書籍『具体と抽象』の中で最も重要なポイントは以下だと、僕は考えています。
「抽象化とは、複数の事象から共通する特徴（法則）を抜き出し、それ以外の要素（枝葉）を捨てることである」
多くのPdMが抽象化できない理由は、「情報を捨てるのが怖いから」です。「Aさんはこう言った、でもBさんはこう言った」と、全ての情報を大事に抱え込むと、共通項は見えなくなります。
「今回は年齢や職種の違い（枝葉）は捨てる！ 共通しているのは『入力時の不安』だ！」このように、勇気を持って情報を切り捨てた人だけが、本質（抽象）に辿り着けます。
プロダクト開発における「抽象の設計」3つのステップ
では、実際の開発プロセスでどう往復運動を行うのか？以下の3ステップを意識してください。
Step 1：”具体の海”に潜る（N=1の収集）
抽象化するためには、その元となる「濃厚な具体」が必要です。
ここをおろそかにして抽象論を語ると、ただの「空理空論」になります。
定量分析では埋もれる「N=1ユーザー」の異端なニーズでも触れましたが、まずは徹底的に個別の事象を見ます。
- 「田中さんは、月末の請求処理で3回エラーを出して舌打ちをした」
- 「鈴木さんは、画面を開いた瞬間に『うわっ』と言って閉じた」
このリアリティのある「具体」を集めることがスタートです。
Step 2：抽象の山に登る（モデリング・Whyの特定）
次に、集めた具体から「要するに何か？（What is this?）」を問います。
ここで「情報を捨てる」勇気が試されます。
- 具体： エラーで舌打ち、画面を見て閉じる、マニュアルを何度も見る……
- 捨てる情報： ユーザーの属性、操作した時間帯、画面の種類
- 残す情報（抽象）： 「システムからのフィードバックが遅く、自分の操作が正しいか確信が持てない（認知的不協和）」
ここまで抽象化できれば、課題は「UIの見た目」ではなく「システムとの対話性（インタラクション）」にあると定義できます。
Step 3：再び具体へ降りる（Howの策定）
抽象化したコンセプト（認知的不協和の解消）を実現するための、最も工数が少なく効果が高い「具体策（UI/機能）」を選びます。
ここで、具体的な”Why（抽象）”を必ず含めて初めてエンジニアと会話しましょう。というか、ここの”具体”はエンジニアに考えてもらったり、エンジニアと一緒に考えたりするのもおすすめです。
「ユーザーは不安がっている（抽象）。だから、処理中はスピナーを出し、完了したら緑色のチェックマークを0.5秒で表示させたい（具体）」
このプロセスを経た仕様は、エンジニアにとっても「なぜそうするのか」が明確なため、納得感が段違いです。
複数の打ち手（具体）の選択肢からどれを選べば良いかわからない、という方はこちらの記事を読んでみてください。
「抽象」が見えない人とのコミュニケーション断絶を防ぐ
しかし、現場ではこの「抽象化」がコミュニケーションエラーに繋がることがあります。特定の人や特定の職種とは話が通じるのに、別の人や職種とは話が噛み合わない、という経験はないでしょうか。
「マジックミラー」の構造を知る
書籍『具体と抽象』では、この現象を「マジックミラー」に例えています。
- 抽象度の高い人（ex, 経営者）： 具体的な事象も見えるし、その背後の構造（抽象）も見える。
- 抽象度の低い人（現場担当者）： 目の前の具体的な事象しか見えない。抽象的な話をされると「で、結局何をするの？」と混乱する。
これは能力の優劣ではなく、役割と視座の違いです。
現場の担当者は、目の前で怒っている顧客（超具体）を何とかしなければなりません。そこでPdMが「それは構造的には〜」などと抽象論を語れば、反感を買うのは当然です。
PdMは「翻訳機」になれ
だからこそ、PdMは相手のプロフェッショナルな領域に合わせて言語を切り替える「翻訳機」になる必要があります。
例えば以下のような形（あくまで例です）
- 対エンジニア（構造と効率への関心）：
「画面ごとの個別対応はやめて、『ユーザー権限』という抽象クラスを一つ定義しませんか？ そうすれば、今後の機能追加もそのクラスを継承するだけで済み、長期的な保守コストが下がります」 - 対セールス/CS（顧客メリットと提案への関心）：
「お客様には『この機能を使えば、面倒な承認フローがスマホだけで完結します』と伝えてください。これが競合他社にはない、商談で使える一番のキラーフレーズになります」
自分の思考プロセスでは「抽象」を使っても、アウトプットする相手の関心事に合わせて、具体と抽象のレベルをチューニングする。これが「現場を動かせるPdM」になるための必須スキルです。
LLMを使って「抽象化力」をトレーニングする
最後に、この「具体と抽象の往復」を鍛える方法を紹介します。
実は、AI（LLM）はこの往復運動が得意です。
AIに「要するに？」を問う
自分が集めたバラバラなユーザーの要望（具体）をChatGPTに投げ込み、こう指示してください。
「以下の5つの要望を、共通する『たった1つの本質的な課題』に抽象化して。それ以外の情報はすべて捨てていい」
AIが出した答えと、自分が考えた抽象化を比べてみてください。
AIの方が大胆に情報を捨てて、鋭い洞察を出してくることがあります。これは最高のスパーリングになります。
アナロジー（例え話）の練習
また、抽象化のゴールは「アナロジー」です。
「この採用管理ツールの課題は、要するに『Uber』のマッチング構造と同じだよね」と言えれば、Uberの成功事例（UIやアルゴリズム）をそのまま輸入（転用）できます。
AIに「この業務フローの課題を、全く別の業界（例えば飲食業界）に例えるとどうなる？」と聞いてみましょう。
一見関係ない分野から解決策を借りてくる「アナロジー思考」が、イノベーションの近道です。
具体の海で溺れず、抽象の雲に逃げない
具体だけのPdMは、御用聞きになり、プロダクトを破綻させます。
抽象だけのPdMは、評論家になり、現場から信頼を失います。
泥臭い具体の海に潜り、そこから真珠（本質）を見つけ出し、また具体の海に戻ってきてそれを手渡す。その孤独な往復運動ができる人だけが、本当に価値のあるプロダクトを生み出せるのです。
今日から実践できるアクションリスト
- ユーザーの要望をチケット化する前に、「これは要するに、何の課題なのか？」と一言で抽象化してメモする習慣をつける。
- エンジニアと話す時は「構造（抽象）」を、セールスと話す時は「画面（具体）」を意識して使い分ける。
- AIを使って「この課題を別の業界に例えると？」というアナロジーの壁打ちをする。
参考
- 細谷功『具体と抽象 ―世界が変わって見える知性のしくみ』
コメント