🏠 ホーム
キャリア
エンジニア組織
働き方
炎上のシステム現場

結局リモートワークはどうなった

  フリーランスCTO >     エンジニア組織 >  

リモートワーク議論で決定的に欠けているもの

 雇用形態・職種・評価不能な仕事の存在

リモートワークを巡る議論は

「生産性が上がる／下がる」
「出社が必要／不要」

といった二元論に陥りがちだ。

しかし、多くの議論で意図的に、あるいは無自覚に欠けている視点がある。

それが 雇用形態（解雇・減給のしやすさ） と 職種ごとの成果の可視性 だ。

日米で真逆の「雇用前提」を無視した議論

■ 日本：解雇できないから「出社させる」

日本の雇用文化では、

つまり、「サボってもクビにならない」構造が制度として存在している。

この前提でリモートワークを導入すると、

という状況に経営・管理側が陥る。

結果として出てくる結論は、極めて単純だ。

「だったら出社させて、最低限サボれない状態にしよう」

日本の出社回帰は、リモート否定ではなく、解雇できない制度の代替手段としての側面が大きい。

■ アメリカ：クビにされないために「自発的に出社する」

一方アメリカでは、

この環境では、リモートワークが可能であっても、

という理由で、自発的に出社する人が一定数存在する。

いわば、

出社は「仕事」ではなく雇用維持のための政治行動（ゴマすり）

という側面を持つ。

つまり、アメリカの出社は「強制」ではなく恐怖と競争が生む自己防衛行動でもある。

日本の「管理される側 vs 管理する側」という対立構造

この雇用前提の違いが、日本では次の構図を生む。

この対立は、どちらが正しいかの問題ではない。

原因は、

成果が出なくても雇用が維持される＝管理コストを物理的拘束で補うしかない

という制度設計にある。

「成果で評価すればいい」は、職種を無視した乱暴な理論

リモートワーク推進論でよく言われるのが、

「成果で評価すれば、出社かリモートかは関係ない」

という主張だ。

だが、これは職種を限定した話でしかない。

■ 成果が数値で明確な職種

これらは確かに、

成果が数値で一発で分かる。

■ 成果が数値化しにくい職種

一方で、以下のような職種はどうか。

これらの仕事は、

という特徴を持つ。

この職種に対して、

「成果で判断すればいい」

と言うのは、
測れないものを測れと言っているに等しい。

結果として、

という摩擦が生じる。

出社回帰は「怠け対策」ではなく「制度の限界」

日本企業の出社回帰は、しばしば

「社員がサボるから」

と説明される。

しかし、正確にはこうだ。

サボっても処分できない制度の中で、成果が測れない仕事をどう管理するか分からない

その結果として、

という、消去法の出社回帰が起きている。

アメリカの最大手とそれ以外の違い

GAFAM回帰の背景と、これからの働き方システム

2020年のコロナ禍で一気に広がったリモートワーク。

「もう会社に行く時代は終わった」そう語られた時期もありました。

しかし、2023年以降、多くの企業——特にGAFAM（Google、Apple、Meta、Amazon、Microsoft）は従業員にオフィスへの回帰を求め始めました。

なぜか？ それはリモートワークが失敗だったからではなく、制度設計が中途半端だったからです。

一方で、GitLab、Automattic（WordPress）、Basecamp、ZapierなどRemote-First企業は、むしろ業績を伸ばし、従業員満足度も高いままで運営しています。

この差を生んでいる要素は何か？

その答えは「文化」や「性格」ではなく、仕組み（Systems）です。

リモートワークが成功する企業と失敗する企業の違い

企業タイプ 管理方法 評価軸 採用 組織構造
GAFAM型（出社要求） 会議中心 / 対面優位 出社＋成果 役職者採用＋プロジェクト単位 階層型
Remote-First企業 非同期コミュニケーション / ドキュメント文化 成果ベース＋稼働時間ベース スキルベース / 世界採用 分散型 / フラット

失敗した企業の多くは、「オフィス文化のままリモート化しようとした」

これが最大の原因です。

Slackで常にオンライン要求、Zoom連打、報告会議の増加。

これは働き方を改善するどころか、疲弊と管理コストを増加させました。

GAFAMの出社回帰は成果と評価の制度の欠陥

GAFAM（Google / Apple / Meta / Amazon / Microsoft）を含め、多くの企業が
「リモートワークでは生産性が落ちる」
「イノベーションには対面が必要」
という理由で出社回帰を進めている。

だが本当にそうだろうか。

問題の本質は、働く場所ではなく、成果の定義と評価制度そのものが壊れていることではないか。

そもそも「成果」とは何かが定義されていない

GAFAMを含む多くの大企業では、

といった制度が存在する。

しかし実態としては、

という構造から抜け出せていない。

つまり、

成果を正しく測れていないから、働いているかどうかを「出社」で代替評価している

これが出社推奨の正体ではないか。

 

