Day 015 — IT-要求・設計:業務要件定義書

物流センターの同梱物の対象判定を情報システム部に頼むための業務要件定義書の「3. 業務要件」を、Bad → Good → Better → Best で書き分けて比べる
カテゴリ15 IT-要求・設計 読み手 Lv2 — 距離のある読み手(カタログ1周目) 2026-10-02 (Fri) 読み手:物流本部の今井課長・情報システム部の長谷川さん 15分版 / 60分版 今日の核心:定義を黙って選ばず、決める人が選べる形で渡す
今日の最短ルート(15分しかない日):① 読み手プロファイル(30秒) → ② 4段階の Good と Best を見比べる(5分。Goodは型が完璧だが要件が現行システムの書き写しで、4月の誤投入約720箱をそのまま再生産する。Bestは「贈り物」の定義を、4月ではどうなったかの表で物流に選んでもらう) → ③ 15分版の演習(10分)。着手しないより、3つだけやる方が良い。

今日の文書 — 業務要件定義書

業務要件定義書 — システムを作る・変える前に、「業務として何を満たす必要があるか」を、業務の言葉で書いて、業務の責任者と開発の双方が合意するための文書。ここで決めたことが、次の機能要件定義書・非機能要件定義書・設計書の入力になる。

この種の文書は、要求を3つの層に分けて考えるのが世界の標準的なやり方である。ビジネス分析の知識体系 BABOK は、要求を ビジネス要求(なぜ必要か)・ステークホルダー要求(それぞれの立場が何を求めるか)・ソリューション要求(システムが何をするか)・移行要求 に分けている。今日の「業務要件」は、前の2つ(なぜ・誰が何を求めるか)を、業務の言葉で書く層にあたる。要求の書き方の国際規格 ISO/IEC/IEEE 29148 も、個々の要求が持つべき性質として 「必要」「適切(実装の細部を含まない)」「曖昧でない」「検証できる」 などを挙げている。

この文書の勝負どころ: 業務の言葉で書かれ、実装に寄りすぎていないか。
今日はこれを、実務の言葉に言い換える。業務の言葉で書かれているとは、業務の責任者が自分の言葉で「これは違う」と言える(赤ペンを入れられる)こと。実装に寄りすぎていないとは、「どう作るか」を決めずに「何が満たされれば良いか」と「業務が決めるべきこと」だけが書かれていることである。この線引きは簡単ではない。たとえば「納品書に印を刷る」は実装(解決策)だが、「作業者が対象かどうかを判断しなくてよい」は要件である。逆に、「ギフトは適切に除外する」のように何も決めていない文は、業務の言葉で書いてあるようで、一番大事な「ギフトとは何か」を、開発者の推測に任せている。

層例(今日の題材)誰が決めるか
要件(業務の結果)贈り物として送られる箱には、販促のカードを入れない業務の責任者(物流・CS・販促)
業務ルール(定義・条件)「贈り物」とは、送り先が注文者と違う、または包装・のしを選んだ注文業務の責任者。ここが最も事故の元
解決策(実装)納品書の右上に ★L の印を刷る/出荷指示に列を足す設計者(情報システム部)。要件には書かない

シナリオ

あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田(Day004〜Day014の続き)。

2028年5月22日(月)。4月のLINE友だち追加カードの同梱(Day014)が終わった。カードは1日約950箱に入った。ところが ギフトを受け取った方から「初めての購入ありがとうございます、と書いたカードが入っていた。私は買っていない」という問い合わせが、4/3〜4/30で9件 届いた〔実測〕。Day014の手順書は「問い合わせが1件でも来たら、作業者ではなく ★L の判定を点検する」と決めていたので、5/10(水)に情報システム部の 長谷川さん(倉庫システムグループの開発リード。新登場) が4月の出荷データを抽出した。

分かったこと〔実測: 長谷川さんの抽出〕:

  • 4月28日間の出荷 252,000箱のうち、初めての購入の注文は11%=27,720件
  • そのうち 「送り先が注文者と違うが、包装・のしを選んでいない」注文が2.6%=約720件。この注文は「ギフトフラグ」(包装・のしを選んだ注文にだけ立つ)がOFFなので、★L が刷られ、カードが入った
  • つまり 誤って入った箱は約720。問い合わせが来たのは9件(1.2%)。連絡してくれた方の陰に、黙って受け取った方が約710人いる〔導出〕

同じ4月、MOps は今後の同梱物の計画(誕生月クーポン、レビュー依頼カード、セール案内など)が 2028年度に9本 あると確認した〔仮定: MOps計画〕。今のやり方は、同梱物ごとに情報システム部へ依頼して納品書の印字条件を変えてもらう(1回3人日・依頼から稼働まで約2週間〔仮定〕)。9本で27人日〔導出〕。そこで MOps は、同梱物の対象判定を「業務のルール」として決め直し、同梱物が増えても条件の追加だけで済む仕組みを情報システム部に頼むことにした。その前提として、業務要件定義書 を書く。

  • 提出: 5/26(金)17:00 までに今井課長と長谷川さんへ。要件確認会は 5/30(火)15:00(45分)。設計着手は 6/5(月)、次の同梱物(夏のレビュー依頼カード)は 7/3(月)開始
  • 読み手: 今井課長(承認者)。長谷川さん(要件を読んで工数を出す人。業務の言葉を実装に翻訳する側)。CS 松本さん(Day009)は「贈り物」の定義の相談先
  • Lv2(距離のある読み手)の回。 カタログの主な読み手(業務部門・開発)が、Lv2 の「他部署」にそのまま一致するので、間接読み手の設定(ルール5)は要らない。今井課長はシステムの言葉を読まず、長谷川さんは物流の現場を見たことがない。両方に同じ1つの文書で届くかが試される
  • 面倒な事情: 「贈り物」の定義が部署で違う。システムは「包装・のしを選んだ注文」、CS は「プレゼントとして送られる注文」、物流は「のし紙の注文」。定義を決めないまま要件を書くと、書いた人の頭の中の定義で設計される。Day014 の手順書は、4月は印(★L)で判断を工程から消したが、印の元になる判定そのものが誤っていた。手順書では防げなかった失敗である

読み手プロファイル

