「これでいいですか？」って仕様を伝えて「はい、大丈夫です」って言われたのに、あとになって「すみません、これだと困ります」って言われたことある？
僕はある。
広い範囲で考えるといろんなケースがあって難しいから、今日は自社サービスの開発を思い浮かべながら喋っている（喋ってはいないか）。
いそいで対応するしかない。時間もないので、その場しのぎの対応になってしまう。そんな状況、嫌だよね。
それで対策としてやったことがあるのは、仕様を細かく書くこと。細かいケースまでしっかり書いた。よし、これで抜け漏れはないぞー！
でも、同じことがおこる。
「ここに書いてあるじゃないですか！」って言ったこともある。あぁ、それを言ったところでプロダクトが治るわけじゃないのにね。若い自分。
そもそも、別に相手に悪意があるわけじゃない。実際にいよいようごきだすぞというときになってはじめて気づくことって結構あるのだ。
本番環境へのデプロイジョブをキックした瞬間に（あれ？新機能でこういう操作したらどうなる？）ってバグを見つけた経験が自分にもある。
じゃあ、どうするといいかなー？って考えると、できるだけはやく「いよいよ動き出すぞ」に近い状態をつくるのがいいのかな。
仕様の詳細じゃなくて具体的な例で説明をしたり、文章じゃなくて図を書いて説明したり、説明するときに全体を同じトーンで説明するんじゃなくて「この部分がリスクありそうだから見てほしい」って強調して伝えたり、あと、いちばんいいのは動くものを見せて「この部分のこれ、この動きでいい？」って確認したり。
相手から本当のOKを引き出すのも、大切なスキルかな。
それに、相手じゃなくて、自分の方に勘違いがあることもある。
僕が「いちごっておいしいですよね」って言ったときに実は頭の中ではみかんを思い浮かべて喋ってるような状況が、冗談に思えるかもしれないけど開発だと本当にある。
だから、みかんの絵を見せながら喋ったり、目の前にみかんの実物を置いて喋るだけで、相手から「え？それいちごじゃなくてみかんですよね？」って言ってもらえる。
そういう、ちょこちょこしたことで、平和に開発を進められるように工夫している。
あの人はプロジェクトに恵まれているから、ひっくり返ることがなくて楽そうでいいなーって思われたい。
ただ、気になる部分はしつこくこまかく確認をしてしまうから、相手からしたら「大丈夫って言ってるのにしつこいなー」って思ってしまうかもしれない。
でも、みんなのがんばりが最後にひっくり返ってしまって、ユーザーにも迷惑をかけてしまうことを考えたら、全然なんともないことなのだ。
川口さんの実感駆動の話は好き。