このユニットの結論
「速く」「止まらず」「安全に」は、願いであって要件ではありません。
非機能要件は、何を・どんな条件で・どの値まで・どう測って確かめるか、の 4 つがそろって初めて要件になります。数値にできない非機能要件は、作る側も確かめる側も守りようがありません。
1. 何の話か
このユニットは、非機能要件を、確かめられる数値に落とす話です。
06-01 非機能要件とは何か では、機能以外の要件（性能、可用性、安全、運用のしやすさ など）の種類を学びます。ここでは、それらを「要件一覧に書ける形」にする手順を扱います。非機能要件は、機能要件より数値にしにくく、だからこそ数値にする努力が要ります。
2. なぜ必要か
非機能要件が言葉のままだと、
- 開発側は「速く」の意味を自分で決めて作り、業務部門は別の意味で期待している
- テストで「速い・遅い」を判定する基準がなく、合否が決められない
- 稼働後に「遅い」と言われても、要件を満たしているかどうかを示せない
ということが起きます。非機能要件は、契約の水準（02-07 サービス水準を契約にどう書くか）と、稼働後の品質の目標（14-03 サービス品質を数値で管理する）の両方の出発点です。
3. このユニットで分かること
- 非機能要件を数値にする 4 つの要素
- 種類ごとの数値の置き方
- 数値にしにくいものをどう扱うか
4. 4 つの要素
| 要素 | 問い | 悪い例（一般的な例） | 良い例（一般的な例） |
|---|---|---|---|
| 何を | どの機能・どの場面か | 「システムの応答」 | 請求の検索画面の表示 |
| どんな条件で | 利用者数、データ量、時間帯 | 条件なし | 同時に 200 人が使い、請求データが 500 万件ある状態で |
| どの値まで | 目標の値と、値の位置（平均か、ほとんどの場合か） | 「速く」 | 100 回のうち 95 回は 3 秒以内 |
| どう測って確かめるか | 測る方法と、確かめる場 | 書かれていない | 本番相当のデータ量の性能試験で、画面の表示までの時間を測る |
「どんな条件で」が抜けると、少ないデータで速くても要件を満たしたことになります。「どう測るか」が抜けると、合否が決められません。
5. 種類ごとの置き方
| 種類 | 数値の置き方（一般的な例） | 注意 |
|---|---|---|
| 性能 | 操作ごとの応答時間（ほとんどの場合の値）、処理の終了時刻、同時利用者数 | 平均ではなく「100 回のうち 95 回」のような位置で書く |
| 可用性 | 業務時間帯の稼働率、止まってよい時間、復旧までの時間 | 計画停止を含めるかを決める |
| データの保全 | 失ってよいデータの時間幅、保管する世代と期間 | 業務の都合から決める |
| 安全 | 権限の最小化、記録の項目と保存期間、暗号化の対象 | 「安全に」ではなく、守る対象と手段を書く |
| 運用のしやすさ | 監視で検知できる異常の種類、手順書の有無、作業の自動化の範囲 | 「運用しやすく」ではなく、運用の作業を列挙して書く |
| 拡張性 | 利用者やデータが何倍になるまで、構成を変えずに持つか | 期間と伸び率を置く |
数値にしにくいもの（使いやすさ、保守のしやすさ）は、確かめる方法で代える手があります。「新しい担当者が手順書だけで月次処理を実行できる」「主要な画面の操作を、初めての利用者が説明なしで 5 分以内に終えられる」のように、試験の形で書きます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の非機能要件に関する記載
- 約1,500件の要件、約36本のシステム連携、10年分のデータ移行
- 成果物に REQ-003 非機能要件一覧、OPS-007 サービス品質目標一覧 がある
- P-008 黒田 健 — システムアーキテクト、P-010 宮田 直人 — テスト・品質管理リーダー、P-011 山下 恵 — 本番移行・運用リーダー
約1,500件の要件のうち非機能要件が何件で、どんな数値が置かれ、どう確かめられたかは、正本に記録がありません。記録なし 上の表の数値は教材上の例であり、アステリア案件のものではありません。
6. THINK — 「十分な性能を確保すること」
非機能要件の一覧に、次の 1 行がありました。
「システムは、業務に支障のない十分な性能を確保すること。」
問題
この要件を、このまま確定してよいでしょうか。
判断例を開く
判断
4 つの要素のどれも書かれていません。確定すると、合否を誰も判定できない要件が残ります。
確認すること:
- どの操作・どの処理の性能か（何を）
- 利用者数とデータ量をどう置くか（どんな条件で）。業務のカレンダーの山を見込んでいるか
- 目標の値と、その位置（平均か、ほとんどの場合か）
- どの試験で、どう測って確かめるか
- 目標を満たせないと分かったとき、誰が判断するか
「十分な」という言葉が出てきたら、数値に直すか、確かめる方法に直すかのどちらかをしてから確定します。
7. よくある失敗
- 非機能要件を「速く・止まらず・安全に」の 3 行で済ませる
- 平均の応答時間だけを書き、遅い場合が隠れる
- 条件（利用者数・データ量）を書かず、少ないデータの試験で合格にする
- 数値にしにくい要件を書かずに落とし、稼働後に「使いにくい」と言われる
8. 成果物との接続
- REQ-003 非機能要件一覧：4 つの要素を欄として持たせ、空欄のまま確定させない
- OPS-007 サービス品質目標一覧：確定した非機能要件のうち、稼働後に測り続けるものを目標として引き継ぐ
非機能要件は、テストの計画（何をどう確かめるか）と運用の目標（何を測り続けるか）の両方に流れていきます。
9. AI WORKFLOW — 4 つの要素の抜けを点検させる
AIは、非機能要件の一覧を 4 つの要素に分け、抜けている要素を見つける下書きに役立ちます。
指示例:
「次の非機能要件の一覧について、要件ごとに『何を』『どんな条件で』『どの値まで』『どう測って確かめるか』の 4 つに分けて表にしてください。書かれていない要素は空欄のまま示し、値や条件を推定して埋めたり、妥当性を評価したりしないでください。」
10. REVIEW — AIの表を確認する
- AIが「書かれている」とした要素が、要件の文に本当にあるか
- 空欄の要素について、業務部門と開発側のどちらが埋めるべきかを人が決めたか
- 要件一覧を AI に渡してよいか（業務情報の扱い）を事前に確かめたか
11. 人間が判断すること
- 目標の値と、その根拠（業務の影響と費用）
- 条件（利用者数・データ量）をどこに置くか
- 数値にしにくい要件を、確かめる方法で代えるか、落とすか
要件確定は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
「月次の締め処理が遅れないこと」という非機能要件を、4 つの要素（何を・どんな条件で・どの値まで・どう測って確かめるか）で書き直してください。
そのうえで、「条件」を書き忘れた場合に、試験で起きうる見落としを 1 つ書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
願いを要件にする。何を・どんな条件で・どの値まで・どう測って確かめるか。数値にしにくいものは、確かめる方法で書く。