項目内容
誰が読むか今井課長(物流本部 出荷管理課長。承認者)と、長谷川さん(情報システム部 開発リード)。CS 松本さんが定義の相談先として同席
何を判断するために読むか今井課長: ①この要件は物流の業務として正しいか ②物流は何を決め、何を守るのか ③梱包ラインの作業は増えないか。長谷川さん: ①何を作ればこの要件を満たしたと言えるか ②工数を出すのに足りない情報は何か
何を知っているか今井課長: 梱包ライン、4月のカード同梱の運用、★L の存在、4月に9件の問い合わせがあったこと。長谷川さん: 出荷指示と納品書のデータ(注文者・送り先の住所、包装・のしの有無)、印字の変更の手間
何を知らないか今井課長: 「ギフトフラグ」が何で決まるか、4月に約720箱が誤って入ったこと、システムの用語(フラグ・テーブル・判定ロジック)。長谷川さん: 物流の現場の制約(梱包は1箱40秒・両手がふさがる)、「贈り物」を物流が何と見分けているか
何を気にしているか今井課長: 梱包のスピードを落とされないこと、現場の責任にされないこと、同梱物が増えるたびに現場への説明が増えること。長谷川さん: 曖昧な要件で作って後から直しを言われること
読む時間と場面今井課長: 会議前日に印刷して20分、赤ペンで「これは違う」を探す。長谷川さん: 机で1時間、工数の根拠にする
この読み手が変わると何が変わるか:
読み手が MOps・情報システム部の同僚だけ(Lv1: 味方)なら、「同梱フラグ」「判定ロジック」の言葉のまま、機能の細部まで書いてよい。読み手が 同梱物の追加に反対している物流のシフトリーダー(Lv3: 利害が対立)なら、冒頭は「作業者の判断は増えません。むしろ0にします」と、相手が一番嫌がる点への答えから書く。読み手が システムを知らない経営層(Lv4)なら、要件の表より先に、4月の誤投入約720箱と、同梱物9本で27人日、という事業の数字を置く。今回は システムの言葉を読まない業務責任者と、業務の言葉を実装に翻訳する開発者の2人 なので、要件は業務の結果で書き、定義は業務の人が選べる形(選択肢と、それぞれ4月ではどうなったか)で渡し、「どう作るか」は書かない のが正解。 ---

4段階で見る — 「3. 業務要件」

以下は同じ業務要件定義書の 「3. 業務要件」 の部分を、4段階で書き分けたもの。業務要件定義書で最も差が出るのは、背景や範囲ではなく、この部分である。

🔴 Bad15行
🟡 Good14行
🟢 Better12行
🔵 Best15行
Bad
目的が「自動化・向上」。
「テーブルに列を足す」と解決策。
「適切に」で定義が推測任せ。
Good
ID・優先度つきで型は完璧。
でも要件が現行システムの書き写し。
ギフトフラグ=4月の誤投入の元。
Better
業務の結果の言葉。確かめ方つき。
要件と業務ルールを別表に。
定義は書き手が黙って選択。
Best
冒頭は「決めていただきたい2点」。
定義A/B/Cを4月に当てはめて比較。
決まらなければ5/31に案Bで着手。
Bad
"shall" form, vague words.
"as appropriate", "fast".
Design dictated as a requirement.
Good
ID, shall, MoSCoW in place.
Subject is "The system".
Copies the current gift flag.
Better
Business side as subject.
Acceptance check column.
Rules in a separate table.
Best
"Decisions requested" first.
Options A/B/C on April data.
If undecided: Option B on May 31.
Bad — 妥協して雑に作った状態 / 15行
業務要件定義書(同梱物の対象判定)
1. 背景
 当社では販促の強化を進めており、同梱物の効率的な運用が求められている。
2. 目的
 同梱業務を自動化し、業務効率の向上と顧客満足度の向上を実現する。
3. 要件
 3.1 同梱の対象判定を自動化すること
 3.2 WMSの出荷指示テーブルに同梱フラグ列を追加し、納品書に印字すること
 3.3 ギフト注文は適切に除外すること
 3.4 システムは高速に動作すること
 3.5 将来の施策に柔軟に対応できること
 3.6 現場担当者が使いやすいこと
 3.7 個人情報の取り扱いに配慮すること
4. スケジュール
 別途調整

解説

何が起きているか:

  • 目的が目標のまま。 「自動化」「効率の向上」「満足度の向上」は、何ができたら達成なのかが書かれていない。達成できなくても失敗にならない
  • 解決策が要件の顔をしている(3.2)。 「テーブルに列を足す」は設計の話である。書き手が思いついた手段を先に書くと、他の手段(たとえば既存の項目を使う)を、読み手は検討しなくなる。今井課長は読んでも何も言えない(「テーブル」を知らない)
  • 曖昧な言葉が4つ(適切に・高速・柔軟・使いやすい)。 どれも、満たしたかどうかを誰も判定できない。特に3.3の「適切に」は、この文書で一番決めるべきこと(ギフトとは何か)を、開発者の推測に任せている
  • 数字が1つもない。 1日何箱か、4月に何が起きたか、同梱物が年に何本あるかが分からないので、長谷川さんは工数を出せない
  • 4. スケジュール「別途調整」。 誰がいつ決めるのかが決まっていない

これは怠慢ではなく、「依頼」と「要件」の区別がついていない ことから生まれる形である。書き手は「こうしたい」と願いを並べ、読み手は「何を満たせばよいか」を探している。

Bad / 16行
Business Requirements Document: Insert Targeting
1. Background
 The company is strengthening its promotions and efficient handling
 of inserts is required.
2. Objective
 To automate insert handling and improve efficiency and satisfaction.
3. Requirements
 3.1 The system shall automate insert targeting.
 3.2 A flag column shall be added to the WMS shipment table and
     printed on the packing slip.
 3.3 Gift orders shall be excluded as appropriate.
 3.4 The system shall be fast.
 3.5 The system shall be flexible for future campaigns.
 3.6 The system shall be user-friendly.
 3.7 Personal data shall be handled with care.
4. Schedule: TBD

英文としての型

