リモートワーク vs. オンサイトワーク

リモートワークとオンサイトワークは単純な二項対立ではなく、チームの分散にはいくつかのパターンがあり、それぞれに異なるトレードオフと、適した効果的な手法が存在します。決定的な証拠を示すことは不可能ですが、私の感覚では、ほとんどのグループはオンサイトで働く方が生産性が高いです。しかし、分散型ワークモデルを採用することで、より幅広い人材プールにアクセスできるため、より生産性の高いチームを構築できます。

2015年10月19日



情報化時代のもたらした最も大きな成果の一つは、場所に縛られずに多くのことができるようになったことです。私はもはや、ほとんどの店、図書館、旅行代理店に行く必要がありません。(歯医者に行かなくて済む日が来るのを楽しみにしています。)世界のほとんどの人がこのことを実感していますが、特にデジタル変革の最前線にいるソフトウェア開発者にとっては明白です。

しかし、ソフトウェア開発に関しては、多くの開発者はネットワーク接続されたコンピュータのコミュニケーションの可能性を活かしていません。Yahooは、最近、すべてのオフサイトワーカーを単一のサイトに戻したことで、大きな話題となりました。NetflixやGoogleのような大手テクノロジー企業は、従業員を単一のサイトに配置することを強く好みます。

このような動きは、私たちの業界の他の人々から冷笑されています。最も声高に反対しているのは、Etsy、Basecamp、Githubなどのスタートアップ企業で、従業員の多くは一緒にオフィスで働いたことがありません。このようなチームにとって、リモートワークは未来であり、それに逆らう者は歴史の敗北者です。

私は長年この業界でリモートワークに関する議論に参加してきましたが、決定的な要因について話せることはあまりありません。リモートワークがソフトウェア開発に与える影響の証拠は、意味のある方法で収集することが困難です。

とはいえ、私は多くのチームと話をしており、それらの会話から、ここで共有する暫定的な意見を持つようになりました。

リモートワークの多様な側面

まず最初に理解しておくべきことは、オンサイトチームとリモートチームの間には単純な二項対立がないということです。それぞれに長所と短所を持つ、多くの異なる種類があります。理解を深めるために、いくつかの類型を紹介します。

シングルサイトチームとは、全員が同じ物理的な場所に配置されているチームです。理想的には、全員が数歩以内にいて、何も手配することなく迅速に協力し、他の全員が何をしているかを簡単に把握できることを意味します。多くのチームは、コミュニケーションを最大限に容易にするために、単一のチームルームを好みます。パーティションで区切られた空間でさえ邪魔になります - 多くのアジャイルコーチはドライバーを使った武勇伝を持っています。

マルチサイトチームとは、より大きなチーム内に、別々の場所に配置された2つ以上のオンサイトグループがあり、おそらく正式なサブチームの境界と責任を持っているチームです。メルボルンと西安に分かれた開発チームが良い例です。

サテライトワーカーとは、チームの大部分がオンサイトで働いていますが、数人のメンバーが自宅や別のオフィスからリモートで働いている場合です。

リモートファーストチームとは、全員が別々の場所(通常は自宅)で作業し、すべてのコミュニケーションがオンラインで行われるチームです。ほとんどのオープンソースプロジェクトはリモートファーストであり、この経験は多くのスタートアップ企業にリモートワークを採用するよう促しました。

リモートの度合いは様々です。同じ建物の2つのフロアにチームを分割するだけで、オンサイトで働く感覚が損なわれることがよくあります。距離とタイムゾーンを追加すると、リモート感が増しますが、最大の変化は、共同作業者から歩いてすぐの場所にいなくなったときに起こると多くの人が主張しています。重要なのは、歩いて話に行くよりもメールを送る方が簡単だと感じるようになるポイントです。

ほとんどの人はオンサイトで働く方が生産性が高い

