acceptance-criteria

受け入れ条件の作成

概要

このスキルでは、ServiceNow の Agile Development 2.0 モジュールでユーザーストーリーや機能の包括的な受け入れ条件を作成するための体系的な方法を紹介します。以下を扱います。

• Given／When／Then（Gherkin）形式で受け入れ条件を記述する
• 基本フロー、代替フロー、エッジケースを網羅する
• 機能要件、検証ルール、エラー処理に対応する
• パフォーマンスのしきい値とセキュリティ制約を定義する
• QA 準備のため、条件をテスト可能な要件に関連付ける
• 適切な形式の受け入れ条件をストーリーレコードに反映する

使用する場面： ServiceNow SPM でのスプリント計画やストーリーの詳細化セッションの前に、プロダクトオーナーやスクラムマスターが明確でテスト可能な受け入れ条件を定義する必要がある場合。

前提条件

• プラグイン： com.snc.sdlc.agile.2.0（Agile Development 2.0）
• ロール： scrum_user、scrum_master、または scrum_admin
• アクセス権： rm_story、rm_epic テーブルへの読み取り／書き込みアクセス
• 知識： ストーリーの機能要件とユーザーペルソナの理解

手順

ステップ 1：ユーザーストーリーを取得する

受け入れ条件を記述する前に、要件を理解するためにストーリーレコードを取得します。

MCP の使用（Claude Code/Desktop）：

Tool: SN-Get-Record
Parameters:
  table_name: rm_story
  sys_id: [story_sys_id]
  fields: sys_id,number,short_description,description,acceptance_criteria,story_points,epic,sprint,state,priority,classification,product,assigned_to

ストーリー番号しか分からない場合は、先に検索します。

MCP の使用：

Tool: SN-Query-Table
Parameters:
  table_name: rm_story
  query: number=STY0010001
  fields: sys_id,number,short_description,description,acceptance_criteria,story_points,epic,sprint,state,priority,classification
  limit: 1

REST API の使用：

GET /api/now/table/rm_story?sysparm_query=number=STY0010001&sysparm_fields=sys_id,number,short_description,description,acceptance_criteria,story_points,epic,sprint,state,priority,classification&sysparm_limit=1&sysparm_display_value=true

ステップ 2：親エピックからコンテキストを収集する

機能全体のコンテキストを理解すると、より完全な受け入れ条件を作成できます。

MCP の使用：

Tool: SN-Query-Table
Parameters:
  table_name: rm_epic
  query: sys_id=[epic_sys_id]
  fields: sys_id,number,short_description,description,state,priority,acceptance_criteria
  limit: 1

REST API の使用：

GET /api/now/table/rm_epic/[epic_sys_id]?sysparm_fields=sys_id,number,short_description,description,state,priority,acceptance_criteria&sysparm_display_value=true

ステップ 3：関連するストーリーを確認して一貫性を保つ

同じエピックに属する兄弟ストーリーを検索し、条件に一貫性を持たせ、重複を避けます。

MCP の使用：

Tool: SN-Query-Table
Parameters:
  table_name: rm_story
  query: epic=[epic_sys_id]^sys_id!=[story_sys_id]^ORDERBYpriority
  fields: number,short_description,acceptance_criteria,state,story_points
  limit: 20

REST API の使用：

GET /api/now/table/rm_story?sysparm_query=epic=[epic_sys_id]^sys_id!=[story_sys_id]^ORDERBYpriority&sysparm_fields=number,short_description,acceptance_criteria,state,story_points&sysparm_limit=20&sysparm_display_value=true

ステップ 4：受け入れ条件を作成する

以下のカテゴリーに沿って受け入れ条件を構成します。

カテゴリー 1：基本フロー（必須） ストーリーで説明されている主要な成功シナリオです。

Scenario: Successful [action]
  Given [precondition describing the initial state]
  And [additional precondition if needed]
  When [action the user performs]
  And [additional action if needed]
  Then [expected observable outcome]
  And [additional outcome or side effect]

