gists

出社回帰はなぜ起きるのか――働き方の設計に必要な「第三の切り口」

1. 出社回帰の流れに対する疑問

LINEヤフーを始め、出社回帰に舵を切る企業が増えている。経営側が挙げる理由は「偶発的コミュニケーション」「新人育成」「組織文化の維持」「マネジメントのしやすさ」「セキュリティ」などだが、これらは一律出社を正当化するには弱い。

一方で批判側の指摘には合理性がある。通勤コストの従業員への転嫁、成果ではなく在席で管理する旧来型への回帰、リモートで生産性が上がった職種を無視した一律適用、オフィス賃料というサンクコストの正当化――これらは的を射ている。

結論として「考え抜いた上での判断なのか怪しい企業は少なくない」というのがフェアな見方だろう。

2. 一律出社は経営判断の放棄である

「出社かリモートか」の二択にしてしまう時点で、状況に応じた最適解を設計する能力が足りていない。

本来やるべきことは、職種や業務内容ごとに出社の必要性を見極めて、チーム単位で柔軟に運用すること。そのためには現場への権限委譲や成果ベースの評価制度への移行が必要だが、これは経営としての難易度が高い。一律出社はその難しい仕事を放棄して、一番簡単な選択肢に逃げているという側面がある。

優秀な人材ほど柔軟な働き方を求める傾向があるため、一律出社は採用競争力を自ら削ぐことにもなる。制度設計の手間を惜しんで従業員に通勤コストを押しつけている――経営判断として筋が悪い。

3. 経営者個人のバイアスが組織を歪める

経営者も人間であり、自分の経験や好みで判断してしまうバイアスがある。日本の大企業の経営層は「出社して顔を合わせてなんぼ」の環境で成功体験を積んできた世代が多い。

さらに、経営者やマネジメント層は対面の会議やコミュニケーションが仕事の大部分を占めるため、自分自身はオフィスにいるメリットが実際に大きい。しかしそこから「だから全員出社すべき」と飛躍するのは、自分の仕事の性質を全社に一般化してしまっている。エンジニアが集中して作業する時間の価値と、経営者の対面ミーティングの価値は別物だ。

「自分にとって良いこと=組織にとって良いこと」と無意識にすり替える認知バイアス。本人は合理的な経営判断のつもりでも、実態としては個人的な好みや慣れの押しつけになっている。本当に優れた経営者は「自分の感覚と、組織全体の最適解は違うかもしれない」と疑える人だ。

4. 会社経営と働き方の設計は別の専門領域である

経営者が得意なのは事業戦略、資本配分、意思決定といった「経営」であり、「人がどういう環境でどう働くと最もパフォーマンスが出るか」は全く別の専門領域だ。にもかかわらず、経営者が自分の権限で働き方まで決めてしまう。

本来、働き方の設計は組織心理学や人間工学、行動科学の領域であり、専門家がいる。しかし多くの企業では、そういう専門性を持った人が意思決定の場にいないか、いても経営者の「こうあるべき」に押し切られてしまう。

経営者が「俺は会社を経営してるんだから、働き方もわかってる」と思い込んでいるのが問題の根っこであり、これは一種の越権行為だ。

5. CHROでもない――経営でも人事でもない新しい切り口が要る

CHROも結局は人事の延長であり、採用・評価・制度設計という「管理側の論理」から抜け出せていない。

必要なのは既存のどの部門にも属さない、「人の働くパフォーマンスを最大化する」ことだけに特化した専門領域だ。認知科学、行動科学、環境デザイン、テクノロジーの知見を横断的に使い、個人やチームごとの最適な働き方を設計・実験・改善し続ける役割。経営の目標を理解しつつも経営の都合には従属しない。人事の枠組みにも縛られない。あくまで「人間のパフォーマンスと幸福の両立」を独立した立場で追求する。

UXデザインが「技術でもビジネスでもなくユーザー起点」という第三の視点を持ち込んで分野として確立されたのと同じ構造で、「働き方のUX」とでも言うべき領域が、独立した専門として必要な時代に来ている。

6. エンジニアこそが働き方を設計できる

この「第三の切り口」を担えるのはエンジニアである。その理由は二つある。

視座:「働き方をいじってもいい」という前提

経営者は「働き方は所与のもの、制度で管理するもの」と思っている。人事は「制度の整合性を保つもの」と思っている。しかしエンジニアは「仕組みはいじれるもの、設計し直せるもの」という前提で世界を見ている。この前提の違いが決定的だ。

スキル:概念をいじり言語化する能力

