はじめに

現在、社内のリスキリング制度を活用してプロダクトマネージャー(PM)に挑戦中です。
PM初心者として学び始めた頃、特に苦労したのが「ユーザーの本当のニーズをつかむこと」でした。
最初のユーザーインタビューでは、自分が想定した課題ばかり質問してしまい、貴重な気づきを得ることができませんでした。
その失敗をきっかけに学び直したのがデザイン思考です。
ユーザー視点で課題を深掘りし、チームでアイデアを形にしていくこのアプローチは、PM初心者にとって「ユーザー価値を軸に考える力」を鍛える最適な方法だと実感しています。
この記事では、初心者PMの方が実務ですぐ活かせるよう、デザイン思考の基本から5ステップの進め方、そして私自身が初めて実践したときの体験談まで、わかりやすく解説します。
- デザイン思考の基本的な考え方とPMに求められる理由
- 5ステップ(共感・定義・アイディエーション・プロトタイプ・テスト)のポイント
- 初めてのユーザーインタビューで学んだ実体験からの教訓
- 初心者PMが実務でつまずきやすいポイントと成功のコツ
デザイン思考とは?初心者PMでも実践できる問題解決法
デザイン思考の基本的な考え方
デザイン思考(Design Thinking)とは、ユーザー視点を起点に問題を発見し、アイデアを素早く形にして検証する問題解決の手法です。
もともとはデザイナーの発想法として注目されましたが、現在ではビジネスやプロダクト開発全般で活用されています。
特にプロダクトマネージャーにとっては、「自分たちが作りたいもの」ではなく「ユーザーが本当に求めている価値」に集中できるアプローチとして重要です。
デザイン思考の特徴は次の3つです。
- ユーザー中心 :ユーザーの行動や感情を深く理解することが出発点
- 試行錯誤を前提にする :完璧を目指さず、作っては学ぶプロセスを繰り返す
- チームでの共創 :多様な視点を集め、アイデアを広げていく

初心者PMの方は、これらをすべて完璧にこなそうとせず、「ユーザー理解を深める」ことから一歩ずつ始めると取り組みやすいです。
なぜ今、PMにデザイン思考が求められるのか
近年、ユーザーのニーズは複雑化し、競合サービスも増えています。そのため、ユーザー価値を素早く検証しながらプロダクトを進化させるスキルがPMに求められるようになりました。
ウォーターフォール型の開発のように、最初にすべての仕様を決めるやり方では、「作ったけど使われない機能」を生みやすくなります。
デザイン思考を学ぶことで、
- 「この機能は本当に必要なのか?」
- 「ユーザーが困っている本当の理由は何か?」
といった問いをチームで繰り返し考えられるようになり、結果としてユーザーに支持されるプロダクトが生まれやすくなります。
デザイン思考の5ステップを徹底解説


ステップ1 共感(Empathize)ユーザーを深く理解する第一歩
初心者がつまずきやすいポイント
デザイン思考の出発点は、ユーザーに共感することです。ここでいう共感とは、ユーザーが口にする言葉だけでなく、行動や感情の背景にある本当のニーズを理解することを指します。
しかし初心者PMが陥りやすいのが、
- 自分が想定した課題を押し付ける質問をしてしまう
- ユーザーの言葉をそのまま鵜呑みにしてしまう
という失敗です。
共感フェーズで重要なのは、観察と傾聴です。ユーザーインタビューや現場観察で「なぜその行動をするのか」を掘り下げ、表面的な回答の裏にある理由を見つけることが求められます。
初めてのユーザーインタビューで学んだ失敗と気づき
私が初めてユーザーインタビューを担当したとき、「この機能があれば便利ですよね?」という、答えが「Yes」になりやすい質問ばかりしてしまいました。その結果、ユーザーは肯定的な答えをしてくれましたが、実際に使い始めるとほとんど活用されませんでした。
その失敗を振り返る中で気づいたのは、ユーザーが本当に困っていることは、自分が想定していた課題とはまったく違う場合が多いということです。
2回目のインタビューでは、質問を変えました。
- 「最近この作業で困ったことはありますか?」
- 「そのとき、どんな気持ちになりましたか?」
こうした質問をすることで、ユーザーが普段どんな場面で不便を感じているのかを深く知ることができ、後のアイデア発想にも役立ちました。


ステップ2 定義(Define)課題を正しく見極める方法
定義の重要性
共感フェーズで得たユーザーの行動や感情の情報をもとに、解決すべき本質的な課題を明確にするステップです。
ここで課題を誤ると、その後のアイデア発想やプロトタイピングがすべて的外れになってしまいます。
初心者PMがよくやってしまうのは、「ユーザーが求めると言った機能」=「解決すべき課題」だと決めつけることです。しかし、ユーザーが口にする要望は、あくまで表面的な解決策に過ぎないことが多いです。
初心者PM向け:定義のコツ
- インサイト(気づき)を整理する
ユーザーインタビューや観察で得た情報を、ポストイットやオンラインツールに書き出し、行動パターンや感情の共通点を探します。 - 「なぜ?」を5回繰り返す
いわゆる「5 Whys(5回のなぜ)」を使い、ユーザーが感じる不便の根本原因を掘り下げます。
例:- なぜその作業が面倒だと感じるのか?
- なぜその作業をしなければならないのか?
- 課題文をユーザー視点で書く
**「ユーザーは〇〇したいが、△△ができない」**という文章で課題を整理すると、具体的かつチームでも共有しやすくなります。
Defineフェーズのよくある失敗例と対策


