こんにちは！クラウドソリューション開発部の今野です！
突然ですが、後輩への指導やチーム内での仕様説明で「なぜか上手く意図が伝わらない…」と頭を抱えたことはありませんか？
実はエンジニアの業務において、「人に教える・伝える力」はコードを書く技術と同じくらい重要です。
今回は他者への教え方について、少しでもナレッジが共有できればと思います。
誰かに教える時に、「なんか上手く伝わらない…」と思ったことはないでしょうか。
プロジェクトで新たにアサインした方がいる場合、情報量の多い内容をどうやってわかりやすく伝えるのか。
図や具体例を出しても良いでしょう。
ですが、図や具体例はわかりやすく伝える「手段」であるため、相手の状況や求めていることを伝える側で理解していないと、「話が伝わらない」ということになってしまいます。
私自身も悩むことがよくありました。どうやったらわかりやすく教えられるだろうか、腑に落ちるような教え方は…?
今も模索中ですが、大切だなと思うことをまとめておきたいと思います。(自分の備忘録としても)
伝え方による行動の変化
1つ目は「伝え方による行動の変化」です。
大袈裟のように見えますが、言い方1つで相手の行動が決まるといっても過言ではありません。
学校での例になりますが、実際によくある一例を紹介します。
小学校低学年が30人。廊下に並びます。
先生が「静かに廊下を歩きましょう。」と言っています。
「何か面白いことないかなー。」
一人の子が静かな雰囲気を壊すことが面白くなって、
「ダンダンダン！！」(足踏み)
周りの子どももつい面白くなってしまい、みんなで足踏みを始めました。
「ダンダンダンダンダンダン！！！！！！！…」
「静かにしなさい！！」
先生が何回注意しても、もう止まりません。
よくある光景です。
そこで伝え方を変えてみましょう。
「廊下を豆腐だと思って歩いてごらん。」
子どもたちは「豆腐？」床が豆腐になったことを想像します。
すると面白いことに子どもたちは「豆腐…豆腐…」と床に対して慎重になりながら歩き始めるのでした。
もちろん、その後の注意が必要でないことは言うまでもありません。
先生は何をしたのでしょう。
ただ言葉を変えただけです。
「静かに廊下を歩きましょう。」→「廊下を豆腐だと思って歩いてごらん。」
柔らかい豆腐を踏みつぶさないように慎重に歩くイメージが湧くため、廊下を豆腐と例えています。
先生の中で伝えたい裏の意図(廊下を静かに歩いてほしい)は同じままです。
このように伝え方1つで相手の行動が定まることがわかります。
ビジネスシーンにおいても同じようなことが言えます。
スライド作成を部下に依頼しています。ですが、誤字脱字が多いため、資料の精度を上げて欲しいといった要望を伝えたいです。
「誤字脱字がないように、しっかり見直してください。」
的確ではありますが目的が不明瞭なため、ただ文字を直す、といった行動で終わってしまいがちです。
これを次のように言い換えてみます。
「明日、役員がクライアントに見せるスライドだと思って最終確認してみて。」
すると、確認の解像度を上げると共に、どのように書いたら役員に伝わりやすいかをイメージしやすくなるため、スライド全体を見直すきっかけにもなります。
また、エンジニアの日常でも全く同じことが起きます。
例えば、後輩にコードレビューで指示を出す時です。
「将来の仕様変更に耐えられるよう、変更しやすいコードにしてね。」
を「クライアントが来週『やっぱりここ、丸じゃなくて四角にして』って言ってくる前提で構造を組んでみて」
と言い換えることで、「変更しやすさ」の基準が曖昧で、余計な抽象化をしてしまったり逆に何も対策しなかったりすることが、
「どこをインターフェースにして切り離しておけば良いか」という具体的な設計方針（行動）に直結することになります。
「伝わらない原因は自分にある」という考え方
2つ目は教える人自身の考え方になります。「伝わらない原因は自分にある」という考え方。
よく誤解されがちですが、かなり大切なことです。
理由はシンプルで、「相手が良くないと思っていると自分の教え方が向上しないから」です。
実際に相手の理解が追いついていないということもありますが、伝え方を変えることでどんな人でも誰でも理解できるはずです。
一言二言で相手がすっと腑に落ちる…そんなピンポイントで響く伝え方を目指してみませんか？
相手の「前提知識」の把握
3つ目は「相手の「前提知識」の把握」です。
いきなり難しい用語を未経験の人に投げかけても、難しいのは当たり前。
そのため、
- 何を知っているか
- どこまで知っているか
- 何を課題としているか(←ここまで把握できたらベスト)
を知っておく必要があります。
例えば、営業メンバーに「新機能のAPI連携」について説明する場合を考えてみてください。
相手がバックエンドの仕組み（前提知識）を知らないのに、「今回のAPIはWebHookでキックされてレスポンスをJSONで返します」と説明しても理解できません。
相手が知りたい（課題）のは「顧客に対してどう提案できるか」「裏でどうデータが動くか」です。
この場合、「スプレッドシートに転記していた作業が、ボタン1つで自動で同期されるイメージです」と相手の前提知識（スプレッドシートの操作感）に合わせて説明することで初めて、「あ、じゃあお客様にはこう提案できますね！」と話が噛み合います。
「どこで躓いているか（記号の意味なのか、概念なのか）」を見極めて前提を揃えることが重要です。
相手の言語・習慣に合わせた言葉選び
4つ目は「相手の言語・習慣に合わせた言葉選び」です。
説明する相手は誰でしょうか？ 経験豊富なシニアエンジニアですか？ それとも非エンジニアのクライアントでしょうか？
相手の「普段使っている言葉・日常の習慣」に領域を合わせる必要があります。
例えば、システムのトラブル時、非エンジニアのクライアントやPMに「データベースでデッドロックが発生して排他制御がかかりました」と説明しても、相手は不安になるだけです。
これを相手の感覚に翻訳するなら、こう言い換えます。
「スーパーに行って、1つのレジに2人の客が同時に並んでしまい、お互いに譲り合ってレジが一時的にストップしたような状態です。」
こう例えることで、相手は「あ、物理的に重なって固まっちゃったんだな」と直感的にイメージでき、不要な混乱を防ぐことができます。
相手に合わせた姿勢・目線（非言語コミュニケーション）
5つ目は姿勢・目線に関してです。
無意識にやっていることではありますが、小さい子どもの前でかがんで話すことはこれにあたると思います。
相手に合わせた姿勢や目線を心掛けることで、興味関心をもってもらうことができます。
具体的には以下の方法があります。ビジネスでも日常でも取り入れやすい方法ではないでしょうか。
-
質問の選択（オープン／クローズド）
いきなり「何でも自由に言って」と丸投げせず、相手が答えやすい「YES/NOで答えられる質問（クローズド）」から入る。
-
ペーシング（話すペースを合わせる）
相手の「話す速度」「声のトーン」「頷くタイミング」を同調させ、会話のテンポを作る。
-
ミラーリング（姿勢・仕草を真似る）
相手が飲み物を飲んだら自分も飲むなど、身体の動きを鏡のように合わせることで無意識の親近感（ラポール）を生み出す。
文字ではなく「映像」での説明
6つ目は話す時にどのように頭の中でイメージを描く必要があるのかについてです。
これは以前の記事でも紹介させていただきました。
道案内をする時に、自分が実際に歩いたときに見える映像をそのまま言葉として投影しながら話す。
教える側にとっても実体験に近いので、教えやすいですし、教わる側も映像を見ているような感覚になるので、腑に落ちやすいかと思います。
また、説明をする際に「最後まで一度に話さない」ということも大切です。
こちらは経験談になりますが、
報告事項を始めから詳細に伝えようとすると、伝える内容が一度に長くなりがちになっていたため、
簡潔に伝える→「レスポンスを確認する」→レスポンスに合わせた詳細を伝える
という過程を踏むことで、相手が求めている内容に沿った情報を伝えるよう心掛けていました。
最後に
今回は「教え方・伝え方」についてお話ししました。
学生時代の塾講師の経験でも、現在のエンジニア業務でも共通して強く感じるのは、「教え方一つで相手の行動やモチベーションは大きく変わる」ということです。
「なぜ伝わらないのか」と相手を責めるのではなく、相手と同じ目線に立って「何に躓いていて、何を求めているのか」を解きほぐす。
まず自分から相手を理解しようとする姿勢こそが、納得感のある対話を生み出し、チーム全体の成長やスムーズな開発へ繋がります。
この記事が、皆さんの日々のコミュニケーションや後輩育成のヒントになれば幸いです。
私たちは1人1人がコミュニケーションを取りやすいと思えるような職場の環境作りを心掛けています。
チームでの円滑な開発や人材育成を大切にしている当社で、一緒に働きませんか？
募集要項はこちら
最後までご覧いただき、ありがとうございました！
