エンジニア全般

【フルリモート vs 出社】エンジニアの働き方の理想を考える

フルリモート

reisuta

Webエンジニア | 20代中盤 | 大学時代はGmailすら知らないIT音痴でプログラミングとは無縁の生活を送る → 独学でプログラミングを学ぶ → Web系受託開発企業にエンジニアとして就職 → Web系自社サービス企業に転職 | 実務未経験の頃からVimを愛好しており、仕事でもプライベートでも開発はVimとTmuxを使っているので、VSCodeに疎いのが最近の悩み。何だかんだでやっぱりRubyが好き。

コロナ禍などで、
世間的に一気にリモートワークが浸透しましたが、
最近ではまた出社回帰の企業が増えてきました。

特に巨大テック企業のGoogleやZoomなどが
出社回帰したことは大きく話題になりましたし、
これらの企業の影響力は大きいので、
リモートワークはオワコンとまことしやかに囁かれることも、
増えてきました。

X(旧Twitter)やYouTubeとかはどうかというと、
フルリモートというと、
楽してるとか、絶対上手くいかないみたいな
巨大テック企業の出社回帰の減少も相まってか、
否定的な意見が多い印象です。

以上のことから、
世間的にはリモートワーク(特にフルリモート)について、
否定的に語られることが多いのですが、私はそうは思いません。
なぜなら、フルリモートには絶大なメリットがあるからです。

たしかにフルリモート特有のデメリットや、
出社ならではのメリットもあります。
実際、それらについては私もその通りだと思いますし、
YouTubeとか Xの意見も、概ねこれらの考え方がメインなのかなと思っています、

ただ、それでもフルリモートのデメリットは、
ある程度対策可能なのに対し、出社のデメリットは対策することが難しいです。

そこで本記事では、フルリモートワークこそが
エンジニアの働き方として理想である理由や、
出社やハイブリッドワークのデメリット、
巨大テック企業が出社回帰したから、
それに安易に迎合するのは避けるべきということについて
解説したいと思います

私自身、前職でフル出社とハイブリッドワークを経験し、
現職ではフルリモートワークを経験しているため、
概ね全ての働き方を経験してきているため、
この題材については結構語れる要素があると思ったので、
本記事を作成しました。

ちなみに、下記の本はエンジニアの働き方を考えるうえで、
とても参考になるので、フルリモートワークとハイブリッドワークどちらがいいのかという
問題意識を持っている人は読んでみることをおすすめします。

また、こちらの記事では、
上記の本以外でも、
プログラミング全般でおすすめの書籍を紹介しているので、
興味がある方はぜひともご参考ください

エンジニアならフルリモートが理想

若干、偏っていることは百も承知なのですが、
個人的にはフルリモートにはメリットしかないと思います。
(もちろんデメリットがないというわけではないのですが、
それらのデメリットは対策可能という点で致命的ではないという意味で、
メリットしかないという意味です)

パッと思いつくだけでもフルリモートには下記のメリットがあります

ポイント

・働く場所を気にしなくていい
・テキストコミュニュケーションが増えるので、やり方次第で情報を資産化できる
・通勤時間を算出する必要がない
・体調が微妙だったり、どうしても外せない用事とかがあった際の融通を、つけやすい
・(フルフレックスなら働く時間も気にしなくていい。フルリモートの理想形はフルフレックスであるべきとも思います)

 

というか、わざわざ私が言うまでもなく、
エンジニア目線であれば、一番働きやすいのって、
フルリモートの圧勝だと思います。

フルリモートのデメリットは、主に経営層から
語られることが多く、社員のパフォーマンスを懸念されることが多いです。

フルリモートのデメリットは対策可能

さて、そんなフルリモートの懸念点(デメリット)ですが、
良く言われるのが、

ポイント

・サボる社員がいるのではないか
・出社したほうが成果が出せる
・フルリモートの人の労務管理が難しい

 

あたりですかね。
実際巨大テック企業の出社回帰もこのあたりが
理由だったかと思います。

個人的にはフルリモートのデメリットは、
これら以外にあると感じており、
これらの社員のパフォーマンス懸念に関しては、
言うほど、致命的な損失はないと思います。

(労務管理については、サイレント残業が発生したりする場合がないわけではないので、
この3つの中では一番的を射たデメリットだとは思いますが)

