Overview
デブサミで公開されたこのスライドが非常に示唆に富んでいて考えることが多かったので、その思考の備忘録です。
※ 備忘録なので、取り止めもなく思考を吐露している文章になります。
コロナ禍以前から WFH を採用していた企業だけあって、その知見の量とここで示されてるだけの項目においても、その深さ、精度は WFH を採用する企業にとってはある意味理想と言える内容のスライドだなという感想を持ちました。
このスライドを読んだ後、Twitter ではこんな感じで感想を書き留めていました。
WFHとかリモートの最適解を探すときにどうしても"同期が前提"で要所要所で"非同期性"を採用しようとするから何かが歪になる気がする。
— Ema (@ema_hiro) 2022年2月23日
業務とはそもそも本来は"非同期なもの"だから、"非同期を前提"にしてどこに"同期的な要素"を入れるのか、というアプローチにするべきなんだよな。スッキリした。
非同期前提で要所要所で同期要素を組み込むアプローチは同期的なやり取りを否定してるわけではなく、単に優先順位を変えるってだけなんだけど、非同期の世界線においてはマネジメントの考え方そのものが根本的に異なるので、結局メンタルモデルの問題では、みたいな帰結に毎度なってしまうな...。
— Ema (@ema_hiro) 2022年2月23日
特に WFH か RTO か、という軸の他に非同期か同期かという軸があることに気づき、特に後者の非同期・同期の使い分けが WFH においてはプロダクト開発 -> 組織運営 -> 事業そのものに影響を及ぼしそうだなと思いました。
前提
WFH or RTO という話
WFH or RTO (Return To Office) はポストコロナのニューノーマルな世界において、世界に名だたる GAFA ですら頭を悩ませている問題でもあり、答えは決まってないと思います。実際日本の大手企業でも働く場所の制限を無くす動きを見てるともう WFH が当たり前になってきているし、そもそも企業が当然備えてる制度の一つである、という常識が完全に定着した、という印象すらあります。特に IT 系と呼ばれる業界においてはそう感じます。
個人的にはこれは結局のところ "スタンス" の差でしかないと思っていて、それぞれにメリットデメリットがありますし、WFH を恒久的に選択肢として採用することは企業文化やそもそも仕組み上人事制度の根本から変える必要がある（それに伴い組織の構成員たる社員、特にマネジメント層のメンタルモデルを変える必要がある）ケースもあり、現場でのハレーションを考えると一朝一夕に進められるところとそうでないところははっきり分かれる事案だと思います。
なので、所属してる組織では WFH と RTO に対しては、こう考えるのでこうする、というスタンスを明示して、そのスタンスに則って組織を作っていく他ないんでしょうし、やはりそこのスタンスが合わない以上、組織から離れる選択をするというのは今後多く見られる話になると思います。
僕個人としては、WFH は一社員としてはその便益を享受しておりますが、RTO の良さも感じてて週一くらいは会社に行くようにしてます。
やはりコミュニケーションにおける UX およびレイテンシの低さ、という点では TCP/IP はリアルを超えることは未だにできていないのではないか？と思います。
非同期か同期か
これが個人的にはポイントかなと考えています。
ツイートした内容とも被りますが、WFH か RTO の話をされるときに必ず、コミュニケーションを同期的にすることによるメリットで RTO を選択してるケースを目にすることが多く、実際それは大いにあり得るんだろうなと思いつつ、スライドでも語られている内容ですが、「それ同期である必要性ある？」という観点はすっぽり抜けてる（のか、あえて議論に入れてないのか）ように感じます。
僕自身は同期的であることが当たり前すぎて、脳死で同期を選択してるケースがあると思っており、そもそも仕事とは一部の業務（エッセンシャルワーカーや小売事業など限られたユースケース) を除いて、 仕事とは本来非同期で進めていたもの だと思っており、非同期を前提としたシステムとメンタルモデルを構築することが大事なのでは？と考えています。
よく耳にする同期と非同期のハレーションは、そもそも同期を前提としてる仕組みの上で非同期的な要素を要所要所で組み込む(許容していく)という選択をしてることで生まれており、そもそも非同期を前提として、要所で必要最低限の同期要素を組み込む方が、実は本来あるべき仕組みの作り方だった、という仮説は成り立つ可能性が高いと感じます。
コロナ以前の世界でも1日の業務内容を分割してみると、作業自体は非同期なことが多かったはずです。特にこの職業ではコード書く時は、ペア作業のケースを除いて大体1人で作業進めてたと思いますのでイメージしやすいかと思います。
非同期で回すために仕組みが頓挫する（もしくは非同期要素があるだけで運用されず、形骸化する) というのは、非同期で進めることを前提にしていないからで、そうなると便利すぎる同期の魔力には勝てずに終わる、みたいな話なのかなと思いました。
リモートで組織回すなら実は全員リモートであるべき、という話もあって、これも似た話かなと思います。非同期に慣れない人が良かれと思って同期に移行してしまった結果、コミュニケーションと持ってる情報量の溝が生まれてチーム内で断絶が発生する、みたいなケースの話です。
非同期がなぜ難しいのか？
同期には強烈な魔力があるからこそ、「それ同期である必要ありますか？」という問いがなかなか出てこないのかな、という考えの他に、非同期は根本的な難しさがあると思います。
社員のスキルが高くないと〜みたい話はよくいわれると思いますし、それは前提として大きな要素かと思いますが、最終的に僕の考えは以下です。
非同期を是とするにはまず個人レベルで「わからんことを大声ではっきりとわからんと言えるスキル」が求められる。
— Ema (@ema_hiro) 2022年2月23日
あとわからないことに遭遇したときに、堂々と"教えてくれ"とお願いできるスキルも求められる。聞かれた側はこれを躊躇しちゃいけないし、もし鬱陶しいと思うならそれこそドキュメントに残しておかないといけない。基本的にわからないことを見つけてくれたことへの感謝がないと回らない世界ではある。
— Ema (@ema_hiro) 2022年2月23日
別に出社してた時代でさえ、「わからないことがあればなんでもチャットで聞いてね」といわれてもなかなか聞けない人がいたとは思いますが、そういう時はうまいことオフラインで状況を目で察知して助け舟を出してくれる人がいたような気がします。僕もそうやって助けてもらったことがありますし、何よりチャットするより、申し訳なさを装いながら直で話しかけた方が話しかけやすい、みたいなのもあって物理で近いこと、そして同期的であることが解決してくれていた要素も実は大きかったなと今になって思います。
ただメンバー同士の距離が物理的にも離れており、こういった助け舟を出してくれる人との関係も断絶してしまい、本当に1人で作業を進めないという状況において、「わからないことを言語化できること」、そして「助けを請う」ことができること、という当たり前にできていてほしいレベルにおいて、できる人とそうでない人が分かれてしまい、後者が組織全体のスループットを低下させてしまう（律速してしまう）ことが発生するようになってしまったのと考えています。
WFH であること、そして非同期であることの難しさは、個人で適切に"同期"を選択するというスキルセットを顕在化させてしまったことにあるのではないかと思います。
結果この "個人で同期を適切に選択できない人" が多い場合に WFH を選択すると "WFH によって仕事が進まなくなった" みたいな全く異なった因果が生まれるようになるのかなと思いました。
本来であれば、そういう面も含めてオンボーディングで解決したり、採用でスクリーニングするべき話でもあるかもしれないんですが、コロナ前後で前提として求められるスキルが変わってしまったのもあって、組織全体としては低い方に合わせてサポートしていくことも必要で、チリツモでスループットに影響が出てしまう、という話です。
余談: カメラ ON について
余談に入れましたが、これを書きたかったがためにこのエントリを書いたといっても過言ではない裏テーマです。
GitLab のスライドは総じてWFH && 非同期をベースにするという点で理想的な仕組みを回しており、参考になる話しかなかったのですが、一点「カメラは原則ON」という部分だけは僕自身の考えとは違う選択をしていたので、どうしてそう感じたのかを記載しておきます。
個人の感想とスタンス
まずこの部分に関して僕個人の感想としては、ここまでうまく組織を作っているのに、カメラだけは ON にさせるんだ、という若干ネガティブよりの感想を持ちました。
とはいえ、これも原則は "スタンス" の問題かなと思っていて、GitLab では社内の原則としてカメラを ON にする、というルールの上で組織を運営してるというだけで、それ自体に是も非もないと思います。あくまでスタンスなので、僕自身はカメラ ON にしたとしても、実際のリアルフェイスを移す必要はない、というスタンスをとっています。
知られたくない権利 (プライバシーの話）の観点
WFH が当たり前の選択肢としてなっている中で表情から読み取れる情報量というのは大きく、カメラをONにするのが望ましいと意見もまっとうなものがあると思います。一方でカメラを ON にすることによる弊害というのも存在して、それはプライバシーに起因することが多いと思います。
例えば、書斎の有無があります。WFH が当たり前となってまだまだ日は浅く、仕事場としての空間を持っている人もいればそうでない人もいます。
都内で1人暮らしをしていればそういった環境を用意するような物件に住むことは一定以上のコストがかかってくることでもあり、それができない人もいることを想像すると、そうした人は生活空間の中で作業をすることで一部露呈することになるかもしれません。(なんのためのバーチャル背景か、という話はあると思いますが顔を見せるまでの身支度のコストとかもあるので、プライバシーはこれに限った話ではありません。寝癖あったりしてカメラをオンしたくない時もあるでしょう）
作業空間や身支度の話を出しましたが、PC の性能上カメラをオンにしたら途端に作業できないくらい重たくなるなど、端末が変数になりうる場合もあり、そもそもカメラオンにするのが最適でないケースもあります。
WFH にしたことで生活空間と職場が混在するようになった結果出てきた弊害ともいえますが、この問題を無視してカメラをオンにすることが是とは言い切れないと自分は考えているので、やはり知られたくないことをわざわざ知らせるルールには違和感を感じました。
アバターという選択肢
ただ、とはいえ上記にも記載しましたが、WFH においてカメラから得る情報は貴重で、話す側としてもカメラオフの相手に話しているというのはコミュニケーションとしては違和感を感じます。その違和感を否定する気はありませんが、この違和感を軽減し、かつプライバシーを守る手段として僕は「アバター」という選択肢は真面目に考えて良い選択肢だと思います。
去年現職でアドベントカレンダーを書いた際に冒頭に記載したのですが、現在のアバターは "そこに人がいる感" を感じることができるレベルでは顔の細やかな動きをトレースしてくれるようになっているので、無機質なカメラオフの画面に向かって話すよりよほど "誰か" に対して話している感覚を享受することができます。
実際僕の関わっていたプロジェクトのメンバーから、カメラオフの状態がメインのチームのMTGから、僕のいたプロジェクトの MTG に戻ってきたらアバターがわちゃわちゃしてて全然会話しやすい、というフィードバックをもらったので、サンプルは少ないですが実際にカメラが ON であるという条件は満たしつつ、そこに人じゃないけど "人がいる" 感覚をある意味錯覚させて、コミュニケーションを円滑化するためのアバターは、WFH のご時世でこそ非常に有用だと考えます。
僕自身としてはこのアバターの体験の良さをもっと広く知って欲しいと思っているので、カメラを ON にして実際の顔を映さずとも、コミュニケーションは成り立つという仮説を検証していきたいですし、そのためにまずはアバターを簡単に被ってもらうことに力を注いでいきたいなと思っています。
ブラウザのアプリを使ってアバターを簡単に切れる方法をブログとして残しているので興味がある方は是非明日から被ってみてください。
まとめ
なんとなく GitLab のスライドを読んでつらつら考えたことをまとめてみました。こういうことを考えさせてくれるという意味でいいスライドだったと思います。 ちなみに最後の方にイキッたこと書きましたけど、そもそもアバター動かすのには高スペックなマシンが必要なので M1Max を全人類に配布してほしいなと思ってます（誰に笑)