ソフトウェア開発における多くのトピックと同様に、プロセスに関する議論は、アウトプットを測定できないため、結論が出ません。100のソフトウェア開発チームを対象に、リモートワークが生産性に定量的に影響を与えるかどうかを分析することはできません。「オンサイトチームの方が生産性が高いと感じる」など、人々は逸話的な発言をしますが、それは優れた証拠ではありません。しかし、それが優れた証拠ではないとしても、私たちが持っている唯一の証拠です。

もう一つの要因は、チームをうまく機能させるための他の多くの要因があるということです。誰かがシングルサイトチームの方が効果的だと言っている場合、それは、他のチームと比較して、他の要因が作用しているためかもしれません。この問題を軽減する一つの方法は、分散パターンを変更したチーム、例えばシングルサイトからマルチサイトに分割したチームに特に注意を払うことです。チームの分散の変化は、多くの場合、人々がチームを離れたり、チームに加わったりすることを意味するため、他の要因が依然として影響しますが、これは全く異なるチームを比較するよりも強力な証拠となると考えます。

これを考えると、私(または誰でも)ができることは、多くの人々の話を聞いて、できる限り最良の判断をすることだけです。私は、チームと場所に関する多くの経験を聞いてきました。その中には、チームが分散パターンを変更したケースもかなり含まれています(ただし、リモートファーストへの、またはリモートファーストからの変更についてはあまり聞いていません)。逸話的な証拠の重みから、ほとんどのチームはシングルサイトモデルの方が生産性が高いと結論付けられます。

その理由は、コミュニケーションの容易さです。(ビデオ)チャット、画面共有などのツールは、リモートワークを容易にするために大きく貢献しましたが、振り返って話したい人を見て、すぐに話せるほど効果的なものはありません。また、オンサイトでは、大量の非公式な会話が行われ、人間関係が改善されます。その結果、良好な関係とコミュニケーションの好循環が生まれます。コミュニケーションはソフトウェア開発の中心的な部分であるため、これは生産性に大きな影響を与えます。

しかし、私が「ほとんど」と言ったことに注意してください。人間は非常に多様ですが、一つの共通の特徴は、誰もが同じように行動すると思う人間の傾向のようです。ですから、リモートで働く方が効率的だという人がいることは容易に信じられます。私の感覚では、これは少数派の人々です。(若い世代はリモートでの交流に慣れているため、世代的な要因もあるかもしれません。)

リモートチームの方が生産性が高い場合も多い

リモート志向の少数派を無視すると、シングルサイトチームの生産性が高いということは、シングルサイトモデルを支持すべきなのでしょうか?実際には、そうすべきではない場合が多いのです。

特定のチームはオンサイトの方が効果的だという話をよく聞きますが、シングルサイトはチームに所属できる人に大きな制約を課します。そのようなルールは、その仕事に最適な人を雇うことができず、単に移住する意思のある最適な人を雇うことしかできないことを意味します。チームをリモートにすることで、チームに迎え入れることができる人の範囲を広げることができます。リモートチームは、同じチームがオンサイトで働いていた場合よりも生産性が低いかもしれませんが、それでも、 تشکیلできる最高のオンサイトチームよりも生産性が高いかもしれません。

リモートワークは、永住権の問題を回避するだけでなく、特にリモートファーストモデルで自宅で働く場合、個人により多くの選択肢を提供します。人々は、学校から子供を迎えに行くのが簡単であること、通勤時間とエネルギーの無駄を省けること、そして快適な環境を高く評価しています。それを提供することで、雇用パッケージはより魅力的になります。女性は、オフィスで過ごす時間を難しくする育児を引き受けることが多いことを考えると、多様性の向上にも役立つ可能性があります。

この効果は、国境を越えても大きな要因となります。オフショアリングが普及するにつれて、ほとんどの人はそれをコスト削減の方法と見なしました。Thoughtworksでは、それは最高の才能を見つける上でより重要であると考えています。例えば、当社の中国オフィスは、人材プールの規模がはるかに大きいため、オーストラリアでの仕事をサポートする上で特に貴重な存在となっています。

コミュニケーションパターンに注意を払う