評価についてはこちらの記事で細かく論じています

■ なぜ360度評価がリモートと相性がいいのか

つまり、

管理者が監視しなくても、同僚との関係性そのものが評価装置になる

サボれない構造は「監視」ではなく「関係性」で作れる

デスクトップ監視や常時オンライン強制は、

一方、360度評価を前提にすると、

という自然な圧力が生まれる。

これは、

サボらないから評価されるではなく評価されたいから、適切に働く

という健全な動機付けだ。

出社推奨が生む「見えない非生産活動」

出社推奨者が言う

「公式ミーティング外での生産性」

を裏返すと、次の行動が増えることになる。

これらは確かに評価には効くが、必ずしも成果には直結しない。

出社推奨とは、

成果ではなく「人間関係構築能力」を暗黙の評価軸に戻す行為

とも言える。

 

信頼関係は「毎日の対面」でしか作れないのか？

よく言われる反論がこれだ。

「リモートでは信頼関係が作れない」

しかし、あなたの小松自身の経験から、

それでも、プロジェクトは成功した。

つまり、

信頼関係に必要なのは毎日の対面ではなく「約束を守る」「反応が早い」「誠実なコミュニケーション」

これらは、工夫すればリモートでも十分に成立する。

出社回帰は「文化」の問題ではなく「設計放棄」の結果

ここまで整理すると、結論は明確になる。

成果を定義せず、評価制度を設計せず、その代わりに出社させている

これは言い換えれば、

管理設計の怠惰

だ。

GAFAMですら例外ではない。

裁量労働制の根本的な矛盾が、リモートで露呈する

裁量労働制では、極端な話、

1日1分でも業務をすれば「働いたことになる」

という解釈が制度上は成立してしまう。

オフィス勤務であれば、

という「物理的拘束」が、この矛盾を覆い隠していた。

しかしリモートでは、

という状態になる。

これはサボりやすい制度設計と言われても仕方がない。

出社は「8時間労働」では終わらない

出社勤務の議論で、軽視されがちなのが通勤コストだ。

仮に、

だとすると、

1日11〜12時間を会社に奪われている

ことになる。

これはエンジニアにとって非常に大きい負担だ。

だからこそ、リモートは「緩すぎてはいけない」

ここで重要な指摘がある。

今までのリモートワークは、正直「緩すぎた」面がある。

これは否定しにくい。

この3点セットは、性善説に頼りすぎている。

リモートなら営業時間12時間でも成立

この考え方は、決して「長時間労働を強制しよう」という話ではない。

ポイントは実質的な負担感にある。

出社勤務を冷静に分解すると、

がセットになっている。

一方、リモートワークでは、

という大きな違いがある。

そのため、出社8時間＋通勤

と

リモート12時間（適切な休憩込み）

は、体感的な負担としてほぼ同等、むしろ後者の方が楽になるケースも少なくない。

稼働時間を長めにすると、なぜ生産性が上がるのか

一見すると矛盾しているが、リモートでは稼働時間を長めに取った方が生産性が上がることがある。

理由はシンプルだ。

結果として、

特に、エンジニアリングや分散チームでは、この効果が顕著に出る。

ただし法制度の壁は無視できない

ここで問題になるのが、日本の労働法制だ。

これらを考えると、「1日12時間労働」をそのまま制度化するのは現実的ではない。

そこで重要になるのが、「稼働時間」と「実労働時間」を分けて考えるという発想だ。

解決案：実労働8時間＋長めの休憩を前提にする

現実的な落としどころは、次のような設計だ。

この4時間の休憩は、

などに自由に使える。

つまり、

を性善説に頼らず制度として成立させることができる。

「緩すぎたリモート」との決別

正直に言えば、これまでのリモートワークは
エンジニアの性善説に依存しすぎていた面は否めない。

この組み合わせは、

を必然的に生み出してしまう。

だからこそ、

という設計に切り替える意味がある。

リモートワークを成立させるための制度設計

リモートワークはエンジニアの採用の観点から切っても切れない魅力的な要素でもあります。しかし、残念ながらこれらの制度設計にしている企業や組織を見たことがないです。

どこかの組織や企業がこういった制度設計にすれば他社と比べて抜群の生産性のある企業になるのではと思います。

過去の記事

エンジニア組織と評価

大規模なエンジニア組織

何年も前の記事でも書いたように裁量を現場に委譲する事で効率に動かす事ができるかと思います。リモートだろうが、オフィス出勤だろうが関係なしにピザ2枚分で満腹できる人数に分けて評価を事業側からも入れれば適正な評価とスタッフのモチベーション維持に貢献できるかと思います。

GAFAMのような利益や人数が桁違いのような組織になれば、そういう細かい仕組みは面倒になるので、どうしても官僚組織になってしまうのもデメリットの一つかと思います。

 

 

登録日：

更新日：

by

コメント         tweetでコメント