英文では "shall" の形は整っているのに、"as appropriate" "fast" "flexible" "user-friendly" は、英語圏の要件の教科書では「検証できない語」の代表例として挙げられる(ISO 29148 の "verifiable" に反する)。3.2 は "shall" で設計を指定してしまっている。
Good — 型は満たしている / 14行
業務要件定義書 BR-DOC-003(第1版 2028/5/22)
3. 業務要件一覧
 ID    要件                                      優先度
 BR-01 出荷時に、同梱物の対象かどうかを判定できること   Must
 BR-02 初回購入の注文を判定できること               Must
 BR-03 ギフトフラグがONの注文は対象外とすること       Must
 BR-04 同梱物ごとに対象条件を設定できること          Must
 BR-05 判定結果を納品書に印字できること             Must
 BR-06 判定結果を出荷日報に集計できること            Should
 BR-07 定期便・法人の注文は対象外とすること          Should
 BR-08 判定は出荷指示の取込から1分以内に完了すること   Must
 BR-09 判定条件の変更履歴を保存すること             Should
 BR-10 個人情報は社内規程に従って取り扱うこと         Must
 (優先度: Must=必須 / Should=できれば。MoSCoW法)

解説 動いた軸:③事実と解釈の分離 / ④次の行動

Badから何が変わったか:

  • ④次の行動が動いた。要件に番号と優先度がつき、「何を作るか」が1つずつ数えられる。長谷川さんは工数の見積りに使える
  • ③事実と解釈の分離が動いた。「適切に」が「ギフトフラグがONなら」と、判定の条件になった。BR-08のように数字(1分以内)を持つ要件もある
  • 要件定義書の標準の型(ID・要件・優先度。MoSCoW法)が揃っている。社内の書式があれば、これで提出できる

まだ足りないもの(ここが今日の本題):

  • 要件が「システムが今やっていること」の書き写しになっている。 BR-03の「ギフトフラグがON」は、4月に使った判定そのものである。この判定が、約720箱の誤投入を起こした。Goodは、業務として正しいかを問う前に、今の挙動を要件にしてしまった
  • 「ギフト」の定義を業務の人が選んでいない。 フラグが何で立つか(包装・のしを選んだ注文だけ)を、今井課長は知らないので、BR-03を読んで「そのとおり」と承認してしまう。承認したのに、4月と同じことが起きる
  • 今井課長が赤ペンを入れられない。 「判定できること」「設定できること」「集計できること」は、システムの機能の羅列で、物流の業務が何を満たせば良いのかが読み取れない。BR-05の「納品書に印字」は解決策である
  • 根拠がない。 なぜ BR-04(同梱物ごとの条件設定)が Must なのか。4月に何が起き、年に何本あるのかがない。優先度が書き手の感覚に見える
  • 満たしたかどうかを、物流の人が確かめる方法がない。 「判定できること」をどう確かめるのかが書かれていない
Good / 14行
BRD-003 (Rev. 1, 2028-05-22)
3. Business Requirements
 ID     Requirement                                             Priority
 BR-01  The system shall determine whether an order gets an insert.   Must
 BR-02  The system shall identify first-time purchase orders.        Must
 BR-03  Orders with the gift flag ON shall be excluded.             Must
 BR-04  Eligibility rules shall be configurable per insert.         Must
 BR-05  The result shall be printed on the packing slip.            Must
 BR-06  The result shall be summarized in the daily report.         Should
 BR-07  Subscription and corporate orders shall be excluded.        Should
 BR-08  Determination shall finish within 1 minute of import.       Must
 BR-09  Rule changes shall be logged.                               Should
 BR-10  Personal data shall follow company policy.                  Must
 (Must / Should: MoSCoW)

英文としての型

英文の要件の標準の型(ID・"shall"・MoSCoW)が揃っている。"The system shall ..." で始まるのは、実はソリューション要求の書き方で、業務要件(business requirements)としては主語がずれている。業務要件の主語は "The business" "Fulfilment" など、業務側であるべき。
Better — 読み手に最適化されている / 12行
3. 物流の業務として、何を満たす必要があるか
 要件                              なぜ(根拠)                     満たしたかの確かめ方
 R-1 初めて買った方の箱にだけ入れる   4月の対象は1日約950箱             4月の出荷日報の対象件数と一致する
 R-2 贈り物として送る箱には入れない   4月に受取人から問い合わせ9件       BR-2に当たる箱が0件
 R-3 作業者に、対象かどうかを判断させない  去年11月に入れ忘れ18%以上     貼り紙に「印以外を見る」手順がない
 R-4 同梱物が変わっても梱包の手順は変えない  2028年度に9本の予定       新しい同梱物の朝礼説明が5分以内
 R-5 間違いに、現場とCSの連絡より先に気づける  9件は受取人の連絡で初めて分かった  毎シフトの終了時に、枚数の差が出る

 業務ルール(物流とCSが決める。システムの言葉では書かない)
 BR-1 初めて買った方 = この注文が、その方の最初の購入である
 BR-2 贈り物 = 送り先が注文者と違う、または包装・のしを選んだ注文
 この章に書かないこと: 印をどう刷るか、どのシステムで判定するか(設計で決める)

解説 動いた軸:②読み手適合 / ③事実と解釈の分離

Goodから何が変わったか(★ここが今日の学習の中心):

読み手プロファイルの各項目に、変更を1対1で対応させている。

読み手プロファイルの項目Betterで行った変更
今井課長が判断すること「物流の業務として正しいか」機能の言葉(判定できる・設定できる・印字できる)を、業務の結果の言葉(入れる・入れない・作業者に判断させない・手順を変えない)に直した。今井課長は、自分の言葉で「R-3は違う、貼り紙でなく朝礼で…」と赤ペンを入れられる
今井課長が気にしていること「作業者の判断が増えないか」R-3「作業者に判断させない」とR-4「同梱物が変わっても手順は変えない」を、要件として前に出した。Goodでは「納品書に印字」という手段の中に隠れていた。業務の側から見て一番守りたい性質が、要件として独立した
長谷川さんが知りたいこと「何を満たせば良いか」右端の列に 「満たしたかの確かめ方」 を置いた。「4月の出荷日報の対象件数と一致する」「BR-2に当たる箱が0件」は、設計の前に決まる受入れの見方で、開発者は確かめ方から逆算して設計できる
何を知らないか「ギフトフラグが何で決まるか」「ギフトフラグがON」を 業務ルール BR-2 の文(送り先が注文者と違う、または包装・のしを選んだ)に置き換えた。物流の人が読んで意味が分かり、データに照らして判定できる。要件と業務ルールを別の表に分けたのが肝
何を気にしているか(長谷川さん)「曖昧な要件」「なぜ(根拠)」の列に、4月の数字(950箱・9件・18%)を入れた。優先度の感覚ではなく、起きた事実で必要性が決まる
何を知らないか「システムの用語」「フラグ」「テーブル」「判定ロジック」を本文から外し、「この章に書かないこと」の1行で、解決策は設計で決めると宣言した。今井課長は安心して読め、長谷川さんは手段の自由を得る