人々のコミュニケーション方法は、効果的なソフトウェア開発の中心です。どのような形であれ、リモートワークを導入することで、コミュニケーションパターンに制約が生じます。特に、オンサイトでのコミュニケーションは、オンラインコミュニケーションよりもはるかに豊富であることを認識する必要があります。少なくともほとんどの人にとってはそうです。そのため、オンサイトで働くほとんどの人は、リモートワーカーよりも優れたコミュニケーションを取り、良好な人間関係を築きます。これにより、認識しておく必要があるさまざまな結果が生じます。

マルチサイトチームは、他のサイトに対して「私たち」と「彼ら」という態度をとる傾向があります。これを軽減するには、定期的な連絡訪問とアンバサダーを活用します。連絡訪問とは、チーム間の短期間の相互訪問です。これらは、時折行われるより深い協力には適していますが、多くの場合、その最大の目的は人間関係を築くことです。組織は後者の重要性を忘れがちです。そのため、連絡訪問を行う際には、社会的交流により重点を置いてください(つまり、関係構築に役立つ活動のための時間を割り当ててください)。アンバサダーとは、別のサイトで数か月間過ごす人のことです。アンバサダーは、一時的なリモートチームと通常のホームチームとの間のコミュニケーションを、リモート時と帰国時の両方で、大幅に促進することができます。

リモートファーストモデルを採用するなら、徹底的に行う必要があります。すべてのコミュニケーションはオンラインで行い、同じオフィスに同僚がいるようなサブグループを作ってはいけません。同じオフィスで働く人々に、個別のオフィスで作業することを強制し、隣のプログラマーとのコミュニケーションもオンラインで行うよう義務付けているチームもあると聞いたことがあります。しかし、リモートファーストはリモートオンリーを意味するわけではありません。リモートファースト組織は、同僚がいることでメリットのある難しい問題の解決と、人間関係の改善の両方を目的として、数ヶ月ごとに直接顔を合わせる会合を一般的に行います。(例えば、Basecampは年に2回、1週間の会合を行っています。)

マルチサイトチームの場合は、完全に自律的なコンポーネントによって作業を分割します。各チームはフルスタックで、アイデアから本番まで、コンポーネント全体を担当する必要があります。レイヤー(フロントエンド/バックエンド/データ)別やアクティビティ(分析/開発/テスト)別には分割しないでください。レイヤーとアクティビティの境界線はどちらも、それを超えた密なコミュニケーションが必要です。コンウェイの法則の重要性を忘れないでください。(コンウェイの法則へのリンク)

サテライトワーカーを効果的に働かせるのは非常に困難です。ほとんどの人が同じ場所に集まっている場合、ほとんどのコミュニケーションは、そのチーム内で行われます。サテライトワーカーが次第に孤立していくという話を聞かない日はありません。彼らの仕事が非常に自律的であれば、問題は軽減されます。また、サテライトワーカーが月に数回はオンサイトチームを定期的に訪問するようにすることも賢明です。しかし、ほとんどの場合、一時的な対策として最善のようです。

リモートコミュニケーションの難しさが特に顕著になるのは、後輩スタッフのメンタリングです。リモートファーストワーキングの支持者の中には、リモートファーストチームには経験豊富なスタッフのみを採用すべきだと主張する人もいます。多くの場合と同様に、リモートで人を指導することは不可能ではありませんが、はるかに困難です。マルチサイトチームの場合は、各サイトに経験豊富なメンターを配置して、新人社員を指導するようにしてください。後輩社員をサテライトワーカーにしないようにしましょう。リモートファーストチームに後輩社員を参加させることには注意が必要です。リモートファーストチームが円滑に機能するまでは試すべきではなく、その後も非常にゆっくりと追加していくべきです。

リモートワークとアジャイル

アジャイルソフトウェア開発はリモートワークと両立しないと主張する人を何人か見かけました。それはナンセンスです。少なくとも私のアジャイル思考の理解ではそうです。

