要件定義学習記事全11節Design
「動けばよい」ではなく、どこまで守るかを先に決める
この記事で身につくこと安全性・速度・使いやすさの品質条件を、利用状況・失敗の影響に結びつけて具体化し、条件同士がぶつかる場合の優先順位を判断できる。
記事内目次（24項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。「正しく動く」だけでなく「どこまで安全か」「どのくらい速いか」「どのくらい使いやすいか」を、機能を作る前に条件として決める話です。
なぜ必要か。これらを決めずに作ると、「思ったより遅い」「権限の確認が甘い」「操作が分かりにくい」といった不満が、完成してから初めて分かります。数値や基準を先に決めておけば、完成後に何を基準に確かめればよいかが分かります。
この記事を読むとできるようになること。
- 安全性・速度・使いやすさの条件を、利用状況に結びつけて具体的に書ける
- 条件ごとに確認方法を決められる
- 条件同士がぶつかる場合に、どちらを優先するかを理由とともに判断できる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「品質条件とは何か」と「一覧の形」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（条件同士の衝突、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、02-02で決めた「最初に作る5つの機能」（依頼の作成・提出・承認・差戻し・一覧閲覧）について、「どこまで安全に」「どのくらい速く」「どのくらい使いやすく」動くべきかを条件として書き出すことです。
機能一覧（02-02）は「何をするか」を決めましたが、「どう振る舞うべきか」はまだ決まっていません。たとえば「承認」という機能は決まっていても、「割当外の人が承認しようとしたら即座に拒否される」のか「しばらく待たされてから拒否される」のかは、品質条件を決めるまで分かりません。
この記事を読み終えると、次のものが手元にできます。
- 安全性・速度・使いやすさの3分類に分けた品質条件一覧
- 各条件の根拠となる利用状況と、確認方法
- 条件同士がぶつかる場合の優先順位とその理由
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
品質条件（非機能要件）
一言でいうと、「何をするか」ではなく「どのように振る舞うべきか」を決めた条件です。
たとえば、「割当外の承認者は承認できない」は機能（02-02）の話ですが、「割当外の承認者が操作しても、画面が固まらずすぐに拒否と分かる」は品質条件の話です。
これがないと、機能が正しく動いても、「遅すぎる」「間違って操作できてしまいそうで不安」といった不満が、完成後にしか分かりません。
システム開発では、これを品質条件・非機能要件（non-functional requirement）と呼びます。「機能要件」（何をするか）と対になる言葉です。
優先度
一言でいうと、条件同士がぶつかったときに、どちらを優先するかを先に決めておく順位です。
たとえば、「操作のたびに権限を厳密に確認する」（安全性）と「ボタンを1回押すだけで済ませたい」（使いやすさ）は、両立が難しいことがあります。
これがないと、作る人がその場の判断で決めることになり、あとから「なぜそうしたのか」を説明できません。
読む順路：品質条件のもとになる機能一覧は02-02が該当します。品質条件を踏まえた技術選定は03-03、テストでの確認観点は09-03が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：なぜ数値や基準を先に決めるのか
3.1 「後で調整すればいい」の危険
品質条件を決めずに機能だけ作ると、次のことが起きます。
- 「遅い」と言われても、何秒なら十分なのかの基準がなく、直すべきかどうか判断できない
- 「使いにくい」という感想が、具体的にどの操作のどの部分を指すのか分からない
- 「もっと安全にしてほしい」と言われても、今の確認がどこまで甘いのかを説明できない
品質条件を先に決めることは、「後から直せなくする」ためではなく、「何を基準に確かめるか」を先に決めるためです。
3.2 よくある誤解
「安全性は高ければ高いほどよい」。確認を増やすほど、操作の手間や表示の待ち時間が増えます。小規模な社内アプリという前提で、どこまでの安全性が必要かを利用状況から決めます。
「速さは数値がなくても『普通』で伝わる」。「普通」の基準は人によって違います。架空の利用状況（利用者数、依頼件数の目安）を仮定として明記し、その仮定に対する目安を書きます。
「使いやすさは見た目の話だから後回しでよい」。「一覧が空のときに何も表示されない」「権限がないボタンが押せてしまい、押した後にエラーが出る」といった問題は、見た目ではなく設計の問題です。02-02の機能一覧の時点で条件を決めておく方が手戻りが少なくなります。
「AIに品質条件を考えさせれば十分」。AIは条件の候補や一般的な目安を提示できますが、「この業務でどこまでの安全性・速度・使いやすさが必要か」は、業務に責任を持つ人が判断します（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
02-02の機能一覧（最初に作る5機能）について、次を確認します。
| 確認すること | 確認前に仮置きしてよいか | この記事での扱い |
|---|---|---|
| 承認・差戻しの権限確認をどこまで厳密にするか | 不可（記事A REQ-003に直結） | 安全性の条件として明記（第5.2節） |
| 一覧・承認操作の速さの目安 | 可（仮置き：架空の利用規模を仮定） | 速度の条件として明記。数値は架空の仮定と表示 |
| 操作しやすさ（空の一覧、権限のない操作の見え方） | 可（仮置き：基本方針を決めて後で調整） | 使いやすさの条件として明記 |
| 二重操作（同じ承認を2回押す等）への対応 | 不可（記事A REQ-006に直結） | 安全性の条件として明記（第5.2節） |
4.2 勝手に決めてはいけないこと
- 安全性の基準（権限確認の厳密さ）は、業務が許容できる操作の手間とのバランスなので、業務の責任者が決めます。
- 速度の目安に使う利用規模（利用者数、依頼件数）は架空の仮定であり、実際の利用規模の測定値ではありません。
- 02-02で「最初に作る」と決めた機能の範囲を、この記事で増やしたり減らしたりしません。
4.3 AIに任せる範囲
品質条件の一般的な観点（安全性・速度・使いやすさでよく確認される項目）の提示や、確認方法の下書きはAIに任せられます。しかし、どこまでの安全性が必要か、条件同士がぶつかったときにどちらを優先するかは、人が決めます。
5. 作って確かめる：品質条件一覧を作る
5.1 準備
02-02の成果物（機能一覧・対象範囲の記入例）を用意します。
5.2 品質条件一覧
| 分類 | 条件 | 根拠となる利用状況 | 確認方法 | 優先度 |
|---|---|---|---|---|
| 安全性 | 割当外の承認者が承認・差戻しを試みても、必ず拒否され、依頼と履歴は変わらない | 承認者は自分に割り当てられた依頼だけを扱う前提（記事A REQ-003） | 割当外の承認者で操作し、拒否されること・データが変わらないことを確認する | 高 |
| 安全性 | 自分の依頼を自分で承認することはできない | 自己承認を禁止する業務ルール（記事A Q-2の決定） | 依頼者と承認者が同一人物のケースで操作し、拒否されることを確認する | 高 |
| 安全性 | 同じ承認操作を2回行っても、承認の効果と履歴は1回分のまま増えない | 通信の再送やダブルクリックで同じ操作が重複する可能性（記事A REQ-006） | 同じ承認を連続して2回試み、履歴が1件のままであることを確認する | 高 |
| 安全性 | 自分に関係のない依頼は一覧にも詳細にも表示されない | 役割・対象データに応じた閲覧範囲（記事A REQ-002） | 他人の依頼が自分の一覧に出ないことを確認する | 高 |
| 速度 | 依頼が20件程度の一覧が、体感で待たされずに表示される（架空の仮定：利用者20名・依頼20件程度の小規模利用） | 社内の小規模な利用を想定 | 架空データ20件で一覧を開き、表示までの体感を記録する（数値の実測は09-03で扱う） | 中 |
| 速度 | 承認操作をしてから、一覧の状態表示が反映されるまでに、別の操作をやり直す必要がない | 承認後すぐに次の依頼を確認する業務の流れ | 承認操作の直後に一覧に戻り、状態が更新されていることを確認する | 中 |
| 使いやすさ | 一覧が空のとき、エラーではなく「対象の依頼がありません」のような案内が表示される | 新しく使い始めた利用者や、対象が0件の状態 | 対象データが0件の状態で一覧を開き、案内が表示されることを確認する | 中 |
| 使いやすさ | 差戻し理由の入力欄が必須であることが、操作前に分かる（記事A REQ-004） | 理由なしの差戻しを防ぐ業務ルール | 理由を入力せずに差戻しを試み、必須である旨が操作前または操作時に分かることを確認する | 中 |
| 使いやすさ | 権限がない操作（例：割当外の承認ボタン）は、押した後にエラーを出すのではなく、操作できないと分かる形にする | 安全性の条件（割当外は拒否）を、使いやすさの面からも支える | 割当外の承認者の画面で、操作できない状態が分かることを確認する（具体的な見せ方は04-02で決める） | 中 |
5.3 AIに条件の下書きを頼む
02-02の機能一覧をAIに渡し、一般的に確認される品質条件の候補と確認方法の下書きを作らせます。
02-02の機能一覧（依頼の作成・提出・承認・差戻し・一覧閲覧）を渡します。
依頼：
1. 安全性・速度・使いやすさの3分類で、確認すべき品質条件の候補を挙げてください。
2. 各候補に、確認方法の案を付けてください。
してはいけないこと：
- 具体的な数値（秒数、件数）を、実測値であるかのように断定しないでください。架空の仮定として示してください。
- 02-02にない新しい機能を前提にした条件を作らないでください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 「一覧は0.5秒以内に表示される」と、実測していない数値を断定的に記載
- 「利用者はマルチデバイスで操作できる」という、02-02にない機能を前提にした条件を追加
6.2 見つけ方と直し方
- 「0.5秒以内」：実測していない数値を断定的に書いています。設計書6.3の「実測していない効果・数値を書かない」に反します。「架空の仮定」であることを明記するか、数値そのものを外して確認方法だけ残すように修正します。
- 「マルチデバイス対応」：02-02の機能一覧にない前提です。削除します。
指摘：
1. 「0.5秒以内」は実測していません。架空の仮定として明記するか、数値を外してください。
2. 「マルチデバイス対応」は02-02の機能一覧にありません。削除してください。
変えないこと：
- 02-02の機能一覧の内容そのものは変更しないでください。6.3 修正後の品質条件一覧
修正後の品質条件一覧は、第5.2節の表のとおりです。
7. 確認結果
第5.2節の品質条件一覧を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 安全性・速度・使いやすさの各分類に1件以上ある | 安全性4件・速度2件・使いやすさ3件 |
| 各条件に確認方法がある | 9件すべてに確認方法あり |
| 数値を置く場合は「架空の仮定」と表示されている | 速度の条件2件とも「架空の仮定」と明記 |
残る制限：この品質条件一覧は架空の利用状況（利用者20名・依頼20件程度）を仮定したものです。実際の利用規模がこれと大きく異なる場合、特に速度の条件は見直しが必要です。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 条件同士がぶつかる場合の優先順位
安全性の条件（操作のたびに役割と割当を確認する）と、使いやすさの条件（操作の手軽さ）は、次の場面でぶつかります。
| 場面 | 安全性を優先した場合 | 使いやすさを優先した場合 | この記事での判断 |
|---|---|---|---|
| 承認ボタンを押すたびに権限を再確認するか | 毎回確認するため、ごくわずかに操作が遅くなる | 一度確認したら次から省略し、操作は速いが、途中で割当が変わった場合に古い権限のまま操作できてしまう可能性がある | 安全性を優先する。社内の小規模アプリでも、割当外の承認は業務上の信頼に関わるため、確認を省略しない |
この判断は架空の設定であり、実際の業務では、操作の頻度や許容できる遅さを踏まえて業務の責任者が優先順位を決め直す必要があります。
8.2 適用限界
この記事の品質条件は、架空企業「みらい業務サービス」の小規模な社内利用を前提にしています。利用者数が大きく増える、社外からのアクセスがある、法令上のセキュリティ基準がある場合は、ここで「中」とした優先度を「高」に引き上げる必要が出てくることがあります。速度の数値目安は実測ではなく架空の仮定であり、実際の利用規模で確かめる工程（09-03）が別途必要です。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 品質条件一覧ひな形（分類、条件、根拠となる利用状況、確認方法、優先度） | templates/02-03-quality-conditions_template.md | templates/02-03-quality-conditions_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（02-02）の機能一覧を用意する
- 各機能について、安全性・速度・使いやすさの観点から確認すべきことを挙げる
- 条件ごとに、根拠となる利用状況と確認方法を書く
- 数値を使う場合は、実測か架空の仮定かを明記する
- 条件同士がぶつかる場合の優先順位と理由を書く
10. 次工程への受渡し
次へ渡すもの：品質条件一覧（分類・条件・根拠・確認方法・優先度）。
次工程での使われ方：03-03（技術とサービスを選ぶ）では、速度・安全性の条件が技術選定の比較軸になります。09-03（例外・権限・同時操作・負荷を確認する）では、この一覧がテストで確認する観点の元になります。
前工程へ戻る条件：品質条件を検討する中で、02-02の機能一覧に無い操作が必要だと分かったら、02-02に戻って機能一覧を見直します。
11. 根拠と更新情報
- この記事の会社・人物・数値・利用規模の仮定はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 品質条件の分類（安全性・速度・使いやすさ）は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.mdの記載に基づく一般的な分類です。実測していない数値は設計書6.3の「架空の仮定」の扱いに従っています。 - 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：実際の利用規模での速度、条件同士の優先順位が実務で妥当かは確認していません。