ユーザー要件

ユーザー要件はシステムによる利用支援を規定し、利用者への命令ではない

ユーザー要件の主要な種類

利用者は、タスクを完了できることだけでなく、実務で使える速さ、分かりやすさ、安全性も求めます。前者は必要な機能、後者は利用時の品質です。両方を書くことで、機能は存在しても採用できない状態を避けます。

ユーザーニーズからユーザー要件を導出する

ニーズは現状を変える理由を示し、要件はそれを解決策が満たせる条件へ変えます。単なる言い換えではなく、タスク、入力、結果、例外、品質境界を確認し、元の利用者課題との関係を残します。

1. ニーズと証拠を確認する

   検証済み、または確信度を明示したニーズについて、ロール、結果、理由、調査範囲、反例を確認し、機能要望から正式要件へ直接飛びません。

2. 利用文脈を固定する

   利用者、目標、タスク、端末、環境、チャネル、頻度、データ、時間圧力、支援要件、リスクを示し、どこで要件が成立するかを明確にします。

3. 必要相互作用を分解する

   業務シナリオから見る、入力、選択、確認、訂正、撤回、受領、引き継ぎを、正常、情報不足、エラー、無権限、復旧経路で識別します。

4. 利用結果の品質を定義する

   タスク完了、誤り防止、理解、時間、負担、アクセシビリティ、安全について、リスク相応の測定条件を設定し、根拠のない丸い数値を選びません。

5. 他ロールと制約を確認する

   一ロールへの対応が情報漏えい、職務分掌迂回、サポート過負荷、業務規則、プライバシー、セキュリティ、規制、運用違反を生まないか確認します。

6. 必要な範囲で実装非依存にする

   必要相互作用と出力属性は規定しつつ、固定制約がなければ部品、ベンダー、控件、アルゴリズムを固定せず、設計決定を別記録します。

7. 検証方法と証拠を決める

   ベースライン前に検査、分析、実演、テスト、ユーザー評価の方法と、版、環境、標本、参加者、期待結果を示します。

8. 共同審査・承認する

   利用者代表、業務、設計、技術、テスト、セキュリティ、アクセシビリティ、運用がリスクに応じて参加し、競合、不可能、証拠不足を解消して承認します。

実装・検証可能なユーザー要件の書き方

「使いやすいこと」は方向を示しますが、設計とテストが何をすべきかは分かりません。誰がどの条件で何を完了するか、結果と制限を観察できる形で書き、技術方式を選ぶ余地は残します。

ベースライン前の品質確認

ベースライン後の要件は設計、見積、検収を動かします。誤った役割、抜けた例外、矛盾を後で見つけるほど修正費用は増えます。各文が後続チームの行動根拠に足るかを先に確認します。

1. 必要か

   採用済みニーズ、リスク、政策、目標へ追跡でき、削除した場合の影響を説明できます。

   確認：親ニーズ、理由、除外判断。

2. 正しく適切な層か

   利用者自身でなくシステム利用を制約し、願望でも早過ぎる控件・コード指定でもありません。

   確認：用語、責任主体、設計決定記録。

3. 明確、単一、無曖昧か

   業務、設計、開発、テストが同じ解釈をし、一文に一主要義務があります。

   確認：同行審査、用語集、再説明。

4. 完全で整合するか

   トリガー、入力、出力、エラー、権限、適用範囲が十分で、他要件・規則・ロールと矛盾しません。

   確認：シナリオ網羅、競合・依存表。

5. 実現可能か

   技術、データ、時間、費用、法務、運用が支え、仮定を確認済みまたは明示リスクとして残しています。

   確認：試作、見積、依存、仮定。

6. 検証可能か

   有限の検査、分析、実演、テストで判断でき、未指定者の「良さそう」に依存しません。

   確認：方法、環境、標本、期待、許容差。

7. 双方向追跡・変更可能か

   存在理由と設計、実装、証拠をたどれ、変更影響を切り分けられます。

   確認：関係、版、状態、変更記録。

ユーザーニーズから導く構成例

以下の顧客と無関係な購買設定で、一つのニーズが複数の検証可能な要件になる過程を示します。分割してもニーズは消えず、各要件が元のタスクのどの部分を満たすかを追えるようにします。

維持可能なユーザー要件ベースライン

要件は変化しても、経緯は見える必要があります。提出者、元のニーズ、承認、影響する設計とテストを追跡します。利用者の仕事が変わった時、システム全体を推測し直さず該当要件を更新できます。

1. 要件台帳を作る

   ID、本文、理由、情報源、ロール、文脈、優先順位、検証、責任者、状態、版、関係を一元記録し、プロトタイプコメントやチャットへ散在させません。

2. 重複せず網羅する

   ニーズ—シナリオ—要件表で欠落、重複、競合を探し、共通品質規則は参照し、多数ストーリーへ異なる版を複製しません。

3. 識別可能なベースラインを承認する

   見積、設計、テスト、検収に使う版と、承認者、日付、未解決仮定、逸脱を明記します。「最新文書」は安定基準ではありません。

4. 履歴を書き換えず設計へ接続する

   設計は要件の充足方法と取捨選択を説明します。不可能・不要と分かった場合は変更手続で要件を修正し、意味を暗黙変更しません。

5. 検証と不具合を結ぶ

   各要件に少なくとも一つの検証経路を計画し、結果・問題がIDを参照し、終了時にどの版・文脈を再検証したかを示します。

6. 変更と影響を管理する

   調査、政策、工程、ベンダー、データ、運用変更時に、ニーズ、設計、連携、研修、テスト、費用、公開時期を分析し、権限者が判断します。

7. 本番後も有効性を確認する

   要件適合だけではニーズ充足の継続を証明しません。実タスク、支援、例外、排除群、業務結果から必要に応じてニーズ・要件基準を修正します。

企業AIで規定すべき観察可能なユーザー要件

「正確で自然で賢い回答」は実装しにくく、安定した検収もできません。引用する時、不確実性を示す時、停止して人へ渡す時、操作前に確認する内容など、利用者が観察できる振る舞いを規定します。

ユーザー要件と混同しやすい概念

ユーザーニーズ、業務要件、システム要件、検収基準は同じ連鎖で具体化しますが、置き換えられません。ユーザー要件は利用者視点を保ちながらシステムや工程へ配分できる精度を持ちます。混在すると技術を早く固定するか、検証不能な願望が残ります。