- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
書かなかったことは実装した誰かが決めます。今回は、書いたつもりでも決まっていない文を見分け、決まった文に書き換える手順を扱います。
まず結論
「わかりやすく表示する」は、どんな画面を出されても「満たしていない」と言い切れません。言い切れない部分は消えずに残り、何を「わかりやすい」とするかは実装した人か AI が黙って決めます。
確かめられる条件とは、満たしていないと言える文のことです。書き換えるには、何を見るか・どこで見るか・どこから不合格か、の3つを足します。
依頼文に「入力を誤ったときのエラー表示をわかりやすくする」と書きました。この条件を満たしていないと言えるのは、どんなときでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
「満たしていない」と言えない文は、何も決めていない
「エラー表示をわかりやすくする」と書いた依頼文を渡されたとします。どんな画面を作って見せても、「これはわかりやすくない」と言い切る根拠が文の中にありません。言い切れないなら、合格と不合格の境目は文の外、つまり読んだ側の頭の中にあります。
2009年の EARS の論文は、自然言語で書いた要件に起きる8つの問題を並べ、その1つをこう定義します。
Untestability (requirements that cannot be proven true or false when the system is implemented).
実装したあとで真とも偽とも証明できない要件、です。この回では裏返して、確かめられる条件とは「満たしていない」と言える文だと考えます(この言い方は教材側の言い換えで、論文の語ではありません)。
NASA のハンドブック付録C も同じ向きです。C.4 の Verifiability/Testability の項は Can the criteria for verification be stated? と問い、検証できない語の例を並べます。easy・user-friendly・appropriate・adequate・clearly などです。
第15期「直す順番を決めるのは、誰か」を前に読んだなら、そこで見た ASVS の「検証が合否のどちらかに決着すること」も同じ向きの条件です。
- ・3つの問いはこの教材の整理。「どこで見るか」は Gherkin Reference、「どこから不合格か」は NASA 付録C C.2 の許容範囲に対応する
Gherkin の Then は、外に出てくるものを見る
受け入れテストを書く記法 Gherkin の公式リファレンス(2026-09-24 取得)は、結果を書く Then についてこう助言します。
An outcome should be on an observable output. That is, something that comes out of the system (report, user interface, message), and not a behaviour deeply buried inside the system (like a record in a database).
続けて resist that temptation! と、DB を見に行きたくなる気持ちを退け、You should only verify an outcome that is observable for the user (or external system) と書きます。例に挙がるのは Receive an invitation や Card should be swallowed です。
これは Then ステップへの助言で、要件文一般の定義ではありません。それでも「どこで見るか」を決める手がかりになります。会員登録で「会員テーブルに行が増える」を条件にすると、利用者に確認メールが届かなくても合格してしまいます。
会員登録の受け入れテストを Gherkin で書きます。Then に置く結果として、Gherkin Reference の助言に沿うのはどれですか。
書き換えの手順は、3つの問いに答えること
確かめられない文を書き換えるときは、次の3つを順に埋めます。
- 何を見るか。表示される文か、届くメールか、返ってくる答えか
- どこで見るか。利用者か外部のシステムから見える場所か
- どこから不合格か。数・有無・一致など、境目を文に書く
3つ目について、NASA 付録C の C.2 は要件を Complete with tolerances for qualitative/performance values にするよう求め、書き方の例に less than, greater than or equal to, plus or minus を挙げます。
3つを埋めても曖昧さがゼロになるわけではありません。埋めた分だけ、読んだ側が黙って決める範囲が狭くなる、というのがこの手順の効き目です。
AI への「短く」を「3文以内で」に
AI に「結果を短く報告して」と頼むと、何を「短い」とするかは AI が決めます。10行の報告が返ってきても「短くない」とは言い切れません。「3文以内で」と書けば、4文なら満たしていないと言えます。プロンプト設計のクイズが正解としている「「短く」などの主観語より、「3文以内で」のように具体的な基準を示す」と同じ書き換えです。
ただし「3文以内」にも残る部分があります。箇条書きの1項目を1文と数えるのかは書いていないので、そこは AI が決めます。気になるなら「箇条書きを使わず」と足します。どこまで足すかは、残る曖昧さで困るかどうかで決めます。
AI への指示のうち、返ってきた答えを見て「指示を満たしていない」と言い切れるのはどれですか。
会員登録の受け入れ条件
「登録が正しく処理される」では不合格の出力がありません。会員テーブルの行を見ると、利用者に何も届かなくても合格します。利用者に届くメールを見る形に変えます。
問い 前 後何を見るか (無い) 確認メールどこで見るか (無い) 登録したアドレスの受信箱どこから不合格か (無い) メールが届かなければ不合格
AI への報告の指示
「短く報告して」では、どの長さも短くないと言い切れません。文の数で境目を決めると、4文の報告は満たしていないと言えます。数え方の残りは必要なら足します。
問い 前 後何を見るか (無い) 返ってきた報告どこで見るか (無い) AI の返答そのものどこから不合格か (無い) 4文以上なら不合格
人が読む受け入れ条件と、AI が読む指示。読み手は違いますが、書き換えで足したものは同じでしょうか。
表の「前」の列が、両方とも何になっているかを見てください。
この章のまとめ
- 確かめられる条件とは 「満たしていない」と言える文(教材側の言い方)。EARS の Untestability は「実装後に真とも偽とも証明できない要件」。
- NASA 付録C C.4 は
easy・user-friendly・appropriateなどを検証できない語の例に挙げる。 - 書き換えは 何を見るか・どこで見るか・どこから不合格か を足すこと。
- Gherkin の Then は観測できる出力で確かめるよう求め、DB の行を見る誘惑を退ける。
- 「短く」→「3文以内で」で不合格と言える範囲は広がるが、残った曖昧さは読んだ側が決める。
- 書いたつもりでも境目の無い文は、実装した人か AI が黙って決めている。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
EARS の論文(RE'09)は、自然言語の要件に起きる問題の1つ Untestability をどう説明していますか。
用語集(3語)
- 確かめられる条件
- 満たしていないと言える文。この教材での言い方で、一次ソースの用語ではない。EARS の Untestability(真偽を証明できない要件)の裏返しにあたる。
- 観測できる出力
- システムの外に出てくるもの。Gherkin Reference は報告・画面・メッセージを挙げ、DB の行のような内部の状態と区別する。
- 許容範囲 (tolerance)
- どこから不合格かを決める幅。NASA 付録C C.2 は less than・greater than or equal to・plus or minus などの形で書くよう求める。