緊急事態宣言も解除されて、オフィスに通勤する日も出てきました*1。コロナの感染状況が今後どうなっていくかは分からないですが、リモート勤務や複数拠点で働く人がいるチームで私が気を付けているポイントを書いてみます。説明するときのポインタが欲しくなってきたので...。
注意 & 前提
- 所属企業の見解ではないです
- エンジニア観点で書いてます
- マネージャーや他の職種の方だと他の観点だと違うところはきっとあるでしょう
- 複数拠点歴はこんな感じ
- 前職で5年、京都 / 東京の複数拠点
- 現職は約半年、大阪(私はここ) / 尼崎 / 東京の複数拠点
- リモート勤務
- 前職の最後の約一年
- 現職は約半年
- 完全にフルリモートではなく、入社直後や緊急事態宣言が解除されてからは少し物理出社あり
- 物流部門などもあるので、リモートや在宅の具合は部門によってかなり異なる
リモート勤務や複数拠点での働き方で気を付けているポイント
暗黙的に発生しがちな情報量、コミュニケーション格差に気を付ける
- 複数拠点や「4人はオフィスだが1人は在宅」といった状況を想定
- 人数が多い拠点やオフィスにいる側だけで議論が進みがち(latencyがないので)。コミュニケーションや受け取れる情報量の格差が意識していなくても生まれてしまうことが多い
- ファリシテーターがものすごく頑張る or 一人でもリモート(or在宅)なら会議室からではなく、それぞれ別の場所からzoomに入る、くらいのことをしないと↑は発生してしまうことが多い
- マイナー拠点のメンバーのオンボーディングの遅れ、職場への満足度の低下、離職率が上昇が起きるケースがある
相手に伝えられるコミュニケーション観点での情報量を増やす
同じ内容のことを議論すると仮定して、コミュニケーション観点での情報量は以下の順に多いかなと思っています。
- 1: 対面でのコミュニケーション
- latencyない、顔色分かる、声色から読み取れる情報もある
- 分かる、とは書いてみたものの、この辺どれくらい正確に読み取れているかは特に自信ない
- 2: zoomなどのオンラインでのコミュケーション
- latencyあるが、リアルタイム。カメラオンやマイクオンだと顔色や声色の情報はある、オフだと情報ない
- 物理的に離れていてもコミュニケーションが取れる
- 3: slackなどのチャットコミュニケーション
- 非同期。顔色や声色の情報はないので、reactionなども駆使しながらコミュニケーションの情報量を増やす
- 時間や場所に限定されず、議論に参加することができる
3に近づくにつれて制約は外れていくものの、意識しないとコミュニケーション観点での情報量は落ちてしまいます。1に近いコミュニケーションはコストが大きい(他拠点の場合は同じ場所にいるために移動が必要、mtgの時間の調整が必要)ため、全てあるいは大部分を1にするのは現実的ではありません。2や3を工夫して、コミュニケーションの情報量を増やすことが現実的だと思います。
zoomのカメラのon/offはよく議論になりますが
- 自分は可能なかぎりonにする
- 人数が多い全社mtgなどは通信量の関係でoffにするとかはある
- 他者に強制はしない
- 在宅の場合はご家庭の事情とか色々あるだろう
という形でやっています。元同僚の以下のエントリが納得感高かったです。
口頭で会話したことは必ずオンラインにも共有する
みんなが単一拠点にいる場合、数人でさっと議論して意思決定したとしても会話が他のメンバーにも漏れ聞こえることが多いので、それとなく情報が入ってきます。一方、リモートや他拠点の人がいる場合、口頭で会話された内容は漏れ聞こえるはなく、明示的に何を話したか聞くしかありません。情報が口頭で会話した人に閉じてしまいます。
意思決定の結果だけ共有されるのではなく
- 議論が起こった背景
- 結果が出るまでに議論があった過程
- alternativeとして出た選択肢、なぜこちらを選んだかの理由
などが共有されることで意思決定に対する納得感も上がると思います*2。なので、口頭で会話したことはslackやissueにすばやく共有することを心掛けています。障害対応や議論の行き違いが起きて微妙な空気になった際などは口頭で会話したいことももちろんあるはずで、そういうケースでは積極的に口頭(zoomとかを含む)で会話したほうがいいと思いますし、その会話が完了した後は会話に参加していなかったメンバーにも共有しましょう、という話です。
何をやっているか、何に困っているか積極的に共有する
サボっていないとかそういうレベルの話ではなく...。slackなどのチャットだけだと、その人が何をやっているか何に困っているかが見えなくなりがちです。そうならないように、私はこの辺を特に注意しながらやってます。
- (うまくいかなかったことを含めて)githubのissueやgoogle docsなどに自分がやっていることをログとして残しておく
- これはオフラインで働いている場合でも必要、という話ではある
- 考えたことや試したことが書いてあると、他人も助けやすい
- slackのチームのチャンネルに「ここ困っている」という情報を早めに出す
- 常に拾ってもらえる(or すぐ反応してもらえる)ことは期待しない
- 反応がなかったら朝会 / 夕会で共有する
- 他人からのヘルプに関してはなるべく早めに反応する
- 常に拾ってもらえる(or すぐ反応してもらえる)ことは期待しない
- チームメイトのcommit logを見ておく
- これは人に依ると思います。テックリードとかジュニアの人のメンターになったときはやってもいいかも
- 進め方を間違えていそうだったら、早めに修正かけれるようにする
- 色々見すぎると自分がshallow workerになるので、やりすぎには注意
- 言いにくい場合はチームの朝会 / 夕会などを積極的に活用
- 個人的には、進捗管理というよりは困り事を積極的に共有するといいと思っています
- slackだと言いにくい...という人はこの場を積極的に共有するとよい
- さらに言いにくいことであれば、上長やメンターとの1on1で解決策を探っていく
- 私の場合はチームの単位ではなく部門や組織全体で解決して欲しいことがあった場合にこの場をよく使っています
チームのアウトカムを最大化しようと思うと、チームメイトの様子を見つつヘルプできそうな人を早めに助けてあげれるように...というのをやりすぎると、自分の仕事が全然進まないという事態になりがちです(定時後から仕事する、みたいな...)。そういう場合は「集中タイム入ります!」とslackで宣言してslackは落とす、くらいをよくやっています。
オフラインでのコミュニケーションが特に有効なとき
当然あると思います。
新メンバーのオンボーディングの時期:
- 人によってはslackでのコミュニケーションに慣れていないという人もいるし、その場合は物理的に隣にいたほうが聞きやすい、ということもある
- 特に複数拠点の場合は、オンボーディング後はオンラインでのコミュニケーション(zoom / slack / JIRAのチケットとか)が多くなるので、徐々にそちらに寄せていく意識は持つ
- オフラインのほうが人となりが早く分かる場合もある*3ので
PoCの構築や図をたくさん書いてコミュニケーションする必要があるとき:
- オンラインのツールが発達したとはいえ、ホワイトボードでガンガン絵を書いては消して...というのは物理がまだ優勢なところはあると思う
- データ基盤のアセスメントだったり、ロードマップを作るときに物理の大きいホワイトボードで絵を書いたけど、オンラインで頑張ってやるより3倍くらいは進みがよかったような気がした
- 開発のときでも合宿のように濃密にコミュニケーションを取りつつ、PoCを作りたいときなどは特にオフラインだと捗ると思います
- 何がユーザーに刺さるか分からない、動くものがないと評価のしようもないからがっと作って、ダメだったら捨てて次に行くとかそういう時期
- ある程度作るものが決まっている場合などはオンラインのほうがはかどる場合も当然ある
所感
書いてて再確認しましたが、完璧なコミュニケーションの手段というのは存在しなくて、{業務, チーム}の性質や個人の働きやすさなど場面に応じて最適な手段は変化します。必要に応じて、自分たちに最適な方法を探っていきたいですね。