カテゴリー 2：代替フロー（必須） 機能を通る、有効ではあるものの既定ではない経路です。

Scenario: [Action] with [variation]
  Given [precondition with variation]
  When [action with different input or context]
  Then [expected outcome for this variation]

カテゴリー 3：エラー処理（必須） 無効な入力や障害条件に対するシステムの応答です。

Scenario: [Action] with invalid [input/state]
  Given [precondition]
  When [action with invalid data]
  Then [error message or validation feedback]
  And [system state remains unchanged]

カテゴリー 4：エッジケース（推奨） 境界条件、空の状態、極端なケースです。

Scenario: [Action] at boundary condition
  Given [boundary precondition]
  When [action at limit]
  Then [expected behavior at boundary]

カテゴリー 5：パフォーマンスとセキュリティ（該当する場合） テスト可能である必要がある非機能要件です。

Scenario: [Action] performance requirement
  Given [load or data volume condition]
  When [action is performed]
  Then [response time or throughput requirement is met]

ステップ 5：条件の品質を検証する

品質チェックリストを使用して、各条件を確認します。

品質チェック	説明	合格基準
テスト可能	明確な合否で検証できる	「すばやく」や「使いやすい」などの曖昧な表現がない
独立性	各シナリオが単独で成立する	シナリオ間に依存関係がない
具体性	具体的な値が含まれている	正確な数値、メッセージ、状態を使用している
完全性	要件のすべての側面を網羅している	基本フロー＋エラー＋エッジケース
簡潔性	冗長なシナリオがない	各シナリオが固有の条件をテストする
一貫性	ストーリーの範囲に合致している	ストーリーの範囲を超えず、また不足もしない

ステップ 6：ストーリーレコードを更新する

確定した受け入れ条件をストーリーに書き戻します。

MCP の使用：

Tool: SN-Update-Record
Parameters:
  table_name: rm_story
  sys_id: [story_sys_id]
  fields:
    acceptance_criteria: |
      Scenario: Successful customer search by phone number
        Given I am logged in as a customer service representative
        And I am on the customer search screen
        When I enter a complete phone number "555-0123" in the search field
        And I click the Search button
        Then matching customer records are displayed within 2 seconds
        And results show customer name, account number, and account status
        And results are sorted by relevance with exact matches first

      Scenario: Partial phone number search
        Given I am logged in as a customer service representative
        When I enter a partial phone number "555" in the search field
        And I click the Search button
        Then all customers with phone numbers containing "555" are displayed
        And a maximum of 50 results are shown with pagination

      Scenario: No matching results
        Given I am logged in as a customer service representative
        When I enter a phone number with no matching records
        And I click the Search button
        Then a message "No customers found matching the provided phone number" is displayed
        And the search field retains the entered value

      Scenario: Invalid phone number format
        Given I am logged in as a customer service representative
        When I enter non-numeric characters "abc-defg" in the phone search field
        And I click the Search button
        Then a validation message "Please enter a valid phone number" is displayed
        And no search query is executed

      Scenario: Empty search field submission
        Given I am logged in as a customer service representative
        When I click the Search button without entering a phone number
        Then a validation message "Phone number is required" is displayed

      Scenario: Search performance under load
        Given the customer database contains over 1 million records
        When I search for a phone number
        Then results are returned within 3 seconds

REST API の使用：

PATCH /api/now/table/rm_story/[story_sys_id]
Content-Type: application/json

{
  "acceptance_criteria": "Scenario: Successful customer search by phone number\n  Given I am logged in as a customer service representative\n  And I am on the customer search screen\n  When I enter a complete phone number \"555-0123\" in the search field\n  And I click the Search button\n  Then matching customer records are displayed within 2 seconds\n  And results show customer name, account number, and account status\n\nScenario: No matching results\n  Given I am logged in as a customer service representative\n  When I enter a phone number with no matching records\n  Then a message \"No customers found\" is displayed"
}

