このユニットの結論
要件には、「業務として何ができなければならないか」（業務要件）と、「そのためにシステムが何をしなければならないか」（システム要件）の2つの層があります。
まず業務要件を決め、そこからシステム要件を導き、両者のつながりを残すことで、「システムは要件どおりなのに、業務で使えない」ことを防ぎます。
1. 何の話か
このユニットは、要件の2つの層の話です。
04-01 要望と要件は何が違うのか では、利用者の要望を、確かめられる要件に直すことを学びました。このユニットでは、その要件を「業務の言葉」と「システムの言葉」の2つの層に分けて考えます。
2. なぜ必要か
2つの層を分けないと、
- いきなり画面や機能の話から始まり、業務として本当に必要なことが抜ける
- システム要件だけが一覧に並び、なぜその機能が必要なのかが分からなくなる
- 業務のやり方が変わったとき、どのシステム要件を見直せばよいか分からない
- テストで「機能は動く」ことしか確かめず、業務として使えるかを確かめない
ということが起きます。
3. このユニットで分かること
- 業務要件とシステム要件の違い
- 業務要件からシステム要件を導く流れ
- 2つの層をつなげて管理する理由
- 要件の整理で、AIに任せてよいことと人間が決めること
4. 2つの層の違い
| 業務要件 | システム要件 | |
|---|---|---|
| 主語 | 業務（人・部門） | システム |
| 例（教材上の例） | 「案件の担当者は、案件ごとの採算を、月の途中でも確かめられる」 | 「システムは、案件ごとに、登録された原価と売上の見込みを集計し、一覧に表示する」 |
| 決める人 | 業務の責任者 | 業務の責任者と、システムの設計の担当 |
| 確かめ方 | 業務の流れの中で、利用部門が確かめる | 機能ごとのテストで確かめる |
1つの業務要件から、複数のシステム要件が生まれることがよくあります。逆に、業務要件につながらないシステム要件があれば、なぜ必要かを確かめます。
5. 業務要件からシステム要件を導く流れ
一般的には、次の順に進めます。
- 業務の流れ（誰が、いつ、何をするか）を図にする（REQ-001 業務フロー図）
- 流れの中で、業務として何ができなければならないかを書く（業務要件）
- 業務要件ごとに、システムが何をすればよいかを書く（システム要件）
- システム要件に番号を付け、業務要件とのつながりを残す（04-04・REQ-004）
- システムで対応しない業務要件（手作業で行う、など）も、そう決めたことを残す
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 約1,500件の要件
- 業務の担当として、P-005 藤本 遥（経理業務リーダー）、P-006 川村 美咲（プロジェクト管理業務リーダー）、P-007 松本 健太（営業・契約業務リーダー）がいる
- 成果物に REQ-001 業務フロー図、REQ-002 要件一覧、REQ-004 要件追跡表がある
約1,500件のうち、業務要件とシステム要件がそれぞれ何件か、どう分けて管理しているかは、正本に記載がありません。未確定 上の例は教材上の例で、アステリア案件の要件ではありません。
6. THINK — 画面の一覧から始まった要件
（教材上の例）要件定義の最初の打ち合わせで、担当者が、今のシステムの画面の一覧を配り、「この画面をすべて新しいシステムにも作ってください。それが要件です」と言いました。
問題
この進め方で、要件を決めてよいでしょうか。
判断例を開く
判断
画面の一覧から始めるのは危険です。
確認すること:
- それぞれの画面は、業務のどの場面で、何のために使われているか
- 今の画面では困っていること、手作業で補っていることはないか
- 業務のやり方を変える予定はないか（変えるなら、今の画面は要らないかもしれない）
- 画面の一覧に出てこない業務（紙や表計算で行っている業務）はないか
今のシステムの画面は、今の業務のやり方の結果です。業務として何が必要かから考え直すと、要らない画面や、足りない機能が見えてきます。
7. よくある失敗
- システムの機能の一覧だけを作り、業務要件を書かない
- 業務要件とシステム要件のつながりを残さない
- システムで対応しない業務要件を、一覧から消してしまう（誰が手作業で行うのかが分からなくなる）
- 業務の担当が確かめないまま、システム要件を確定する
8. 成果物との接続
- REQ-001 業務フロー図：業務の流れを図にし、業務要件の出どころにする
- REQ-002 要件一覧：業務要件とシステム要件を、番号を付けて管理する
- REQ-004 要件追跡表：業務要件からシステム要件、設計、テストまでのつながりを残す
9. AI WORKFLOW — 業務要件からシステム要件の候補を出させる
AIは、業務要件からシステム要件の候補を洗い出す下書きに役立ちます。
指示例:
「次の業務要件ごとに、システムに求められることの候補を挙げてください。候補ごとに、どの業務要件から出たものかを示し、業務の担当に確かめるべき点を添えてください。候補を確定したものとして書かないでください。」
10. REVIEW — AIの候補を確認する
- 候補が、業務要件から本当に導けるものか（一般論で足されていないか）
- 業務要件につながらない候補が混ざっていないか
- 業務の担当が、候補を確かめたか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 要件の階層と、現状と将来の差分
階層は 2 つより多い
業務要件とシステム要件の 2 層は入口です。世界で共有されている整理では、おおむね 4 つの階層に分けます。
- 事業の要求：投資で実現したい状態（01-02）
- 利害関係者の要求：部門や役割ごとに、業務で何ができる必要があるか
- 業務要件：業務の流れの中で、何ができなければならないか
- システム要件：そのためにシステムが何をするか
上の層から下の層へ導き、下の層のすべてが上の層のどれかにつながっている状態を保ちます。つながりのないシステム要件は、誰かの思い込みか、昔の画面の名残です。
現状と将来を分けて描く
業務の流れは、今の流れ（現状）と、新システムで変える流れ（将来）を分けて描きます。2 つの差分が、業務要件の出どころになります。この差分を見つける作業をギャップ分析と呼びます。現状だけを描いて要件にすると、今の不便をそのまま作り直します。将来だけを描くと、今の業務で暗黙に行われていることが抜けます。
「システムで対応しない」も要件
将来の流れの中には、システムが担わない作業（人が判断する、紙で残す、別の仕組みで行う）があります。これも業務要件として一覧に残し、「システム対象外、担当は誰」と書きます。残さないと、稼働後に「誰もやっていない作業」が見つかります。
測り方の例
- 上の層につながらないシステム要件の数
- 将来の流れのうち、現状と差分がある箇所の数と、それに対応する業務要件の数
- 「システム対象外」とした業務要件の数と、担当が決まっている数
現場で確かめる問い
- 要件の階層は、何層で管理しているか。層をまたぐつながりは残っているか
- 業務の流れは、現状と将来を分けて描いているか。差分はどこか
- 上の層につながらないシステム要件を、数えたことがあるか
- 「システムで対応しない」業務要件は、一覧に残っているか。担当は決まっているか
アステリア案件の要件の階層の数、現状と将来の流れの図の有無、システム対象外の業務要件の扱いは、正本に記録がありません。記録なし
11. 人間が判断すること
- 業務として何が必要か（業務要件）
- どの業務要件を、システムで対応し、どれを手作業で行うか
- システム要件を確定すること
要件確定は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
「営業の担当者は、契約を登録した当日に、案件の準備を始められる」という業務要件があります。
この業務要件を確かめるために、業務の担当に聞いておきたいことを3つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
要件は、業務要件（業務として何が必要か）からシステム要件（システムが何をするか）へと導き、つながりを残します。
画面や機能の一覧から始めず、業務から始めます。