ユーザーストーリーと検証可能な受け入れ基準を作る

著者: AILesson9 分でセットアップテスト済み:ChatGPTレビュー日: 2026-08-28

クイック回答

製品判断を創作せず、確認済みのユーザーと事業のニーズを範囲付きのストーリーと観察可能な動作へ変えます. 入力するもの: ニーズと根拠, 承認済みの製品判断, 提供と検証. 期待される結果: 根拠、境界、シナリオ、受け入れ基準、非機能要件、依存関係、未解決の判断を含むストーリー一式.

コンテキストを追加

テキストはこのブラウザ内に留まります。AILesson Prompts は、そのテキストをモデルやサーバーに送信しません。

ニーズと根拠承認済みの製品判断提供と検証

あなたのプロンプト

未入力のフィールドはプレースホルダーとして表示されたままなので、プロンプトをコピーして編集できます。

確認済みのニーズと承認済みの製品判断から、ユーザーストーリーと検証可能な受け入れ基準を作成してください。

ユーザー状況、役割、目標、行動、根拠、事業上の理由、調査の制限、反例：
[evidence]

選択済みの範囲、ワークフロー、状態、規則、権限、データ、統合、プラットフォーム、非機能要件、除外事項：
[product]

リリース、チーム、依存関係、分析、アクセシビリティ、プライバシー、セキュリティ、環境、完了条件、未解決の判断：
[delivery]

根拠のあるニーズ、製品仮説、承認済み判断、実装上の仮定、未解決の選択肢を分けてください。技術レイヤーや大きすぎるエピックではなく、実行者と独立した成果ごとにストーリーを分割します。ユーザーストーリーの1文は要約としてだけ使い、背景、根拠の参照位置、範囲内・外、前提条件、開始条件、主な流れ、代替・エラー経路、権限、データ処理、業務規則、依存関係を追加してください。受け入れ基準は観察可能なGiven／When／Thenシナリオまたは同等形式で書き、通常経路、境界、欠損・無効データ、権限拒否、同時または反復操作、復旧、アクセシビリティ、プライバシーとセキュリティ、分析、互換性について、承認済みの範囲だけを扱います。UI文言、状態、しきい値、統合、役割、データ保持、性能目標、通知、エラー動作、指標を創作してはいけません。未解決の判断は、影響する基準を阻害する質問として明記します。解決策が承認されていない場合、解決案を含めません。最後に、根拠からストーリー、基準への追跡可能性と、テスト可能性、範囲、競合、準備状況の監査を示します。

Playgroundで試す

デフォルトで非公開プロンプトの組み立てはブラウザ内で行われます。組織が許可しない限り、機密情報を AI サービスに入力しないでください。

入力から結果へ

具体例

具体的なコンテキストを加えると、このレシピが実用的な結果になる様子をご覧ください。

実際の入力

ニーズと根拠: UXセッションP01／P03の調査根拠：Ready状態の引き継ぎで受け入れ責任が見えないと、担当者が人を探し回ったり、期待していたメンションを見落としたりした。反例P02／P04では、意図的な待機や既知の承認待ちもある。承認済みの事業上の理由：通知負担を増やさず、回避可能な不確実性を減らす。根拠は一般的な発生率やメール需要を裏付けない。
承認済みの製品判断: 探索段階のプロトタイプ向け承認済み解決策：引き継ぎに任意のaccepterフィールドを表示する。requesterまたはworkspace coordinatorだけが設定・変更でき、ownerとaccepterが閲覧できる。既存状態Draft、Active、Ready、Acceptedは維持。accepter未設定時は承認済みdesign tokenを使って未割り当て状態を示す。正確なUI文言は未決定。メールやpush通知なし。accepterはactive workspace memberでなければならない。audit logは実行者、変更前後のaccepter、時刻を記録。Webアプリのみ対応。保持期間の変更は未承認。
提供と検証: ユーザビリティテスト用プロトタイプで、本番リリースではない。Designが文言を担当し、Engineeringがmembershipとaudit eventを検証する。Accessibility要件はキーボード操作、プログラムから判別可能なラベル、色だけに依存しない状態表示。既存member IDを使用するプライバシーレビューは完了。analytics event名と性能しきい値は未解決。完了の定義：レビュー済みデザイン、動作するプロトタイプ、単体テスト、アクセシビリティチェック、調査スクリプト。本番SLAを書かない。