Googleとか、Zoomとかは必ずしもエンジニアだけではなく、
いろんな職種の人がいる、巨大企業なので、
実際のところは、エンジニアの働き方が、
フルリモートに向いていないからと言うより、
全社員を出社にしたほうが手っ取り早いみたいな側面もあったような気もしています。
(あとは、エンジニアだけリモートにするのは不公平だからという理由もあった気がします)

つまり、エンジニア単体で考えると、
これらのデメリットってほとんど意味をなさないなと感じています。

以下順番に解説します

フルリモートはサボるのか?

よくある疑問として、フルリモートだとだらけるのではないかというのがあります。
だらけるのが心配だからフル出社にした方がいいという主張もたまに見かけます。

ただ、これについては、
私からすると、自分からマネジメント能力がないと言っているようにしか聞こえません。

確かにフルリモートというのは、基本的に個人の自主性に任せるので、その気になればサボることは可能です。

しかし、そもそも論として、このサボるサボらないということ自体、馬鹿馬鹿しい議題です。

平たくいうと成果主義。
すなわち、その人がどれだけのアウトプットをしたかで判断し、途中経過は任せればいいのです。

ぶっちゃけ、成果を適切にアウトプットしていれば、サボっていようが何しようがどうでもいいのです。
つまり時給でその人の労働を、図るという発想のままだと、フルリモートは実現できないでしょう。

サボるという思想自体も、その労働時間に対して仕事していない時間があると考えるから生まれるわけです。
それであれば、そもそも労働時間に対して仕事をしているという発想を改めるべきです。

もちろん、これは職種によっては馴染まないので、
エンジニアの場合の話です。

裏を返せば、成果を出せないのであれば、
アウトプットを出せるまで、仕事をしなければならない時もあります。
なので、労働時間ではなく、その人の成果で判断すれば、フルリモートを実現するのは難しくないと思います。

つまりフルリモートで、いわゆるサボりを行ったところで、最後に苦しむのは結局自分なので、必然的にサボらなくなります。

それどころか、場合によっては出社しているときよりも、いわゆるサイレント残業が発生しがちな気もします。

OSS開発はフルリモート

皆さんは、エンジニアのチームとして最高峰を考えると何を思い起こすでしょうか?

もちろん、GAFAとかもありますが、
もっと身近でかつ高レベルなものとして、
OSS開発があります。

これも多くの場合、フルリモートですよね。
そして、最高のプロダクトが作り出されています。

それに加えて、OSSとかだと、時差が異なることもあるので、基本mtgとかもないでしょう。
完全にテキストチャットで行う非同期分散開発の究極系です。

個人的にはこれこそあるべき姿なのかなと思っています。

出社したほうが成果が出せる

もう一つよく聞くのが、
出社したほうがパフォーマンスが高いというのがあります。

これについては、正直企業の業態とか
組織構造によるなと思っていて、
一概に全ての企業がそう断定できないとは思います。

というのも、基本的に出社したほうが効率が良い企業は、
mtgやディスカッションが比較的多かったり、
顧客とのコミュニケーションの重要性が相対的に高いパターンに
当てはまると思っていて、裏を返せば、
これらの特徴が弱ければ、
正直出社してようがリモートだろうが、
そんなに変わらないと私は考えます。

しばしば、Googleとかの素晴らしい製品は、
同じ部屋で話し合って生まれたみたいなエピソードを聞くと、
出社こそ最高というふうに感じるかもしれませんが、
フルリモートで生み出されたOSSとかにも素晴らしい製品はいくらでもあるので、
出社だからこそ、最高の製品を作り出せて、リモートだと作り出せないなんていうことは
全くないと思います。

なので、結局のところ、出社の方が成果を出せるというのは、
そういうケースもあるかもしれないけど、
どこまで確証があるのかはわからないふわっとしているものと
言わざるをえない気がします。

ハイブリッドワークが理想というのは嘘

このようにフルリモートがいいと言うと、
それなら、出社とフルリモートを合わせたハイブリッドこそ理想という意見も聞きます

これについては、組織によって何が正解かはもちろん異なりますし、
ハイブリッドワークはフルリモートのデメリットをある種適切に解決している側面はあるので、
悪いアプローチとは私も思いません。

ただ、私個人の意見としては、
ハイブリッドワークよりも、フルリモートの方がいいと考えます。