「実装に寄りすぎない」と「曖昧でない」の両立: 「ギフトを適切に除外する」は曖昧で、「ギフトフラグがON」は実装に寄りすぎる。その間にあるのが 「送り先が注文者と違う、または包装・のしを選んだ」 という、業務の人が読めて、データでも確かめられる条件である。業務要件は、システムの項目名は書かないが、業務が使う情報(送り先・注文者・包装)の名前は書く。この線引きが、勝負どころである。

それでも残っている問題(Bestで扱う):

  • BR-2は宮田さんが1人で決めたことになっている。 贈り物の定義は、4月の失敗の核心で、物流・CS・販促の3者の利害が違う(案によって見逃しも誤投入も変わる)。書き手が黙って選ぶと、承認も黙って通る
  • 選ばなかった定義と、その代償が見えない。 BR-2のように「送り先が違う」を入れると、自分の職場や実家に自分用として送る方を、対象から外してしまう。この見逃しがどのくらいか、読み手に見えない
  • 決まらなかったときにどうなるかがない。 5/30に決まらなければ、6/5の設計着手が遅れ、7/3の同梱物に間に合わない
  • 扱わないことが書かれていない。 定期便・法人(別ライン)は? 注文後に送り先が変わった場合は?

ここで動いた軸: ②読み手適合(機能の羅列から、今井課長の赤ペンと長谷川さんの工数見積りに使える形へ)、③事実と解釈の分離(「ギフトフラグ」という実装から、業務ルールの文へ)。

Better / 12行
3. What the fulfilment operation must achieve
 Requirement                          Why (evidence)                Acceptance check
 R-1 Insert only in first-time buyers' boxes   ~950 boxes/day in April   Matches April target count
 R-2 Never insert in boxes sent as gifts       9 recipient inquiries      0 boxes meeting BR-2
 R-3 Operators make no eligibility decision    18%+ missed in Nov 2027    No step other than the mark
 R-4 Pack procedure unchanged for new inserts  9 campaigns in FY2028      Briefing under 5 minutes
 R-5 Errors visible before customers report    9 cases found by recipients  Shift-end count difference shown

 Business rules (owned by Logistics and CS; no system terms)
 BR-1 First-time buyer = this order is the person's first purchase.
 BR-2 Gift = ship-to differs from the orderer, or wrapping/noshi chosen.
 Out of this section: how the mark is printed, which system decides.

英文としての型

主語を "Operators" "Pack procedure" と業務側に置いたのが英文の業務要件の型。"Acceptance check" の列は、英文の要件定義でも "acceptance criteria" として別に持つのが普通。"ship-to" と "orderer"(注文者)という用語は、英語の受発注の世界では bill-to / ship-to と呼ぶ(後述の日英差分ノート)。
Best — 読み手が意思決定できる / 15行
5/30(火)の要件確認会で、今井課長に決めていただきたいこと(2点)
 ① 「贈り物」の定義を、A・B・C のどれにするか(案: B)
   案  定義                             4月に当てはめると                 代償
   A   包装・のしを選んだ注文(4月のやり方) 受取人への誤投入 約720箱(連絡は9件)  なし
   B   Aに加え、送り先が注文者と違う注文     誤投入 0。対象は1日約925箱(−約26)   自分宛ての別住所の方を逃す。最大約220件/月
   C   注文時にお客さまに「贈り物ですか」と聞く  誤投入・見逃しとも最小              注文画面の変更が要る。早くて9月
 ② 定義を決め、変えられる人(案: 定義は物流とCSが決め、何を入れるかは販促が決める。変更は今井課長の承認)

要件(業務の結果。実装は設計で決める) 受入れ: 4月分のデータに当てはめて確かめる
 R-1 贈り物と決めた箱に入れない    受入: 受取人になる箱が0件
 R-2 作業者に判断させない・手順を変えない 受入: 朝礼説明5分以内、貼り紙に印以外を見る手順がない
 R-3 同梱物が増えても条件の追加だけで済む 受入: 条件の追加から稼働まで5営業日以内(今は約10営業日)
 R-4 間違いに現場の連絡より先に気づける  受入: 毎シフト終了時に対象件数と使用枚数の差が出る
決まらなかったら: 5/31(水)に案Bで設計に入る。案Cの工数は長谷川さんが6/12(月)までに出す
この要件で扱わないこと: 定期便・法人(別ライン)/注文後の送り先変更(件数は月数件で、別に決める)

解説 動いた軸:①結論の位置 / ②読み手適合 / ④次の行動 / ⑤想定反論

Betterから何が変わったか:

  • ①結論の位置 → 冒頭が「今井課長に決めていただきたいこと」になった。 読み手が前日に最初に見るのは、決めること2点。要件の一覧(Betterの前半)は、その後ろに下げた
  • ②読み手適合 → 贈り物の定義を、「宮田さんが選んだ文」から「物流が選ぶ表」にした。 A/B/Cの 列を「4月に当てはめるとどうなったか」 にしたのは、今井課長が実際に起きたことで比べられるようにするため。「送り先が違う注文を含めるか」という抽象的な問いは、物流の人には答えられない。「約720箱に誤投入、でも連絡は9件」なら答えられる
  • ③事実と解釈の分離 → 選んだ案の代償を同じ行に書いた。 Bは誤投入を0にするが、自分宛ての別住所の方(職場・実家宛て)を最大約220件/月 逃す〔仮定: 別住所・包装なしの約3割〕。誤投入(受取人に「初めての購入ありがとう」と書いたカードが届く)の方が、見逃し(友だち追加の機会を逃す)より重い、という判断を書き手が先に済ませて推奨にした。Aの「代償: なし」は、現状維持の代償は誤投入そのものだと読めるように、あえて書いた
  • ④次の行動 → 決まらなかったときの動きを日付で決めた。 5/31に案Bで設計に入り、案Cは6/12までに長谷川さんが工数を出す。決めないと全体が止まるが、止まらない道を先に作った
  • ⑤想定反論 → 「そこまで物流が決めるのか」「システムの話ではないのか」に、②の1行で先回りした。 定義を決めるのは物流とCS、何を入れるかは販促、というルールの持ち主を決めた。後で「そんな定義は聞いていない」と言われる事故を、持ち主を決めることで防ぐ
  • 削ったもの: Betterの「なぜ」の列(根拠)は、4月の数字としてA/B/Cの表に統合した。業務ルールBR-1の定義は全文へ移した
  • 分量: 行数は後掲の「差分5軸まとめ」の実測のとおり。Betterより短くなったのではなく、「選んでもらう表」と「決まらなかったとき」が足された分だけ、Better以上になる

