様々ケースについて事例をベースに解説しており、わかりやすい。 あまり本を読まない人でもテンポよく読めて、年次が若いといろいろ学ぶ点も多いと感じた

ITエンジニアのための察する力についての本。 最近やけに、上司や同僚の先輩から、相手とスムーズなコミュニケーションや、相手に配慮したメールを書いてほしいといわれるので読んでみた(内心、そんなこと言われてもコミュ症なんだよ…とは思わなくない)。 まあでも、性格は変えられないから、コミュニケーションのスキルを磨いていって実践するようにしようというこの本の内容は、共感を覚えた。意識できて取り組めるようにしたい。 何より、「わからないことは正直にたずねる」というのは大事だろうなと思う。ただ、自分の場合、話を聞いている時にはなんとなく分かった気にはなることがあるおで…。後々思い返すと、よく分からないなとはなるのだけど、会話でスムーズで分からないことを質問できる自信がない。上司から何か依頼をうけて分かったような返事をしても、後になって、「どういうことだ？」とか「もしかして、自分の思ってたことと違うか？」というようになることが度々ある(さすがにその時は、もう一度確認するけど)。 「ARCSモデル」という言葉は初めて知った。「注意喚起（Attention）」「関連性（Relevance）」「自信（Confidence）」「満足感（Satisfaction）」の略で、その順で人に伝えることで、相手の学ぶ意欲を刺激させることができるらしい。ただ、理論は分かるけど、難しそうだなぁ。何が「注意喚起」になるとか、すぐに分かるものなんだろうか。 コミュニケーションについての話ではないけど、「ユーザに何か努力を強いたり、余計なことを考えさせたり、不安を感じさせたりしたら、そのシステムは不親切だよね。エンジニアとして、ボクたちは、そこまで考えてモノ作りをしなきゃいけない」という言葉は、自分も最近似たようなことを上司に言われたので、自分は多いに反省しなきゃいけないところだろうと思う。「そここだわるか？」と思う事も多いのだけど、もっとユーザー目線でシステム開発するようにしていかないといけないなと思う(それが難しいのだけど…)。 後、否定的な言葉で返すのではなく、肯定的な相槌をうつのが大事というのも、自分が反省しないといけないところだろうなと思う。ついつい、人の意見を、「それはおかしくないか」と思うと否定的な言葉を言ってしまうことがある。最近は意識して言わないようにしてるけど、逆に何も言わないようになってしまうので、うまいこと肯定的な言葉で返せるようになりたい。

2017年10月20日読了。ITエンジニアが社外・社内で遭遇する「コミュニケーションが必要な局面」でのNGケース・OKケースを解説する本。「相手の身になって考える」ことが結果的に自分の仕事も回りやすくする、ということは繰り返し実践しながら学んでいくしかないとは思うのだが、「意識して臨む」ことは大事だよな。本書も書かれていることは当たり前のことだが、読み手目線というか非常に具体的な内容で、改めて気づくところも大きかった。「言い方ひとつで変わる」は社外でも社内でも同じ、どうせ変わるなら良い方向に変えていきたいものだ。

お客さまとのコミュニケーション、 社内でのコミュニケーションをとる際のポイントを 事例を含めて書いてくれている本です。 基本的なことではありますが、 意外と出来ていないなと気づかされました。 【勉強になったこと】 ・教育学者ジョン・ケラーのARCSモデル 　Attention：注意喚起 　Relevance：関連性 　Confidence：自信 　Satisfaction：満足 　あれっと気づかせて、自分にも関係があると 　感じさせ、自分でも出来そうだと思ってもらい、 　なるほどと理解・満足してもらうって流れ。 ・相手の質問の背景を探るのは大切。 　人は質問の中ですべてを出し切れているとは 　限らないし、むしろ出ていないことが多い。 　行間を読むのではなく、分からないことは聞く。 ・相手も自分も尊重する態度で接するのが良い。 　上記のような接し方をアサーティブという。 　アサーティブな表現を使うためのポイント。 　①「なぜ？」ではなく、依頼や提案の表現に。 　②可能な限り、肯定文を使う 　③「私」を主語にして話す。 ・後輩の悩み相談のときは、アドバイスをするより、 　まずは聞くことが大事。話している内容を 　一緒に深堀りしてあげて、解決策について、 　今考えていることを聞き出すだけで済むのなら、 　アドバイスはあえてしない。 　アドバイスするのは何も思いついていないときだけ。 ・後輩に与えた仕事のレベルが適切かどうかは、 　自分の頭で考えることが出来ているかどうかで 　判断するとよい。 　言われたことしか出来ないのであれば、 　その仕事を実施するレベルに到達していない証拠。 　考えるためには「前提」となる知識や経験が 　ないと出来ないもの。 ・リーダーシップにはＰとＭがある。（ＰＭ理論） 　Ｐ機能： 　　仕事の遂行に関する影響力 　Ｍ機能： 　　人間関係の維持に関する影響力

エンジニアはとかく技術力ばかりに目が向きがちだけれど、仕事が1人で完結するのでないかぎり、対人スキルも同じくらい重要。

まさにIT業界あるあるのコミュニケーション不全ケースが満載で、それをどのように改めると良いかがとても丁寧に説明されています。話し手あるいは受け手として物事の背景や目的をなぜ共有すべきか、そしてそれはどのようにして共有すべきかについては、さっそく背景と目的を明らかにした上で、社内で共有しました。一度話をしただけでは相手に伝わらないことも改めて確認です。

察する力は人と人との関わり合いの中でなくてはならない力だと痛感する。 事例形式で書かれているので、思い浮かべやすかった。 似たような事も仕事をしていくなかであるし、なるほどと思う事も多かった。 察することによって相手に気持ちが伝わるし、たとえ察したことが間違っていたとしても悪い気持ちはしないのではないかと思う。 気にしてもらえているとか、自分の事を理解しようとしてくれているとか、気持ちが伝わるので。 読みやすい形式で書かれていて何度でも読み返しやすい。