判断の出発点
技術を選ぶ前に、目で確かめられる動作を書きます。誰が、どの状態から、何をして、どの結果を確認するかを示し、その結果を変える権限と例外を加えます。
具体例で考える
架空の経費ツールでは担当者が領収書を提出し、上司が承認か理由付き差し戻しを行い、経理が承認済みデータを出力します。読めない領収書、上司の不在、承認後の金額変更も決めます。
演じて確かめられる例を書く
架空の具体値を使い、出張の領収書を載せ、案件を選び、提出すると書きます。管理者は許可された申請だけを見ます。差し戻しには理由が必要で再編集が可能になり、承認は版を固定します。訂正が新版か再承認か拒否かまで定義してください。カードや簡単な図で演じられるなら、技術を決める前にも理解を確かめられます。
ルール、好み、仮定を分ける
経理だけが承認済みを出力できるのは権限、ボタンを右上に置くのは案、表計算形式が必要というのは受取業務を知るまで仮定です。この区別でデザインを良くしても約束が変わりません。ルールの出所と確認できる人を記します。契約や法的条件は権威ある本文や適切な専門家の解釈を取り、伝聞から開発者に推測させないでください。
両側の担当者とレビューする
提出者、審査者、経理が同じ例を追います。中断アップロード、不在、繰り返し出力、承認後訂正など異なる心配が見つかります。必要な決定を加え、任意の好みは残します。安全な試験データと実演内容を定め、承認済み要件は版を保存します。明確な要件は難しい用語の多さでなく、事業の判断を勝手に補わず作り評価できるものです。
選択肢とその負担
短い説明文は背景を、注釈付きの図は操作を、受入例は境界を示します。必要に応じて組み合わせ、巨大な文書より決定記録を最新に保ちます。
見落としやすい点
業務ルールをデータベースの表で説明しようとしないでください。「速い」「簡単」には対象の仕事と評価方法が必要です。必須の動作とデザイン案を分け、意見が割れたときの決定者を置きます。
依頼前に確認すること
別の人が成功例と失敗例を実演できるか。役割が決まっているか。共有するデータは安全か。要件と不明なケースをMVPの検討に持ち込んでください。