---
sourceDocument: オーストラリア 戦略的ポートフォリオ管理 (SPM)
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/it-business-management

 Release :

    - australia

ft:locale :

    - ja-JP

ft:publication_title :

    - オーストラリア 戦略的ポートフォリオ管理 (SPM)

ft:clusterId :

    - itbm

bundleId :

    - itbm

workflow :

    - Technology


---

# アジャイル開発 2.0 での効果的なストーリーの記述

# アジャイル開発 2.0 での効果的なストーリーの記述 {#ariaid-title1}

* リリースバージョン: Australia
* 
* 更新日 2026年03月12日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

ストーリーの記述が適切だと、あらゆる開発者や、テストまたはドキュメントなどのチームのメンバーも理解しやすくなります。

ストーリーを使用すると、アサイン先グループは、完了の定義に従って作業を実施するために必要な工数を正確に見積もることができます。完了の定義は、ストーリーがどのような状況で完了するかを決定する、グループによって合意された終了基準です。  
ストーリーには、次の基本条件があります。

* 説明：ストーリーの説明は、アドミンなどのユーザーペルソナに関連し、ビジネス価値を説明するか、技術的負債に対処します。
* 受け入れ基準：ストーリーの受け入れ基準は測定可能およびテスト可能です。
{#how-to-write-stories__ul_jhr_1mg_dp}

## ストーリーの説明

適切なユーザーストーリーの説明は、指定された要件を満たすための次のことを示しています。

* システム内のユーザーペルソナのロール
* ユーザーペルソナによって表されるニーズ
* 開発者、ユーザーなどのすべてのステークホルダーにとってのメリット
{#how-to-write-stories__ul_c3y_mmw_d1b}

通常、ストーリーの説明は、「\<ロール\> として、\<メリット\> のために、\<目標またはニーズ\> を実現したい」という形式で表現されます。

適切なストーリーの説明の例
:
    * 説明：開発者として、本番システムにアプリケーションを展開するために、アプリケーションの現在のステータスを更新セットに公開したいと考えています。
    * 説明：顧客として、最新のステータスを得るために、インシデントにコメントが入力されたときに通知を受け取るようにしたいと考えています。
    * 説明：変更マネージャーとして、複数の選択肢からなる質問のリストを作成して、特定の変更に対するリスクのアセスメントを可能にしたいと考えています。
    {#how-to-write-stories__ul_dhg_wmg_dp}

不適切なストーリーの説明の例

:   説明：インシデントが作成されると、通知が送信されます。

    この説明は、次の理由で不適切です。

    * 説明に、通知の送信者や送信内容が記載されておらず、またメールなどの通知の形式も記載されていません。
    * 説明にメリットに関する情報が含まれていないため、ビジネス価値が明確ではありません。
    {#how-to-write-stories__ul_ukd_bng_dp}

    次のように記述してください。

    説明：インシデント作成者として、関係者に影響を与えるインシデントが作成されたときに関係者に通知できるように、インシデントを作成するときに、事前定義された一連の関係者にメール通知を送信したいと考えています。

## ストーリーの受け入れ条件

受け入れ基準は、ユーザーストーリーの境界を定義し、ソフトウェアが意図したとおりに動作している状況、つまりストーリーが完了した状況を確認するために使用されます。受け入れ基準は、ストーリーの「完了の定義」の重要な部分です。

適切な受け入れ条件

:   適切な受け入れ条件には、必要に応じて以下のことを含める必要があります。

    * 使いやすさ：受け入れ条件には、使いやすさの測定値を必ず含めてください。この質問に対する回答方法を示してください：使いやすいですか？重要なのは、適切な測定値を特定し、それぞれが定量化可能であることを確認することです。
    * 機能：プロジェクトの最後に実施する必要がある特定のユーザータスク、ビジネスプロセス、または機能を特定します。機能の要件は次のとおりです：ユーザーは複数のサイズから選択できます。
    * エラー処理：エラーケースとそれぞれの処理方法を列挙します。たとえば、ユーザーが間違った順序でステップを実行した場合に、ソフトウェアはそれをどのように処理するのでしょうか？
    * パフォーマンス：個々のユーザーの観点からシステムパフォーマンスをテストします。例：UI はレスポンシブですか？
    * ストレステスト：多数のユーザー、トランザクション、またはクエリによりシステムがストレスを受けたときにシステムがどのように対応するかを説明します。受け入れ条件では、ストレステストの許容可能なしきい値を定義する必要があります。例：100 人のユーザーが同時にクエリを送信した場合、システムは 250 ミリ秒のしきい値以内に応答しますか？
    {#how-to-write-stories__ul_ebt_nkq_pz}

適切な受け入れ条件の例

:   説明：顧客として、クレジットカード情報の安全性を確保するために、安全な Web ベースのフォームを使用して書籍の注文と支払いを行いたいと考えています。

    受け入れ条件：

    * 顧客がフォームを送信する前に、すべての必須フィールドに入力する必要がある。
    * フォームの情報は、顧客注文データベースに保存される。
    * 支払いは、Amex、マスターカード、または Visa クレジットカードで行うことができる。
    * システムは売上税を正確に計算して適用しなければならない。
    * システムは配送料を正確に計算して適用しなければならない。
    * 顧客は注文の正確性を確認できるものとする。
    * フォームを送信した顧客に確認メールが送信される。
    * スパムに対する保護機能が働く。
    {#how-to-write-stories__ul_fd5_h4g_dp}

不適切な受け入れ条件の例

:   説明：顧客として、最新のステータスを得るために、インシデントにコメントが入力されたときに通知を受け取るようにしたいと考えています。

    受け入れ条件：インシデントにコメントが入力されたときに、適切な担当者に通知されます。

    適切な担当者が明確でないなど、テストに十分な詳細が提供されていないため、受け入れ条件は不十分です。  
    受け入れ条件は、次のように記述してください。

    1. ESS ユーザーとして、インシデントを作成します。
    2. \[ステークホルダーに通知\] を選択します。
    3. インシデントを保存します。
    4. ステークホルダーとしてログインします。
    5. ログに記録されたインシデントのメールを受信したことを確認します。
    {#how-to-write-stories__ol_fgl_s4g_dp}