あらすじ
正しいことを言っても、伝わらない、揉める…。
そんな悩みを抱くエンジニアに贈る、
「高解像度」のコミュニケーション本が誕生！
「技術的には可能です」
「コードを読めばわかる」
「仕様です」
つい、こんなフレーズを口にしてしまうエンジニアは少なくありません。しかし、論理的には正しくても、「伝え方」が間違っていると、誤解やすれ違いが生じ、結局損をしてしまうことも…。
本書は、エンジニア出身の「超ホワイト」IT企業を経営する著者が、そんな「すれ違い」を起こさないためのコミュニケーションの技法を解説。経営、営業、開発など多様な側面が見える著者だからこそ、
・無茶な案件を安請け合いする営業との対立
・「ざっくり」など曖昧な指示による混乱
・一見軽微な修正が招く「デグレ地獄」
・相手を責めるようなコードレビュー
など、「あるある」なミスコミュニケーションの事例を紹介しながら、具体的な解決策を提示していきます。
さらに各章の導入をマンガにし、シチュエーションをイメージしやすくしました。
生成AIの台頭で、エンジニアの「コミュニケーション力」の重要性が増す今、本書を読めば、生産性や評価をアップさせるスキルが身につきます！
■こんな人にオススメ
・他職種のメンバーにうまく話が伝わっていないと感じるエンジニア
・正しいことを言っているのに摩擦が生じがちなエンジニア
・エンジニアとのコミュニケーションに悩みを抱える非エンジニア
■目次
第1章 正論が通じないのはなぜなのか？
第2章 伝わるエンジニアになる10のメソッド
第3章 営業と開発はなぜ仲が悪いのか
第4章 経営と開発のすれ違い
第5章 デザインと技術の衝突
第6章 上司とエンジニアの摩擦
第7章 エンジニア同士の技術的対立
感情タグBEST3
Posted by ブクログ
技術系と一括りにされることは違和感がある。技術者はまるでコミュニケーション能力がないと言われているみたいだ。とはいえ技術者にかぎらず、人の話は正しく伝わらないと考えておく必要がある。言わなくて分かるよね、は通じない。日本人同士でも伝わらないのに、外国人とビジネスするときはもっと伝わらない。
Posted by ブクログ
【書籍の要旨】
「技術的には可能です」とか「仕様通り」という
IT現場ではよく聞く話。
これはある側面では正しいことを述べているが、
そもそもの前提がズレている
ことが大半で、鵜呑みにすると後で手戻りとなり、
結果的に大きな負債を抱えてしまう。
そうならないためにも、何を伝えるのが良いかを
学ぶことが出来る書籍です。
【主なトピックと学びになったこと】
・正しいを形作る４つの軸
①技術
②価値
③時間
④リスク
・コミュニケーションの好循環
コミュニケーションはインプットとアウトプットの
循環で成り立っている
聴く
新しい情報が入る
アウトプットが洗練される
対話が深まる
・相手の発言の根拠は必ず確認すること
・相手が傷つくかもしれないからという理由で
フィードバックをしないのは相手の成長機会を
結果的に奪っていることでもある。
相手の成長を願ってフィードバックをするという
姿勢があれば一時的には傷つくかもしれないが、
そこまで傷つくことはない。
・認識齟齬が生まれるポイント
①判定基準があいまい
②合意形成が出来ていない
③決定事項が明文化されていない
・判定できる言葉で書くために
①意図を正確に聴き取る
②完了条件を明文化する
③合意事項を記録する
・シンプルに報連相するコツ
①結論を書く
②理由と影響を説明する
③期限とその期限到達時点の状態を明確にする
④必要に応じて上記の補足説明をする
