problem-statement

problem-statement skill の概要

problem-statement skill は、あいまいな製品要望を、「誰が行き詰まっているのか」「何をしようとしているのか」「なぜ重要なのか」「どう感じているのか」まで明確にした、ユーザー中心の問題定義に変えるための skill です。特に、解決策に入る前の認識合わせが必要な場面、つまり discovery、優先順位付け、PRD、ステークホルダーレビューで役立ちます。

problem-statement skill は何のためのものか

この problem-statement skill は、機能設計ではなく「問題の切り取り方」を整えるためのものです。ユーザー視点で問題を言語化できるので、実装方法の議論に入る前に、その仕事を本当にやる価値があるのかをチームで判断しやすくなります。

どんな人に向いているか

製品ブリーフ、技術仕様書、調査サマリー、ロードマップメモを書く人で、より筋の通った問題ストーリーが必要な場合に向いています。Technical Writing のワークフローでも、散らかった入力を、簡潔で共感のある問題文に落とし込む場面と相性がいい skill です。

何が違うのか

この skill は、I am、Trying to、But、Because、Which makes me feel という問題フレーミングの型に、背景と制約を組み合わせる構成になっています。単なる汎用プロンプトよりも意思決定に使いやすいのは、機能上の障害と人間への影響の両方を必ず拾うよう促すからです。

problem-statement skill の使い方

インストールして内容を確認する

次のコマンドでインストールします。

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

そのあとで、まず skills/problem-statement/SKILL.md を読み、続けて template.md と examples/sample.md を確認してください。期待される構成、最終的な出力、完成度の高い problem statement の見た目を最短でつかめます。

プロンプトに入れるべき内容

problem-statement skill をうまく使うには、ざっくりしつつも具体性のある入力を渡すことが大切です。たとえば、ユーザーの種類、やりたいタスク、つまずいている点、制約条件です。機能要望だけを入れると、出力が本当の問題ではなく、解決策寄りの表現に流れやすくなります。

より強い入力の例は次のとおりです。

• Persona: “new support agents on mobile”
• Goal: “resolve tickets without switching tools”
• Blocker: “they lose context between CRM and chat”
• Constraints: “high volume, low training time, remote-first team”

おすすめの進め方

まず短い下書きを作り、それを 5 要素のストーリーに整えます。template はチェックリストとして使ってください。Because が解決策っぽく聞こえるなら、実際には何が痛みの原因なのかを掘り直します。Which makes me feel が一般論に見えるなら、ワークフローに結びついた具体的な感情に置き換えます。

最初に読むファイル

SKILL.md、template.md、examples/sample.md を優先して読んでください。特に example ファイルは、よいフレーミングのパターンとアンチパターンの両方を示しているため、問題定義ではなく「解決策を問題文に偽装する」書き方を避けやすくなります。

problem-statement skill の FAQ

problem-statement はただのプロンプトテンプレートですか？

いいえ。problem-statement skill は、穴埋め式のプロンプトではなく、再利用できるフレーミング手法です。PRD を書く前、あるいは修正案を出す前に、ユーザー、障害、根本原因を明確にすることに価値があります。

どんなときに使わないほうがいいですか？

すでに要件が十分に絞り込まれた文書がある場合や、実装の詳細を記録している場合は使わないでください。また、解決策のブレストが目的なら相性がよくありません。この skill は、まず問題を定義するためのものです。

problem-statement は初心者向けですか？

はい。ユーザーと痛点を平易な言葉で説明できるなら使えます。テンプレート自体はシンプルですが、ユーザーの問題と自分が望む解決策を切り分けられるかどうかで品質が決まります。

Technical Writing の仕事にどう役立ちますか？

Technical Writing では、読者の痛みを明確にしたいとき、ドキュメント要望を整理したいとき、執筆前に内容のギャップをフレーミングしたいときに役立ちます。文書が機能紹介に流れず、成果物として何を達成するのかに焦点を保ちやすくなります。

problem-statement skill を改善するには

スローガンではなく根拠を入れる

problem-statement の質を上げるには、具体的な観察が最も重要です。ユーザーが何を試したのか、どこで止まったのか、代わりに何を使ったのか、何が壊れたのかを入れてください。「ユーザーが混乱している」では弱く、「初回管理者は UI に必要な API key フィールドが隠れていてセットアップを完了できない」のほうがはるかに強いです。

問題と解決策を分ける

よくある失敗は、解決策を紛れ込ませることです。もし下書きに「ユーザーは dashboard が必要だ」と書いてあるなら、「status signals が各所に散らばっているため、サービス全体の account health を比較できない」と言い換えてください。そうすることで、problem-statement が本当の障壁に集中できます。

答えを変える制約を足す

デバイス、チーム規模、時間的な切迫、コンプライアンス、経験レベル、プラットフォーム制約など、問題の形に影響する要素は必ず入れてください。こうした情報があると problem statement の信頼性が上がり、最終成果物も優先順位付けに使いやすくなります。

下書きから意思決定できる状態へ詰める

初回出力のあと、その文がステークホルダーレビューに耐えられるくらい具体的かを確認します。足りない場合は、persona をより明確にし、Because をより因果的にし、最後の文が追加説明なしで読めるかを確かめてください。