仕事で使う型公式資料確認：2026年10月3日。例・型・基準案は編集上の提案です。AI製品の実操作・現場での効果検証は未実施です。

「検索を付けたい」だけでは、完成品が役立つか確かめられません。この記事では、利用者・場面・目的を整理し、正常・該当なし・権限なしの合格条件を作ります。成果物は、開発者と利用者が同じ期待を確認できる1ページの要件メモです。

機能名を、利用者の目的へ戻す

架空の社内文書サイトです。新入社員が申請方法を確認するために、閲覧が認められた現行規程へ到達したいとします。検索欄があっても、旧版を現行として案内したり、権限外の資料を出したりすれば目的を満たしません。

英国政府のユーザーストーリーのガイドは、利用者・したいこと・その理由を説明し、完了したと判断する結果を合格条件として残す考え方を示しています。以下は社内文書サイト向けに置き換えた編集上の例です。

利用場面と合格条件の到達例

場面試す条件合格の確認
現行規程を探す管理者が指定した現行・旧版の架空資料と例題を用意対象者が現行版と適用日を確認し、原本へ到達できる
該当資料がない用意した資料に答えがない例題条件を創作せず、該当なしと問い合わせ先を示す
閲覧権限がない役割が異なる試験アカウントを用意権限外の本文・要約・機密を含む題名等を返さない

これらは実施結果ではありません。機密かどうかの判定、アクセス制御、旧版の保持・表示ルールは管理者と開発者が別に設計します。「見せない」とプロンプトへ書くだけで権限制御が完成したとは扱いません。直接URLや別の経路からのアクセスも検証対象を決めます。

コピーして使う：小さな要件メモ

要件ID・版：
利用者・役割：
利用場面と困りごとの根拠：
したいこと／その理由：
対象データと正本・現行版の判定：
必須条件：
合格条件：前提／利用者の操作／期待する結果／確認方法
例外：該当なし、権限なし、旧版、資料の欠落
更新担当と変更通知：
初回に含む範囲／含めない範囲と理由：
未確認の条件・確認先：
優先順位と承認者：

AIには整理と不足の質問を頼む

目的：現場メモを要件メモへ整理する。
利用者、場面、したいこと、目的、合格条件に分ける。
合格条件は観察できる結果と確認方法の案を出す。
未記載の権限・期限・数値目標を確定しない。
事実、編集案、確認が必要な事項を分ける。
優先順位は提案までとし、決定者に確認する。
材料：［利用者と管理者が確認したメモを貼る］

「使いやすい」だけでは判断しにくいので、どの例題でどの資料へ到達すればよいかを決めます。必要な時間や件数の基準は現場で合意し、未合意なら数値を補いません。通知や推薦などの追加機能は、初回の目的に必要かを別に判断します。

結果の確認ポイント

  • 利用者が「これができれば助かる」と確認したか。検索欄の存在だけを合格にしていないか。
  • 期待する結果と試験資料・役割・確認手順が対応しているか。
  • 正常だけでなく該当なし・権限なし・更新時の扱いを決めたか。
  • 必須と後回しが分かれ、未確認事項を決定済みとして渡していないか。

今日試すこと

身近な機能要望を1つ選び、利用者と理由を1文にします。合格条件を正常と例外で1つずつ書き、利用者・管理者に確認してください。要件メモの確認と製品の実操作検証は別です。

参考資料

GOV.UK：ユーザーストーリーを書く（公式資料、2026年10月3日確認）。文書サイト例・試験案・要件メモはTOMONIの編集上の提案です。

次に読む

記事一覧へ戻る