理由はシンプルで、
例えば週二回の出社日を、
リモートにしてしまったりした際に、
注意を受けやすかったり、
ひどい場合にはフル出社にすると切り替えたり、
基本的に出社の方がいいという風潮に陥りやすく、
結果的にリモートワークの人の立場が弱くなるからです。

もちろん、営業職などのように、
はっきりとこの日は出社しないとそもそも仕事にならないみたいな職種の場合はこの限りではありませんが、
少なくともエンジニアのように、出社するしないで、仕事の生産性が0か100かになるような世界線でない職種で、
きっちり出社したかどうかを管理するのは、はっきり言って馬鹿馬鹿しいと思います。

Macとマグカップの画像

逆に出社するメリットを考える

さてフルリモート賛美が続いたので、
少し出社のメリットも考えています。

まず挙げられるのが、
信頼関係を構築しやすいという点です。
これは確かに一理あるでしょう。

しかし、信頼関係を構築しやすいということは、
壊しやすいというのもあります。
出社は、リモートに比べ良くも悪くもコミュニュケーションが密になるので、
適切にコミュニュケーションが取れれば効果的に信頼関係を構築できる一方、やり方を間違えると、
逆に信頼をそこなってしまうこともあります。

これはあくまで個人的な考えではありますが、
そもそも職場の信頼関係を築くことは、
高いパフォーマンスの仕事をすることに必須なのかという疑問があります。

もちろん、信頼関係を構築できれば、
それだけ風通しもよくなり、
心理的安全性は高まりますから、
個人が自分の能力を発揮しやすくなります。

ただ、信頼関係を構築しないと発揮できないかというとそんなことは決してないと思います。

信頼関係構築の背後には、
仕事を楽しくして、人生を充実させたいのような、本来の仕事のパフォーマンスとは別の側面も含まれている気がしており、
信頼関係を構築したからといって、エンジニアなどは基本的に実力やスキルがモノをいうので、
パフォーマンスが低い人は低いままであることがほとんどです。

つまり、これは、本来パフォーマンスが高いはずなのに、
コミュニュケーションの齟齬によって発揮できていない際に問題になることですが、
そのレベルのコミュニュケーションであれば、
フルリモートで十分達成できます。

あと、出社のメリットとして語られがちな、
すぐにわからないことを聞けるという点ですが、
個人的にはこれは結構現場によって変わるよなという印象でして、
少なくとも私の場合では、このメリットは全くなかったと言っても良かったです。

というのも、結局出社していて、隣に先輩エンジニアがいても、
mtgばっかりだったり、死ぬほど忙しそうで話しかけられる雰囲気じゃなかったりで、
結局chatで聞いた方が早いということがしばしばあったからです。

それと、めちゃくちゃあるあるなのが、
新人は出社させられるけど、先輩はリモートだから、
結局コミュニケーションはchatになるっていう、
意味不明なシチュエーションもあります。

結局のところ、出社の方が良いというのではなくて、
単にその人が出社のほうがあっているというケースがほとんどで、
働き方としては、出社じゃないとだめということは
基本ないのかなと思います。

フルリモートにおける関係構築とデメリットについて

冒頭でフルリモートこそ最高みたいな論調で語ってしまいましたが、
正直、フルリモートにデメリットがないわけではありません。

世間的には、フルリモートはサボるから良くないとか、
楽してるみたいな、パフォーマンス面を懸念するデメリットが多いですが、
個人的にはフルリモートのデメリットはそこではないと思います。

フルリモートは病みやすい

フルリモートの最大のデメリット。
それは病みやすいということです。

これって意外と語られることが少ないのですが、
正直フルリモートのデメリットはこれ以外には存在しないと、
私は思っています。

フルリモートは、基本的に家で一人でずっと仕事をするので、
何もしないと、家に引きこもりがちになりますし、
職場とのコミュニケーションも、オンラインmtgしかないので、
どうしても希薄になります。

そのため、人との交流が極度になくなってしまい、
精神を病みやすくなります。

なので、本来フルリモートの対策としては、
この点に焦点を当てるべきなのですが、
これを解決しようとしている組織は、
まだそこまで多くない印象です。
(冒頭で紹介したGitlabとかはこの点についても
触れていたと思います。)

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