ステップ 7：受け入れ条件がないストーリーを一括更新する

バックログから受け入れ条件がなく、詳細化が必要なストーリーを探します。

MCP の使用：

Tool: SN-Query-Table
Parameters:
  table_name: rm_story
  query: epic=[epic_sys_id]^acceptance_criteriaISEMPTY^state=-6
  fields: sys_id,number,short_description,description,story_points,priority
  limit: 25

REST API の使用：

GET /api/now/table/rm_story?sysparm_query=epic=[epic_sys_id]^acceptance_criteriaISEMPTY^state=-6&sysparm_fields=sys_id,number,short_description,description,story_points,priority&sysparm_limit=25&sysparm_display_value=true

ツールの使用方法

MCP ツールのリファレンス

ツール	使用する場面
SN-Get-Record	sys_id で単一のストーリーまたはエピックを取得する
SN-Query-Table	ストーリー、エピック、および関連レコードを検索する
SN-Update-Record	受け入れ条件をストーリーに書き戻す
SN-Natural-Language-Search	条件が必要なストーリーを自然言語で検索する

REST API リファレンス

エンドポイント	メソッド	目的
/api/now/table/rm_story	GET	ストーリーを検索し、受け入れ基準を取得します
/api/now/table/rm_story/{sys_id}	GET	特定のストーリーレコードを読み取ります
/api/now/table/rm_story/{sys_id}	PATCH	ストーリーの受け入れ基準を更新します
/api/now/table/rm_epic	GET	基準を作成するためのエピックのコンテキストを取得します
/api/now/table/rm_epic/{sys_id}	GET	特定のエピックの詳細を読み取ります

ベストプラクティス

• ハッピーパスから始める： まず主要な成功シナリオを定義し、その後でエラーケースやエッジケースを追加します
• 具体的な値を使う： 曖昧な表現を具体的な数値、メッセージ、状態に置き換えます（例：「すぐに」ではなく「2 秒以内に」）
• 1 つのシナリオにつき 1 つの動作： 各 Given/When/Then ブロックでは、動作または条件を 1 つだけテストします
• 実装の詳細は避ける： 基準ではシステムが何をするかを記述し、内部でどのように構築されているかは記述しません
• 否定テストを含める： 無効な入力、認証されていないアクセス、システムエラーが発生した場合の動作を必ず定義します
• 境界条件を網羅する： 空の入力、最大長、数量ゼロ、日付の境界などの制限値をテストします
• ストーリーの範囲に合わせる： 基準がストーリーの範囲を超えないようにします。超える場合は、ストーリーを分割する必要があるかもしれません
• チームでレビューする： 受け入れ基準はプロダクトオーナー、開発者、テスターの合意を得る必要があります

トラブルシューティング

「受け入れ基準が曖昧すぎてテストできない」

原因： 「使いやすい」「速い」「直感的」などの主観的な表現を使っている 解決策： 「2 秒以内に読み込む」「検証メッセージを表示する」「1 ページあたり 10 件の結果を表示する」など、測定可能な表現に置き換えます

「ストーリーに受け入れ基準があるのに、QA で失敗し続ける」

原因： 基準にエッジケースやエラー処理のシナリオが不足している可能性があります 解決策： 5 つのカテゴリ（ハッピーパス、代替ケース、エラー、エッジケース、パフォーマンス）に照らして基準をレビューし、不足しているシナリオを追加します

「acceptance_criteria フィールドを更新できない」

原因： フィールドレベルの ACL 制限、またはストーリーがロックされた状態（例：Closed）にあります 解決策： 自分のロールに rm_story.acceptance_criteria への書き込みアクセス権があることを確認します。Closed 状態（state=7）のストーリーは、再オープンしないと編集できません。

「保存後に受け入れ基準が途中で切れている」