確かにアジャイル手法は、同じ場所に集まって働くことをより奨励しています。エクストリームプログラミングでは、「一緒に座る」ことを主要なプラクティスの一つとして挙げています。*「顔を合わせる時間が長ければ長いほど、プロジェクトはより人間的で生産的になる」*。アジャイルマニフェストには、*「開発チーム内、及びチームと顧客間のコミュニケーションにとって、最も効率的で効果的な方法は、フェイス・トゥ・フェイスの会話である」*とあります。

しかし、これらはすべて、特定のチームは通常、同じ場所に集まって作業する方がより良いコラボレーションができるという点を述べているに過ぎません。リモートワークパターンをサポートすることで、より良いチームが得られるという議論はしていません。アジャイルマニフェストの最初の価値は「プロセスやツールよりも個人と対話」であり、これは、チームに可能な限り最高のメンバーを集め、彼らがうまく協力できるようにすることを優先すべきだと解釈するべきです。(ケントは、「一緒に座る」ことはXPでは必須ではないと指摘しています。)私たちは、対面でのコミュニケーションがより効果的であることを認識していますが、その認識は、個人と対話の重要性を覆すものではありません。

結論

ここまで読んでいただければ明らかだと思いますが、リモートワークの有効性について明確な結論を導き出すのに十分な証拠はありません。しかし、これらの不安定な基盤に基づいて、私の主な考えは以下のとおりです。

  • チームの分散パターンは、単純なリモート対同僚という二分法だけではないことを決して忘れてはなりません。マルチサイトチームの利点、欠点、効果的な手法は、リモートファーストの仕事とは異なることがよくあります。
  • ほとんどのグループは、より密なコミュニケーションが取れるため、同じ場所に集まって作業する方が効果的です。しかし、リモートファーストモデルの方が効果的に仕事ができる人もいることを忘れてはなりません。
  • ほとんどのチームは同じ場所に集まって作業する方が生産性が高いと思いますが、分散型モデルを採用することで、採用できる人材のプールが広がるため、より効果的なチームになることがよくあります。
  • リモートワークパターンを使用する場合は、コミュニケーションパターンの形成方法に注意を払ってください。出張やテクノロジーを含め、コミュニケーションの改善に投資しましょう。

リモートワークパターンをサポートすることで、より良いチームが得られるという事実は、私がソフトウェア業界で働いている間にますます重要になってきており、その重要性は今後も高まり続けると予想しています。優秀な開発者の間では、単一サイト勤務の場所や通勤のデメリットを受け入れることに抵抗感が強まっていると感じています。これは、経験を積み、価値が高まるにつれて、ますます顕著になっています。この事実を無視して、あなたのために移転してくれる最高の社員を受け入れるか、リモートワークパターンをより効果的にする方法を探求するか、どちらかを選択できます。リモートワークパターンを効果的に活用できる組織は、大きな、そして成長し続ける競争優位性を持つと考えています。


謝辞

Bill Kimmel、Fábio Santos、Gayatri Kalyanaraman、Hugo Corbucci、Jie Xiong、Ken McCormack、Kevin Yeung、Kyle Hodgson、Pete Hodgson、Peter Gillard-Moss、Rouan Wilsenach、Sriram Narayan、Tiago Griffo、Valerie Roskeの各氏が、この記事の草稿にコメントを寄せてくださいました。Pete Staplesはイラストレーションを手伝ってくれました。

参考文献

リモートワークは、ウェブの記事やブログでよく取り上げられる問題であり、私は推奨読書リストを作成しようとはしていません。しかし、10年前にインドでの経験に基づいて書いた、オフショアワークにアジャイル手法を使用することに関する記事を紹介します。この記事のアドバイスと結論は、マルチサイトチームにも当てはまりますが、技術的な微調整をいくつか追加したいと考えています。

Bjorn Freeman-Bensonは、同僚がいる環境と分散型の環境の両方でチームを率いてきました。James Shoreは、そこから学んだ教訓をうまくまとめています。リモートファーストモデルは大規模なチームには適しておらず、経験の浅い開発者には効果が薄いという彼の見解は、特に注目に値します。

主な改訂

2015年10月19日:初版発行