ある新人エンジニアが、新しい機能の設計をチームに説明することになりました。「最初は A 案を考えたんですが、B 案もありかなと思って、でも性能が気になって……。そういえば以前似たケースがあって、それを思い出して……。あと、このライブラリも調べたんですが……」。10 分話しても、結局「何を採用したのか」が誰にも伝わりませんでした。
一方、別の人はこう話します。「今回の課題は処理速度でした。3 案比較しましたが、保守性と性能のバランスから B 案を採用しました。理由は 3 つあります。」。これだけで、聞いている人はすぐに理解できます。
実は、最初の人も頭の中では一生懸命考えています。問題は、考えた順番のまま話してしまったことです。
思考するときは、迷ったり、仮説を立てたり、間違えたり、寄り道したりします。それは自然なことです。しかし、人に説明するときに必要なのは、その迷いの記録ではありません。相手が知りたいのは、「結論は何か」「なぜそう判断したのか」「自分は何をすればいいのか」です。
料理で例えるなら、レストランで食べたいのは完成した料理です。「最初は塩を入れようと思ったけど、やっぱり醤油かな……いや、味噌も試して……」。そんな調理中の独り言を 30 分聞かされても、お客さんは困ります。完成した一皿を出し、「この料理はこういう特徴があります」と説明してもらった方が、ずっと価値があります。
考える過程は自分のため、話す内容は相手のため。この 2 つを意識して切り替えるだけで、説明は驚くほど分かりやすくなります。
