前回の機能要件と対になる「品質」
前回のM-05では、システムが何をできるかを入力・条件・結果の3点で書く機能要件を学びました。今回はその対になる、どの品質で動くかを決める非機能要件です。機能要件が「できること」を並べるのに対し、非機能要件は速度や安全性といった、できて当たり前とされる裏側の条件を扱います。この2つが揃って、はじめて要件定義は実装に渡せる形になります。
このスライドのポイント
- 前回M-05: システムが何をできるかを「入力・条件・結果」で書く機能要件
- 今回M-06: どの品質で動くかを決める非機能要件（機能要件の対）
- 機能要件＝できること／非機能要件＝できて当たり前の裏側の条件
- 2つが揃って要件定義は実装へ渡せる形になる
非機能要件の定義と代表6観点
非機能要件とは、何をできるかではなく、どの品質で動くかを定める要件です。代表的なのは6つの観点です。速度は応答が何秒以内か、可用性は止まってよい時間、セキュリティはA-08で決めた権限と公開範囲、容量はデータ量と利用者数の想定、保守性は後から変更しやすいか、利用環境は使う端末や回線です。そして最も大切な書き方の原則が、測れる形で書くことです。「速く」ではなく「3秒以内」と、誰が測っても同じ判定になる数値で書きます。
このスライドのポイント
- 非機能要件＝何をできるかではなく「どの品質で動くか」の要件
- 代表6観点: 速度／可用性／セキュリティ／容量／保守性／利用環境
- セキュリティはA-08で決めた権限・公開範囲が土台
- 書き方の原則: 測れる形で書く（「速く」ではなく「3秒以内」）
なぜ必要か——決めないと使われないアプリになる
非機能要件を決めないと、機能は全部あるのに「遅い・落ちる・危ない」という理由で使われないアプリになります。特に注意したいのは、AIは非機能要件を指定されないと考慮しないことです。A-08で、権限を指定しないとAIは最も緩い設定で作りがちだと学びました。非機能要件も同じで、応答時間や同時利用者数を伝えなければ、AIはそれらを気にかけずにコードを生成します。品質は、人間が数値で先に渡す仕事です。
このスライドのポイント
- 決めないと「遅い・落ちる・危ない」で、機能があっても使われない
- AIは非機能要件を指定されないと考慮しない
- A-08の「指定なしは最も緩い設定」の要件版
- 品質は人間が数値で先に渡す仕事
構造——悪い書き方と測れる書き方
6観点は、悪い書き方と測れる書き方を並べると違いがはっきりします。表のように、「速い」は「一覧表示は3秒以内」、「安全に」は「社内のみ公開・5回失敗でロック」へ直します。左の欄はどれも、人によって判定が変わる言葉です。業務アプリで最低限おさえたいのは、速度・セキュリティ・利用環境の3つです。この3つが崩れると、現場ではまず使ってもらえません。
このスライドのポイント
- 6観点は「悪い書き方」と「測れる書き方」を並べると違いが明確
- 業務アプリで最低限おさえる3観点: 速度・セキュリティ・利用環境
経費精算アプリでの具体例
経費精算アプリで具体化してみましょう。非機能要件はこう書けます。一覧表示は3秒以内、月末の同時利用は50人まで、公開範囲は社内のみ、端末はスマホ対応。ここで大事なのは、どれも数字や具体的な範囲が入っていることです。数字が入ると、この要件は後の設計、たとえばデータ件数の見積もりや画面の作り方へそのまま翻訳できます。「速く・安全に」のままでは、設計者もAIも動けません。
このスライドのポイント
- 経費精算アプリの非機能要件例: 一覧表示3秒以内／月末の同時利用50人／社内のみ公開／スマホ対応
- どれも数字か具体的な範囲が入っている
- 数字が入ると後の設計（件数の見積もり・画面の作り方）へ翻訳できる
技術サンプル——6観点の記入表
サンプルは、6観点をそのまま埋める記入表です。種別は表で、目的は経費精算アプリの非機能要件を漏れなく数値で書き出すことです。表の各行が1観点で、記入例の欄には必ず数字か具体的な範囲を入れます。読み方の要点は、測れない表現が残っていないか、業務アプリの必須3観点が埋まっているかの2点です。AIへの質問例は「このアプリの非機能要件を6観点で提案してください。測れない表現があれば数値に直してください」です。
このスライドのポイント
- 種別: table
- 目的: 経費精算アプリの非機能要件を、漏れなく測れる形で書き出す
- サンプル本体（各行が1観点、記入例は数値か具体的な範囲を入れる）:
混同しやすい——機能要件と非機能要件
混同しやすいのが、機能要件と非機能要件です。機能要件はできること、非機能要件はその品質です。たとえば「ログインできる」は機能要件ですが、「ログインは2秒以内で、5回失敗するとロックする」には非機能の条件が混ざっています。1つの文に両方が入っていたら、できることと品質を分けて書き直します。分けておくと、後から品質だけを見直せます。
このスライドのポイント
- 機能要件＝できること／非機能要件＝その品質
- 「ログインできる」は機能要件
- 「ログインは2秒以内・5回失敗でロック」には非機能が混ざる
- 1文に両方が入っていたら分けて書き直す
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIへの開発依頼には、想定件数・同時利用者数・応答時間の目標を必ず含めてください。これはA-07で学んだ制約を、非機能の言葉で具体化したものです。これらを後出しすると、作り直しになる代表格です。質問例として「この依頼に非機能要件が不足していれば、作業前に指摘してください」と一言添えると、抜けを早い段階で塞げます。
このスライドのポイント
- AIへの開発依頼に「想定件数・同時利用者数・応答時間の目標」を必ず含める
- A-07で学んだ制約を、非機能の言葉で具体化したもの
- 後出しすると作り直しになる代表格
- 質問例:「この依頼に非機能要件が不足していれば、作業前に指摘してください」
一問一答とまとめ
最後に一問一答です。「速くしてほしい」を、そのまま要件にできるでしょうか。少し考えてみてください。答えは、できません。測れる形に直して、はじめて要件になります。たとえば「一覧表示は3秒以内」です。30秒まとめです。非機能要件は、どの品質で動くかを6観点で、必ず測れる形で書く。これが今日の芯です。次回は、作るものを最小で検証するMVPへ進みます。関連資料は「AIアプリ要件定義シート」と「AIアプリの品質評価シート」です。
このスライドのポイント
- 一問一答:「『速くしてほしい』を要件にするには？」→ 測れる形にする（例: 一覧表示は3秒以内）
- 30秒まとめ: 非機能要件は「どの品質で動くか」を6観点で、必ず測れる形で書く
- 次回: 最小で検証するMVPへ
- 関連資料:「AIアプリ要件定義シート」「AIアプリの品質評価シート」