エンジニアは概念を分解して再構成するのが本業であり、漠然とした「コラボレーション」を細かいモジュールに分解して、それぞれを独立に設計・組み替えできるようにする。経営者や人事は「制度」という粒度でしか働き方を扱えない(出社/リモート、フレックス/固定、のような大きなスイッチのオンオフ)が、エンジニアはもっと細かい粒度で設計できる。

7. 具体例:コラボレーションモジュール

この主張を体現するリポジトリとして stakiran/collaboration-modules がある。「コラボレーション(複数人による協業)を柔軟に行う際に使える概念的な道具」を80個近くのモジュールとして体系化したものだ。

リポジトリの構造

モジュールは二種類に分かれる。

「説得はこのリポジトリの責務ではない。ゼロをイチに近づけることにフォーカスする」と明言されており、コストメリットや事例やストーリーといった説得用の情報は一切含まない。概念の提示による認知変容だけを目的としている。

代表的なモジュール

コミュニケーション拘束パラダイム — コミュニケーションの本質を「拘束」として整理。場所の拘束、時間の拘束、話題の拘束、身元の拘束の4つを特定し、それぞれの突破レベル(Lv0〜Lv5)を定義する。ハイブリッドワークはLv3にすぎず、フルリモートを標準化してLv4、さらに完全不参加を許容してLv5。「突破とはLv4以上」と定義し、ハイブリッドワーク程度の会社は場所の拘束すら突破できていないと指摘する。

Full Four — 現代的な働き方を4つに整理。フルリモート、フルフレックス、フルアシンク、フルマスク。フルアシンクは「ミーティングレス」を目安とし同期的コミュニケーションを有事扱いする。フルマスクは本名・性別・容姿を一切公開せずに働くこと。いずれも従業員の健康と生活に寄り添う。

管理3.0 — 管理パラダイムの変遷を整理。管理1.0(過程を管理、本質的に搾取的)→管理2.0(成果物を管理、生産性の概念)→管理3.0(状態を管理、理想状態の維持を目指す)。理想状態を定義し、妨害因子をモニタリングすることで、結果的に生産性も満たせるとする。

Human as Agent — チームメンバーをAIエージェントのように扱う。入力を与え、処理を任せ、出力を受け取るモデル。チームワークが苦手なメンバーの追放やチーム内不和を防ぐために、コミュニケーションにプロトコルを与える。非同期コミュニケーションで完結し、介入は例外的にし、並行は薄くする。

エクスプロラトリ — ウォーターフォール、アジャイルに次ぐ第三のプロジェクトパラダイム。テーマと探索期間だけ定めて、各自が好き勝手に探索を行う。No Assign, No Ball, No Consensus, No Deadline。ただし「探索者の義務」として、進捗と成果物のpublicな共有と言語化が強制される。

概念ドリブン — イシュー・ドリブンでもギャザー・ドリブンでもない第三のメンタルモデル。第三者に伝わる形で言語化したものを読み書きすることで、思考・議論・意思決定を行う。課題を解くわけでも集まるわけでもなく、概念をやりとりすることでコミュニケーションする。

分離リテラシー — .gitignoreの発想を一般化し、センシティブな情報を日頃から分離して透明性の確保を行いやすくする基礎素養。テンプレート化、センシティブの眼、抽象化、センシティブの可視化を構成要素とする。

このリポジトリが示していること

このリポジトリは、「コラボレーション」という漠然とした営みを、エンジニアがソフトウェアのモジュールを設計するのと同じ方法論で分解・再構成している。一つ一つのモジュールが独立していて、組み合わせ可能で、名前がついていて、定義がある。

これは「概念をいじる」行為そのものであり、経営者や人事にはできない。経営者は「制度」か「人間関係」の枠組みでしか働き方を触れない。エンジニアは、.gitignoreの発想で機密情報の分離を一般化したり、非同期通信プロトコルの発想でコミュニケーションを設計したり、ソフトウェアアーキテクチャの発想で意思決定構造を定義したりできる。

8. まとめ

出社回帰は、経営者が働き方の設計を自分の感覚と権限で行ってしまうことの帰結だ。しかし会社経営と働き方の設計は別の専門領域であり、後者は経営でも人事でもない第三の切り口が必要である。

その切り口を担えるのはエンジニアだ。「仕組みは設計し直せる」という視座と、「概念を分解・言語化・再構成する」スキルを持つからこそ、働き方をモジュールとして設計できる。コラボレーションモジュールはその具体的な実装例であり、80個近い概念的道具によって「働き方のUX」を体系化している。

働き方をいじるには、働き方をいじってもいいという視座に立つことと、それを実現するだけのやり方・考え方の会得が要る。そしてそれは、概念をいじり言語化が得意なエンジニアだからこそ出来る。