要件をデザイン仕様書にする
引き継いだ開発者が、あなたに聞かずに実装できるように
以下の要件をデザイン仕様書にしてください（コードは不要）。含めるもの：1）ユーザーが完了すべき操作を手順順に；2）各手順の UI 要素と状態；3）例外と境界ケース；4）やらないこと（明確な除外項目）；5）受け入れ基準。 [要件]
使い方
除外項目から書く。手戻りの多くは、誰も書かなかったことから生まれる。
向いている場面
- 要件は頭の中では明確なのに、背景を知らない開発者や外部委託に渡す必要がある——操作の順序、各段階の状態、除外項目を固定すれば、確認の往復が大きく減る。
- 要件レビューの前に穴を自己点検したい——仕様書を書く過程で「異常系を考えていなかった」箇所が出る。会議で詰められるより前に気づける。
向いていない場面
- 要件がまだ探索中で、全部ひっくり返る可能性がある——この段階の詳細仕様は廃案の豪華装丁になる。まずローファイのラフで方向を合わせる。
- 性能上限や外部 API の制約など、強い技術制約が絡むのに自分が理解していない——実現できない案が書かれる。先に開発と実現性を確認する。
例
入力
「請求書宛名管理」を作る：よく使う宛名を保存でき、注文時に 1 つ選べる。その場での新規追加も可能
得られるもの
手順を明記：注文画面に入る→「宛名を選ぶ」→一覧に既定項目の印→選択で戻って反映。異常系は宛名が空、20 件上限、適格請求書番号の形式エラー、同時更新の 4 つを網羅。除外項目は編集履歴を作らない、企業情報の自動照合をしない、と明示。受け入れ基準はチェック可能な文にする（例：「注文画面に戻ると宛名が反映され、直接編集はできない」）。
よくある誤用
- 正常系だけ書いて異常系と境界を空欄にする——開発は推測するしかなく、問題は結合テストで発覚する。手戻りコストが最も高いタイミング。
- 「やらないこと」を任意項目として省略する——除外項目がないと、開発が自分の解釈で機能を足し、範囲も工期も崩れる。
こう変えると効く
- 「やらないこと」を 1 番目に移し、理由も書かせる——境界を先に引くと以降の各項目が書きやすくなり、会議で追加要求も断りやすい。
- 「各受け入れ基準は、テスト担当がそのまま 1 本のテストケースにできる粒度であること」を足す——「体験が滑らか」のような曖昧な表現がその場で落ちる。