サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

旧館より 考え方

教えてもらう、教える時に気をつけていること

投稿日:2008年1月8日 更新日:


仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。
↓は自分が教える = 伝え手の場合に気をつけていることです。

1:論理や順序の飛躍をしない

当たり前なのですが、せっかちな人程してしまいがちだと思います。

思考と会話が追いつかずに(逸る気持ちばかりが前に出てしまい)飛躍してしまいます。
また、自分自身が試行錯誤して苦労した過程をすっ飛ばして、凝縮してダイジェスト的に伝えてしまい、飛躍してしまうこともあります。

例として適当ではないかもしれませんが、コマーシャルなんかの映画ダイジェストでは「なんかイメージはつかめたけど詳細はよう分からん」(もちろんコマーシャル的には興味を喚起できれば良いわけですが)となります。

その結果、いざ聞き手が実践しようとすると「自分の腑に落ちていない」ため、うまく出来ないことが多いと思います(「分かった気になっていたけど…」という感じです)。

2:一度に多くを伝えない

1でも書きましたが、伝え手にとって既知である故、また状況によって時間的制約等があって、一度に多くのことを伝えようとしがちです。そしてその結果上に書いたように飛躍をしてしまいます。
これは未知の事柄と対面している聞き手は消化不良を引き起こしがちです。

この1と2に嵌ってしまうと…

聞き手:「分かったようでなんか分からない」だから「もう一度聞く」
伝え手:「前に話したし、時間も無いのに」だから「より勢いよく(=飛躍して)話す」
聞き手:「(より飛躍しているので)何が分からないのかすら分からなくて」だから「イライラして聞く」

…と悪循環に突入します。
結果、予定していた時間、リソースより多くが必要になります。また感情的にも双方満足できないことになります。

3:伝え手ではなく、聞き手にあった形に伝える

伝え手が「論理的な文章」でキチッと説明されるのがあっているとしても、聞き手は、擬音/擬態語が散りばめられた(そこでバァーとして、そっちにシャシャッとする感じで…)生き生きした言葉が分かりやすいかもしれません。
また別のある人にとっては図表を駆使した方が良いかもしれません。
※伝えるべき事柄によっても合う形も違いますが。

人によって「自分の腑に落ちる」形は違うので聞き手の鍵穴(腑に落ちる為には開ける必要がある)に合うように伝え手の鍵を変える感じです。合わない鍵で無理矢理ガチャガチャしても、鍵穴も鍵も傷ついて良いことはありません。

ではこのようなことを少しでも回避/防止するために、聞き手に対してアプローチしていることを考えてみました。

アプローチしていること

1:事前:「結果としてどのレベルに到達したいか?」を確認する

概略、さわりだけをサクッと知りたいのか…、仕事で実際に使えるようにガッツリ知りたいのか、それとも…という感じです。
これには、知りたい深さとその周辺知識への広がり(広さ)、そしてそれに使うことのできる時間の3要素があり、その組合せで到達したい(する)レベルが決まるものです。
これが伝え手と聞き手でずれていると、どっちか(だいたい聞き手ですが)がイライラすることになります。

2:途中:伝えたことを聞き手の言葉で言ってもらう

聞き手が消化不良を起こしていないか、(なんとなく)「分かったつもりだが実は分かっていない」状態でないか確認できます。
これの注意点は、その聞き手の言葉から話題が派生していき、本筋から外れていく…脱線していくことです。特に議論が熱くなっていると往々にしてあります。

3:事後:伝えたことが実践されているか確認する

内容によって確認できないこともありますし、また、アドバイスを聞き入れるかは聞き手の判断によるので難しいですが…。
また運動系は「分かっていても(身体がついていかず)すぐに出来ない」ことも多いですのでこれまた難しいですが…。
ただ、すぐに結果が出ないとしても、理解して聞き手の「腑に落ちている」のなら、意識しているはずなので、外から(特に伝え手が)見れば分かると思います。

逆に自分が教えてもらったりする時にはこれらを実践することが、伝え手/聞き手の双方にとって良い関係を築き、目的を達成する近道と思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: starmanseries via Visual Hunt / CC BY

-旧館より, 考え方

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

テスト工程

…とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。 今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。 しかし現実は単体テスト …

あるプロジェクトで工夫したこと

(QCD的に)成功したあるプロジェクトで工夫したことを備忘録のために書いておきます。 そのプロジェクトの特徴は以下の通りです。 【納期】サービスインの時期は確定しており、それまで約3.5ヶ月。 【要素 …

仕様変更における納得感の大事さ

システム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。 その仕様変更決定までの過程によっては、(SIerも含めた)プロジェクト関係者の納得感のある/なしが大きく変わり、それはアウトプッ …

社内システムは自分で作りましょうよ

SIerでは社内(情報)システムを自分達で作らない…内製しない…ことが多いのでしょうか? 「××社内システムの再構築の件ですが、○○ベンダーさんに発注することになりました」と報告を聞いていて、冒頭のこ …

「お医者さん」だって全部の病気を知らないでしょ?

仕事、プライベート問わず「パソコンの事」を質問されると結構困ります。 自分の知っている/使っているアプリケーション、OSに関する質問であれば、それなりに答えられます。 もし、答えが分からなくても、(経 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。