ただ、これについても
対策は可能だと思っていて、
私としては下記のような対策が有効だと思います
(この対策としてハイブリッドワークを取り入れるのは、
悪手とは言えないが、微妙に目的が変わってしまっている気がするので、
個人的には推奨できない)

ポイント

・まず、今後同じチームで仕事をするであろうメンバーの初回顔合わせを行う
・いつでも飲みとかに誘えるような心理的安全性を作る

 

このあたりかなと思います。
よくある、定期的に会う機会を設けるというのも、
悪くはないと思いますが、
会うのを目的にすると言うよりかは、
会いたくなったから会うということのほうが理想だと思うので、
いつでも気軽に誘える心理的安全性を築くっていうことが大事だと私は考えます。

timesの使い方

フルリモートの場合、
timesも意外と重要だったりします。

timesは平たく言うと、
chatツールにおける、
自分のTwitterのようなもので、
好きなことを呟ける部屋です。

なので、このtimesで、
趣味の話とか好きなものとかを語っていると、
そのtimesを観た人で興味がある人と盛り上がったり出来るので、
フルリモート組織ならtimesの導入はメリットが大きいなという印象です。

巨大テック企業の出社回帰について

さて、そうは言っても、
Googleとか、リモートワークの代名詞のZoomが
フルリモートをやめた時点で正解はわかりきっているんじゃないって感じる人も
多いかもしれません。

私からすると、GoogleやZoomの組織構造やビジネス構造と、
他の多くの企業が一緒なわけはないので、
Googleとかが出社回帰したからそれに迎合するというのは、
あまりに軽率すぎないかとも感じますが、
確かにこれらの企業の影響力があるのは間違いありません。

そこで、これらの企業の出社回帰についても
考察してみます。

Googleの場合

まずGoogleです。

下記の記事を見ると、
週3日の出社と、出社したかどうかの
チェックも行っているとのことで、
かなり厳しめの出社回帰だなと感じました。

https://www.businessinsider.jp/post-272779

同じ部屋で一緒に働くことがポジティブな変化ということが語られているように、
出社することによるパフォーマンスを重視しての、
決断なのかと思います。

私個人の意見としては、
OSSとかもあるので、出社しないと、
ポジティブな変化が表れないとは全然思えないのですが、
Googleとかになると、規模や影響力なども、
普通の企業と大きく異なるので、世界1位を走るために、
微細なパフォーマンス向上でも見込めるならそうするべきだみたいな
考えもあるのかもしれませんし、それなら別に特段不思議な意思決定とも感じません。

ただ、注意したいのは、
これはあくまでGoogleレベルの話だからそう言えるのであって、
他の多くの企業がGoogleと同じレベルなのかというと、
絶対そんなことはないのかなと思います。

求めているものや背景、状況も全く違うので、
Googleがリモートワークをやめたから、
うちもリモートワークをやめるというのは
思考停止なのではと思ってしまいます。

Googleの場合、
そもそもGAFAとして苛烈な競争にさらされ、
トップに君臨し続ける重圧があるため、
パフォーマンス向上にこだわるのはめちゃくちゃわかります。
そして、Googleのような巨大テック企業であれば、
週3日出社という強気な施策に出ても、
エンジニア採用に困ることはほぼないでしょう。

こういう背景があるから、Googleは出社にしているだけなのかなと
私は考えます。

なので、正直私からすると、
Googleのほうが特殊ケースで、
他の多くの企業は、やはりフルリモートのほうが
適しているのではないかなと思います。

特に日本の多くの企業では、
エンジニア採用を不利にしてまで、
出社回帰をするメリットがあるのか疑問です。

世界一位を維持するとかならたしかに
出社にして、最高パフォーマンスを追求するというのはわかりますが、
正直そのレベルではないなら、フルリモートで、
全然パフォーマンスは出せると思います。

Zoomの場合

お次はZoomです。

こちらは、下記の記事を見ると、
週二回出社を要請しているっぽいですね。

https://www.nikkei.com/article/DGXZQOUC153QZ0V11C23A1000000/

「リモートワークの代名詞のZoomが出社回帰。リモートオワコン」みたいな
ことがよく語られがちですが、
個人的には、これもGoogleのときと同じく、
思考停止の一種かなと思っています。

私としては、ZoomもGoogleのときと同じく、
特殊ケースでしかないと思っていて、
別に特段の驚きはありません。