なぜ定義を黙って選ばず、選ばせたのか — 宮田さんが迷った点:
宮田さんは最初、Better のまま(案Bを黙って採用)で出すつもりだった。案を並べると「自分で決められない担当者」に見えるおそれがあった。しかし、贈り物の定義は、4月の失敗の核心であり、決める権限が宮田さんにない(物流の梱包と、CSの問い合わせ対応に直接響く)。黙ってBで通せば、見逃し約220件を物流が知らないまま受け入れたことになり、後で「聞いていない」になる。5/10のデータを見ると、Aのままなら4月と同じ約720箱が毎月起きる〔導出〕。年に換算すると約8,650箱〔導出〕である。

反証条件(この文書の形が変わる場合):

  • 自分宛ての別住所の割合が3割ではなく大きかったら、案Bは推奨できない。 5/26までに長谷川さんが、別住所・包装なしの初回注文720件のうち、同じ住所に過去の注文がある(自分用に使っている)割合を出す。5割を超えたら、推奨を案Cに変え、設計着手を遅らせる
  • 注文者と送り先の住所が、出荷指示のデータに入っていなかったら、案Bは作れない。 5/10に長谷川さんが「入っている」と確認済みだが、法人の複数配送先では例外があるかもしれない。ここは設計で確かめる

今回はBestまで作るべきか: Best必要。 判定の誤りが、お客さまへの不信(受取人へのカード)になり、すでに4月に起きた。しかも定義は3つの部署で食い違っている。逆に、1つの部署だけが使う小さな画面の変更(定義の論点がない)なら Better で十分。選択肢の表と決まらなかったときの動きは、定義が部署をまたいで食い違うときにだけ効く。要件定義書の品質は、「決めるべきことを、決める人に決められる形で渡したか」で決まる。

Best / 15行
Decisions requested at the May 30 (Tue) requirements review (2)
 1. Definition of "gift" - A, B or C (we recommend B)
   Option  Definition                         If applied to April               Cost
   A       Wrapping/noshi chosen (April rule)  ~720 recipient boxes wrongly filled (9 reported)  None
   B       A, plus ship-to differs from orderer  0 wrong inserts; ~925 targets/day (-26)  Misses up to ~220/month self-addressed
   C       Ask the customer at checkout "Is this a gift?"  Fewest errors both ways  Checkout change; September at earliest
 2. Who owns the definition (proposal: Logistics and CS own it; Marketing owns what is inserted; changes approved by Mr. Imai)

Requirements (outcomes; design decides how) - acceptance: run against April data
 R-1 No insert in boxes defined as gifts      Accept: 0 recipient boxes
 R-2 No operator decision, no new procedure   Accept: briefing <= 5 min; no step other than the mark
 R-3 New inserts need rule entry only         Accept: <= 5 business days from request (now ~10)
 R-4 Errors visible before customers report   Accept: shift-end count difference shown
If undecided: Design starts May 31 on Option B; Mr. Hasegawa sizes Option C by June 12.
Out of scope: subscription/corporate (separate line); ship-to changes after order (a few per month; decided separately).

英文としての型

"Decisions requested" で始め、選択肢 A/B/C+"we recommend B" と書くのが、英文の意思決定文書の BLUF の型。"Out of scope" を明記するのは英文の要件定義の定型で、日本語より厳密に書く(スコープの曖昧さを契約の問題として扱う文化のため)。

日英差分ノート

1. 英語の "The system shall ..." は、業務要件には主語が合わない

英語の要件の定型は "The system shall ..." だが、これは ソリューション要求(システムが何をするか) の書き方である。業務要件の段階で同じ型を使うと、「システムが何をするか」から書き始めてしまい、業務の結果が消える。BABOK でも、ビジネス要求(なぜ)とソリューション要求(どう)は層を分けている。日本語の「〜できること」も同じ罠で、主語がないぶん気づきにくい。日本語版は「入れる/入れない」「判断させない」と業務の動詞で書き、英語版も "Operators make no eligibility decision" と業務側を主語にした。

2. 「ギフト」の定義は、英語では bill-to / ship-to という語彙がある

英語の受発注では、請求先(bill-to)と届け先(ship-to)を別の項目として扱う語彙が定着しているので、"ship-to differs from the orderer" と短く書ける。日本語の業務要件では「送り先が注文者と違う」と言い換える必要があり、日本語の方が定義を長く書く。逆に日本語の「贈り物」「ギフト」は、英語の "gift" より範囲が広く、「贈答」と「プレゼント」と「のし紙の注文」を同じ言葉で呼ぶ。だから、言葉ではなく条件で定義した。

3. 優先度と "shall"・"should" の強さが日英でずれる

英語の要件では "shall" は義務、"should" は推奨、"may" は任意(RFC 2119 や ISO 29148 の慣行)。日本語の「〜すること」「〜できること」は、強さの違いを文では表しにくく、MoSCoW のような別の列で優先度を持つ。今日の Good は日本語も英語も MoSCoW を使っているが、英語の "Should" 行を "shall" で書いたため、文は義務で、優先度は「できれば」という矛盾が出る。日本語でも同じ矛盾が起きやすい。

頻出表現

日本語Englishトーンの強さ
〜すること/〜であることshall ... / must ...強い。義務。業務要件では業務側を主語に
できれば〜should ...中立。推奨。優先度の列と合わせる
適切に/速やかにas appropriate / promptly弱い。検証できない。使わない
受入れ条件(確かめ方)acceptance criteria強い。要件と対にする
業務ルールbusiness rule中立。定義・条件。要件と別の表に
決めていただきたいことdecisions requested強い。冒頭に置く。BLUF
今回は扱わないout of scope中立。理由とセットで
見逃し/誤投入false negative / false positive中立。代償の欄で使う
4月に当てはめるとapplied to April data中立。選択肢の比較の列

