曖昧な要望をAcceptance Criteriaに分解

学習のねらい

AI に具体的なコードを書いてもらうためには、曖昧な「〜したい」という要望を、誰が読んでも同じ意味になる「〜であること」という明確な条件に分解することが重要です。 このレッスンでは、Acceptance Criteria (AC、受入条件) と呼ばれる手法を使って、要件を詳細なテスト可能な条件に落とし込む方法を学びます。これにより、AI がどこまで実装すれば良いかを明確に指示できるようになります。

Acceptance Criteria (AC) とは

AC は、ある機能が「完成した」と判断するための基準を具体的に記述したものです。 一般的に、Given / When / Then の3部構成で記述されます。

• Given (前提条件): 何かを行う前の初期状態や状況
• When (操作): ユーザーがシステムに対して行う特定のアクションやイベント
• Then (結果): そのアクションの結果としてシステムがどう振る舞うべきか

例: 「ユーザーがログインできる」という要望の AC

• Given: ユーザーが未ログイン状態である

• When: ユーザーが正しいメールアドレスとパスワードを入力してログインボタンをクリックする

• Then: ユーザーはダッシュボード画面に遷移し、「ログインに成功しました」というメッセージが表示される

• Given: ユーザーが未ログイン状態である

• When: ユーザーが間違ったメールアドレスを入力してログインボタンをクリックする

• Then: 「メールアドレスまたはパスワードが間違っています」というメッセージが表示され、ログイン画面に留まる

このように、Given/When/Then を使うことで、どのような状況で、どのような操作をしたら、どうなるべきか、という一連の振る舞いを具体的に定義できます。

Done 条件の明文化

AC を記述する際は、「これで終わり」という Done 条件を明確にすることが大切です。 例えば、「ログインできる」という要望に対して、AC を複数書くことで、どのようなケースまで考慮すれば「ログイン機能が完成した」と言えるのかが明確になります。 これにより、AI も「どこまで実装すれば合格点なのか」を理解しやすくなります。

Out of scope (範囲外) の列挙

AC を書くとき、同時に「今回の実装では対応しないこと」を明確にすることも有効です。 これを Out of scope (範囲外) と呼びます。 例えば、ログイン機能では「二段階認証は今回対象外」「パスワード再設定機能は別途検討」といった具合です。 これにより、AI が不要な機能を実装したり、複雑な考慮事項に時間を費やしたりするのを防ぎ、タスクの範囲を絞り込めます。

まとめ

曖昧な要望を AC に分解することで、AI とのコミュニケーションが格段にスムーズになります。 Given/When/Then で具体的な振る舞いを記述し、Done 条件と Out of scope を明確にすることで、AI は迷うことなく正確な実装を進められるようになります。