その理由はシンプルで、
Zoomがリモートワークを推進する商売をしているから、
メインクライアントである、出社をしている顧客の立場とか、
出社からリモートに切り替えたいと考えている顧客の立場や課題を知るために、
自分たちもある程度は出社をしないとわからないからです。

これは確かにその通りだなと感じており、
リモートを推進する会社だからこそ、
リモート以外を知る必要があるというのは、
全然不思議ではありません。

ただ、Zoomのようにリモートワークの推進を商売にしている会社って、
どれだけあるのかっていうことを考えると、
これも特殊ケースだと思います。

特殊ケースをみて、
リモートワークがオワコンと考えるのは、
早計なのかなと感じます。

実際、Zoomってたしかに出社しているときにも使うことあるので、
そういうニーズを捉えるために、出社したほうがいいという判断は、
何ら不思議はないと思います。

結論:フルリモートvs 出社

議論がやや錯綜したので、
最後に結論だけ言って、
締めます。

この記事で私が最も伝えたかったのは、
フルリモートへの誤解と、巨大テック企業への迎合への違和感です。

すなわち、
フルリモートが適しているかどうかは組織によって異なるし、
少なくともエンジニアにおいては、フルリモートでパフォーマンスを出せないこともないし、
巨大テック企業の特殊ケースを除けば、むしろフルリモートのほうがメリットが大きいことが
ほとんど。

ということが言いたかったのですが、
うまくまとまりませんでした。

正直、フルリモートを実現するためには、
どうしてもメンバーの能力とかも関係してくるので、
すべての企業がフルリモートが適しているとは私は思いません。

しかし、フルリモートという選択肢を最初から薙ぎ払ってしまうのはナンセンスだなとは
思っており、基本的に巨大テック企業のような例外を除き、
フルリモートを目指したほうがメンバーの能力、パフォーマンス双方ともに、
レベルが上がることがほとんどで、そもそもフルリモートって、
能力が高い人が多くないと成り立たないので、
組織の理想形として目指したい像ではあります。

それを最初から薙ぎ払ってしまうのは、
自分から「私はマネジメント能力がありません」って言っているような
ものになりかねないので(フルリモートでも上手く回るけどあえて出社にしているとかなら、
良い選択だと思います)、個人的にはフルリモートこそが、
手っ取り早く組織のレベルを上げる働き方として優れているということを
本記事でお伝えしたかったです。

  • この記事を書いた人
  • 最新記事

reisuta

Webエンジニア | 20代中盤 | 大学時代はGmailすら知らないIT音痴でプログラミングとは無縁の生活を送る → 独学でプログラミングを学ぶ → Web系受託開発企業にエンジニアとして就職 → Web系自社サービス企業に転職 | 実務未経験の頃からVimを愛好しており、仕事でもプライベートでも開発はVimとTmuxを使っているので、VSCodeに疎いのが最近の悩み。何だかんだでやっぱりRubyが好き。

おすすめ記事はこちら

Vim/Neovimプラグイン 1

プラグインをどれだけ入れるかは、その人の思想なども関係するので、一概にこれがいいというのはないかもしれません。 プラグインを全く入れない人もいれば、100個以上入れる人もいます。 ただそれでも、これだ ...

VimとNeovimの比較 2

本記事では、VimとNeovimの違いについて、解説します。 VimとNeovimの違いについては、普段頻繁にVimなどを使う方でなければ、正直、あまり気にしなくてもいいかなと思います。 ただ、Vim ...

Ruby変数やすべてがオブジェクトについて 3

本記事は、Rubyの基礎文法である、変数や真偽値、論理演算子に触れると同時に、「すべてがオブジェクト」というRubyの特徴的な思想についても解説します。 この思想は、Rubyの文法の根幹になっているの ...

4

エンジニアにおすすめの技術書 書籍学習は、エンジニアの嗜みみたいなところがありますが、 良書というものは、意外とそこまで多くもありません。 そこで本記事では「技術書マニアの筆者が厳選した技術書20選」 ...

5

エンジニアになるには? プログラミングは、専門性が高く自分一人で勉強するのが大変に感じることも多いですよね。 そこで本記事では「おすすめのプログラミングスクール5選」を特徴と、現役エンジニア目線で優れ ...

-エンジニア全般