ステップ3 アイディエーション(Ideation)量を出すことが質につながる理由
アイディエーションの目的
定義で整理した「本質的な課題」を解決するために、できるだけ多くの解決策を出すステップです。
この段階では、アイデアの良し悪しをすぐに判断する必要はありません。むしろ、「質より量」を重視することが良いアイデアにつながると言われています。
理由は簡単で、最初に出てくるアイデアの多くは「ありきたりなもの」だからです。大量に出すことで、チームが自由に発想し、斬新なアイデアが生まれる確率が高まります。
初心者PMが意識すべきアイディエーションのコツ
- 発散と収束を分ける
- 発散フェーズ:まずは批判禁止。どんな突飛なアイデアでも歓迎する
- 収束フェーズ:後から「実現可能性」「ユーザー価値」「インパクト」で優先度を絞る
- 視点を変える質問を使う
例:- 「もし〇〇が全く存在しなかったら、どう解決する?」
- 「10倍の時間があれば、どんな方法を試す?」
- 他業界の事例からヒントを得る
同じ課題でも、他の業界での解決方法が新しい発想につながることがあります。
初心者でも使いやすい発想ツール
・ブレインストーミング:チーム全員でアイデアを出す基本的手法
・SCAMPER法(置き換える、組み合わせる、応用する、など7つの視点で考える)
・マインドマップ:課題を中心に関連するアイデアを広げる


ステップ4 プロトタイプ(Prototype)作り込みすぎない試作のコツ
プロトタイプの目的
プロトタイプは、出したアイデアを簡易的に形にして、ユーザーやチームから早い段階でフィードバックを得るためのステップです。
ここで重要なのは、完成品を作ることではなく、仮説を検証することです。
初心者PMがやりがちなのは、
- 「見た目を完璧にしよう」と作り込みすぎる
- フィードバックをもらう前に「完成品に近い状態」にしてしまう
という失敗です。これでは、時間も労力もかかり、早期の学びが得られません。
初心者PM向け:プロトタイピングのコツ
- 作り込みすぎない
紙に描いたワイヤーフレームや、簡単なクリック可能なモックアップなど、ユーザーがイメージできる最低限の形で十分です。 - 目的を明確にする
- 何を検証したいのか?(例:「この機能の操作フローは直感的か?」)
- フィードバックをもらう観点を事前に整理しておく
- 捨てる前提で作る
プロトタイプはあくまで「学びのため」。使いにくいとわかれば、すぐに作り直す覚悟が大事です。
簡易プロトタイプで大きな気づきを得た話
私が初めてプロトタイピングをしたとき、Figmaで1週間かけて見た目まで作り込んだUIモックを用意しました。しかし、ユーザーに見せた瞬間、最初の操作でつまずかれ、ほとんどの時間が「そもそも操作がわかりにくい」という指摘で終わりました。
その後、ペーパープロトタイプを使って再挑戦したところ、ユーザーは気軽に「ここは押しにくい」「この順番は違う方がいい」と意見をくれました。作り込みすぎない方が、フィードバックが集まりやすいと実感した経験です。
ステップ5 テスト(Test)フィードバックを最大限活かす方法
テストの目的
テストは、プロトタイプをユーザーに実際に触ってもらい、仮説が正しいか、ユーザーにとって本当に価値があるかを検証するステップです。
ここで得られるユーザーの意見は、最終的なプロダクトの方向性を左右します。
初心者PMが陥りやすい失敗
- 「ユーザーが褒めてくれた=成功」と勘違いする
→ ユーザーは遠慮してポジティブな意見を言いがちなので、裏にある不満や使いにくさを見逃さないようにします。 - 1回のテストで結論を出してしまう
→ 数人の意見だけで判断するのではなく、複数回テストを重ねてパターンを探すことが重要です。
テストを成功させる3つのコツ
- ユーザーが自由に触れる環境を作る
操作を横でじっと見つめると、ユーザーは緊張して自然な行動ができません。できるだけリラックスした雰囲気を作りましょう。 - 行動を観察しながら「なぜ?」を尋ねる
ユーザーが迷ったり、想定と違う動きをしたときに「なぜそうしたのか」を聞くと、隠れた不満や課題が見つかります。 - 否定せずに受け止める
ユーザーが「使いにくい」と言ったら、すぐに理由を説明したり弁解したりせず、まずは受け止めて詳しく掘り下げましょう。
テスト後の活かし方
テストの結果は「成功・失敗」で終わらせるのではなく、次のプロトタイプ改善にすぐ反映させることが大事です。
デザイン思考はこのテストを繰り返すことで、ユーザーにとって最適な解決策へと近づいていきます。


