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