リモートワーク採用について

tl;dr

  • リモート採用する会社増えてきた
  • 採用しないのはエンジニア採用において不利じゃない?
  • リモート採用の前に基盤を整える必要(業務改善)

はじめに

最近リモートワークを採用してる採用がかなり増えてきたと思いますが、「リモートワークは絶対ダメ!」と断固拒否してる会社はデメリット部分にも目を向けてるんでしょうか?

もちろんフルリモートにすると色々と弊害が出てくる可能性はありますが、そのデメリットに関してはやり方次第だと思うのであまり触れません。 散々批判している記事はあると思うので。

採用で不利になる

エンジニアに限らずとは思いますが、騒々しいオフィスや不快感しかない電車通勤から解放されるのは、QOLを考える上でかなり重要だと思います。

昔はどうだったか知りませんが、Slack や appear.in などと言ったツールを使えば、どこで働くかはそんなに重要じゃありません。

そんな中「ウチは毎日出社してもらいます」とかいう姿勢の会社はよっぽど説得力のあることが言えない限りは「良く」映ることはないでしょう。現にリモートワークが認められている会社があるので。

Webエンジニアであれば、 仕様策定 -> 実装 -> デプロイ(かなり端折りました) というサイクルで仕事することがほとんどだと思うので、基本リモートワークでも回ります(環境さえ整っていれば)

リモートワークのための基盤作り

先ほど Slack や appear.in の例をあげましたが、ツールはどこまでいってもツールなので、単にそれらがあるから、という理由でリモートワークマンセーと言ってるわけではないです。

リモート導入に失敗した話

以前働いていた職場ではリモートワークを導入しようとして失敗してました。(僕は「失敗」を見る前に辞めているので伝聞情報もあります)

その時はチャットツールに Slack, リモート時は Sqwiggle をつけるという運用でした。

エンジニアのみリモート可で、ポジションが上の方のエンジニアに関しては出社が義務付けられていました。すでにダメそうな匂いがしてますね。

それまではそんなに Slack が使われていたわけでもなく、ほとんどのコミュニケーションが口頭で行われ、ドキュメントを残す文化もありませんでした。

なのでリモートワークになっても「どうやったら前と同じようなコミュニケーションがとれるか」ということを考えていたように思えます。

仕様の話し合いをするときは画面を見せたい -> hangout なら画面を写せる -> ちょっと使いづらい -> xxx さん家はネットが遅いからイライラする… とまぁ全然ダメそうな感じで、結果ダメでした笑

リモートワークなりのやり方を探す

少し考えればわかりそうなものですが、物理空間で行ってた方法をそのままリモートに持っていくのはほぼ不可能だと思っています。

リモートワークを批判する人はそこがあまり考えられてないんじゃないかなと哀れんでしまします。かわいそう :cry:

なので今から導入する、という組織はそれまでにやってきたやり方を一回捨てて、どうしたらちゃんと回るようになるか、新しいワークフローを考える必要があると思います。

エンジニアに限った話ではありますが、そこまで難しいとは思ってなくて、厳密なルールを設けておけば大抵はうまく回ると思います。

個人的に必要そうなのは以下の2つ

  • コミュニケーションは基本非同期。メンバー全員がそれに慣れる
    • レスが極端に遅い人や、即レスがこないとイライラするタイプの人はリモートに向かないので人格を磨いてください
  • ドキュメントを残す文化

あとあればいいなと思うのは、納期に遅れた場合にペナルティを課すのはいいと思います。サボる人は本当にサボることばかり考えているので、ひどい人は会社を去ってもらうなどの対応をした方がいいです。

一切出社しないというのはなかなか難しいと思うので最初のうちは週1くらいで顔を合わせるようにする、とかってする方がいいと思います。

まとめ

かなり抽象的な話でしたが、個人的にはリモートワークの前に業務改善してね、って感じです。

もっとリモートワークが一般的になりますように :innocent: :pray:

Contents