Photo by Open Knowledge Foundation Deutschland
こんにちは。谷口です。
最近はリモートワークをしているエンジニアの方も増えてきたかと思います。（エンジニアに限った話ではありませんが…）
以前piazaでリモートワークにおける課題をアンケート調査しましたが、もっとも多かった課題は「コミュニケーションのとりづらさ」でした。
「エンジニアは一人でもくもくと進められる仕事」というイメージを持っている人もいるかもしれません。が、実際は組織に所属してチームでプロダクトを作るわけですから、コミュニケーションは欠かせません。（エンジニアに限った話ではありませんが…）
というわけで今回は、リモートワークが主流となったエンジニア組織におけるコミュニケーションに必要なことについて考えてみます。
リモートにおけるコミュニケーションの複雑化
もはや一時的なものではなくなったリモートワーク、もう一年以上会社に出社していない…なんてエンジニアの方も多いのではないでしょうか。かくいう私も昨年の3月以降一度も出社していません。
リモートワークは通勤のストレスもなく、自分に合った環境とペースで仕事しやすいなどのメリットがあります。一方で、チーム開発を進めるために状況や情報を共有したり、議論や相談、ヒアリングや雑談、加えて求人応募者との面接などなど、仕事で細かなコミュニケーションが発生する場面は数え切れないほどあります。
「別にSlackとzoomがあれば足りるし」と思っている人もいるかもしれませんが、特にチームリーダーなどでマネジメントや採用を担当している方々、転職先に入社したばかりだけどリモートせざるを得ない方々などの中には、こうしたコミュニケーションの難度が上がっていると感じている方も多いかと思いでしょう。
発生しがちな課題
出社していた頃からコミュニケーションは苦手だったという方もいるかと思います。オンライン通話でのコミュニケーションは、対面とは違い一人ずつしか話せない、音質や画質によって情報が伝わりづらい、そのせいで対面のときよりも話さない人が出てくるなどといった問題が発生しがちです。
一人で話し続ける人が発生する
zoomなどのオンライン通話では、1対全員で話す形になってしまい、一人で延々と話し続ける人、悪い意味で話好きな人、話しながら話す内容を考えるような人の独壇場になってしまいがちです。
逆に全然話さない人が発生する
特にファシリテーターがいない場合、話さない人がいてもそのまま放置されやすく、いつも何も言わない人というのも発生してしまいがちです。
新メンバーと打ち解ける機会がない
リモート前から一緒に働いていた社員同士であれば、リモートへの移行もそれほど問題ないでしょう。しかし、新しく入ってきた人にとっては、チームメンバーとちょっと一緒にランチしたり雑談したりする機会もない、どんな人がいるのかわからない、チームの雰囲気もわからない、こんなこと聞いてもいいのかわからない、どこまで自分で判断してよいのかわからない…などとわからないことだらけで、サポートが不十分だと入社早々孤立してしまう場合もあります。
評価が難しい
リモート中心になってくると、勤務態度や労働時間のような成果以外のものは見えにくくなってしまいます。（そもそも、エンジニアの業務は知識集約型で成果物ベースで評価されるべきだとは思いますが）今後はよりエンジニアをきちんと成果で評価できる評価制度が必要となるでしょう。
組織規模で必要なコミュニケーションの変化
コミュニケーションの不具合の解決を個人任せにしておくのは限界があります。できれば組織やチームの規模で、マネジャーが先頭に立って改善していくよりほかありません。
オンラインでは意識して適度にあいづちを打つ
基本的なことですが、オンライン通話の場合、対面で直接話しているよりも、聞き手の反応がわかりづらくなってしまいます。
ふだんよりも意識してあいづちを打ったり、うなずいたりして、「聞いているよ」と伝わるリアクションをとりましょう。反応が少ないと、向こうも「ちゃんと聞こえているのかな」「説明や質問の内容が理解できているのかな（もし聞こえていなかったなら聞き返してほしいな）」と不安になってしまいます。
チーム全体が発言しやすい雰囲気づくり
例えば、「進捗問題ありません」と言うしかない空気が漂っている進捗会議…なんて意味がないですよね。いつもオンライン会議がすぐに終わってしまう、意見が出ない状態が続いている場合、それは業務がスムーズすぎて問題がないのではなく、むしろチーム間に話しにくい空気が漂っているおそれがあります。
何か起きてから「なぜもっと早く言わなかったのか」とメンバーを問いただしたところで、もとはといえば発言しやすい雰囲気のチームビルディングができていないマネジャーが悪いのです。
例えば1on1で「ぶっちゃけこのタスクきつくない？」といったことを聞いてみたり、一緒に解決策を考えたりする。会議の場ではちゃんと全体を見てファシリテーションする。など、気になることがあればすぐに声をあげられる、「この人になら言える」と思われるようなチームを作っていく必要があります。
人数が多い場でのファシリテーション
会議や打ち合わせなどの場では、ファシリテーター（進行役）がいないと対面のとき以上に収拾がつかなくなってしまいます。
企画の担当者や提案者などいない場合は、マネジャーが全体を見回して、話を振ったり意見を聞いたりして、積極的にファシリテーションしましょう。ファシリテーターをメンバー間で回していく場合もあるかと思いますが、最初に手本を見せたり、慣れていない人に対しては積極的にサポートしていきましょう。（じゃないと苦手意識を持たれてしまいかねません）
また、会議室などの場所の確保などが必要ないぶん、リモートの会議は延長してしまいがちです。無駄な延長でメンバーを疲弊させないよう、タイムマネジメントに気を配ったり、タイムキーパーを立てたりしたほうがよいでしょう。
コミュニケーションの機会を増やす仕組みづくり
特に新メンバーを受け入れる場合などは、歓迎ランチなど、コミュニケーションや雑談が発生しやすい場を業務として設置しておかないと、いつまでも打ち解けることができません。
「開発業務と関係ないコミュニケーションは必要ないし面倒くさい」と思う人もいるかもしれませんが、ある程度お互いの考えや背景を理解したり、信頼しあえていないと、リモートでチームワークを発揮していくのは難しいのではないでしょうか。
この場合も会議と同じで、今まで接点がなかった・少なかった人同士を放り込んで「はい、適当に雑談でもして打ち解けて」というのも難しいので、リーダーやマネジャーなどが積極的に話題を提供したり、話を振ったりすることが必要です。（もちろんメンバー同士が慣れてきたら減らしていっていいと思いますが）
評価制度の見直し
勤務態度みたいなあいまいなものは見えなくなりますから、きちんと成果を見て評価できる評価制度も整えなければなりません。「勤務体系は変わっても評価制度は変わりません、個人でうまくやってください」なんて状態では、優秀なエンジニアから愛想をつかされてしまいます。
メンバーがどれだけ働き何を作ったのか、どこでどんな問題が起きているのか、正しくつかむには、チャットやメールによる日々の連絡や質問、成果の把握などが重要です。そうして評価をする側・受ける側が連携をとって、エンジニアをきちんと成果で評価できる土壌と評価制度を作っていけるとよいでしょう。
まとめ
前述の通り、もはやリモートワークは一時的なものではなくなりました。特にエンジニアの場合、今後もこのような働き方を選択する人、また選択できる企業がより一般的になっていくでしょう。ということは、仕事で欠かせないコミュニケーションも、それに適応できる形をとっていくことが重要なのだと思います。
paiza転職では多くの求人掲載企業が、オンラインで自宅から受けられて、企業側からも事業内容や業務に関する説明が聞けるカジュアル面談を実施しています。
またpaizaの転職成功ガイドでは、採用選考におけるさまざまな落選理由や悪い例、改善のためのアドバイスなどを公開しています。実際にpaizaから応募をされた多くの方から「参考になった」という声をいただいています。面接に苦手意識のある方は、ぜひごらんください。
paizaの転職成功ガイドについて詳しくはこちら
paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
詳しくはこちら
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
詳しくはこちら
