相手に合わせた抽象度を探究して
こんにちは！@Ryo54388667です。
今回は、説明の仕方について思ったことを備忘録がてら書いてみました。
そもそものきっかけ
ある日、同僚がエラーの相談を上長にした時、同僚と同じ立場の僕に対して行った説明と全く同じだったことに違和感を感じました。
「経歴や立場も異なる相手に、同じ説明の仕方で良いのか？」
その時はなんとなく違和感を感じただけでしたが、自分の中で整理ができたのでここに記録として残しておきます。
まず具体と抽象について
わかりやすい例として、生物の分類があります。
生物 => 魚類 => サンマ => 太平洋ミニサンマ
(引用: イラストや)
このように、右に進むほど具体的なカテゴリーになります。
この例と同様に、説明が詳細になるほど、それは具体的な説明と言えるでしょう。
❓具体的な説明が常にベストなのか？
「抽象的だ」という言葉は、多くの場面でネガティブに受け取られることが多いです。
矢継ぎ早に、「もっと具体的に説明して」と言われることも多いでしょう。
僕も今、この記事を書いていて当時の上司の声が脳内で再生されました…😇
しかし、これはいかなる場合も正しいのでしょうか？
結論、説明は相手に合わせた抽象度で行う必要があり、必ずしも具体的であることが最良ではない、 ということです。
例えば、自分がコーダーで、同僚と画面作成の作業中に、複数の画像表示でエラーが出てしまったとします。この時、「同僚」、「上長」、「バックエンドエンジニア」のそれぞれに相談する際、どのように説明しますか？
まず、上長に対しての説明を考えてみましょう。
上長に対して、「変数imageListをforEachで展開し、next/imageを利用して…」と言う説明をするのはどうでしょうか？
これは同じコーダーの同僚に対する説明なら納得します。しかし、上長の場合どうでしょうか？エラーの原因の特定というより、より上位の、最終的には何がしたいか」のほうが聞きたい説明ではないでしょうか？上長は技術的な詳細(具体)よりも「最終的に何が実現したいのか」「どのように進めるべきか」などの情報(抽象)を求めているかもしれません。
次に、バックエンドエンジニアに対しての説明を考えてみましょう。
「フロントエンドで複数の画像を一覧表示しようとしているのですが、特定の条件下でエラーが発生しています。APIリクエストを送った際、予期しないレスポンスが帰ってくることがあるようです。具体的には、リクエストパラメーターに特定のフィルタを設定した場合にこの問題が発生するようです。APIのレスポンスに何か異常があるか、もしくは私たちのリクエストの仕方に問題があるのか確認していただけますか？」
バックエンドのエンジニアに対する説明の抽象度は難しいです…🤔
主に関心を持っているのはサーバーサイドの問題やデータフローなので、そちらに寄せた説明をできるといいですね！
抽象度を誤った説明をしてしまうと、先ほどのサンマの例で言うと、太平洋ミニサンマを知らない人にひたすら、その説明をしたり、逆に、太平洋ミニサンマを知りたいのに、魚類の説明をするなど、話が全く噛み合いません。
このように、同じ事象であっても、受け手の立場や背景知識によって、適切な抽象度での説明が求められます。
ここで、
「いや、むしろファクトをはっきりさせないといけないから、説明は具体であればあるほど良い」 という反論もあるでしょう。
確かに、具体的な情報を提供することで、あいまいな表現や解釈の余地を減らせます。しかし、具体をつめすぎても、結局伝わらなければ意味がありません。説明の具体性はその状況や受け手のニーズに応じて適切に調整することが必要になってきます。
その人がエンジニア上がりで、上流から下流まで全て把握しているような全知全能のゼウス系プレイヤーなら話は別です…💪
💡具体と抽象の往還
しかし、他人と抽象度を合わせるのは非常に難儀です。
そのためトレーニングが必要でしょう。
説明をする際は、常に相手が何に関心があるのか、また自分がぶつかったエラーの前に何を解決したいのかを明確に言語化することが、抽象度のトレーニングに寄与すると思います。また、適切な抽象度は人によって様々です。この適切な抽象度を探るためにも、日々、どんな説明が「サンマ」に相当するのか、あるいは「魚類」に相当するのかを自分自身で理解しなければなりません。これがトレーニングです💪
説明をする際は具体と抽象を往還しながら、相手の抽象度を探究することが必要ではないかなと思いました。自分もまだまだ未熟なのでこの点を意識しながら業務に取り組んでいきたいところです〜
最後まで読んでいただきありがとうございます!
気ままにつぶやいているので、気軽にフォローをお願いします！🥺
Discussion