- 相手の「期待した動き」を、相手の言葉のまま書き留めたか
- 「実際の動き」を、自分の目で確認した事実だけで書いたか(推測と分けたか)
- 根拠を探す場所を決めて、時間を区切って探したか
- コードの実装を「根拠」として扱っていないか(現状の証拠であって、あるべき姿の根拠ではない)
- 根拠が見つからなかったことを、「分からない」ではなく「決まっていなかった」と書けているか
- 「仕様」に仕分けたとき、相手の困りごとを改修依頼として受け止め直したか
- 費用や契約が絡みそうなとき、自分ひとりで結論を出さずに済む形にしたか
- 決まった内容を、次に同じ質問が来たときに引ける場所へ残したか
全部そろわなくても構いません。1件でも「決めごと」として決着させられたら、その分だけ仕様の空白は減っています。
この内容は記事「「これはバグか仕様か」の決め方|判断が割れたときの合意の取り方」のチェックリストです。印刷してそのままお使いいただけます。 / 無料ツール一覧へ