差分5軸まとめ

軸🔴 Bad🟡 Good🟢 Better🔵 Best
① 結論の位置目的が「自動化・向上」要件の一覧が先頭「物流として何を満たすか」が先頭冒頭に「決めていただきたいこと2点」
② 読み手適合「テーブルに列を足す」(解決策)機能の言葉(判定できる・設定できる)業務の結果の言葉。確かめ方つき定義を物流が選ぶ表。列が「4月ではどうなったか」
③ 事実と解釈の分離数字なし。「適切に」数字はBR-08だけ。ギフトフラグは書き写し根拠の列に4月の数字。業務ルールを分離選ばなかった案の代償・仮定を明記
④ 次の行動「別途調整」優先度のみ受入れの確かめ方5/31に案Bで着手、6/12に案Cの工数
⑤ 想定反論無視触れない「ギフトフラグ」を業務ルールの文に「決めるのは物流か」に持ち主を決めて先回り
分量(実測)15行14行12行15行
今回の学習の中心は Good → Better → Best の全部。 Good→Better は 機能の言葉を業務の結果の言葉に直し、要件と業務ルールを別の表に分け、確かめ方をつけるという読み手最適化。Better→Best は 書き手が黙って選んでいた「定義」を、業務の人が選べる形に開き、代償と決まらなかったときの動きを足した。要件定義書で一番大きな事故は、要件を書き写す人が、定義を黙って選んでしまうことである。「実装に寄りすぎない」とは、システムの項目名を書かないことではなく、業務が決めるべき判断を、開発者の推測に任せないことである。 ---

Best版・全文

日本語版 全文を見る(44行)
業務要件定義書 BR-DOC-003「同梱物の対象判定」(第1版 2028/5/22)
作成: 販促システム部 MOps 宮田 読み手: 物流本部 出荷管理課長 今井/情報システム部 開発リード 長谷川
要件確認会: 2028/5/30(火)15:00〜15:45

━━ 1. 決めていただきたいこと(5/30)━━
 ① 「贈り物」の定義: A / B / C から1つ(推奨: B)
   案  定義                               4月に当てはめると                   代償
   A   包装・のしを選んだ注文(4月のやり方)   受取人への誤投入 約720箱(連絡は9件)   なし
   B   Aに加え、送り先が注文者と違う注文       誤投入 0。対象は1日約925箱(−約26)    自分宛ての別住所の方を逃す。最大約220件/月
   C   注文時に「贈り物ですか」と聞く          誤投入・見逃しとも最小              注文画面の変更。早くて9月
 ② 定義を決め、変えられる人: 定義は物流とCSが決め、何を入れるかは販促が決める。変更は今井課長の承認
 決まらなかったら: 5/31(水)に案Bで設計に入る。案Cの工数は長谷川さんが6/12(月)までに出す

━━ 2. 背景(根拠)━━
 ・4/3〜4/30、ギフトの受取人から「買っていないのに初回購入のお礼カードが入っていた」という問い合わせ 9件〔実測〕
 ・4月の出荷 252,000箱、初回購入 27,720件、うち「送り先が違う・包装なし」2.6%=約720件(5/10 長谷川さん抽出)〔実測〕
 ・誤投入 約720箱に対し連絡は9件(1.2%)。連絡の陰に約710人〔導出〕
 ・同梱物は2028年度に9本の予定〔仮定〕。今は1本ごとに印字条件の変更が3人日・約2週間〔仮定〕。計27人日〔導出〕

━━ 3. 要件(業務の結果。実装は設計で決める) 受入れ: 4月分のデータに当てはめて確かめる ━━
 R-1 贈り物と決めた箱に入れない                    受入: 受取人になる箱が0件
 R-2 作業者に判断させない。同梱物が変わっても梱包の手順は変えない  受入: 朝礼説明5分以内、貼り紙に印以外を見る手順がない
 R-3 同梱物が増えても、条件の追加だけで済む          受入: 条件の追加から稼働まで5営業日以内(今は約10営業日)
 R-4 間違いに、お客さまの連絡より先に気づける        受入: 毎シフト終了時に、対象件数と使用枚数の差が出る

━━ 4. 業務ルール(物流とCSが決める)━━
 BR-1 初めて買った方 = この注文が、その方の最初の購入である
 BR-2 贈り物 = 案で選んだ定義(B: 送り先が注文者と違う、または包装・のしを選んだ注文)
 BR-3 対象外のライン: 定期便・法人(別の梱包ライン/出荷口)

━━ 5. この要件で扱わないこと ━━
 ・定期便・法人(別ライン) ・注文後の送り先変更(月数件。別に決める)
 ・印の刷り方、判定するシステム、データの持ち方(設計で決める。要件には書かない)

━━ 6. この要件が崩れる条件 ━━
 ・別住所・包装なし720件のうち、同じ住所に過去の注文がある(自分用)割合が5割を超えたら、推奨を案Cに変える(長谷川さんが5/26までに確認)
 ・注文者と送り先の住所が出荷指示に入っていない例外が見つかったら、案Bの範囲を設計で見直す

━━ 7. 日程 ━━
 5/26(金)17:00 提出 5/30(火)要件確認会 5/31(水)設計着手(案B) 6/5(月)設計開始 6/12(月)案Cの工数
 6/26〜6/30 試験(4月分のデータで受入れを確認) 7/3(月)夏のレビュー依頼カード開始

━━ 8. 承認 ━━
 業務責任者: 物流本部 出荷管理課長 今井  開発: 情報システム部 開発リード 長谷川  作成: 宮田
English 全文を見る(44行)
BRD-003 "Insert Eligibility" (Rev. 1, 2028-05-22)
Author: Miyata, Promotion Systems (MOps)  Readers: Mr. Imai, Outbound Shipping, Logistics; Mr. Hasegawa, Information Systems
Requirements review: Tue 2028-05-30, 15:00-15:45

