- SDD(仕様駆動開発)では「レビューの質」がプロジェクトを決める
- なぜチェックリストが必要になるのか
- チェックリスト設計の基本方針
- 入力仕様のチェック項目
- 出力仕様のチェック項目
- エラー仕様のチェック項目
- 状態遷移のチェック項目
- 並行処理のチェック項目
- セキュリティ観点のチェック
- チェックリストの運用方法
- よくある失敗
- 注意点：チェックリストは万能ではない
- まとめ：レビューを個人技からプロセスへ
SDD(仕様駆動開発)では「レビューの質」がプロジェクトを決める
SDD(仕様駆動開発)を導入しても、すぐに開発が安定するとは限りません。
むしろ最初に多くのチームがつまずくのは、仕様レビューのやり方です。
仕様をレビューすると言われても、何を見ればいいのか分からない。
結果として「読み合わせ会」になり、結局コードレビューに戻ってしまいます。
SDDが機能するかどうかは、仕様レビューのチェックリスト設計に大きく依存します。
レビューを属人化させない仕組みが必要になります。
なぜチェックリストが必要になるのか
仕様レビューはコードレビューより難しいです。
コードには構文や設計パターンがありますが、仕様には基準がありません。
レビュー担当者によって指摘内容が変わります。
- Aさん：命名を指摘
- Bさん：エラー処理を指摘
- Cさん：UXを指摘
どれも正しいですが、抜け漏れが発生します。
そこで必要になるのがチェックリストです。
チェックリストは「確認の範囲」を定義します。
つまり、レビューの責任範囲を明確にします。
チェックリスト設計の基本方針
チェックリストは網羅的にするほど良い、と思われがちです。
しかし実際には逆です。
項目が多すぎるチェックリストは使われません。
重要なのは、失敗に直結する項目に絞ることです。
設計の考え方は次の3つです。
- 事故が起きたときに困るもの
- 後から変更できないもの
- 実装者が迷うもの
この3条件を満たすものを中心にします。
入力仕様のチェック項目
最初に確認すべきは入力です。
不具合の多くは入力仕様の曖昧さから発生します。
| 確認項目 | 例 |
| 必須項目 | 未入力時の挙動 |
| 最大長 | 文字数制限 |
| 形式 | メール形式・数値 |
| 範囲 | 最小値・最大値 |
| 重複 | 一意制約 |
ここで重要なのは「入力可能か」ではありません。
入力できなかったときの挙動です。
例えば「必須」と書くだけでは不十分です。
- 400を返すのか
- 422を返すのか
- メッセージ内容は何か
ここまで決めます。
出力仕様のチェック項目
次にレスポンスです。
特に公開APIでは最重要項目です。
| 確認項目 | 内容 |
| フィールド存在 | 常に返るか |
| null許容 | nullになる条件 |
| 配列 | 空配列かnullか |
| 順序 | ソート保証 |
| 日時 | タイムゾーン |
配列の扱いは典型的なトラブルになります。
空データ時にnullか[]かを定義しないと、クライアントが壊れます。
エラー仕様のチェック項目
仕様レビューで最も見落とされる部分です。
しかし運用では最も重要です。
- 認証失敗
- 権限不足
- データ不整合
- 外部連携失敗
- タイムアウト
それぞれに対して次を定義します。
| 項目 | 例 |
| HTTPステータス | 401/403/409 |
| メッセージ | ユーザー向けか |
| リトライ可否 | 可能か不可か |
| ログ | 記録レベル |
エラー仕様が曖昧なシステムは、障害時に対応できません。
状態遷移のチェック項目
業務システムでは特に重要です。
データには状態があります。
例：注文
| 状態 | 遷移 |
| 作成 | →支払い待ち |
| 支払い待ち | →確定 |
| 確定 | →発送 |
確認すべき点は次です。
- どのAPIが状態を変更するか
- 取り消し可能か
- 同時更新時の挙動
- 不正遷移時の応答
ここを定義しないと、運用トラブルが発生します。
並行処理のチェック項目
実装時に最も危険な領域です。
しかし仕様に書かれないことが多い部分です。
- 同時更新
- 二重送信
- リトライ
- 遅延処理
例えば「注文ボタン連打」で何が起きるかを決めます。
ここを決めないと、後から修正できません。
セキュリティ観点のチェック
最低限確認すべき項目です。
- 認証必須APIか
- 権限チェックの有無
- ID推測可能性
- レート制限
SDDでは、セキュリティも仕様です。
実装任せにしないことが重要です。
チェックリストの運用方法
チェックリストは作るだけでは機能しません。
運用が重要です。
推奨フローは次です。
- 仕様作成
- チェックリストレビュー
- 指摘修正
- 実装開始
ここでのポイントは、チェックが完了するまで実装を開始しないことです。
順序が崩れると形骸化します。
よくある失敗
導入時に頻発します。
- チェックリストが長すぎる
- 全員が全部確認する
- 更新されない
チェックリストは成長させる必要があります。
障害が発生したら項目を追加します。
つまり、過去の失敗を組織知に変える仕組みです。
注意点：チェックリストは万能ではない
チェックリストがあると安心しますが、過信は危険です。
想定外は必ず発生します。
重要なのは、チェックリストを「守る」ことではなく、
抜けを見つけたら更新することです。
まとめ：レビューを個人技からプロセスへ
SDD(仕様駆動開発)における仕様レビューは、優秀な人に依存しないための仕組みです。
チェックリストはレビューの効率化ではありません。
品質の再現性の確保です。
属人的なレビューは、一度うまくいっても再現できません。
しかしチェックリストは再現できます。
開発の安定とは、ミスが起きないことではありません。
同じミスを繰り返さないことです。
その基盤になるのが、設計された仕様レビューのチェックリストです。
