はじめに
仕様レビューで「分かりました」と言われたのに、実装が始まったら認識がズレていた。
要件定義が終わったはずなのに、テスト工程で「これどういう仕様？」と聞かれる。
こういう事故の原因は、たいてい 「分かった気」 だ。
「分かった気」とは、表面的な説明を聞いて理解したつもりになっている状態のこと。
本人は理解しているつもりだから、質問も出ない。確認もしない。
そして後工程で爆発する。
この質問リストは、「分かった気」を早期に検出して潰す ためのもの。
仕様レビュー、要件定義、設計レビューなど、上流工程で使ってほしい。
判定基準
YES / NO で即答できない時点で、理解していない
これがこのリストの判定基準。
「えーと…」「たぶん…」「基本的には…」が出たら、そこが「分かった気」ポイント。
① 前提破壊チェック（最優先）
なぜ聞くか：仕様は「ある前提が成り立つ」ことを暗黙に仮定している。その前提を言語化できないなら、仕様の本質を理解していない。
- その仕様が 成り立つ前提条件 を全部言える？
- その前提が 1つでも崩れたらどうなる？
- 「普通は」「基本は」「原則」は 例外がある前提 だけど、その例外は？
- その前提は 誰が保証する？ システム？運用？人？
👉 ここで詰まるなら「分かった気」確定
② 境界・責任チェック
なぜ聞くか：責任範囲が曖昧だと、障害時に「うちじゃない」の押し付け合いが始まる。境界を言えないなら、設計を理解していない。
- どこからどこまでが この機能の責任範囲？
- その一歩外側は 誰の責任？
- データが欠けていた場合、誰が直す？
- 失敗したとき、再実行の責任はどこ？
👉 境界を言語化できない＝理解していない
③ 入力・出力の完全性チェック
なぜ聞くか：入出力の仕様が曖昧だと、結合テストが作成できない。「想定外のデータが来た」は、想定しなかった側の責任。
- 入力に 来てはいけない値 は？
- 入力が来なかった場合は？
- 出力が 使われる側の期待 は何？
- 出力が 想定外だった場合、次工程はどう壊れる？
👉 「たぶん大丈夫」は即NG
④ 状態・タイミングチェック（漏れ最多）
なぜ聞くか：状態遷移とタイミングは、仕様書に書かれていないことが多い。ここを詰めないと、本番で「再現しない」バグが出る。
- 処理前／処理中／処理後で 状態はどう変わる？
- 同時に2回起きたら？
- 途中で止まったら？
- 夜間バッチ中だったら？
- ユーザーが戻る／再操作したら？
👉 時間軸を語れない＝仕様を理解していない
⑤ 例外・失敗系チェック（必ず漏れる）
なぜ聞くか：正常系しか考えていない仕様は、本番で必ず事故る。失敗系を語れないなら、その機能を理解していない。
- 通常系が通らないケースを 3つ 即答できる？
- そのときユーザーは 何を見て、何をする？
- ログは 誰が、何のために見る？
- 障害時に 問い合わせが来たら何を見る？
👉 失敗系を語れないなら、まだ設計が足りない
⑥ 数量・頻度チェック
なぜ聞くか：「動く」と「運用に耐える」は別物。数字が出てこない仕様は、負荷試験できない。
- 1日何回？
- 同時最大何件？
- 最大件数はいくつ？
- 将来10倍になったら？
- 想定を超えたら「壊れていい」のか？
👉 数字が出ない＝雰囲気理解
⑦ 業務代替チェック（業種知識ゼロでも使える）
なぜ聞くか：システムは業務の代替手段。元の業務を知らないと、「なぜこの仕様なのか」が分からず、的外れな実装になる。
- この機能がなかった時、現場は何をしていた？
- 今後もその代替手段は使う？
- システムが止まったら業務は止まる？回避できる？
- 人がやるとしたら何分かかる？
👉 業務を知らなくても、この質問で仕様漏れを炙り出せる
⑧ 「それ誰が決めた？」チェック（決定不在を無くす）
なぜ聞くか：決定者がいない仕様は、後から「聞いてない」と言われる。合意の証拠がないと、プロジェクト後半で揉める。
- その仕様、誰の判断？
- 変更できる？
- 変更不可なら理由は？
- 合意した証拠は？
👉 決定者が出てこない仕様は必ず揉める
使い方
全部聞く必要はない
このリストは網羅的に使うものじゃない。
レビュー中に「ここ怪しいな」と思ったセクションだけ使えばいい。
「1つでも詰まったら」がポイント
全問正解を求めているわけじゃない。
1つでも詰まったら、そこが「分かった気」ポイント。
それを見つけるためのリストだと思ってほしい。
その場で解決しようとしない
詰まったポイントを見つけたら、その場で議論して解決しようとしないこと。
「未確定事項」として持ち帰らせる のが正解。
理由は2つ：
- その場で出た答えは、十分に検討されていない可能性が高い
- 「持ち帰り」にすることで、相手に考える時間を与えられる
よくある「分かった気」の失敗パターン
パターン1：前提条件の認識ズレ
「この機能、ユーザーがログイン済みの前提ですよね？」
「え、未ログインでも使えると思ってました」
仕様書に「ログイン必須」と書いてなかった。
PM側は「当然ログイン済み」と思っていた。開発側は書いてないから未ログインも対応した。
結果：テスト工程で発覚、手戻り2週間。
パターン2：責任範囲の曖昧さ
「このデータ、おかしい値が入ってるんですけど」
「それ、入力側でチェックしてると思ってました」
「いや、出力側で弾くと思ってました」
誰の責任かを決めていなかった。
結果：本番障害、原因調査に3日。
おわりに
「分かった気」は、本人に自覚がないから厄介だ。
だからこそ、質問という形で外から潰す 必要がある。
このリストを使って、レビューの精度を上げてほしい。
最初は「こんなに聞くの？」と思うかもしれないけど、慣れると自然に頭の中でチェックできるようになる。
まずは、次のレビューで 1つだけ 使ってみて。
コメント