wwas

wwas skill の概要

wwas は、Why-What-Acceptance 形式でプロダクトのバックログ項目を書くためのプロンプト skill です。単なる機能要約以上のバックログ項目が必要なときに使います。ビジネス上の理由を示し、変更内容を明確に説明し、チームがテストできる受け入れ条件まで定義できるようにします。

この skill は、粗いアイデアをスプリント投入可能な作業項目に落とし込みたいプロダクトマネージャー、アナリスト、デザイナー、AI エージェントに特に向いています。実際にやるべきことは、戦略的な文脈を保ちながら、項目を独立していて、価値があり、交渉可能な形に整えることです。wwas skill は、実装を過度に細かく決め込みすぎずに、チーム全体で一貫したバックログの言葉づかいを揃えたいときに特に役立ちます。

wwas が特に向いている用途

wwas は、機能分解、段階的なプロダクト提供、部門横断の計画立案に最適です。コードを書く前に、チームが意図を明確に理解する必要がある場面で力を発揮します。たとえば、会議メモ、デザインリンク、まだ形になりきっていない依頼のように、元の入力が散らかっているときに助けになります。

wwas が他と違う理由

汎用的なプロンプトと比べると、wwas はモデルに Why、What、Acceptance Criteria を分けて書かせます。その結果、曖昧なチケットが減り、スコープを小さく保ちやすくなり、計画会議でもレビューしやすい出力になります。また、プロンプトを完全な仕様書に変えてしまうことなく、順序付け、見積もり、テストができる項目を作りやすくします。

wwas を導入すると効果が大きい場面

バックログの整備、再現性のあるチケット品質、AI 支援の要件整理に依存するワークフローなら、wwas を導入する価値があります。一度きりの文章生成ではなく、Requirements Planning の共通フォーマットが必要なチームほど効果が高いです。

wwas skill の使い方

wwas をインストールしてソースファイルを確認する

npx skills add phuryn/pm-skills --skill wwas で skill をインストールします。次にまず SKILL.md を読みます。ここには、wwas の使い方を形作るワークフロー、項目テンプレート、引数一覧がまとまっています。自分の運用に合わせて調整するなら、周辺の skill にある規約も含めて skill ディレクトリ全体を確認するとよいです。

wwas に何を渡すべきか

wwas は、次の 4 つの入力があると最もよく機能します。プロダクトまたはシステム名、機能や能力、デザインリンクがあればその URL、そして前提条件や戦略的文脈です。improve onboarding のような弱い入力だと、受け入れ条件が曖昧になりがちです。強い入力は、プロダクト名、対象ユーザー、望ましい成果、制約条件がはっきりしています。

より良いプロンプトの書き方

良い wwas プロンプトは、提供する単位とビジネス上の理由を明示します。たとえば、Create a WWA item for the mobile checkout flow. Why: reduce cart abandonment for returning users. What: add saved payment selection, using the Figma link. Assumptions: authenticated users only, no new payment provider. のように書きます。こうすると、skill はただ整った段落を返すのではなく、実際に使えるバックログ項目を生成しやすくなります。

Requirements Planning の実践的な流れ

wwas は、機能の方向性がある程度見えていて、まだ詳細設計に入る前に使うのが適切です。まず、ざっくりした依頼内容と、デザインやディスカバリーのメモを集めます。次に、wwas を実行して Why-What-Acceptance の構造を作ります。最後に、独立性、スコープの大きさ、テスト可能性を確認します。もし 1 つの項目に複数の成果が詰め込まれているなら、分割して、より小さな単位で wwas をもう一度実行します。

wwas skill の FAQ

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

いいえ。wwas skill は、エンジニアリングやデザインが実行に移せる Requirements Planning の出力を必要とする人なら誰でも役立ちます。PM、ビジネスアナリスト、創業者、デリバリーリード、AI 支援のドキュメント運用にも向いています。

wwas は普通のプロンプトとどう違いますか？

普通のプロンプトでも、機能の説明文のようなものは出せます。wwas はそれより狭く、戦略的文脈、簡潔な機能説明、観測可能な受け入れ条件を持つバックログ項目の構造に強制します。結果として、生成後の手直しが少なくなることが多いです。

wwas を使うのにデザインファイルは必要ですか？

必須ではありませんが、デザインリンクがあると精度は上がります。デザインがない場合でも、ユーザーのニーズ、作業範囲の境界、期待される挙動を定義できるだけの文脈を渡してください。それがないと、項目が広すぎるものになりやすいです。

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

詳細な技術設計、実装タスク、リリースノートが必要なときは、wwas は使わないでください。これは Requirements Planning のツールであって、コーディング仕様書を作るための generator ではありません。

wwas skill を改善する方法

問題設定をもっと具体的にする

wwas の出力が最も良くなるのは、具体的なユーザー課題またはビジネス課題から始めたときです。add filters ではなく、help support agents find open cases faster in a high-volume queue のように置き換えてください。こうした入力は Why セクションの質を上げ、ありがちな受け入れ条件を防ぎます。

先に境界条件をはっきり伝える

wwas は、何が対象外かを最初に伝えると精度が上がります。機能がモバイル限定なのか、社内限定なのか、特定ユーザーセグメントに限るのかを、最初から明示してください。そうしないと、受け入れ条件が関係のないケースまで広がりやすくなります。

独立性とテスト可能性を確認する

wwas のよくある失敗は、複数の成果物を 1 つのバックログ項目にまとめてしまうことです。出力が UI、分析、権限を 1 つに束ねているなら、それらを分割して skill を再実行してください。また、受け入れ条件が実装の詳細ではなく、観測できる成果を説明しているかも確認します。

最初のドラフトをもとに反復する

最初の wwas 出力は、計画用のドラフトとして扱ってください。Why が弱ければ、ビジネスゴールを再度与えます。What が大きすぎるなら、機能を絞ります。受け入れ条件が曖昧なら、役割、トリガー、期待結果を追加します。こうした反復のほうが、最終的な Requirements Planning の成果物を改善するうえで、最初から情報を盛り込みすぎるより効果的です。