mcpField
P
problem-definition

problem-definition

github.com/refoundaiデザイン・UI1.4k1.8k 回インストール15 週間前に更新
リポジトリ

problem-definition について

解決策を選ぶ前に、ユーザーやビジネスの問題を定義するプロダクトデザイン向けスキルです。ユーザーが行き詰まる状況を調べ、ニーズと機能案を切り分け、解決する価値がある問題かを見極めます。

主な機能

  1. 01現在の問題の捉え方の整理
  2. 02ユーザーが困る具体的な状況の特定
  3. 03問題と解決策の切り分け
  4. 04顧客ニーズとビジネスニーズの区別
  5. 05プロトタイプによる問題の具体化

活用シーン

  1. 01広すぎる問題定義の見直し
  2. 02ユーザーが困る場面の調査
  3. 03開発前の機能案の評価
  4. 04顧客の痛点と事業目標の比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/refoundai/lenny-skills --skill problem-definition

インストール後、Claude Code で/problem-definitionを入力して読み込まれたか確認します。

同梱ファイルreferences/guest-insights.md

詳細

問題の定義

91 人のプロダクトリーダーのフレームワークを活用し、解決策に飛びつく前に、ユーザーが問題を明確に定義できるよう支援します。

支援の方法

ユーザーが問題の定義について助けを求めたときは、次のようにします。

  1. 現在の捉え方を理解する - 問題を今どのように考えているか尋ねます
  2. 困っている瞬間を掘り下げる - ユーザーが行き詰まる具体的な状況を言語化できるよう支援します
  3. 問題と解決策を切り分ける - 望ましい機能と、その根底にあるニーズを混同していないか確認します
  4. 問題に取り組む価値があるか検証する - 解決に取り組むほど緊急性が高く、広く存在する問題か確認できるよう支援します

基本原則

アナログをデジタル化するだけでは不十分です

Bret Taylor:「なぜイエローページではなく、これを使うのでしょうか? それは、以前からあったものをデジタル版にしただけでした。」アナログの前身を単にデジタル化するだけでは、新しいプラットフォームに存在する本質的な理由がないため、うまくいかないことがよくあります。「顧客がこれに時間を割くべき理由は何でしょうか?」と尋ねてください。

プロトタイプで問題を定義する

Jake Knapp + John Zeratsky:「行き詰まりを解消し、抽象的なアイデアや話し合ってきた概念を、実際に見てクリックして操作できる具体的なプロトタイプに変えるという考え方です。」抽象的な概念から具体的なプロトタイプへ移行することが、問題を定義し解決する最速の方法です。

目新しさに飛びつく罠を避ける

Marily Nika:「目新しさに飛びつく罠というものがあります。私はいつも、『ねえ、AI を使うこと自体を目的にしないで』と伝えています。そこに問題があることを確認してください。」AI(または新しいテクノロジー)は、それ自体を目的とするのではなく、特定され検証済みのユーザーの悩みを解決するために使いましょう。

困る瞬間が需要を生む

Bob Moesta:「困る瞬間が需要を生みます。そして、そうした困る瞬間が実際に存在し、長く続く場合であっても、誰も解決していないことがあると気づき始めます。」需要は製品そのものではなく、ユーザーの生活における特定の「困る瞬間」によって生まれます。ユーザーの行動を合理的にしている状況を調べましょう。

最初に最後を見通す

Ryan Singer:「最初から最後まで見通せないものには着手しません。大きな概念から始めて、『これにどれくらいかかりますか?』と尋ねるようなことはしません。」リソースを投入する前に、チームが完成した機能を思い描けるようにしてください。曖昧な概念から始めるのは避けましょう。

顧客が購入するのは解決策です

Marty Cagan:「人々は問題を買うのではなく、あなたの解決策を買います。もちろん、関心のある何かを解決していなければ買いません。しかし、人々が関心を持つことを解決している製品は数多くあります。」問題の理解は必要ですが、競争優位性は解決策の質から生まれます。問題が十分に理解されているなら、問題の検証に過度にこだわらないでください。

問題にもっと時間をかける

Christopher Lochhead:「解決策よりも問題に時間をかけましょう。」社内で製品のアイデアを出し合うよりも、顧客の視点から問題を深く理解するほうが価値があります。解決策を売り込むのではなく、顧客の見方を理解するために耳を傾けましょう。

問題の種類を見極める

Christopher Miller:「条件をつけずに問題について話すことはないと思います。ビジネス上の問題について話しているのでしょうか? 顧客の問題について話しているのでしょうか?」効果的な問題の定義には、ビジネス上のニーズと顧客の悩みを区別し、「顧客に不利益をもたらす」解決策を避けることが必要です。

ユーザーを支援するための質問

  • 「この問題に直面する直前、ユーザーは何をしていますか? 何を達成しようとしていますか?」
  • 「この問題はなぜまだ解決されていないのでしょうか? 何が難しいのでしょうか?」
  • 「これはビジネス上の問題ですか、それとも顧客の問題ですか? これらは同じでしょうか?」
  • 「この問題を完璧に解決できたら、ユーザーの生活はどう変わりますか?」
  • 「特定の瞬間にこの問題を経験している人を、具体的に説明できますか?」
  • 「人々は現在、この問題を回避するために何をしていますか?」

よくある見落とし

  • 解決策ありきの思考 - 機能のアイデアから出発し、それを正当化するために逆算して考えます
  • テクノロジーありきの思考 - AI/ブロックチェーンなどを使いたいと考え、それを適用できる問題を探します
  • 抽象的な問題提起 - 特定の解決策につながらないほど広い範囲で問題を定義します
  • ビジネス上の問題と顧客の問題の混同 - ユーザーのニーズに対応せず、社内の指標を改善しようとします
  • 困難が生じる瞬間を見落とす - 痛みが生じる具体的な状況を理解していません

詳細

91 人のゲストから得られた 123 件すべての知見については、references/guest-insights.md をご覧ください。

関連スキル

  • ポジショニングとメッセージング
  • ロードマップの優先順位付け
  • スコープの設定と削減
  • プロダクトのセンスと直感

コメント