これを読んだ。
とてもよかった。特にココ。
エンジニア出身ならわかると思いますが、企画はもちろんデザインナーエンジニアも、「なぜつくるのか」「今後どうするのか」ということはとても関心のあることで、そこの納得感はチームのパフォーマンスに直結するといっても過言でないです。
わかる。自分も納得した上で作りたい。納得感なくても素早く作ればええやんと思われるかもしれないが、ふとした時につらくなるし何か起きても提案する気も起きなくなる。特に小さい組織だと納得感重要。
自分でもちょっとしつこいなと思うくらい納得できるまで質問することがある。「この機能なんで最初のリリースに入れるんでしたっけ?」とか「これをつける目的は○○で合ってますか?」とか。相手を信用していないわけではなくて、納得して取り組みたいので気になったところを質問するのだ。聞き方をもっと工夫すればよかったと後で反省することは何度もあるのでそれは別の問題として考えたい。
納得感を持ってもらうために説明する立場だとして少し考えてみる。納得してもらって進めるには、ロードマップを作っておいたり意見を事前に聞いて取り込んだりと色々とやることはあるが、伝え方も重要である。本来はすごいたくさんのことを考えて色々検討もしたはずなのに、いざ共有してみるとなんかめちゃくちゃ突っ込まれてなんかみんな納得できたかどうかわからん微妙な空気になることあるよね。自分も昔よくあったけど、それは伝え方が下手だったせいだと思っている。
たとえば「この機能って最初のリリースで本当に必要なんでしたっけ?」と聞かれた場合、
「必要です。もともとやるって話で進めていたし、事業上もないといけない機能です。」
みたいな感じで伝えるよりも
「もともと今回のリリースは○○という目的で始まった話なので必要かというと必要です。やらないことも考慮はしたんですが、○○という経緯もあってこの時期にやらないと問題になりうるので必要なんですよね。ちなみに、工数上の懸念からですか?それともそもそもない方がユーザーにとっていいからという話ですか?」
みたいに目的や背景をお互いに再確認した上で、どういう思考でその質問が出てきたのかを深掘りすると納得感を持ってもらいやすい。すでに検討したみたいな話を説明するのも大事。これを実践するためには、いつなぜやるのかを人に説明できるレベルまで考えておく必要がある。また、相手がどこに納得できていないかを想像して話を進める必要もある。子供でもわかるように言うと相手の気持ちを考えて自分の意見を伝えましょうという話なのだけれど、とても大変である。よく考えてきた本人は、相手もわかった前提で話をしがちだからだ。めちゃくちゃ根っこの部分から説明する癖をつけなければならない。
長いプロジェクトだと途中で納得感が揺らいでくることもある。なので、目的や背景、検討して捨てた選択肢などは記録に残しておいた方がよい。コストはかかるのだけれど、後で自分が振り返る時にも役に立つ。ある程度テンプレート化しておくと楽かもしれない。リリースノートを先に書くみたいな話もここに関係してくると思う。
納得感なんて必要ないくらい阿吽の呼吸で仕事できる状態が理想だと思う。しかし、納得感を持つための説明が不要な関係を築くには今まで納得感のある説明をしてくれてきたという信頼関係が必要なのだ。なので自分が説明する立場の時には相手には完全に納得できるまで質問してほしいし、自分も納得してもらえるまで説明できるようにしたい。