== 1. Decisions requested (May 30) ==
 1. Definition of "gift": choose A, B or C (we recommend B)
   Option  Definition                          If applied to April             Cost
   A       Wrapping/noshi chosen (April rule)   ~720 recipient boxes wrongly filled (9 reported)  None
   B       A, plus ship-to differs from orderer  0 wrong inserts; ~925 targets/day (-26)  Misses up to ~220/month self-addressed
   C       Ask the customer at checkout          Fewest errors both ways          Checkout change; September at earliest
 2. Owner of the definition: Logistics and CS own it; Marketing owns what is inserted; changes approved by Mr. Imai.
 If undecided: design starts May 31 on Option B; Mr. Hasegawa sizes Option C by June 12.

== 2. Evidence ==
 - Apr 3-30: 9 inquiries from gift recipients who got a "thank you for your first purchase" card [measured]
 - April: 252,000 boxes; 27,720 first-time orders; 2.6% (~720) ship to another address with no wrapping (extracted May 10) [measured]
 - ~720 wrong inserts vs 9 reports (1.2%): ~710 recipients stayed silent [derived]
 - 9 insert campaigns planned in FY2028 [assumed]; each needs a 3 person-day print change, ~2 weeks [assumed]; 27 person-days in total [derived]

== 3. Requirements (outcomes; design decides how). Acceptance: run against April data ==
 R-1 No insert in boxes defined as gifts          Accept: 0 recipient boxes
 R-2 No operator decision; procedure unchanged for new inserts   Accept: briefing <= 5 min; no step other than the mark
 R-3 New inserts need rule entry only             Accept: <= 5 business days from request (now ~10)
 R-4 Errors are visible before customers report   Accept: shift-end difference between targets and cards used is shown

== 4. Business rules (owned by Logistics and CS) ==
 BR-1 First-time buyer = this order is the person's first purchase.
 BR-2 Gift = the option chosen above (B: ship-to differs from the orderer, or wrapping/noshi chosen).
 BR-3 Excluded lines: subscription and corporate (separate packing line / dock).

== 5. Out of scope ==
 - Subscription and corporate orders; ship-to changes after order (a few per month; decided separately).
 - How the mark is printed, which system decides, how data is held (design decides; not a requirement).

== 6. What would change this ==
 - If more than half of the ~720 orders share an address with a past order (self-use), we switch the recommendation to Option C (Mr. Hasegawa checks by May 26).
 - If exceptions exist where the orderer and ship-to are not in the shipment data, we revisit Option B's scope in design.

== 7. Schedule ==
 May 26 (Fri) 17:00 submit; May 30 (Tue) review; May 31 (Wed) design on Option B; Jun 5 (Mon) design starts; Jun 12 (Mon) Option C estimate;
 Jun 26-30 test against April data; Jul 3 (Mon) summer review-request card starts.

== 8. Approval ==
 Business owner: Mr. Imai   Development: Mr. Hasegawa   Author: Miyata

完成の定義チェックリスト

業務要件定義書を出す前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。

進捗 0 / 9

今日の演習

15分版(まずこれだけでもやる)

Good版の BR-01〜BR-10 から、「システムが今やっていることの書き写し」になっている要件を2つ選び、業務の結果の言葉に書き直す。

手順:

  1. 各要件に、主語を「システム」ではなく「物流(業務)」にして 読み直す。意味が通らないものが、機能の言葉のまま残っている要件
  2. 2つ選び、「それは業務として何のためか」「満たしたかを物流の人はどう確かめるか」 を1行ずつ書く
  3. 書き直した文を、Betterの R-1〜R-5 と見比べる

確かめ方の欄を2つ書けたら、今日の目的は達成。文面が Better と違っていてもよい。

60分版

自分の職場の「システムに頼もうとしていること」を1つ選び、「贈り物の定義」にあたる、部署によって定義が違う言葉を1つ見つけて、A/B/Cの選択肢と「過去の実例に当てはめるとどうなるか」の表を作る。 題材がない場合は下の設定を使う。

設定(自分の題材がない場合): 7月から、返品を受け付けるときに「返品理由コード」を選ばせる画面を作る。CS は「商品の不具合」、物流は「再販できない状態」、経理は「返金の対象」を、それぞれ「不良品」と呼んでいる。2028年4月の返品は 3,400件で、うち CS の定義では 12%(約410件)、物流の定義では 7%(約240件)、経理の定義では 9%(約310件)が「不良品」〔仮定〕。

守る条件:

  • 「不良品」を A(CS の定義)/B(物流の定義)/C(経理の定義) とし、列を「4月に当てはめると何件になるか/その定義を選んだときの代償」にする
  • 4月の件数から「定義によって、誰の作業・誰のお金がいくら変わるか」を1行ずつ書く
  • 要件は 「業務の結果」で4つ以内。受入れは「4月分のデータで確かめる」形にする
  • 決めるのは誰か、決まらなかったらいつ誰が何をするかを書く
  • 最後に、この業務要件定義書は Better 止めでよいか、Best が要るかを1行で判定する
取り組む前のヒント

考える順序

  1. まず、3部署の定義を 同じ4月のデータに当てはめて 件数を出す(12%・7%・9%)。定義の違いは、件数の違いとして見せると、決める人が選べる
  2. 次に、定義を選んだときに 誰が困るか(CS は問い合わせが増える、物流は再販の判断が増える、経理は返金の対象が変わる)を書く
  3. 要件は、定義が決まった後の 業務の結果(例: 返品の箱を開ける前に区分が分かる)で書く。画面の項目は設計で決める

陥りやすい罠

  • 定義を3つ並べて、推奨を書かない。選ぶ人が決めやすいように、書き手として理由つきで勧める
  • 件数を出さずに「CSの立場」「物流の立場」で説明する。立場の説明は議論になり、件数は選択になる
  • 要件の中に「コード表」「プルダウン」など画面の手段を書いてしまう

チェックすべき観点
書き上げたら、「担当役員が、この表だけで5分で定義を選べるか」と「選ばれなかった定義の部署が、自分の代償が書かれていることを見て、納得できるか」の2点を確かめる。

実務での使いどころ

業務要件定義書は、システム開発の最初の入口にあたる。ここで決めなかった定義は、開発者が推測で決め、リリース後に事故として現れる。