初心者PMがデザイン思考を実務で活かすポイント
1. 小さく試す文化をチームに根づかせる
デザイン思考の最大の特徴は、完璧を目指さず、試行錯誤を繰り返すことです。しかし、実務では「しっかり計画を立ててから作り込むべき」という意見が根強く、初心者PMほど「まずは小さく作る」という考えを通しにくいものです。
ポイントは、小さな成功体験をチームで共有することです。
- 例:簡易プロトタイプで得られた意外なユーザーの声を紹介する
- 例:1回のテストで改善できた具体的な数値(離脱率が〇%減った等)を共有する
こうした小さな実績が積み重なると、チーム内でも「まず試してみよう」という空気が生まれやすくなります。
2. ユーザーとの距離を縮める習慣を作る
デザイン思考は、ユーザー理解が浅いままでは機能しません。
初心者PMがやるべき第一歩は、ユーザーと直接話す・観察する機会を増やすことです。
- 月1回のユーザーインタビューをチームの定例に組み込む
- 自社サービスを実際に使っている現場を訪問する
これだけでも、「机上の仮説」ではなく「リアルな課題感」を共有する文化が少しずつ根づいていきます。
3. 失敗を共有することを恐れない
デザイン思考のプロセスでは、失敗は学びの一部です。しかし、実務では「失敗を報告する=評価が下がる」と感じる人も多いです。
初心者PMこそ、まず自分が率先して「失敗からの学び」をチームにシェアしましょう。
- 例:「最初のインタビューでは課題を深掘りできなかったが、質問を変えたら〇〇という気づきが得られた」
- 例:「作り込みすぎたプロトタイプをやめて、簡易版でテストしたら多くの意見が集まった」
こうした共有が増えるほど、チーム全体が「失敗を恐れず挑戦する文化」に近づきます。
デザイン思考のよくある誤解と成功のコツ
1. デザイン思考=デザイナーだけのもの?
誤解:「デザイン思考はデザイナーやクリエイティブ職の人が使うもの」
実際は:PMをはじめ、ビジネス職でもエンジニアでも活用できる汎用的な問題解決手法です。
むしろ、異なる専門性を持つメンバーが集まるほど多様なアイデアが生まれやすく、デザイン思考の強みが発揮されます。
2. 完璧なアイデアを考え抜いてから始めるべき?
誤解:「しっかり考え抜いてから作り始めたほうが効率的」
実際は:デザイン思考では、不完全なアイデアでも早く形にして学ぶことが重要です。
頭の中だけで考え続けても、ユーザーにとっての本当の価値はわかりません。小さく作り、テストし、学びを得るサイクルを回すことが成功への近道です。
3. ユーザーの要望をすべて取り入れるべき?
誤解:「ユーザーが欲しいと言ったものはすべて実装すべき」
実際は:ユーザーの声は重要ですが、言葉どおりに受け取るだけでは本質的な課題を見失います。
成功するPMは、ユーザーの要望を鵜呑みにせず、「なぜその要望が出たのか」という背景を深掘りすることで、真に価値のある解決策を見つけています。
4. 成功のコツ:小さく学び、大きく育てる
デザイン思考の成功のポイントは、「小さく学び、大きく育てる」ことです。
- 小さく学ぶ:簡易プロトタイプや短いサイクルでのテストで素早く学ぶ
- 大きく育てる:得られた学びを次の改善につなげ、徐々にスケールさせる
このサイクルを回し続けることで、ユーザーにとって価値あるプロダクトが磨かれていきます。
まとめ|デザイン思考は「小さく始めて学び続ける」ことが大事です
デザイン思考は、特別なスキルが必要な難しい手法ではありません。初心者PMでも、ユーザー視点に立つことを意識し、試行錯誤を繰り返すことで実務にすぐ活かせます。
特に意識すべきポイントは3つです。
- まずはユーザー理解から始める
深い共感がなければ、どんなアイデアも的外れになりやすいです。 - 小さく作り、すぐに試す
完璧を目指さず、簡易なプロトタイプで学びを得るサイクルを早く回すことが成功の鍵です。 - 学びをチームで共有する
小さな気づきを積み重ね、失敗も含めてチームでオープンに共有することで、挑戦しやすい雰囲気が生まれます。
私自身、最初は「正しい答え」を探すことばかりに必死でしたが、デザイン思考を実践するうちに、「答えはユーザーとの対話と試行の中にある」と気づきました。
初心者PMの方も、ぜひ小さく始めて、学び続ける一歩を踏み出してみてください。きっと、チームの会話も活発になり、プロダクト作りがもっと楽しくなるはずです。
コメント