今日の文書 — 機能要件定義書
機能要件定義書 — 業務要件(Day015: 何を実現したいか)を受けて、システムが「どの入力のとき、何を出力し、何を記録するか」 を、作る人が迷わず・受入れる人が確かめられる形で書く文書。業務要件が「贈り物と決めた箱にカードを入れない」なら、機能要件は「何を見て贈り物と決め、見えないときにどうするか」まで下りる。
| 比べる文書 | 何を決めるか | 読み手 |
|---|---|---|
| 業務要件定義書(Day015) | 業務の結果と業務ルール(解決策は書かない) | 業務責任者・開発 |
| 機能要件定義書(今日) | システムが何をするか(入力・条件・出力・例外)。どう作るかは書かない | 作る人・受入れる人 |
| 非機能要件定義書(次の回の候補) | どれだけ速く・止まらず・安全か | 開発・運用 |
| 基本設計書(外部設計) | 画面・帳票・IF の形(機能要件を満たす解決策) | 発注者・開発 |
この文書の勝負どころ: 曖昧語(適切に・速やかに)が排除されているか。
今日はこれを実務の言葉に言い換える。曖昧語を消すとは、言葉を数字に置き換えることだけではない。「2人の開発者が別々に読んで、同じテストケースを書けるか」で測る。 書けないところは、数字の問題ではなく定義か、例か、決めていない判断が抜けている。
| 考え方 | 中身 | 今日の題材に当てはめると |
|---|---|---|
| 要求1件の品質特性(ISO/IEC/IEEE 29148 など): 曖昧でない(解釈が1つ)/単一(1件が1つのこと)/検証できる | 1文に複数の約束を入れない。読み手が違っても同じ意味に取れる。合格か不合格かを決められる | 「適切に判定する」は検証できない。「判定と、住所の比較と、エラー時」を1文に詰めると単一でない |
| EARS(Mavin ら、Rolls-Royce、RE'09): 要求を「〜のとき(WHEN)/〜の間(WHILE)/もし〜なら(IF…THEN)、システムは〜する」の型で書く | きっかけ(トリガー)と応答を必ず対にする。IF…THEN は「起きてほしくないこと」への応答を書く型 | 「判定できない場合は必要に応じて」は IF…THEN が欠けている。何が起きたら、何をするか |
| 例による仕様(Adzic『Specification by Example』2011 の考え方) | 文章の説明に、入力と期待する出力の具体例を添え、それを受入れテストにする | 住所12例の表が、浅野さんの見積の前提であり、今井課長の「こう動くのか」の確認でもある |
曖昧語の置き換え表(この回の道具)
| よく出る言葉 | 何が抜けているか | 置き換えの形 |
|---|---|---|
| 適切に/適宜 | 基準 | 基準を条件で書く(「Aのとき X、Bのとき Y」) |
| 速やかに/すぐに | 時間 | 「〜から○秒以内」「次の出荷指示の生成前に」 |
| 必要に応じて/場合によっては | 誰が・いつ判断するか | 条件を列挙する。列挙できないなら決めていないと書く |
| 〜等/〜など/その他 | 範囲 | 全部書く。書けないなら範囲外と書く |
| 考慮する/配慮する/対応する | 結果 | 「Aを B にそろえてから比べる」と処理を書く |
| 使いやすい/分かりやすい | 測り方 | 「初見の物流担当が5分以内に〜できる」など測れる形(または非機能へ) |
| エラーとする | その後の動き | 「止める/流す/記録する/誰に知らせる」のどれか |
| 一致する/同じ | 比べる項目と、そろえ方 | 項目を列挙し、比べる前の処理を書く(今日の中心) |
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田(Day004〜Day031 の続き)。
2028年6月9日(金)。5/30 の要件確認会(Day015)で、今井課長は「贈り物」の定義を案B(包装・のしを選んだ注文、または送り先が注文者と違う注文を贈り物とする)に決めた。条件は1つ。「見逃し(自分宛てなのにカードが入らない)の中身を、数字で見せてほしい」。
倉庫システムの出荷指示を作る部分を直すのは、保守ベンダーの ミナトソフトの浅野SE(新登場)。見積を出し、書いてあるとおりに作る。浅野さんは物流センターに来たことがなく、Day015 の議論の場にもいなかった。渡されるのは、この機能要件定義書の1通だけである。窓口は情報システム部の長谷川さん(Day015)。
6/6(火)に長谷川さんが、4月の初回購入の注文(27,720件)に案Bを当てはめて数えた〔実測: シナリオ内の設定〕。
| 4月の初回購入・包装なしで、送り先が注文者と「違う」と数えた注文 | 件数 | 中身 |
|---|---|---|
| 郵便番号〜番地が違う(はっきり別の場所) | 520件 | 贈り物。カードを入れない |
| 郵便番号〜番地は同じで、建物名・部屋番号だけ違う | 200件 | 内訳 → 別の部屋 140件(同じマンションの別室など。贈り物の可能性)/同じ部屋の書き方の違い 60件(「ハイツ青葉101」と「ハイツ青葉101号室」など) |
| (合計) | 720件 | Day015 の誤投入 約720箱と同じ集合 |
- 提出: 6/9(金)17:00 に浅野さんと今井課長へ。説明会は 6/14(水)10:00(45分)。ベンダー見積の依頼は 6/16(金)、回答は 6/23(金)、設計着手 7/3(月)、稼働 8/28(月)、次の同梱物(秋の誕生月クーポン)は 9/4(月)から〔仮定: MOps計画〕
- Lv2(距離のある読み手)の回。 カタログの主な読み手(開発・発注者)のうち、前提を共有していない外部の開発者と、システムの言葉を読まない受入れ側の業務責任者に同時に届ける。ルール5(間接読み手)は要らない
- 面倒な事情:
- 業務要件 R-1 は「贈り物と決めた箱に入れない」だが、「送り先が違う」を機械が判断するには、住所の「同じ」を決めなければならない。住所の書き方は、全角半角・「1丁目2番3号」と「1-2-3」・「101」と「101号室」とバラバラ
- 一致を甘く取る(建物名・部屋番号を見ない)と、同じマンションの別室への贈り物にカードが入る。厳しく取ると、自分宛てなのに書き方の違いでカードが入らない。 誤投入(受取人に「初めての購入ありがとう」)の方が重い。ただし、どちらに倒すかを浅野さんが選んではいけない。物流と販促が選ぶ
- 住所が空欄・読めない注文が、4月に18件あった〔実測: シナリオ内の設定〕。「エラーとする」と書くと、出荷を止めるのか、流すのかで、現場に与える影響が真逆になる
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 浅野SE(ミナトソフト。倉庫システムの保守を5年担当。物流センターには行ったことがない)と、今井課長(出荷管理課長。受入れテストの合否を決める)。窓口の長谷川さんが写し |
| 何を判断するために読むか | 浅野さん: ①何を作ればよいか ②見積に足りない情報は何か(足りなければ安全側に高く見積もる) ③どこで書いてあるとおりに作ると事故になるか。今井課長: ④自分が決めることは何か ⑤出来上がりを何で確かめるか |
| 何を知っているか | 浅野さん: 倉庫システムのデータ(住所の項目構成)、出荷指示の生成のしくみ。今井課長: 梱包ラインの実際、4月に何が起きたか、案Bを自分が選んだこと |
| 何を知らないか | 浅野さん: なぜカードを入れてはいけないか、どちらの間違いがより重いか、現場は何秒で箱を見るか。今井課長: 「一致」を機械がどう判断するか、住所の書き方のばらつきの大きさ |
| 何を気にしているか | 浅野さん: 後から「それは当然こうでしょ」と言われる手戻り、見積を超える作業。今井課長: 梱包のスピードが落ちないこと、現場が新しい判断をしなくていいこと、聞いていない動きで出荷が止まること |
| 読む時間と場面 | 浅野さん: 説明会前日に机で40分、見積の根拠にする(曖昧なところに付箋を貼る)。今井課長: 前日に1ページ目だけ10分、例の表に○×を付ける |
この読み手が変わると何が変わるか: 読み手が 同じ会社の長谷川さんだけ(Lv1: 味方)なら、業務の背景は省け、「F-3 は住所正規化の共通部品を使う」と書いてよい。読み手が 見積を競わせる複数ベンダー(Lv3: 利害が対立)なら、曖昧さがそのまま見積の差と後の追加請求になるので、例の表を契約の別紙にする。読み手が システムを知らない経営層(Lv4)なら、機能の一覧より先に「どちらの間違いを許すか」の1文を置く。今回は 前提を共有しない外部の開発者と、機械の判断を読まない業務責任者 なので、1ページ目に「業務の人が決めること」を置き、機能要件は「書いてあるとおりに作れば同じものができる」粒度で2ページ目以降に置く。例の表は両方が使う。
4段階で見る — 3.機能要件「贈り物の判定と住所の一致(F-2・F-3)」
以下は同じ機能要件定義書の 「3. 機能要件」のうち、贈り物の判定と住所の一致を4段階で書き分けたもの。機能要件定義書で最も差が出るのは、機能の数ではなく、条件の言葉が一つに決まっているかである。
タブで精読、「横に並べる」で差を一望できる(横並びは各段階の要点3行だけ)。
行数 11・13・14・17行、字数 Bad269 → Good326 → Better478 → Best697字(空白を除く・実測)。Best が最長(Good→Better→Best と単調増加)。Best で初めて「業務側が選ぶ表」と「決まらなかったときの既定」が揃う。
「適切に」「など」「配慮し」「必要に応じて」が条件の中心。
「エラーとして扱う」の後(止める?流す?)がない。
受入れ「適切に動作すること」は合否が決まらない。ID・入力・出力・優先度の型は完璧。見積に使える形。
ただし「一致しない」の一致が未定義(建物名は?号室は?)。
エラーはログに残すだけで、出荷がどうなるか不明。一致を「6項目・そろえ方4つ・すべて同じ」で定義。
判定不能は「不一致・カードなし・出荷は止めない」。
受入れ=例12件。ただし厳しさ(建物名まで)は黙って選択。冒頭に「決めていただきたいこと」。P/Q案を4月の件数と代償で。
判定不能の動きと、決まらなければ6/15にQで見積。
付録の例12件を見積の前提・受入れテストに。"appropriately / as needed / promptly / etc." in the conditions.
What happens after "handle as an error" is missing.
Acceptance "work properly" cannot be pass/fail.IDs, shall, Must: standard form, usable for a quote.
"does not match" is undefined (building? room?).
Only logs the error; shipment behavior unknown.When ... shall / If ... shall (EARS). Match defined as six fields, N-1..4.
Unreadable = mismatch, no insert, shipment not held.
Acceptance = 12 examples; strictness chosen silently."Decisions requested" first; Option P/Q with April counts and cost.
Default if undecided (June 15, Q); out of scope stated.
Appendix A examples = basis of the quote and the acceptance test.3. 機能要件
3.1 同梱対象判定機能
システムは、出荷指示ごとに、同梱物の対象かどうかを適切に判定すること。
(1) 贈り物と判断される注文は、同梱の対象外とする。
(2) 送り先が注文者と異なる場合など、贈り物と考えられる場合も対象外とする。
(3) 住所の比較は、表記ゆれ等に配慮し、適切に行うこと。
(4) 判定結果は、速やかに出荷指示へ反映すること。
(5) 判定できない場合は、必要に応じてエラーとして扱うこと。
(6) 利用者にとって分かりやすい画面とすること。
(7) その他、詳細は設計時に協議のうえ決定する。
受入れ基準: 上記の機能が適切に動作すること。Subject: Functional requirements - Gift inserts
3. Functional Requirements
3.1 Insert eligibility
The system shall appropriately determine whether an order is eligible for an insert.
(1) Orders considered gifts shall be excluded.
(2) Orders where the ship-to differs from the orderer, etc., shall also be treated as gifts.
(3) Address comparison shall take typographical variation into account as appropriate.
(4) The result shall be applied to the shipping instruction promptly.
(5) If the determination is not possible, handle as an error as needed.
(6) The screen shall be user-friendly.
(7) Other details to be discussed during design.
Acceptance: The above functions work properly."appropriately / as appropriate / promptly / as needed / user-friendly / etc." は英文の要件書で weak words として機械的に検出される典型。"shall" を使っていても、条件が曖昧なら要件になっていない。
3. 機能要件
ID 機能名 要件 入力 出力 優先度
F-2 贈り物判定 システムは、出荷指示の生成時に、次のいずれかに 注文情報 贈り物フラグ 必須
該当する注文を贈り物と判定すること。
(a) 包装またはのしが選択されている
(b) 送り先住所と注文者住所が一致しない
F-3 住所比較 システムは、注文者住所と送り先住所を比較し、 住所2件 一致/不一致 必須
一致または不一致を返すこと。表記ゆれは吸収すること。
F-4 判定不能 システムは、判定に必要な項目が取得できない場合、 注文情報 エラーログ 必須
エラーとしてログに記録すること。
F-5 結果反映 システムは、贈り物でない注文のみ、同梱対象として 贈り物フラグ 同梱指示 必須
出荷指示に付与すること。
受入れ基準: F-2〜F-5 が上記のとおり動作すること。Badから何が変わったか:
- ③事実と解釈の分離が動いた。「贈り物と判断される」という解釈が、(a)(b) の2つの条件に分かれた。機能ごとに ID・入力・出力・優先度がそろい、「どの機能が何を受け取って何を返すか」が追える
- ②読み手適合が少し動いた。浅野さんが見積で使う形(ID・入力・出力)になった。社内の書式があれば、これで出せる。多くの職場で「よくできた機能要件」と言われる形である
- ①結論の位置・⑤想定反論は動いていない
まだ足りないもの(ここが今日の本題):
- 「一致しない」の一致が定義されていない。 F-3 は「表記ゆれは吸収する」と書くが、何を吸収し、何を吸収しないかが書いていない。「ハイツ青葉101」と「ハイツ青葉101号室」は同じか。「ハイツアオバ101」は。建物名を比べるのか。ここが、4月の200件(建物名・部屋だけ違う)と60件の見逃しを分ける一点なのに、浅野さんの判断になっている
- F-4 の「エラー」の後がない。 ログに残して、そのあと出荷はどうなるか。ここが決まっていないので、浅野さんは一番無難な(出荷を止める)を選ぶかもしれない。4月の18件が止まると、朝の梱包ラインに保留の箱が出る
- 受入れ基準が、まだ循環している。 「上記のとおり動作すること」は、何を入れて何が出れば合格かを言っていない
- 今井課長が決めることが、どこにもない。 住所の比べ方の選択(誤投入と見逃しのどちらに倒すか)、判定不能時の動き。Good は、決めるべきことが文書の中に隠れている
- 誰の数字・誰の判断かが書かれていない。 (b) は Day015 で今井課長が選んだ定義だが、その背景(4月の誤投入720箱)が浅野さんには見えない。浅野さんは「なぜこの条件か」が分からないので、迷ったときに安全側を判断できない
3. Functional Requirements
ID Function Requirement Priority
F-2 Gift determination The system shall classify an order as a gift if (a) wrapping Must
or noshi is selected, or (b) the ship-to address does not
match the orderer address.
F-3 Address comparison The system shall compare the two addresses and return match / Must
mismatch. Notational variation shall be absorbed.
F-4 Undeterminable The system shall log an error if required fields cannot be Must
obtained.
F-5 Applying result The system shall attach the insert instruction only to Must
non-gift orders.
Acceptance: F-2 to F-5 operate as specified above.ID・shall・優先度(MoSCoW の Must)は英文要件の標準形。ただし "does not match"、"absorbed"、"log an error"(その後は?)がそれぞれ未定義。英文ではレビューで "Match on what?" と必ず返ってくる。
3. 機能要件(浅野さん向け: 書いてあるとおりに作れば、誰が作っても同じ結果になる粒度)
F-2 贈り物判定
出荷指示を生成するとき、システムは次のどちらかに当てはまる注文を「贈り物」と判定する。
(a) 包装またはのしの選択がある (b) F-3 の結果が「不一致」
贈り物でない注文だけを、同梱物の対象にする。
F-3 住所の一致(Day015 の案B の「送り先が違う」の意味はこれ)
1. 比べる6項目: 郵便番号・都道府県・市区町村・番地・建物名・部屋番号
2. 比べる前にそろえる: 全角→半角/「-」「-」「−」→「-」/「丁目・番地・番」→「-」、末尾の「号」を除く/
空白と「号室」「室」を除く
3. 6項目がすべて同じなら「一致」。1つでも違えば「不一致」
4. 郵便番号・都道府県・市区町村・番地のどれかが空、または郵便番号と都道府県が合わない
→ 「不一致」とし、理由コード G-07 を残す(カードは入れない。出荷は止めない)
受入れ: 下の例12件がその結果になること(付録A: 注文者/送り先/結果/理由)
例: ハイツ青葉101 と ハイツ青葉101号室 → 一致 / 101 と 102 → 不一致(G-02)Goodから何が変わったか(★ここが今日の学習の中心): 読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 何を気にしているか(浅野)「後から当然こうでしょと言われる手戻り」 | 「一致」を比べる項目(6つ)→ そろえ方(4つ)→ 判定(すべて同じ) の3段で定義した。「表記ゆれは吸収する」は、吸収する処理の一覧に置き換えた。書いていない処理(「ハイツアオバ」と「ハイツ青葉」の同一視)はしないことが、一覧にないことで分かる |
| 何を気にしているか(今井課長)「聞いていない動きで出荷が止まること」 | 判定不能のとき、「不一致とし、カードは入れず、出荷は止めない」 と書いた。「エラー」の語を条件の中から消した(EARS の IF…THEN: 起きてほしくないことへの応答を書く) |
| 何を判断するために読むか(浅野)「見積に足りない情報は何か」 | 例12件を添えた。例が見積の前提になる。浅野さんは「この12件が通る範囲で作る」と読め、安全側に高く見積もる理由が減る |
| 何を判断するために読むか(今井課長)「出来上がりを何で確かめるか」 | 受入れを「上記のとおり」から「例12件がその結果になること」 に変えた。今井課長は例の表に○×を付ければよい |
| 何を知らないか(浅野)「どちらの間違いが重いか」 | まだ足りない。 迷ったときの方向(カードを入れない側)は G-07 の1箇所にしか書かれていない。F-3 の厳しさ(建物名・部屋まで比べる)の理由は、浅野さんに伝わらない |
まだ足りないもの:
- F-3 の「建物名・部屋番号まで比べる」は、Better が黙って選んだ。 4月の200件でいえば、建物・部屋を見ないと140件が「一致」になり、贈り物の可能性のある箱にカードが入る。見る場合は60件が書き方の違いで入らない。これは宮田さんの選択であり、今井課長が決めたものではない
- 判定不能の方向(入れない)も、黙って選んだ。 出荷を止める案との差(現場の保留が出る/出ない)を、今井課長は知らない
- 決まらなかったらどうなるかがない。 説明会で決まらなければ、見積依頼(6/16)が遅れ、稼働(8/28)が動く
3. Functional Requirements (written so that any developer produces the same behavior)
F-2 Gift determination
When a shipping instruction is generated, the system shall classify the order as a
gift if (a) wrapping or noshi is selected, or (b) F-3 returns "mismatch".
Only non-gift orders shall be eligible for the insert.
F-3 Address match
1. Compare six fields: postal code, prefecture, city, street number, building, room.
2. Before comparing, normalize: full-width to half-width; "-", "-", "−" to "-";
"chome / banchi / ban" to "-" and drop a trailing "go"; remove spaces and "号室" / "室".
3. Return "match" only if all six fields are identical; otherwise "mismatch".
4. If any of postal code, prefecture, city or street number is empty, or the postal
code does not agree with the prefecture, the system shall return "mismatch" with
reason code G-07. The insert shall not be added; shipment shall not be held.
Acceptance: the 12 examples in Appendix A produce the stated results.
e.g. "Heights Aoba 101" vs "Heights Aoba 101-goshitsu" = match / 101 vs 102 = mismatch (G-02)条件が When ... the system shall ...(EARS の event-driven)、起きてほしくないことが If ..., the system shall ... の形になった。"Only if all six fields are identical" の only if が一致の定義を閉じている。
6/14(水)10:00 の説明会までに決めていただきたいこと(2点)と、お願い(1点)
① 今井課長: 「同じ住所」を、建物名・部屋番号まで比べるか(案: Q)
案 比べる範囲 4月に当てはめると 代償
P 郵便番号〜番地まで 別室宛て140件にカードが入る(贈り物の可能性) なし
Q 建物名・部屋まで(書き方をそろえて) 誤投入0。書き方の違い60件は入らない(見逃し) 60件/月。工数+1.5人日
② 今井課長: 住所が空・読めない注文(4月18件)は、カードを入れず、出荷は止めない(案)
止めて人が見る案は、1件3分×月18件=54分の保留が梱包ラインに出る〔仮定〕
③ 浅野さん: 付録の例12件を、見積の前提・受入れテストにしてください。
ずれる例があれば 6/16(金)の見積依頼前日までに
機能(業務の結果は Day015 の R-1〜R-4。ここはシステムが何をするか)
F-2 包装・のしの選択があるか、F-3 が「不一致」なら、その注文を贈り物とし、同梱の対象にしない
F-3 6項目(郵便番号〜部屋番号)を、付録 N-1〜N-4 でそろえて比べ、すべて同じなら一致
郵便番号〜番地のどれかが空、または郵便番号と都道府県が合わない → 不一致(G-07)
F-5 贈り物かどうかと理由コード(G-01/02/03/07)を出荷指示に残す(毎シフト数えるため)
受入れ: 付録の例12件。かつ4月分27,720件の再判定で、包装・のしありと720件がすべて対象外
決まらなかったら: 6/15(木)に ①Q ②入れない で見積を依頼する。P と Q の工数差は +1.5 人日〔仮定〕
扱わないこと: 法人の複数配送先(別ライン)/注文後の送り先変更の再判定(月数件。別に決める)Betterから何が変わったか:
- ①結論の位置 → 冒頭が「決めていただきたいこと」になった。 今井課長は前日に最初の10行だけ読む。F-2〜F-5 は、浅野さんが読む2ページ目以降の仕事に下げた
- ②読み手適合 → 一致の比べ方を、宮田さんが黙って選ぶ(Better)のをやめ、物流が選ぶ表にした。 列を「4月に当てはめるとどうなったか」にしたのは、今井課長が起きたことで比べられるようにするため。「建物名まで比べるか」は技術の問いに見えるが、実際は「別室宛て140件にカードが入ってよいか」という業務の問いである
- ③事実と解釈の分離 → 案の代償を同じ行に書いた。 Q は誤投入を0にするが、書き方の違い60件が見逃しになる。「見逃し」は今回の判断で、今井課長が引き受けることを、そのまま見える形にした
- ④次の行動 → 誰が・いつまでに・何をを3点で確定し、決まらなかったときの既定を日付で決めた。 6/15 に Q と「入れない」で見積依頼。決めないと全体が止まるが、止まらない道を先に作った
- ⑤想定反論 → 「止めて人が見ればよい」「P で十分では」に、②の1行と①の表で先回りした。 止める案は54分/月の保留、P は140件の誤投入。どちらも数字で答えが出る形にした
- 削ったもの: 正規化の4つの規則と、理由コードの一覧、例の12件は付録に下げた(見積の根拠として浅野さんは付録を読む)。Better の「比べる6項目」の説明は F-3 の1行に圧縮した
なぜ黙って選ばず、選ばせたのか — 宮田さんが迷った点: 宮田さんは最初、Better のまま(Q を黙って採用)で出すつもりだった。「案を並べると決められない担当者に見える」と思ったからである。しかし、5/30 に今井課長が引き受けたのは案B(送り先が違えば贈り物)の定義までで、その「違う」の意味(書き方の違い60件を見逃しにすること)は引き受けていない。黙ってQで通せば、見逃しが増えたことを、稼働後に現場が最初に知る。 逆に P を黙って選べば、140件の誤投入が戻る。宮田さんが選べないのは、どちらにも物流の梱包への影響があるからである。
反証条件(この文書の形が変わる場合):
- 60件が「書き方の違い」でなく、実は別の部屋(贈り物)だったら、Q の代償は消え、Q が明確に勝つ。 逆に、書き方の違いが60件でなく数百件なら、Q の見逃しが大きすぎるので、書き方をそろえる処理(住所の正規化ライブラリ)を増やす案を並べ直す。6/6の抽出は4月1か月で、季節で住所の書き方は変わらないと仮定している
- 浅野さんが例12件のどれかを「作れない」と言ったら、機能要件の側を直す。 例は、仕様の飾りではなく正である
今回はBestまで作るべきか: Best必要。 住所の「同じ」は誤投入と見逃しのどちらに倒すかという業務の選択で、作る人が選ぶと見積が安い側に寄る。しかも外部の開発者は、後から「当然こう」と言われるのを避けて安全側に高く見積もる。逆に、画面の文言を変えるだけの機能要件(判断を含まない)なら Better で十分。選択肢の表と決まらなかったときの動きは、作る人が選べないことを選ぶときにだけ効く。
Decisions requested before the June 14 (Wed) 10:00 walkthrough (2), and one request
1. Mr. Imai: Compare "same address" down to building and room? (we recommend Q)
Option Compared down to If applied to April Cost
P postal code to street no. 140 other-room orders would get the card none
Q building + room (normalized) 0 wrong inserts; 60 notation-only cases skipped 60/month; +1.5 person-days
2. Mr. Imai: If address fields are empty/unreadable (18 in April): no insert, do not hold
shipment (holding costs ~54 min/month on the line [assumption])
3. Mr. Asano: please treat the 12 examples in Appendix A as the basis of your quote and as
the acceptance test. Flag any you cannot meet by June 15.
Functions (business outcomes are R-1 to R-4 in Day015; this is what the system does)
F-2 If wrapping/noshi is selected or F-3 returns "mismatch", treat as gift: no insert
F-3 Normalize per N-1 to N-4, compare six fields; all identical = match.
Postal code..street number empty, or postal/prefecture disagree = mismatch (G-07)
F-5 Record gift flag and reason code (G-01/02/03/07) on the shipping instruction
Acceptance: Appendix A (12 examples); re-run of 27,720 April orders puts all wrapped/noshi
orders and the 720 into "no insert"
If undecided: on June 15 (Thu) we request a quote with 1 = Q and 2 = no insert.
Out of scope: corporate multi-address (separate line); ship-to changes after order."Decisions requested" から始め、選択肢の表に "we recommend Q" と添えるのが、英文の意思決定文書の BLUF の型。"If undecided" と "Out of scope" を独立の行にするのは、外部ベンダーとの文書でスコープを契約の問題として扱う習慣による。
日英差分ノート
1. 「〜すること」と "The system shall ..." — 日本語の文は主語を隠せる
日本語の要件は「〜すること」「〜とする」と、主語(誰が)を書かなくても文が成り立つ。Bad の「適切に判定すること」は、システムがするのか、運用でするのかさえ曖昧になる。英語に直すと The system shall が必要になり、"shall"(義務)/ "should"(推奨)/ "may"(任意)のどれかを選ぶ(RFC 2119 の使い分け)。日本語で書いた要件を英語に直すと、主語と強さが抜けた文が見つかる。 Better 以降は日本語でも「システムは〜する」と主語を立てた。
2. 「表記ゆれ」と "notational variation" — 同じ現象に一語で足りない
日本語の「表記ゆれ」は全角半角・長音・送り仮名・住所の書き方までを一語で言う。英語に直すと 何の variation か(width, hyphenation, abbreviation)を分けて書かざるをえなくなる。それが 正規化の規則を1つずつ書くことにつながる。一語で言える言葉ほど、仕様では分解して書く。
3. 「ご確認ください」と "Please flag any you cannot meet"
日本語の「ご確認ください」は礼儀の定型で、何をどう確認するかが空になりがち。英語の依頼は 何を(examples)・誰が・いつまでに(by June 15)・結果として何を返すか(flag any you cannot meet) がないと、返事が来ない。Best の ③ はその型。
4. 「見逃し」と "false negative" — どちらを許すかは用語から決める
日本語の「見逃し/誤投入」は、現場の被害の言葉である。英語の要件では false positive / false negative(どちらを「陽性」と呼ぶかで意味が反転する)と書くと誤読が起きるので、"wrong insert" / "missed insert" と被害の言葉を使う。Best はそうした。
頻出表現
| 日本語 | English | トーンの強さ |
|---|---|---|
| 〜すること/〜とする | The system shall ... | 強い・義務。仕様の標準 |
| 〜することが望ましい | The system should ... | 中・推奨。受入れ基準に入れない |
| 〜してもよい | The system may ... | 弱い・任意 |
| 〜のとき、〜する | When <trigger>, the system shall ... | 中立・EARS の event-driven |
| もし〜なら(起きてほしくないこと) | If <condition>, the system shall ... | 中立・EARS の unwanted behaviour |
| 本件の対象外 | Out of scope | 中立・契約の境界 |
| 決まらなければ〜で進める | If undecided, we will proceed with ... | 中立・既定動作 |
| 受入れ基準 | Acceptance criteria | 中立・合否の定義 |
差分5軸まとめ
| 軸 | Bad | Good | Better | Best |
|---|---|---|---|---|
| ① 結論の位置 | ない(「適切に判定」が冒頭にあるが何も言っていない) | 表の中。どの機能が先に決めるべきかが分からない | F-2 が先頭。一致の定義が機能の中にある | 「決めていただきたいこと」が冒頭。機能は後ろ |
| ② 読み手適合 | 想定していない | ID・入力・出力(見積に使える形) | 浅野さん向けの粒度(誰が作っても同じ)。今井課長向けは例の表 | 浅野さんは付録の例を前提に、今井課長は選択肢の表を。両方が同じ12例を見る |
| ③ 事実と解釈の分離 | 「配慮し」「適切に」(解釈が条件に混じる) | 条件(a)(b)に分離。一致は未定義 | 一致を項目・そろえ方・判定で定義 | 案ごとに4月の件数と代償(140件/60件)を併記。〔仮定〕は印をつける |
| ④ 次の行動 | 「設計時に協議」 | 優先度のみ | 受入れ=例12件 | 誰が・いつまでに(6/14説明会・6/15既定・6/16見積依頼)。決まらなければ既定 |
| ⑤ 想定反論 | 無視 | 触れない(エラーの後・一致の定義) | 判定不能時の動きを書く。建物名まで比べる理由は黙っている | 「P で十分」「止めて人が見る」に数字で先回り。反証条件を書く |
Best版・全文
日本語版 全文を見る
倉庫システム改修 機能要件定義書(第1版)— 同梱物の対象判定
2028年6月9日 ノヴァストア EC事業本部 販促システム部 MOps 宮田
宛先: ミナトソフト 浅野様/物流本部 柏物流センター 今井課長
写し: 情報システム部 長谷川(窓口)
━━ 1ページ目 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6/14(水)10:00 の説明会までに決めていただきたいこと(2点)と、お願い(1点)
① 今井課長: 「同じ住所」を、建物名・部屋番号まで比べるか(案: Q)
案 比べる範囲 4月に当てはめると 代償
P 郵便番号〜番地まで 別の部屋宛て140件にカードが入る なし
(同じマンションの別室。贈り物の可能性)
Q 建物名・部屋番号まで 誤投入0 書き方の違い60件は入らない
(書き方をそろえたうえで) 書き方の違い60件が「違う」になる (自分宛てなのに入らない=見逃し)
見積の工数 +1.5人日〔仮定〕
※4月の初回購入27,720件のうち、送り先が注文者と違う720件の内訳
(520件は番地から別、200件が建物・部屋のみ違う)。長谷川さん 6/6 抽出
推奨はQ。誤投入(受取人に「初めての購入ありがとう」)の方が、
見逃し(友だち追加の機会を逃す)より重いため。
② 今井課長: 住所の項目が空・読めない注文(4月18件)は、
カードを入れず、出荷は止めない(案)
止めて人が見る案は、1件3分×月18件=54分の保留が梱包ラインに出る〔仮定〕
この動きは稼働後も変わらない(変えるなら今井課長の承認)
③ 浅野さん: 付録Aの例12件を、見積の前提・受入れテストとしてお読みください。
「この例は作れない/解釈が違う」があれば、6/15(木)17:00 までにご連絡ください
(6/16 の見積依頼に反映します)
決まらなかったら: 6/15(木)に ①Q ②入れない で見積を依頼します。
業務の背景: 4月の同梱で受取人への誤投入 約720箱。Day015 の業務要件 R-1〜R-4 を実現する機能です。
━━ 2ページ目: 機能要件 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
F-1 同梱物の登録と条件(業務要件 R-3)
同梱物ID・開始日・終了日・条件(初回購入のみ/贈り物を除く/対象商品)を、管理画面で登録できる
登録から稼働までは、承認(今井課長)を経て、翌営業日の出荷指示から適用される
※管理画面の項目と承認の流れは、別紙の画面仕様で定める(この文書の範囲外)
F-2 贈り物判定(R-1)
出荷指示を生成するとき、次のどちらかに当てはまる注文を「贈り物」とする。
(a) 包装またはのしの選択がある → 理由コード G-03
(b) F-3 の結果が「不一致」→ G-01(番地までが違う)/ G-02(建物名・部屋が違う)/ G-07(項目欠け)
「贈り物」の注文は、同梱物の対象にしない。贈り物でない注文は、F-1 の条件に合えば対象にする
F-3 住所の一致(F-2(b) の「違う」の意味)
入力: 注文者住所と送り先住所(各6項目: 郵便番号・都道府県・市区町村・番地・建物名・部屋番号)
処理: 付録 N-1〜N-4 でそろえてから、6項目を1つずつ比べる
出力: 6項目がすべて同じなら「一致」。1つでも違えば「不一致」
(建物名・部屋番号は、両方が空なら同じとみなす。片方だけ空は「違う」)
郵便番号・都道府県・市区町村・番地のどれかが空、または郵便番号と都道府県が対応しないとき:
「不一致」とし、理由コード G-07 を残す。同梱物は付けず、出荷は止めない
F-4(欠番。F-3 の判定不能を F-3 に統合したため、番号は変えない)
F-5 結果の記録(R-4)
出荷指示ごとに、贈り物かどうかと理由コードを残す。残した値は、
毎シフト終了時に「対象件数」「使用枚数」の差を出すために使う(レポートの画面仕様は別紙)
受入れ
・付録Aの例12件が、記載の結果になること
・4月分27,720件を再判定し、包装・のしありの注文と、長谷川さん抽出の720件が
すべて「対象外」になること
・F-2〜F-5 は、処理時間の要件を持たない(非機能要件は別書)
━━ 付録A: 住所の例(受入れテスト)━━━━━━━━━━━━━━━━━━━━━━━
# 注文者 送り先 包装/のし 結果 理由
1 柏市柏1-2-3 ハイツ青葉101 同じ文字 なし 入れる -
2 柏市柏1-2-3 ハイツ青葉101 柏市柏1-2-3 ハイツ青葉101 なし 入れる -
3 柏市柏1-2-3 ハイツ青葉101 柏市柏1丁目2番3号 ハイツ青葉101 なし 入れる -
4 柏市柏1-2-3 ハイツ青葉101 柏市柏1-2-3 ハイツ青葉101号室 なし 入れる -
5 柏市柏1-2-3 ハイツ青葉101 柏市柏1-2-3 ハイツ青葉102 なし 入れない G-02
6 柏市柏1-2-3 ハイツ青葉101 柏市柏1-2-4 ハイツ青葉101 なし 入れない G-01
7 柏市柏1-2-3 ハイツ青葉101 柏市柏1-2-3 ハイツアオバ101 なし 入れない G-02(書き方の違い。見逃しを受け入れる)
8 柏市柏1-2-3(戸建て) 同じ(建物・部屋とも空) なし 入れる -
9 柏市柏1-2-3 ハイツ青葉101 柏市柏1-2-3(建物・部屋が空) なし 入れない G-02
10 柏市柏1-2-3 ハイツ青葉101 同じ文字 あり 入れない G-03
11 柏市柏1-2-3 ハイツ青葉101 郵便番号が空 なし 入れない G-07
12 柏市柏1-2-3 ハイツ青葉101 郵便番号277-0005と都道府県「大阪府」 なし 入れない G-07
※「入れる」は、F-1 の条件(初回購入など)に合う場合に限る
付録N: そろえ方
N-1 全角の英数字・記号は半角にする
N-2 「-」「-」「−」「ー」は、すべて「-」にする
N-3 「丁目」「番地」「番」は「-」にし、住所番号の末尾の「号」は除く(1丁目2番3号 → 1-2-3)
N-4 空白(全角・半角)と、部屋番号の後ろの「号室」「室」を除く
上の4つ以外はそろえない。例: 「ハイツアオバ」と「ハイツ青葉」は別、「1F-101」と「101」は別
(上の4つで足りない書き方は、見逃しとして受け入れる。Q の代償)
理由コード: G-01 番地までが違う/G-02 建物名・部屋が違う/G-03 包装・のし/G-07 項目欠け
扱わないこと
・法人の複数配送先(別ライン。定期便・法人は Day015 でも対象外)
・注文後の送り先変更の再判定(月数件。判定は出荷指示の生成時の1回のみ。別に決める)
・住所のカナ変換・漢字の異体字の同一視(需要があれば、4月の件数を見て追加を決める)
English 全文を見る
Warehouse system change - Functional Requirements v1: eligibility for inserts
June 9, 2028 MOps (Miyata), Marketing Systems, Nova Store
To: Mr. Asano, Minato Soft / Mr. Imai, Kashiwa Logistics Center Cc: Mr. Hasegawa (IS)
== Page 1 ==
Decisions requested before the June 14 (Wed) 10:00 walkthrough (2), and one request
1. Mr. Imai: Compare "same address" down to building and room? (we recommend Q)
Option Compared down to If applied to April Cost
P Postal code to street number 140 other-room orders would get the card None
Q + building and room (normalized) 0 wrong inserts; 60 notation-only 60 missed/month;
cases do not get the card +1.5 person-days [assumption]
Basis: the 720 April first-purchase orders whose ship-to differs (520 differ from the
street number; 200 differ only in building/room). Hasegawa, June 6.
We recommend Q: a wrong insert (a recipient reading "Thank you for your first
purchase") is worse than a missed insert (a lost chance to add a friend).
2. Mr. Imai: If any address field is empty or unreadable (18 in April): no insert, and
shipment is not held. Holding would cost ~54 min/month on the line (3 min x 18)
[assumption]. Changes to this rule need your approval.
3. Mr. Asano: please read the 12 examples in Appendix A as the basis of your quote and as
the acceptance test. If you cannot meet one, or read it differently, tell us by
June 15 (Thu) 5 p.m. so that it is reflected in the June 16 quote request.
If undecided: on June 15 we request the quote with 1 = Q and 2 = no insert.
Background: ~720 recipient boxes in April got the card. This implements R-1 to R-4 of Day 015.
== Page 2: functional requirements ==
F-1 Insert registration (R-3). An administrator can register insert ID, start/end date and
conditions. Changes apply to the next business day's shipping instructions after
Mr. Imai approves. Screens and approval flow: separate spec (out of scope here).
F-2 Gift determination (R-1). When a shipping instruction is generated, the system shall
classify the order as a gift if (a) wrapping or noshi is selected (reason G-03), or
(b) F-3 returns "mismatch" (G-01, G-02 or G-07). Gift orders shall not receive an insert.
F-3 Address match. Input: orderer and ship-to addresses, six fields each. After applying
N-1 to N-4, the system shall compare the six fields one by one and return "match" only if
all are identical. Building and room: both empty = identical; one empty = different.
If postal code, prefecture, city or street number is empty, or the postal code does not
agree with the prefecture, the system shall return "mismatch" with G-07, shall not add
an insert, and shall not hold the shipment.
F-4 (not used; merged into F-3. Numbering unchanged.)
F-5 Recording (R-4). The system shall record the gift flag and the reason code on every
shipping instruction, to be used for the shift-end difference between target count and
inserts used.
Acceptance: Appendix A examples; a re-run of the 27,720 April orders in which all
wrapped/noshi orders and the 720 are classified "no insert". No performance requirement here.
== Appendix A: examples (acceptance tests) ==
# Orderer address Ship-to Wrap/noshi Result Reason
1 Kashiwa 1-2-3 Heights Aoba 101 identical string no insert -
2 same full-width digits and dashes no insert -
3 same "1-chome 2-ban 3-go" Heights Aoba 101 no insert -
4 same Heights Aoba 101-goshitsu no insert -
5 same Heights Aoba 102 no no insert G-02
6 same street number 1-2-4 no no insert G-01
7 same "Heights Aoba" spelled in katakana no no insert G-02 (notation only; accepted as missed)
8 Kashiwa 1-2-3 (house, no building) identical no insert -
9 Kashiwa 1-2-3 Heights Aoba 101 Kashiwa 1-2-3, building/room empty no no insert G-02
10 Kashiwa 1-2-3 Heights Aoba 101 identical yes no insert G-03
11 Kashiwa 1-2-3 Heights Aoba 101 postal code empty no no insert G-07
12 Kashiwa 1-2-3 Heights Aoba 101 postal 277-0005 with prefecture Osaka no no insert G-07
"insert" applies only if the F-1 conditions (e.g., first purchase) are also met.
Appendix N: N-1 full-width to half-width; N-2 "-", "-", "−", "ー" to "-"; N-3 "chome / banchi / ban"
to "-" and drop a trailing "go"; N-4 remove spaces and trailing "goshitsu" / "shitsu". Nothing else
is normalized (e.g., katakana vs. kanji spellings of a building differ; "1F-101" vs "101" differ).
Reason codes: G-01 street number differs; G-02 building/room differs; G-03 wrap/noshi; G-07 field missing.
Out of scope: corporate multi-address; re-evaluation after ship-to change; kana/variant-kanji equivalence.
完成の定義チェックリスト
機能要件定義書を出す前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
今日の演習
Bad の「(3) 住所の比較は、表記ゆれ等に配慮し、適切に行うこと。」と「(5) 判定できない場合は、必要に応じてエラーとして扱うこと。」の2行だけを、各2〜3行に書き直す。
手順:
- 曖昧語に線を引く: (3) は「表記ゆれ」「等」「配慮」「適切」、(5) は「できない場合」「必要に応じて」「エラー」
- (3) は3つに分ける: 比べる項目/比べる前の処理/同じと言える条件。この3つが書ければ、2人の開発者は同じものを作る
- (5) は「何が起きたら → 何をする」の1文にする: 起きたこと(どの項目が空か)と、止める/流す/記録するのどれか
(3) を「3項目の定義」で、(5) を「1つの IF…THEN」で書けたら、今日の目的は達成。書けたら Best の F-3 と見比べる。余裕があれば、書いた(3)に当てはまる「迷う例」を1つ足してみる(例: 「ハイツ青葉」と「ハイツあおば」)。
同じ機能要件を、「今井課長」でなく、現場で運用を受け持つ「シフトリーダー」向けの1枚(運用説明)に書き直す。 読むのは稼働前の研修と、稼働後に「カードが入らなかった」と作業者から聞かれたとき。
設定(自分の題材がない場合): 8/28 の稼働後、シフトリーダーに「この箱にカードが入っていない(入っている)のは正しいか」を尋ねる作業者が、1日数人来る。
守る条件:
- 技術の言葉(正規化・理由コード・F-3)を使わない。代わりに、「カードが入らないのは、こういう注文」を、例の表の言葉(「同じマンションの別の部屋宛て」「包装を選んだ」) で書く
- 「入らないはずなのに入っている」(誤投入)と「入るはずなのに入っていない」(見逃し)で、現場が何をするかを分ける。誤投入は止める・連絡する、見逃しはそのまま出す(Q の代償)と明記する
- 「書き方の違いで入らない注文が月60件ほどある」ことを、現場の責任でないこととして書く(Day014 の「判断を工程から消す」の考え方)
- 例の表から、現場が見分けられる3例だけを選ぶ(12例すべては要らない)
取り組む前のヒント
考える順序
- 同じ内容でも、作る人(浅野さん)、受入れる人(今井課長)、運用する人(シフトリーダー)で、要る粒度が違う。作る人には「同じ入力→同じ出力」、受入れる人には「選ぶこと」、運用する人には「この箱は正しいか」。まず、Best のどの行がシフトリーダーに要らないかに線を引く
- 現場の人に「システムのルール」を説明しない。説明するのは、箱を見て「正しい/連絡」を決める基準だけ。理由コードは、見分けの材料にならなければ出さない
- 見逃し(60件/月)は、「間違いでない」と先に言わないと、現場が毎回連絡してくる。連絡してよい基準と、しなくてよい基準を1行ずつ
陥りやすい罠
- 「システムの判定に従うこと」と書く。従えない(従わせてはいけない)ときの基準を書く
- 例を12個全部載せる。現場が持てる数は3〜4個
チェックすべき観点 書き上げたら「初めて夜勤のリーダーになった人が、作業者から『この箱カードが入ってない』と聞かれて、1分以内に答えられるか」を確かめる。
実務での使いどころ
機能要件定義書は、業務要件(何を実現するか)と、設計・実装(どう作るか)のあいだにある文書である。受託開発・保守では見積の根拠になり、ここの曖昧さはそのまま見積の幅と、後の追加請求や手戻りになる。2026年現在、LLM やコード生成は「書いてある要件を実装する」ことをかなり速くした。だからこそ、書いていない判断(一致の定義・欠損時の動き)を、生成する側が一番安い解釈で埋める。自動で出ないのは、今日の Good→Best の部分 —— 作る人が選べない選択を見つけ、業務の人が選べる表にし、例を受入れテストにすることである。
隣接する文書との関係:
- 前: 業務要件定義書(Day015: R-1〜R-4)
- 後: 非機能要件定義書(カテゴリ15の3本目: 判定を出荷指示の生成時に何秒以内か)、基本設計書(4本目: 管理画面と帳票)、テスト仕様書(カテゴリ16の1本目: 付録Aの例12件がそのまま入口)、ADR(6本目: 住所の正規化を自作するか既製の部品を使うか)
- 横: RFQ(カテゴリ4の3本目: ベンダー見積の依頼書。6/16 の依頼に付ける)、SOW(調達#4: 付録Aを別紙にする)
この回の設計メモ(迷った他案・扱わなかった範囲・出所)
題材の選び方で迷ったこと
- Day015(業務要件)の続きにし、R-1〜R-4 のうち R-1 の「贈り物」の判定を機能に下ろした。他案の「R-3(条件の追加だけで済む)の管理画面の機能要件」は、判断の論点が少なく、曖昧語の置き換えの学びが薄いため見送った(演習の素材には使える)
- 書き手は MOps の宮田さんのまま。販促システム部は自分でも仕組みを持つ部署なので、倉庫システムの改修の機能要件を書くのは不自然でない。新登場は外部ベンダーの浅野さんにした。カタログの主な読み手(開発・発注者)と Lv2 が一致し、ルール5は要らない
- 読み手を「長谷川さん(社内の開発リード)」にする案もあったが、長谷川さんは Day015 の議論にいたので「距離」が足りない。議論の場にいなかった外部の開発者にした
Best の形で迷ったこと
- Better のまま Q を黙って採用する案(案を並べると頼りなく見える)と、選択肢の表にする案で迷い、後者にした。住所の「同じ」は技術の問いでなく、誤投入140件と見逃し60件のどちらを許すかという業務の問いだから。書き手が黙って選ぶと、5/30 に今井課長が引き受けた範囲(案B)を超える
- ②(判定不能の方向)は表にせず1行の案にした。選択肢が実質2つで、止める案は54分/月と数字ですぐ答えが出る。全部を表にすると、今井課長が前日に見る10行を超える
- 例を12件にした。10件では「片方だけ空」「両方空」の境界を含められず、15件以上だと今井課長が○×を付けきれない、という粗い見積。最適な件数を測ってはいない
- F-4(欠番)は、F-3 に統合しても番号を変えないことを示すため残した。Good の F-4 はこの形に書き換えられる
数字の出所
- 〔実測〕とした値(4月の初回購入27,720件、720件の内訳520/200(140/60)、空欄・読めない18件、誤投入約720箱、対象925箱/日)は、すべてシナリオ内の設定で、現実のデータではない。Day015 の数字(27,720・約720)と整合させ、内訳(520/200、140/60)はこの回で新設した
- 〔仮定〕: 判定不能時の保留 1件3分、Q の工数 +1.5人日(長谷川さんの概算という設定)、書き方の違い60件が季節で変わらないこと
- 〔導出〕: 54分 = 3分×18件。520+200 = 720、140+60 = 200
出典の深さ
- EARS(Mavin ら、RE'09、Rolls-Royce): Wikipedia ほか検索結果の要約で、パターン(Ubiquitous / When / While / If-then / Where)を確認(2026-10-17。論文本文は未読)。https://en.wikipedia.org/wiki/Easy_Approach_to_Requirements_Syntax
- ISO/IEC/IEEE 29148 の要求1件の品質特性(曖昧でない・単一・検証できる): 検索結果の要約で確認(2026-10-17。規格本文は有償で未読。版により特性名が異なる要約があり、「検証できる」は testable/verifiable の両方の表記を見た)。INCOSE『Guide for Writing Requirements』の曖昧語の一覧は確認できなかったので、置き換え表は一般的な実務慣行に基づく私の整理であり、同ガイドの引用ではない
- 『Specification by Example』(Adzic 2011)と、RFC 2119 の shall/should/may の使い分け、IPA の機能要件・要件定義関連の資料は、記憶による。出典ページは確認していない
- 分量(実測): JA Bad11・Good13・Better14・Best17行、字数(空白除く)Bad269・Good326・Better478・Best697字(EN 13・12・15・18行)。単調増加で、Best が最長(逆転ではない)。Best で初めて「業務側が選ぶ表」と「決まらなかったときの既定」が揃うため(Day007・022 と同じ型)。次の逆転候補: Runbook(itops#2)
扱わなかった範囲
- 非機能要件(処理時間・可用性)。F-2〜F-5 は「処理時間の要件を持たない」と明記し、次の回(カテゴリ15の3本目)に送った
- 住所の正規化の技術(既製のライブラリ、住所辞書、カナ変換)。今日は「規則を書く」までで、自作か既製かは ADR(6本目)の題材
- 管理画面(F-1)の項目・承認の流れ。画面仕様の別紙とし、本文では扱わなかった
- 例12件は、書き方の違いの全パターンを網羅していない。今日扱った住所の書き方のばらつきは、実際の住所の表記のうち一部で、残りは不一致(見逃し)として受け入れる設計にした。網羅度は測っていない
AI臭さ検査(努力の痕跡4軸): ①トレードオフ=P/Q案と代償、黙って選んだ Better の問題 ②ドメインへの接地=EARS・29148(要約まで確認、未読は明記)③測った証拠=〔実測〕〔仮定〕〔導出〕ラベル(実測の出所はシナリオ設定と明記)④止め方=扱わなかった範囲。「同じ指示を AI に出せば数時間で出るか」→ 型と曖昧語表は出る。出ないのは、作る人が選べない選択(一致の厳しさ)を見つけて、業務側の選択肢の表にする判断と、その代償を4月の件数に接地させる部分。世界の実物との比較: 要求品質の中核概念(曖昧でない・単一・検証できる・完全・一貫)のうち、今日扱ったのは前3つと、EARS のうち event-driven と unwanted behaviour の2パターン。完全性・一貫性(要求の集合の質)と state-driven・optional は扱っていない。
何が起きているか:
これは怠慢ではなく、「業務要件は書いた。細かいことは作る人の専門だから任せる」という遠慮から生まれる形である。しかし、住所の「同じ」は専門技術ではなく業務の選択(誤投入と見逃しのどちらを許すか)である。作る人に任せると、作る人は見積が安く、手戻りが少ない側(甘く比べる)を選ぶ。