非機能要件の定義

• 日程: Day 2 / セッション 6
• 時間: [13:30-14:15]
• 形式: 演習
• ゴール: 自分の開発テーマについて、性能・可用性・セキュリティ等の観点から非機能要件を5項目以上定義し、各項目にペルソナ視点の根拠を添えた「非機能要件一覧書」を作成できる
• 学習形式: AIブレスト

前のセッションで、開発工程の地図に1つ空白が残りました。非機能要件です。機能一覧（何をするか）はできましたが、「どの程度うまくやるか」はまだ白紙です。

ここで質問です。

あなたのペルソナにとって「遅い」とは、何秒からでしょうか？

「速いほうがいい」では要件になりません。3秒なのか、30秒なのか。数字が決まらないと、Day 4 で実装したとき「これで合格なのか」を誰も判定できません。

答えのヒントは、いつもの場所にあります。ペルソナです。通勤電車の中で乗り換えまでの2分で家計簿をつける人にとって、10秒の待ち時間は「使うのをやめる理由」になります。一方、月に1回じっくりレポートを眺める場面なら、10秒待てるかもしれません。

このセッションでは、非機能要件を「ペルソナ視点で数字にする」練習をします。観点の抜け漏れはAIブレストで確認し、成果物として「非機能要件一覧書」を完成させます。

非機能要件とは、システムが「どの程度うまくやるか」の要件でした。ここで大事なのは、形容詞を数字に変えることです。

• 「速く表示される」→ 該当しません。速いの基準が人によって違い、検証できないからです
• 「支出入力は3秒以内に完了する」→ 該当します。作った後に測って合否を判定できます

「速い」「安全」「安定」といった形容詞のままの要件は、こうもり問題と同じです。読む人によって獣にも鳥にもなります。数字にする——つまり形式知にすることで、初めてチーム（あなたとAI）の共通の約束になります。

では、その数字はどこから来るのでしょうか。健康診断に例えると、非機能要件は「血圧130以下」のような基準値です。基準値は気分で決めるのではなく、「その人がどんな生活を送るか」から導かれます。システムの基準値も同じで、ペルソナの生活場面から導きます。

• ペルソナは「いつ・どこで・どんな状況で」使うか → 性能・可用性の数字が決まる
• ペルソナは「何を失うと致命的か」 → セキュリティ・バックアップの水準が決まる

家計簿システム（ペルソナ: 節約したい20代会社員。通勤電車で入力、月末にレポート確認）の非機能要件一覧の例です。この形式をそのまま成果物のテンプレートにしてください。

注目してほしいのは3列目です。すべての根拠が「ペルソナの生活」で書かれています。「サーバの性能上」のようなシステム都合の根拠は1つもありません。

• 形容詞（速い・安全）を数字・条件（3秒以内・第2認証必須）に変換する
• 根拠は必ずペルソナ視点で書く。「なぜ3秒か」に答えられない要件は要件ではない
• 機能によって基準は変わってよい（入力は3秒、レポートは5秒）。一律にしない

Webの世界には「3秒ルール」があります。表示に3秒以上かかると多くの利用者が離脱する、という経験則です。Amazonは「表示が0.1秒遅くなると売上が1%落ちる」と報告し、Googleは検索結果の表示を0.5秒遅らせる実験で検索利用が明確に減ることを確認しました。0.1秒——まばたきの半分以下の時間が、巨大企業の売上を左右します。人間は「遅い」を論理ではなく生理で判定しているのです。だからこそ非機能要件は「ペルソナの体感」から決める必要があります。

「性能は考えたけど、バックアップは思いつかなかった」——非機能要件の失敗は、たいてい観点の抜け漏れで起きます。そこで先人が作った観点の地図を使いましょう。IPA（情報処理推進機構）の「非機能要求グレード」は、非機能要件を6つの大項目に整理しています。

6つ全部に要件を書く必要はありません。地図の使い方は「全項目を一度は眺めて、書かない理由を言えるようにする」ことです。「移行性は今回対象外。理由は研修内のプロトタイプだから」——これも立派な判断です。抜け漏れ（考え忘れ）と、意図的な対象外は違います。

観点チェックの進め方を図にすると、次の流れになります。

Day 1 から使っているPDCA（発散→収束→見直し）と同じ形です。

• 6大項目は「全部書く」ためではなく「考え忘れを見つける」ための地図
• 「対象外」と決めるのも要件定義。理由を一文添えれば判断の記録になる
• 迷ったら「この観点が最悪の形で裏切られたら、ペルソナはどうなる？」と自問する

非機能要件の欠落は、歴史的な障害の常連です。2020年10月、東京証券取引所は終日売買停止という異例の事態に陥りました。原因は共有ディスク装置の故障そのものではなく、故障時にバックアップ機へ自動で切り替わる設定が意図どおりに働かなかったこと。つまり「機能」は揃っていたのに、「止まったらどうするか」という可用性の設計が現実と食い違っていたのです。復旧手順も「再起動すると当日の取引データに影響が出る」ため実行できませんでした。何をするかより、どの程度うまくやるかが市場全体を止めた一日でした。

このあとの演習では、AIを「観点出しのパートナー」として使います。コツは、ペルソナと開発テーマをプロンプトに必ず含めることです。含めないと、教科書どおりの一般論しか返ってきません。

