user-story

user-storyスキルの概要

user-story スキルは、ざっくりした製品要件を、Mike Cohn の書き方と Gherkin の受け入れ条件を備えた、開発にそのまま渡せる1件のユーザーストーリーにまとめるのに役立ちます。作りかけのアイデアや大きな仕様書ではなく、きれいな受け渡し用成果物が必要なプロダクトマネージャー、テクニカルライター、アナリスト、AI支援ワークフローの利用者に最適です。

本質的な仕事は、ユーザー、行動、価値、そしてテスト可能な結果を、エンジニアリングと QA が使える形式ではっきり定義することです。汎用プロンプトと比べると、user-story スキルは再現しやすい構成とより絞られたスコープを提供します。曖昧なストーリーを減らし、レビュー回数を減らしたいときに効いてきます。

プロダクトからエンジニアリングへの受け渡しに最適なケース

すでに意図は分かっているものの、それを簡潔で、テスト可能で、見積もりしやすい形にしたいときに、この user-story スキルを使います。PRD のメモ、関係者からの要望、ロードマップの箇条書きを、実装に使えるストーリーへ落とし込む用途に特に向いています。

user-story が他と違う点

最大の差別化ポイントは、標準的なユーザーストーリー形式に明示的な受け入れ条件が組み合わさっていることです。つまり、出力は読みやすいだけでなく、検証しやすく、分解しやすく、議論もしやすい。複数の項目で一貫したストーリー品質を求めるなら、user-story スキルは自由形式のプロンプトよりずっと有効です。

使うべき場面

機能開発、ワークフロー変更、オンボーディング手順など、1つのユーザー操作が1つの測定可能な結果につながるような、スコープの明確な成果物には user-story を選びます。プロダクト文書を支えるテクニカルライティングチームにも相性がよく、製品意図と成功条件をそろえたまま進められます。

user-story スキルの使い方

user-story スキルをインストールする

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

npx skills add deanpeters/Product-Manager-Skills --skill user-story

インストール後は、まず skills/user-story/SKILL.md を読み、次に template.md と examples/sample.md を確認して、想定されている構成と品質基準を把握します。ストーリー生成を自動化したい場合は、scripts/user-story-template.py も見て、スキルがどのフィールドを期待しているかを確認してください。

適切な入力を与える

user-story スキルは、具体的なユーザー、1つのやりたい行動、その背後にあるビジネス価値またはユーザー価値を与えたときに最もよく機能します。たとえば、次のような入力が強いです。

• Persona: trial user, support agent, account owner
• Action: reset my password, export invoices, approve a request
• Outcome: so that I can regain access quickly

「オンボーディングを改善する」のような弱い入力は、誰が、何を、なぜが分からないため、曖昧な出力になりがちです。

テンプレートに合うプロンプトを使う

user-story の使い方を最適化するには、1回につき1件のストーリーを依頼し、スキルが埋める前提のフィールドを含めます。よいプロンプトの例は次のとおりです。

“Write a user-story for a trial user who wants to connect their Google account so that they can sign in faster. Include one summary, the use case, and one scenario with one Given/When/Then set.”

これは「ログインについてのユーザーストーリーを書いて」と頼むより良い結果になりやすいです。スコープと成果が明確になり、受け入れ条件の品質が上がるからです。

リポジトリのファイルはこの順番で読む

実践的に user-story guide を使うなら、次の順で確認すると分かりやすいです。

1. SKILL.md で記述ルールと考え方を確認する
2. template.md で正確な Markdown 形状を把握する
3. examples/sample.md で良いストーリーと悪いストーリーの差を見る
4. 生成を再現可能にしたいなら scripts/user-story-template.py を確認する

この順番なら、自分で書き始める前に、形式とガードレールの両方を把握できます。

user-story スキル FAQ

user-story はプロダクトマネージャー専用ですか？

いいえ。user-story スキルは、計画や実装のために共通の成果物が必要なテクニカルライター、アナリスト、デザイナー、エンジニアにも役立ちます。意図をテスト可能なストーリーに翻訳する必要がある人なら、誰でも使えます。

user-story は普通のプロンプトと何が違いますか？

通常のプロンプトでもストーリー風の段落は作れますが、user-story スキルは、summary、persona、action、outcome、scenario、acceptance criteria という一貫した構成を強く促します。この一貫性は、ストーリーをレビュー、見積もり、分割するときに重要です。

user-story は初心者にも向いていますか？

はい。ユーザー、目的、望ましい結果を説明できるなら使えます。初心者がやりがちな失敗は、ユーザーの問題より先に解決策から入ってしまうことです。「誰のために、なぜ必要か」に答えられるなら、このスキルはよく合います。

user-story を使わない方がいいのはどんなときですか？

広い戦略文書、複数ステップの epics、アーキテクチャ判断、相互依存する結果が多い機能仕様には user-story を使わないでください。複数の振る舞いが必要なら、そのストーリーは大きすぎる可能性が高く、実装前に分割すべきです。

user-story スキルを改善する方法

元になる材料をより具体的にする

品質を最も大きく上げるのは、入力を鋭くすることです。正確な persona、きっかけ、期待する結果、そして platform、role、permission level などストーリーに影響する制約を含めてください。たとえば「billing admin on desktop exports invoice history」は、「user downloads data」よりずっと良い入力です。

スコープの広がりすぎに注意する

user-story の出力でありがちな失敗は、複数の結果を1つのストーリーに詰め込もうとすることです。下書きに複数の When/Then 経路、別々のユーザー行動、または混在したユーザー種別が必要なら、先に分けてください。repo の template と examples が 1 ストーリーにつき 1 つの主要な振る舞いを勧めているのには理由があります。

受け入れ条件を具体的にする

最初の下書きが曖昧に感じるなら、Given の状態にもっと具体的な文脈を足し、Then の成功条件をより正確にしてください。強い受け入れ条件は、システムが「何を支援すべきか」ではなく、レビュー担当者が観察できる内容を記述します。これは特に user-story for Technical Writing で重要です。曖昧だと、その先のドキュメントが書きにくくなります。

レビューコメントをもとに反復する

最初の出力は下書きとして使い、その後、persona の修正、outcome の絞り込み、実装の推測に基づく受け入れ条件の削除で磨きます。レビューで「これは誰向けですか？」や「どうやってテストしますか？」と聞かれたら、その質問を次のプロンプトに戻してください。そうすることで、user-story skill はより使いやすい改訂版を出しやすくなります。