出力例

ストーリー1 — 受け入れ責任を設定する requesterまたはworkspace coordinatorとして、引き継ぎのaccepterにactive workspace memberを指定し、関係者が受け入れ権限を持つ人を確認できるようにしたい。根拠：P01／P03。範囲はプロトタイプ仮説であり、検証済み需要ではない。

受け入れ基準 • Given Web上の引き継ぎと権限を持つrequester／coordinator、When active workspace memberを選んで確定、Thenそのmemberがaccepterとして保存され、requester、owner、accepterに表示される。正確な確認UIは未解決で、承認済みデザインから提供されなければならない。 • Given requester／coordinatorではない人、When引き継ぎを閲覧、Then accepterは見えるが変更できない。承認済みの拒否時動作が欠けており、正確な基準の確定を妨げている。 • Given inactiveまたは非memberのアカウント、When accepterとして指定、Thenシステムは保存しない。正確なエラー文言はDesign待ちで、創作しない。 • Given既存のaccepter、When権限を持つ実行者が変更または解除、Then audit dataに実行者、旧値、新値、時刻を記録する。保持は既存ポリシーに従い、新しい期間は指定しない。

ストーリー2 — 未割り当ての引き継ぎを理解する ownerまたはrequesterとして、accepterが未割り当てであることを認識し、誰かを指定するか、意図的に未割り当てのまま進めるかを判断したい。この表現はP02／P04の反例を保ち、待機がすべてエラーだとは示唆しない。

基準：accepterがないとき、承認済みの未割り当てvisual tokenを表示する。新しい状態は作らずReadyのまま。表示にはプログラムから判別可能なラベルがあり、色以外でも区別できる。キーボード利用者は論理的な順序でフィールドへ移動し、許可された操作をすべて実行できる。画面表示とアクセシビリティ用の正確な文言はDesign待ちで、最終的な文言の断定を妨げている。

範囲外：メールとpush、本番リリース、新しい保持期間、一般的な発生率や成果の主張、自動割り当て、本番SLA。analytics基準はevent名と目的が承認されるまで未確定。追跡関係ではP01／P03を可視性のストーリーへ結びつけ、P02／P04により任意割り当てと自動通知なしを維持する。

これがうまくいく理由

1
追跡可能性により、短いストーリー文が裏付けのない製品動作を隠すのを防げます。
2
境界と失敗シナリオにより、受け入れ基準がデモの正常経路だけに偏らなくなります。

結果を確認

各ストーリーは確認済みニーズの根拠と承認済み製品判断に対応していますか？
基準は観察可能で曖昧さがなく、架空のUIやしきい値を含んでいませんか？
関連する境界、権限、エラー、復旧、アクセシビリティ、プライバシー、未解決の判断を扱っていますか？

安心して使うために

よくある質問

このレシピをいつ使うか、何を用意するか、どの場面で人による確認が依然として重要かについての実践的な回答です。

「ユーザーストーリーと検証可能な受け入れ基準を作る」を使う前に、何を準備すればよいですか？

「ユーザーストーリーと検証可能な受け入れ基準を作る」を使う前に、ニーズと根拠、承認済みの製品判断、提供と検証の情報を準備してください。プレースホルダーは確認できる情報だけで置き換えます。不明な点はモデルに推測させず、不明であることを明記してください。

「ユーザーストーリーと検証可能な受け入れ基準を作る」の結果をまだ使えないのは、どのような場合ですか？

提供された根拠から、根拠、境界、シナリオ、受け入れ基準、非機能要件、依存関係、未解決の判断を含むストーリー一式をまだ作れていない場合や、未解決の仮定、得られていない承認、創作した詳細に依存している場合、その結果は使用できません。チェック項目を公開前の判定基準として使い、根拠のない出力を整えるのではなく、入力情報を修正するか、権限を持つ担当者を決めてレビューしてください。

「ユーザーストーリーと検証可能な受け入れ基準を作る」で、テスト記録があるAIツールはどれですか？

2026-08-28時点で、「ユーザーストーリーと検証可能な受け入れ基準を作る」の公開テスト記録にはChatGPTが記載されています。これは実行記録があることを示すだけで、後の製品バージョンでの互換性や同じ結果を保証するものではありません。別のツールやバージョンでは、すべての制約を明示したまま、使用前に結果をもう一度確認してください。

さらに探す方法