原因： acceptance_criteria フィールドに文字数制限が設定されている可能性があります 解決策： 辞書（sys_dictionary）でフィールドの長さを確認します。デフォルトは 4000 文字です。より長い基準には、description フィールドを使用するか、ドキュメントを添付します。

例

例 1：ログイン機能の受け入れ基準

ストーリー：「登録ユーザーとして、メールアドレスとパスワードでログインし、ダッシュボードにアクセスしたい」

生成された受け入れ基準：

Scenario: Successful login with valid credentials
  Given I am on the login page
  And I have a registered account with email "[email protected]"
  When I enter my email "[email protected]" and correct password
  And I click the "Sign In" button
  Then I am redirected to my dashboard
  And my display name appears in the top navigation
  And my last login timestamp is updated

Scenario: Login with incorrect password
  Given I am on the login page
  When I enter my email "[email protected]" and an incorrect password
  And I click the "Sign In" button
  Then an error message "Invalid email or password" is displayed
  And no indication is given whether the email or password was wrong
  And the failed attempt is logged for security auditing

Scenario: Login with unregistered email
  Given I am on the login page
  When I enter an unregistered email "[email protected]"
  And I click the "Sign In" button
  Then an error message "Invalid email or password" is displayed

Scenario: Account locked after failed attempts
  Given I have failed login 5 times consecutively
  When I attempt to log in a 6th time
  Then my account is temporarily locked for 30 minutes
  And a message "Account locked. Try again in 30 minutes." is displayed
  And a security notification email is sent to my registered address

Scenario: Login with empty fields
  Given I am on the login page
  When I click "Sign In" without entering email or password
  Then validation messages appear for both required fields
  And no authentication request is sent

Scenario: Session timeout after inactivity
  Given I am logged in
  When I am inactive for 30 minutes
  Then my session expires
  And I am redirected to the login page with message "Session expired"

例 2：スプリントバックログの基準を一括生成する

シナリオ： 受け入れ基準がない、次のスプリントのすべてのストーリーについて受け入れ基準を生成します。

ステップ 1 - 基準がないストーリーを検索する：

Tool: SN-Query-Table
Parameters:
  table_name: rm_story
  query: sprint=[sprint_sys_id]^acceptance_criteriaISEMPTY
  fields: sys_id,number,short_description,description,story_points
  limit: 30

ステップ 2 - 各ストーリーの基準を生成して更新する：

Tool: SN-Update-Record
Parameters:
  table_name: rm_story
  sys_id: [story_sys_id]
  fields:
    acceptance_criteria: |
      Scenario: [Primary success scenario]
        Given [precondition]
        When [user action]
        Then [expected result]

      Scenario: [Error handling scenario]
        Given [precondition]
        When [invalid action]
        Then [error feedback]

出力の概要：

ACCEPTANCE CRITERIA GENERATION REPORT
Sprint: Sprint 2026-04-A
Stories Updated: 8 of 8

STY0010101 - Add to cart (3 scenarios: happy path, out of stock, max quantity)
STY0010102 - Remove from cart (3 scenarios: single item, last item, undo)
STY0010103 - Update quantity (4 scenarios: increase, decrease, zero, max)
STY0010104 - Apply coupon code (4 scenarios: valid, expired, invalid, stacking)
STY0010105 - View cart total (3 scenarios: with tax, empty cart, multi-currency)
STY0010106 - Save cart for later (3 scenarios: save, restore, expiration)
STY0010107 - Share cart via link (3 scenarios: generate link, access, expired link)
STY0010108 - Cart item availability check (3 scenarios: in stock, limited, unavailable)

Total Scenarios: 26
Stories Ready for Sprint Planning: 8/8

関連スキル

• spm/agile-story-generation - 要件からユーザーストーリーを生成する
• spm/project-insights - プロジェクトの健全性とベロシティ指標を追跡する
• spm/planning-summarization - スプリント計画とリリース計画を要約する
• development/automated-testing - 受け入れ基準から自動テストケースを生成する
• development/business-rules - 基準で参照されている検証ルールを実装する