関係文書この業務要件定義書との関係
前作業手順書(製造・オペレーション#1、Day014)4月の手順書は ★L の判定を信じる手順だった。手順書では防げなかった失敗の原因が、この文書の題材
前会議アジェンダ(会議・コミュニケーション#1、Day012)5/30の要件確認会の招待は「案で決めます」の型。冒頭の「決めていただきたいこと」をそのまま議題にできる
後機能要件定義書(IT-要求・設計#2)R-1〜R-4 を、画面・データ・判定の機能に分解する。曖昧語の排除がそこでの勝負
後非機能要件定義書(IT-要求・設計#3)R-3 の「5営業日以内」や判定時間は、非機能の数値基準に引き継がれる(Day010の「測定可能の5点」を再利用)
横ADR(IT-要求・設計#6)案A/B/Cのうち B を選んだ理由と、却下した案の理由は、ADR として残す(前提が変わったら判断が変わる条件つき)
横効果測定レポート(マーケティング#8)「誤投入は何件減ったか」を4月と比べる続編にできる
現場で一番効くのは、要件を書き終えたら、定義を持つ言葉(贈り物・初回・不良品・在庫)を全部抜き出し、「この言葉を3つの部署に聞いたら、同じ答えが返るか」を確かめること。 返らない言葉が、その要件定義書で一番高くつく。 ---

この回の設計メモ(迷った他案・扱わなかった範囲・出所)

迷った他案と採らなかった理由
  • 経営層(Lv2の「経営」)に業務要件定義書を読ませる案 — 経営層は業務要件定義書を直接読まない。承認者としては「他部署の業務責任者」が実態に近く、今回は物流本部の課長にした。カタログの主な読み手(業務部門・開発)と Lv2(他部署)がそのまま一致する
  • 今日の題材を「新しい画面を作る」大型案件にする案 — 要件が数十本になり、比較の部分が長くなる。今回は、定義が部署で食い違う1つの論点(贈り物)に絞って、「要件を書き写すと定義を黙って選ぶ」という、この文書の一番の事故を見せた
  • Good を「要件を1つも書き写さない完全な型」にする案 — Good が正しすぎると、Better との差が「丁寧さ」だけになる。実務で多いのは、型は完璧で、中身が現行システムの書き写しという状態なので、そちらをGoodにした
  • Better で選択肢(A/B/C)まで出す案 — それだと Best との差がなくなる。Better は「業務の言葉で書く・要件と業務ルールを分ける・確かめ方」にとどめ、定義を黙って選んでいることを Best への課題として残した
  • Best で案Cを推奨する案 — 誤投入も見逃しも最小だが、注文画面の変更が要り、早くて9月で、7/3の同梱物に間に合わない。「間に合わない最善」より「間に合う次善(B)で始め、Cは工数を出す」を推奨した。前提(7/3の同梱物の開始、自分宛ての別住所の割合)が変わったら、推奨はCに変わる(反証条件に記録)
  • 要件を「〜すること」の名詞止めではなく動詞の文にする案 — 日本語の要件は名詞止め(〜すること)が慣行だが、主語がなく、システムか業務か分からなくなる。今回は業務の動詞(入れない・判断させない)で書いた。ただし社内の書式が「〜すること」なら、それに合わせる
扱わなかった範囲
  • 非機能要件(性能・可用性・運用時間)。BR-08のような性能はGoodの罠として見せただけで、Best では次回以降の非機能要件定義書(IT-要求・設計#3)に回した
  • 要求の優先順位づけの手法(MoSCoW以外。Kano、WSJF など)。今日は Must/Should の意味と、根拠の列の有無にとどめた
  • 要件のトレーサビリティ(要件から設計・試験までの追跡表)。大規模案件向けで、今回の9本の同梱物には過剰とした
  • 個人情報保護法の観点(住所を判定に使うこと)。社内の目的の範囲として扱い、法的な確認はしていない
  • 「自分宛ての別住所」の判定方法(過去の注文との照合)の詳細。設計で決めるものとして扱った
数字と概念の出所
  • 本文の会社・人物・日付・金額はすべて架空の設定。〔実測〕はシナリオ内の実績値(4月の誤投入に関する問い合わせ9件、4月出荷252,000箱=9,000箱×28日、初回購入11%=27,720件、別住所・包装なし2.6%)、〔導出〕は計算値、〔仮定〕は置いた値(同梱物9本、印字変更3人日・約2週間、自分宛ての別住所の割合約3割、現状の稼働までの約10営業日、60分版の返品件数)
  • 計算は作成時に Python で行った〔導出〕: 初回購入 9,000×11%×28=27,720件。別住所・包装なし 27,720×2.6%=720.7件(約720)。問い合わせ 9件÷720.7=1.2%、連絡の陰の人数 約710。1日の対象 現行定義 9,000×11%×(1−4%)=950.4箱、案B 950.4−25.7=約925箱(−約26)。見逃しの最大 720×30%=約216(約220)。年換算 720.7×12=8,648(約8,650)。9本×3人日=27人日
  • 日付の曜日(2028/4/3月・4/30日・5/10水・5/22月・5/26金・5/30火・5/31水・6/5月・6/12月・7/3月)は作成時に計算して確認した
  • 要求の層(ビジネス要求・ステークホルダー要求・ソリューション要求・移行要求): BABOK Guide の分類。解説記事 https://modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/2033/Explain-how-BABOK-categorizes-requirements.aspx 、https://businessanalyst.techcanvass.com/types-of-requirements-as-per-babok/ (2026-10-02に検索結果の要約で確認。BABOK の本文は未読)
  • 要求の性質(必要・適切・曖昧でない・完全・単一・実現可能・検証可能・正確・準拠): ISO/IEC/IEEE 29148:2018。解説 https://www.modernrequirements.com/blogs/iso-29148-explained/ 、https://www.cwnp.com/req-eng/ (2026-10-02に検索結果の要約で確認。規格本文は有料で未読。「適切=実装の細部を含まない」は要約による)
  • "shall / should / may" の強さ: RFC 2119 と ISO 29148 の慣行(記憶による記述。出典のページは今回確認していない)
  • MoSCoW法(Must / Should / Could / Won't)は一般的な優先度づけの手法として使った。出典のページは確認していない(記憶による)。bill-to / ship-to の語彙も一般的な受発注用語として使い、出典は確認していない
  • 分量(行数)は、各コードブロックの行数を作成後にスクリプトで数えた実測値

自己評価(やった後に記入)