79. 仕様の把握のやり方その⑨
反対を考える
マインドマップを書いていると薄い部分が「見える」。
「ここって他にないんだっけか？」と思う場所が出てきたりする。
それがマインドマップの効果の１つ。
そういうときは発想して行間を読むのだけど、そのときに「反対」を考えてみると面白いかも。
- 最大値→最小値。
- 整数→整数以外。
- ～リストの表示は20件まで→0件表示
- 購入時→販売時（プロジェクト中では「反対」ととらえられている概念など）
などなど。
当たり前のこと
作者はweb/App系、ゲーム系しか回ってきてないけれど、仕様書になんでもかんでも全部全部書いているところは見たことがない。
時間的にも求められている粒度的にも現実的ではないし、そもそも気付いてなかったりするからだ。
けどプロジェクトに最初からずっといる人ならいいけど、途中参加の場合「？？？」となる。
こういうことを見つけたら質問しよう。
放置するとあとで死にますｗ（体験談
ただ、１つ１つ質問するとコミュニケーションコストもハンパない。
なので作者はよく仕様把握をしながら「質問表」を作成して「お手すきで回答いただけたら嬉しいですー」みたいな感じで投げていた。
さて、この「書かれていないこと」が本番障害につながると、ふりかえりで「仕様書にしっかり事細かに書いてもらう」という意見が必ず出てくる。
確かにそうであれば嬉しいのだけれど、果たしてそれは費用対コストなどを考えて本当に現実的なことなのか考えてみよう。
あと「暗黙の了解を資料に残しておく」の意見も必ず出てくる。
これ、作者は今まで成功したことがないTryだったりする。
他のみんなはどうしているんだろう。
質問票をまとめておく、なんてTryもあったけど結局やらなく……
