NEW! スキル
レビュー文化を持つエンジニアにとって、他者からフィードバックを受けることはもはや仕事の一部。とはいえ、「指摘を受ける・する」というのは決して楽なことではない。
「責められている気がして怖い」「良かれと思って伝えているつもりが、後輩が萎縮している」……フィードバックを受ける側もする側も、そんな抵抗感やもどかしさを感じているケースは多いだろう。
なぜフィードバックがうまく機能しないのか。フィードバックを良い機会にするためにはどうすればいいのか。そんな悩みを、書籍『「技術的には可能です」はなぜ伝わらないのか エンジニアのコミュニケーションの教科書』（KADOKAWA）の著者であり、システム開発会社であるアクシアの代表・米村 歩さんにぶつけてみた。
アクシア 代表取締役
米村 歩さん（@yonemura2006）
青山学院大学卒業後、システム開発会社に入社。その後フリーランスを経て、2006年にシステムの受託開発を行う株式会社アクシアを設立。既存のソフトウエアやサービスなどでカバーできない業務分野のWebシステム構築をはじめ、既存システムの保守・運用、サーバー構築までのトータルサービスを手掛ける。かつて同社では長時間労働が常態化していたが、12年に残業ゼロを断行し、現在も継続中。有給消化率は100％。17年 にホワイト企業アワード 労働時間削減部門 大賞を受賞。20年にはオフィスを廃止し、全社員完全リモートワーク化を実現。著書に『完全残業ゼロの働き方改革』（プチ・レトル）、『「技術的には可能です」はなぜ伝わらないのか エンジニアのコミュニケーションの教科書』（KADOKAWA）など
ーーエンジニアとして働く上で、上司や先輩からの「フィードバック」は必要不可欠ですよね。米村さんご自身が若手エンジニアだった当時、フィードバックを受けることに対してどう感じていましたか？
コードレビューや設計のレビューで何度もフィードバックを受けてきましたが、「貴重な学びの機会」になったことも、「なんだかすごく嫌な体験」になったこともあります。
エンジニアには、書籍やネットを通じて自主的に技術を学ぶ習慣が身に付いている人が多く、私もその一人です。ですが、第一線で活躍する先輩エンジニアから得られるフィードバックには、書籍からは得られない生きたアドバイスが詰まっていました。まるで自分専用のコンサルティングを受けているような感覚があったんです。
一方で、単なる粗探しや、自身の優位性を示す「マウント」をされていると感じるフィードバックもありました。そうなると、現場の空気はギスギスしますよね。
ーーなぜそういった「良くないフィードバック」が生まれてしまうのでしょうか。
フィードバックする側から「相手の成長を願って伝える」という大前提が抜け落ちてしまった結果ですね。
フィードバックの目的が「相手の成長」である以上、時に厳しい指摘も必要でしょう。それを避けることは、相手から成長のチャンスを奪うことと同じです。
ですが、フィードバックする側も感情がある人間なので、ヒートアップして無意識のうちに「どうしてちゃんとやらないんだ」という非難になってしまうことがある。これでは、相手の成長を願って発言しているとはいえません。
ーー相手を思う「厳しさ」を見失っている、と。
そうですね。軸さえブレなければ、厳しい指摘も有益なフィードバックになるはずです。
むしろ、「厳しいことを言ってはいけない」「優しく接しなければならない」という思い込みは、コミュニケーションを歪ませます。オブラートに包みすぎた結果、伝えるべき本質がぼやけて、かえって相手を混乱させてしまいかねません。冒頭で相手に対して「あなたの成長につながることだから」と宣言することも効果的ですよ。
さらに言うなら、フィードバックを良い機会にするためには、「する側」だけでなく、「受ける側」にもそれ相応の姿勢が必要です。
ーー「受ける側」も、ですか。「指摘を受ける」と思うと怖くて身構えてしまいそうですが……。
意識的な問題ですが、「相手は自分のためにこの場を設定してくれている」と心から理解することが大切です。
人間にはどうしても自己防衛という本能があります。そのため、何か指摘を受けるかもしれないと察知した瞬間、無意識のうちに心のガードを固めて身構えてしまう。それは誰もが抗えない自然な反応です。
だからこそ、前提として「未来の自分にとってプラスになるもの」だと捉えておくことで、相手の言葉が自然に受け入れられるようになるはずですよ。
フィードバックは「受ける側」と「する側」の両方がいて成立するキャッチボールのようなもの。する側が完璧な球を投げたとしても、相手が受け取る準備が整っていなければ成立しませんからね。
ーーフィードバックを良いキャッチボールにするために、「受ける側」は他にどんな工夫ができますか？
まず大切なのは、何を言われても「まずは聞く」ことです。
自分とは異なる意見を突きつけられたとき、最初から聞く耳を持とうとしない人は少なくありません。ですが、相手の意見を受け入れるかどうかは後で考えて決めればいいんです。
目の前に相手がいるその瞬間は、一旦聞くことだけに集中する。相手から投げられたボールをキャッチしないことには、次のターンで自分が投げるボールすらありませんから。最初から全て跳ね返すのではなく、どんな意見もまずは一回受け入れましょう。
過去に関わったエンジニアの姿を思い返してみても、フィードバックを受け止める力のある人の方が伸びているのは明らかです。
ーーとはいえ、数々の指摘を受けていると、気持ちが落ち込んでしまうこともありそうです。
人間である以上、その日のコンディションが「聞く姿勢」を左右することもありますしね。余裕を失っているときに、他者の言葉をフラットに聞き入れるなんて難しくて当然です。
なので、聞いたフィードバックを全部受け入れようとする必要はありません。「1～2割は取りこぼしてもOK」という割り切りも大事です。
その代わり、受け入れたフィードバックに関してはなるべく早く実践しましょう。行動を一つ起こすだけでもいいんです。「フィードバックに基づいて改善が進む」というプラスのサイクルが回るようになれば、個人だけでなく組織の成長にもつながっていきますよ。
ーーでは、フィードバックを「する側」は何を心掛けるべきでしょうか？
フィードバックを「する側」は、「受ける側」の状態に注意を払うといいですね。相手の様子がいつもと違ったり、どうも元気がなさそうに見えたりしたときは、「受ける側」が話を聞ける状態にない可能性があります。
そういうときはフィードバックが徒労に終わってしまいかねないので、機会を改めるという判断も必要です。
ーー自分が話すことばかりに集中して、相手の様子を軽視してはいけないということですね。
そもそも、一方的に何かを言ってくる人の話は聞きたくないですよね。
もし相手に「今は話を聞く余裕がなさそうだ」と感じたら、一度思っていることを全部吐き出してもらってもいいかもしれません。そうすると、先に言いたいことを言った分、今度は自然と聞く姿勢を持ってくれやすくなります。
ーー「受ける側」がしっかりと聞ける状態を整えることから始めるのが大切ですね。
あとは、一回のフィードバックで「あれもこれも」と詰め込みすぎないことも重要です。
つい「思っていたことを全部話そう」と意気込んでしまいやすいのですが、フィードバックは「受ける側」からすると少なからず負担になります。結果として余裕がない状態にさせてしまいかねないので、要点は1個か2個に絞るとよいでしょう。
ーー米村さんが代表を務めるアクシアには、どんなフィードバック文化がありますか？
書籍でも紹介した通り、アクシアでは二つのルールを設けています。
一つ目は「テキストでのフィードバック禁止」。表情も声も分からない状態だと、非言語情報が伝わらず予想外のニュアンスで受け止められてしまうことがあります。書かれていない行間を無意識のうちに読み取って不安になってしまう人は、想像以上にたくさんいると思うんです。アクシアはフルリモートですが、オンラインで直接伝えるようにしています。
二つ目は「一対一で伝える」こと。第三者が見ている前で晒さないということです。人の目があると萎縮してしまいますし、組織の雰囲気にも影響するので要注意です。
ただ、これらはあくまでもネガティブなフィードバックの場合です。当然ですが、フィードバックはネガティブなものに限りません。ポジティブな内容のものについては、チャットであろうと、人前であろうと自由に伝えていいと思いますよ。
ーー確かに、フィードバックと聞くと「指摘されるもの」と思いがちですが、良いフィードバックがあってもいいですもんね。
もう一つ見落とされがちなポイントを挙げるとしたら、フィードバックは「上から下へ」するものではないということ。本来フィードバックは全方向で行われるべきものですから、「下から上」があってもいいんです。
上司や先輩にフィードバックをするのは緊張しますし、抵抗感がある人もいるかもしれません。ですが、「相手や組織の成長のため」という姿勢を忘れなければ、耳を傾けてもらえると思いますよ。
フィードバックは、継続的な成長が求められるエンジニアにとって避けることができないものです。苦手意識を持っている人ほど、真摯に向き合い、自分自身や組織の成長につなげていってもらいたいですね。
「技術的には可能です」はなぜ伝わらないのか エンジニアのコミュニケーションの教科書
「技術的には可能です」「コードを読めばわかる」「仕様です」
つい、こんなフレーズを口にしてしまうエンジニアは少なくありません。しかし、論理的には正しくても、「伝え方」が間違っていると、誤解やすれ違いが生じ、結局損をしてしまうことも……。本書は、エンジニア出身の「超ホワイト」IT企業を経営する著者が、そんな「すれ違い」を起こさないためのコミュニケーションの技法を解説。経営、営業、開発など多様な側面が見える著者だからこそ、
・無茶な案件を安請け合いする営業との対立
・「ざっくり」など曖昧な指示による混乱
・一見軽微な修正が招く「デグレ地獄」
・相手を責めるようなコードレビュー
など、「あるある」なミスコミュニケーションの事例を紹介しながら、具体的な解決策を提示していきます。
＞＞詳細はこちら
取材・文／一本麻衣 編集／秋元 祐香里（編集部）
タグ
