要件定義書を読んでいると、「すぐに表示する」「大量データに対応する」「エラー時は適切に処理する」のような文章に出会うことがあります。
なんとなく言いたいことは分かります。ただ、そのまま実装や見積もりやテストに進むと、人によって解釈が分かれます。
「すぐに」は1秒なのか、3秒なのか。
「大量」は1万件なのか、100万件なのか。
「適切に」は画面にメッセージを出すことなのか、ログに残すことなのか、再実行できるようにすることなのか。
曖昧な言葉を見つけたときに大事なのは、その言葉を機械的に禁止することではありません。何がまだ決まっていないのかを分解し、関係者に確認し、第三者が同じ意味で読める文章へ直すことです。
ここでは、要件定義でよく出る曖昧な表現をBefore / Afterで見ながら、どこを確認すれば要件として扱いやすくなるのかを整理します。
曖昧さの正体
要求工学の資料でも、要求は一意に解釈でき、確認可能な形で書く必要があるとされています。
要件が曖昧なままだと、実装時に解釈が分かれるだけではありません。見積もりの前提も揃わず、完成後に「この状態で要件を満たしたと言えるのか」も判断しにくくなります。
要件として使える状態にするには、書いた本人だけが意味を分かっている状態では足りません。実装する人と確認する人が同じ意味で読めて、満たしたかどうかを判断できるところまで具体化する必要があります。
とはいえ、業務システムの要件定義で毎回こうした標準を細かく引きながら書くわけではありません。実務では、次の問いに答えられるかを見れば十分な場面が多いです。
- 誰が読むか
- 何を対象にするか
- どの条件で成り立つか
- どこまでを範囲にするか
- 何をもって満たしたと判断するか
- 例外時にどう動くか
tomo数値を足せば解決する要件もあります。けれど、数値だけでは足りない要件もあります。
すぐに表示する
表示時間に関する表現は、曖昧さに気づきやすい例です。
Before:
tomo商品検索画面では、検索結果をすぐに表示する。
この文章では、検索結果を速く出したいことは分かります。ただ、決めるべきことがかなり残っています。
- 初期表示なのか、検索実行後なのか
- 何件の商品を対象にするのか
- 同時に何人が使う想定なのか
- 何秒以内なら業務上問題ないのか
- 時間がかかる場合、処理中表示を出すのか
聞き返すなら、たとえば次のようになります。
- 対象は初期表示ですか、検索実行後の結果表示ですか。
- 想定する商品件数と同時利用者数はどの程度ですか。
- 業務上、何秒以内であれば問題ありませんか。
- 時間がかかる場合、処理中表示やキャンセル操作は必要ですか。
確認した結果を踏まえると、たとえば次のように書けます。
After:
tomo商品検索画面では、一般利用者が検索条件を入力して検索ボタンを押した後、通常営業時間中に、有効商品10万件、同時利用者50人の条件で、検索結果の先頭50件を3秒以内に表示する。3秒を超える場合は処理中表示を出し、検索処理の完了後に結果を表示する。
この書き方なら、検索ボタン押下から先頭50件表示までの時間を測れば確認できます。3秒を超えた場合の画面表示も確認対象にできます。
ポイントは、3秒という数字だけではありません。対象操作、データ件数、同時利用者、表示件数、超過時の動きまで決めているところです。
大量データに対応する
「大量データ」もよく出てきます。便利な言葉ですが、そのままだと見積もりの幅がすぐ広がります。
Before:
tomo注文データは大量データに対応する。
ここで分からないのは、件数だけではありません。
- 大量とは何件、何MB、何年分なのか
- 対象は登録、検索、集計、CSV出力、保管のどれなのか
- 処理完了までの許容時間はどれくらいか
- 上限を超えた場合に受け付けるのか、エラーにするのか
聞き返し例は次のようになります。
- 大量データ対応が必要なのは、取り込み、検索、集計、出力のどれですか。
- 1回の処理で想定する最大件数と最大ファイルサイズはいくつですか。
- 処理完了までに許容できる時間はどの程度ですか。
- 上限を超えたデータは受け付けますか、それともエラーにしますか。
After:
tomo注文CSV取込機能では、管理者が1回の操作で最大5万行、最大100MBのCSVファイルをアップロードできる。システムはアップロード完了後15分以内に検証と登録を完了する。5万行または100MBを超えるファイルは取込開始前にエラーとして扱い、管理者へ上限超過の理由を表示する。
この要件なら、5万行かつ100MB以内のCSVで取込完了時間を確認できます。上限を超えるCSVを使えば、取込前にエラーが出ることも確認できます。
「大量」のような言葉は、上限と処理対象を分けて聞くと具体化しやすくなります。
使いやすくする
少しやっかいなのが「使いやすくする」です。ここで無理に「5分以内」だけを足しても、まだ要件としては弱いままです。
Before:
tomo見積登録画面は使いやすくする。
この文章では、次の点が決まっていません。
- 誰にとって使いやすいのか
- どの操作を対象にするのか
- 何を改善したいのか
- 何を見れば使いやすくなったと言えるのか
聞き返し例です。
- 主な利用者は新人担当者ですか、経験者ですか、管理者ですか。
- 使いやすくしたい主要操作は何ですか。
- 現状で時間がかかる、間違えやすい、問い合わせが多い箇所はどこですか。
- 使いやすくなったと判断する確認方法は、操作時間、入力ミス数、問い合わせ件数、ユーザーテストのどれにしますか。
After:
tomo見積登録画面では、営業担当者が顧客、商品、数量、値引率、見積有効期限を入力して見積を保存できる。入社1か月以内の営業担当者が、操作説明資料を参照しながら、標準的な見積1件を5分以内に登録できることを確認対象とする。必須項目の未入力や値引率の範囲外入力がある場合は、該当項目の近くに修正内容を表示する。
この要件では、想定利用者に近い担当者に標準シナリオを実施してもらい、登録完了時間と入力エラー時の案内を確認できます。
「使いやすい」は主観が入りやすい言葉です。だからこそ、対象ユーザーと対象操作を先に決めた方が話が進みます。いきなり全画面の使いやすさを背負わせると、まあまあ無理があります。
必要に応じて通知する
「必要に応じて」は、関係者の頭の中にある条件が文章へ落ちていないときに出やすい表現です。
Before:
tomo申請状況は必要に応じて通知する。
このままだと、通知を実装する側もテストする側も困ります。
- 何をきっかけに通知するのか
- 誰に通知するのか
- 通知手段は何か
- 何分以内に通知するのか
- 通知失敗時にどう扱うのか
聞き返すなら、次のような質問になります。
- 通知が必要な状態変更はどれですか。
- 通知先は申請者、承認者、管理者のどれですか。
- 通知手段はメール、画面内通知、チャット連携のどれですか。
- 通知できなかった場合、再送や管理者確認は必要ですか。
After:
tomo経費申請のステータスが「差し戻し」に変更された場合、システムは申請者へ5分以内にメールを送信する。メールには申請番号、差し戻し理由、申請詳細画面へのリンクを含める。メール送信に失敗した場合は送信エラーとして記録し、管理者画面の通知エラー一覧に表示する。
この要件なら、申請を差し戻し状態へ変更し、5分以内のメール送信、メール本文の項目、送信失敗時のエラー記録を確認できます。
通知の要件では、きっかけ、通知先、手段、期限、失敗時の扱いを分けると抜けが見えます。
管理者が確認できる
「確認できる」も、見た目より曖昧です。閲覧だけでよいのか、検索や出力も含むのか。権限範囲も決める必要があります。
Before:
tomo管理者がユーザーの利用状況を確認できる。
未決定なのは、たとえば次の点です。
- 管理者とは全社管理者なのか、部門管理者なのか
- 利用状況とはログイン日時なのか、操作履歴なのか、機能利用回数なのか
- 何日分を対象にするのか
- 他部門のユーザーを見られるのか
- CSV出力が必要なのか
聞き返し例です。
- 管理者は全社管理者ですか、部門管理者ですか。
- 確認したい利用状況はログイン日時、操作履歴、機能利用回数、エラー発生状況のどれですか。
- 何日分の履歴を確認できればよいですか。
- CSV出力や監査用の保存は必要ですか。
After:
tomo部門管理者は、自部門に所属するユーザーについて、過去90日間の最終ログイン日時、ログイン回数、登録済み申請件数をユーザー別に一覧表示できる。部門管理者は他部門のユーザーを一覧に表示できない。一覧は対象期間とユーザー名で絞り込みでき、CSV出力は行わない。
この要件なら、部門管理者でログインし、自部門ユーザーのみが表示されること、90日間の指定項目が表示されること、期間とユーザー名で絞り込めることを確認できます。
ここでは「CSV出力は行わない」と明記している点も効きます。やらないことを書いておくと、後から「当然できると思っていた」を減らせます。
エラー時は適切に処理する
エラー処理の「適切に」も、かなり危ない言葉です。
Before:
tomoエラー時は適切に処理する。
エラー処理では、少なくとも次の点を決めたいところです。
- 対象エラーは入力エラーなのか、外部APIエラーなのか、DBエラーなのか
- ユーザーへ何を表示するのか
- 入力済み内容を保持するのか
- ログに何を残すのか
- ユーザーへ見せてはいけない情報は何か
聞き返し例です。
- この要件で対象にするエラーはどの操作のどのエラーですか。
- ユーザーはその場で修正できますか、再実行が必要ですか。
- エラー発生時に入力済み内容を保持しますか。
- 運用担当者が調査するために、どの情報をログへ残しますか。
After:
tomo見積登録画面で入力値エラーが発生した場合、システムは登録処理を実行せず、入力済み内容を保持したまま、対象項目の近くにエラーメッセージを表示する。単価が0円未満の場合は「単価は0円以上で入力してください」と表示する。エラーメッセージにはスタックトレース、SQL、内部ホスト名を表示しない。
この要件なら、単価に0円未満を入力して保存し、登録されないこと、入力内容が保持されること、項目近くにエラーが出ること、内部情報が表示されないことを確認できます。
エラー処理では、ユーザーへ見せる情報と、運用担当者が調査する情報を分けて考えると書きやすくなります。
曖昧な要件の見方
ここまでの例をまとめると、曖昧な要件にはいくつかのパターンがあります。
- 対象が曖昧: どの画面、データ、処理、ユーザーに適用するのかが決まっていない
- 主体が曖昧: 誰が操作するのか、誰へ通知するのか、どの権限で見られるのかが決まっていない
- 条件が曖昧: いつ、どの状態で、どのイベントをきっかけに動くのかが決まっていない
- 基準が曖昧: 何秒、何件、何日分、どの品質なら満たしたと言えるのかが決まっていない
- 範囲が曖昧: 対象データ、権限範囲、履歴期間、出力要否が決まっていない
- 例外時の動きが曖昧: 上限超過、エラー、失敗、タイムアウト時にどう扱うかが決まっていない
- 確認方法が曖昧: 実装後に誰がどの観点で満たしたと判断するのかが決まっていない
曖昧な表現を見つけたら、「言葉が悪い」と見るより、「何が未決定なのか」を見る方が建設的です。
「大量データ」という言葉を消すだけでは、要件は良くなりません。何件なのか、どの操作なのか、何分以内なのか、超えたらどうするのか。そこまで決まって初めて、実装やテストで扱いやすくなります。
チェックリスト
要件定義書をレビューするときは、次の項目を見ると曖昧さに気づきやすくなります。
- 対象の画面、機能、操作、データは明示されているか
- 主体となる利用者、管理者、外部システム、処理は明示されているか
- その要件が適用される条件、タイミング、期間は明示されているか
- 件数、時間、容量、回数など、判断に必要な基準は明示されているか
- 上限超過、入力エラー、外部連携失敗など、例外時の動きは明示されているか
- 権限範囲や閲覧できる対象は明示されているか
- 満たしたかどうかを第三者が確認できる方法を説明できるか
- 実装担当者とテスト担当者が同じ意味で読める文章になっているか
全部の要件を細かく書けばよい、という話ではありません。抽象度が高いままでよい段階もあります。
ただ、実装、見積もり、テストに渡す要件なら、少なくとも誰かが満たしたかどうかを確認できる状態にはしておきたいところです。
まとめ
要件定義で曖昧な表現を見つけたら、すぐに数字を足す前に、何が未決定なのかを分けて考えます。
対象、主体、条件、範囲、基準、例外時の動き、確認方法。このあたりを確認すると、「すぐに表示する」「大量データに対応する」「適切に処理する」といった文章は、実装担当者とテスト担当者が同じ意味で読める要件に近づきます。
曖昧な言葉そのものが敵なのではありません。曖昧なまま合意したことにしてしまうのが、後で効いてきます。
