「検索機能がほしい」と言われても、すぐ検索ボックスの仕様には進めません。誰が、何を探し、見つけたあとに何をしたいのかで、必要な機能が変わるからです。
この記事は、Webサービスの企画を仕様に落とし込む人向けに、要件定義の初期整理を扱います。GOV.UKのユーザーニーズとユーザーストーリーの説明を参照し、架空の社内資料検索を例にします。以下の整理表は記事側の提案で、規格や要件定義全体を網羅する様式ではありません。
機能の希望と、解決したい問題を分ける
GOV.UKは、ユーザーニーズを解決策ではなく利用者の問題に着目して書き、利用者由来でない意見は調査で確かめる仮説として扱うよう説明しています。Learning about users and their needs
社内から「AI検索を付けたい」という要望が出たとします。これは解決策の候補です。背景にある問題は「似た名前の資料が多く、今使える手順を見分けられない」かもしれません。まだ確認していないなら、問題の記述にも「仮説」と付けます。
| 分けるもの | 架空の記入例 | 次に確かめること |
|---|---|---|
| 利用者 | 初めて経費を申請する社員 | 実際に困っている人は誰か |
| やりたいこと | 今の申請手順を知りたい | 直近の申請でどう探したか |
| 困りごと・仮説 | 古い資料と新しい資料を区別できない | 迷った資料と判断の過程 |
| 解決策の候補 | 更新状況を表示する／資料を整理する／検索を作る | どれが問題に合っているか |
問題が資料の管理にあるなら、検索だけを追加しても古い資料は残ります。機能の要望を否定するためでなく、他の解決策も比較できる状態にするために分けます。
「できた」と判断する条件を書く
GOV.UKのWriting user storiesでは、誰が・何を・なぜ必要とするかを記述し、受け入れ条件を、ニーズを満たしたか確認する結果の一覧として説明しています。
この作例なら、利用者の目的は「初めて申請する社員が、差し戻しを避けるために、現在の申請手順を確認したい」。これを開発する範囲に分けてから、結果を確かめられる条件を書きます。
- 指定した申請種別に対応する手順を表示できる。
- 各手順に適用開始日と管理部署が表示される。
- 廃止済みの手順を選んだ場合、現在の案内先が分かる。
- 閲覧権限がない資料は、タイトルや抜粋も表示されない。
これらは仮の受け入れ条件です。「速い」「使いやすい」のままでは確認が難しいため、実際のデータや利用場面を使って、判定方法を関係者と決めます。応答時間の数値を置く場合も、測定する端末・データ量・同時利用条件と合わせて合意します。
範囲・例外・未決事項を残す
最初から全機能を作るとは限りません。今回の対象が「日本語の経費申請資料を探す」なら、他部署の資料検索やAIによる回答生成は別途検討、と明示する案があります。
また、「0件だったらどうするか」「資料の管理者が退職したら誰が更新するか」は正常な検索結果だけを見ていると抜けます。画面の動きに加え、運用する人の作業も確認します。
決まっていないことを推測で埋めると、後から合意済みの仕様に見えてしまいます。たとえば権限の管理元が未定なら、担当者・確認先・期限を付けて未決として残します。
打ち合わせに持っていく整理表
次の項目を、要望が一つ出たときの確認メモとして使えます。AIに整形を手伝わせる場合も、観察や合意のない内容を事実として補わせないことが前提です。
| 項目 | 記録する内容 |
|---|---|
| 誰の、どの場面か | 利用者と発生する状況 |
| 何に困っているか | 観察・問い合わせなどの根拠。未確認なら仮説 |
| 何ができればよいか | 利用者が達成したい結果 |
| 今回どこまで作るか | 対象と対象外 |
| どう確認するか | 受け入れ条件と確認方法 |
| 何が未決か | 例外、運用、依存先、確認担当 |
この表は着手前の整理用です。必要に応じて、データの保持、権限、可用性、移行、運用コストなども別に詰めます。まずは一つの要望をこの表に当てはめ、根拠と未決事項が分かる状態にしてから、機能の優先順位を話し合ってみてください。