そのまま使えるプロンプト例を3段階で示します。

発散（観点出し）:

家計簿システムの非機能要件を、性能・可用性・セキュリティの観点で
ブレストしてください。ペルソナは「節約したい20代会社員。通勤電車で
支出を入力し、月末にレポートを見る」です。ペルソナの生活場面に
結びつけて、各観点3個ずつ挙げてください。

抜け漏れチェック（収束）:

私が定義した非機能要件は以下です。
（ここに自分の一覧を貼る）
IPA非機能要求グレードの6大項目（可用性、性能・拡張性、運用・保守性、
移行性、セキュリティ、システム環境・エコロジー）と照らして、
考え忘れている観点を指摘してください。

定量化（数字を詰める）:

「レポート表示が速いこと」という要件を検証可能にしたいです。
このペルソナの利用場面を想像して、妥当な秒数の候補と、
その秒数にする理由を提案してください。私が最終決定します。

最後の一文に注目してください。数字を決めるのはAIではなく、ペルソナを一番よく知るあなたです。

悪いプロンプトと良いプロンプトの対比です。

• 「非機能要件を教えて」→ 該当しません。テーマもペルソナもなく、誰にでも当てはまる一般論が返るだけです
• 「上記のペルソナにとって『遅い』とは何秒からか、利用場面ごとに意見をください」→ 該当します。ペルソナの生活場面に立った、検証可能な答えを引き出せます

• プロンプトには「開発テーマ＋ペルソナ＋観点」の3点セットを必ず入れる
• AIの提案は候補。採用・修正・却下の判断根拠はペルソナ視点で自分が持つ
• AIの答えに「なぜ？」と聞き返すと、根拠の列が埋まっていく

「AIに要件を決めてもらえば楽では？」と思うかもしれません。しかしAIはあなたのペルソナに会ったことがありません。Day 1 で市場調査をし、プロフィールを書き、こうもり問題を考えたあなたのほうが、ペルソナについては世界一の専門家です。AIブレストとは、世界一の専門家（あなた）が、博識な壁打ち相手（AI）を使う構図なのです。

• 「私の開発テーマ〇〇のペルソナは△△です。このペルソナが『もう使わない』と感じる瞬間を、非機能の観点で5つ想像してください」
• 「『データが消えない』を検証可能な非機能要件に書き直す例を3パターンください」
• 「私の非機能要件一覧を貼ります。ペルソナになりきって、一番不満な項目とその理由を教えてください」

1. 自分の開発テーマとペルソナをAIに伝え、非機能要件をブレストする（発散）
2. IPA非機能要求グレードの6大項目と照合し、抜け漏れを確認する（収束）。対象外とする観点には理由を一文書く
3. 各要件を「数字または検証可能な条件」に定量化する。根拠は必ずペルソナ視点で書く
4. 本編1の家計簿の表と同じ形式（No.／観点／非機能要件／ペルソナ視点の根拠）で「非機能要件一覧書」に清書する

• 非機能要件一覧書（5項目以上。各項目に観点・検証可能な要件・ペルソナ視点の根拠を含むこと）

• まず自分で3項目書いてから、AIブレストで広げましょう。先にAIに聞くと、自分の頭で考える練習になりません
• 「〜が速い」「〜が安全」と書いたら赤信号。「何秒？」「何をどう守る？」と自分に突っ込みましょう
• 数字に自信がなくて構いません。「暫定3秒（Day 4 の実装後に見直す）」と書けば、PDCAの1周目としては十分です
• 根拠の列が「サーバが」「技術的に」で始まったら書き直し。「ペルソナは〜だから」で始めましょう
• 5項目がすぐ埋まった人は、AIに「この一覧の中で矛盾する項目や、コストが高すぎる項目はどれ？」と聞いてみましょう。要件同士のトレードオフが見えてきます

今回学んだことを一言でまとめると「非機能要件とは、ペルソナの体感を検証可能な数字に翻訳したものだ」です。

• 形容詞（速い・安全）を数字・条件に変換し、根拠をペルソナ視点で書いた
• IPA非機能要求グレードの6大項目で抜け漏れを点検した
• AIブレストで発散し、判断は自分が持つという役割分担を実践した

これで開発工程の「要件」がひととおり揃いました。機能要件（機能一覧）と非機能要件（非機能要件一覧書）の両輪です。

次のセッションからは、要件を「利用者の目に見える形」にする話——ユーザインタフェースに進みます。「支出入力は3秒以内」と決めた今、その3秒を実現する画面はどんな形であるべきか。休憩のあとで考えていきましょう。

• 「表示が速いこと」を、自分のペルソナ向けの検証可能な非機能要件に言い直せますか？
• IPA非機能要求グレードの6大項目のうち4つ以上を、問いかけの形で言えますか？
• 自分の非機能要件一覧書の中で、根拠が一番強い項目はどれですか？　その根拠を一文で言えますか？

• 参考リンク: IPA「非機能要求グレード」（本体・活用シート・解説書が無償公開されている）
• 発展課題: 自分の非機能要件一覧書の各項目に「もしこの要件を外したら、ペルソナに何が起きるか」を一文ずつ追記してみましょう。根拠がさらに強くなり、Day 4 でのテスト観点にもなります