リモートワークはとても良い。フルリモートワークには超えるべき高い壁がある
IBMのリモートワーク廃止のニュースに伴い色々な記事が出ていますが、私もリモートワークを導入している中で感じたことを書いてみました。
リモートワークについて、個人的に感じるメリットは次の3つです。
- リモートワークは生産性が高い
- リモートワークで通勤時間はゼロになる
- リモートワークで色々な国、地方の方と仕事が出来るようになる
リモートワークの3大メリット
生産性が高い
リモートワークでは集中してタスクに望むことが出来ます。集中している時間に何かを差し込まれることはありません。集中タイムだけSlackを終了しておくとなお集中出来ます。
オフィスでタスクに取り掛かる場合と比べ、非常に早いです。
通勤時間はゼロになる
通勤にかかる時間がゼロになります。定量的に圧倒的に価値があります。また、おそらくあまり良くありませんが、身だしなみに使う時間もいくらか削減することが出来ます。
色々な国、地方の方と仕事が出来るようになる
多くの会社が人不足で悩んでいますが、採用の幅を地理で縛ることなく広げる事ができるので、様々な国、もしくは日本の地域の方と一緒に仕事が出来るようになります。
リモートワークの課題
リモートワークをする上での課題としては、次のような3つを特に大きく感じます。まだまだ、テクノロジーの進化が追いついていませんが、2020年頃には大半はなんとかなるんじゃないかと期待しています。
- 「一緒にやってみる」ことの難しさ
- 会話、会議における全体的な時間のロス
- 時差の問題
いくらかは前回下記にも書きました。
「一緒にやってみる」ことの難しさ
隣にいたり、すぐ近くにいれば声を掛けて気軽に相談することが出来ます。もし詰まっていたら一緒にホワイトボードの前に行ってディスカッションしたり、ペアプログラミングしたり、様々なことをメンバーと一緒にやってみることが出来ます。
これがリモートでは非常に難しいです。まず声をかけることが気軽にしづらく、「チャットでメンションを飛ばす」というアクションが必要です。そのあとハングアウトのチャンネルを作り、ディスカッションするためのGoogle Docsの準備をしたり、Trelloのボードを作ったり、色々な道具を準備する必要があります。
声のかけやすさについてはRemottyなどにチャットを置き換えると良いかもしれません。
似たようなサービスとしては、Sqwiggleが一時期話題になりました。残念ながら、サービス停止が昨年発表され、ついに公式サイトも停止しました。
SqwiggleはCPUを1コア専有するぐらい処理を要していたので、動画を使う系チャットツールに備えて、全員Core i7以上のスペックのPCを使うようにするなどしておくと良いかもしれません。
ペアプログラミングはScreenheroが良いかもしれません。但し、ScreenheroはSlackに買収され、現在は統合の準備が進められているようで、新規会員登録を停止しています。(2017/2/13現在)
兎にも角にも、まだ道具が十分に揃っておらず、リモートで「一緒にやってみる」というアクションはまだ難易度が高いです。道具が今後整う事を期待しています。
会話、会議における全体的な時間のロス
Slackでは `/hangout`や`/appear`コマンド、連携を使うことなどによってスピーディに会話、会議を始める事ができます。
但し、回線の調子が良くなかったり、音声が聞き取りづらかったり、まだオフライン会話との隔たりは大きいです。
会社の会議室では下記の割りと高価なマイクを使っていますが、それでも大きな声で話すようにするなどの気配りが必要です。
ちなみにこのマイク、なぜかエアコンの動作音をガンガンに拾ってしまうので、リモートメンバーを含む会議中はエアコンを使えない謎事件が発生したりします。
皆様もご経験があると思うのですが、接続トラブルも稀に発生します。稀にといっても、コミュニケーションを全てリモートでしている場合、1日に何回も会話する事がありますから、稀の接続トラブルによるロスも無視するには多いです。
会話のレスポンスタイムも全体的下がります。物理的に距離があるメンバーとハングアウトをしてみるとわかりますが、「せーの、パン」と手をお互い同時に叩くと、1秒以上のズレが出ることがあります。
ほんとに細かい時間ばかりなのですが、全体的に少しずつ遅くなります
ただし、これらの時間のロス問題の時間については、移動時間を鑑みると、定量的にはおそらくプラスです。
時差の問題
これは非常に難しい問題です。同じタイムゾーンで活動する限りはすぐに同一タイムゾーンの人に声をかけることが出来ますが、異なるタイムゾーンの場合、活動時間がかぶっている時間帯しかコミュニケーションを取ることが出来ません。
非同期コミュニケーションを心掛ける必要がありますが、非同期では「一緒にやる」ということが出来ないので、例えば、「タスクの3割ができた時点でメンバーに相談してから残りを進める」といった進め方が難しく、もしそうしようとした場合、1タスクに掛かる時間が数日間になってしまいます。(GitHub PullRequestをWIPで作成し、途中で見てもらってから進める場合など)
コミュニケーションの時間が貴重なので、会議の準備は事前に徹底する、ようにすることにより、会議時間は減らす事が出来ます。一方で、会議の準備に掛かる時間は増大します。
コミュニケーションのための時間に制約が生まれる事、大半のコミュニケーションを非同期に頼らないといけない事、この2つは時差があるリモートワーク上避けて通れない難しい問題です。
GitLabやGitHub、Atlassian社などは世界中にメンバーが分散しています。時差を含んだリモートワークは不可能な事ではありません。「非同期を前提としつつもすぐにコミュニケーションが取れるメンバーがいるチーム」か、「同一タイムゾーンで組成されたチーム」が良いのではないかと考えています。
また、顧客がグローバルに分散する場合には、リモートワークを取り入れる事はおそらく不可欠なことでしょう。
GitLabは下記のように記載されています。
Yコンビネータを卒業した9人は、それぞれが「営業職」のようにちりぢりになって働くのがごく自然な形
http://gigazine.net/news/20170213-gitlab-160-employee-management/
おわりに
リモートワークについて、メリットはみなさんが容易に想像出来ると思うので短文にし、課題の方を特に多く書きました。
リモートワークは日本で非常に話題ですし、出来ることがモダンであるようにエンジニア界隈ではなっていると思います。リモートワークが出来るかどうかが求人媒体に書いてある割合も非常に多くなりました。
リモートワークのメリットは本当に分かりやすいのですが、問題点はやってみないとわからないですし、やってみても肌感覚的にはなかなか問題点に気づきづらいものです。
週1リモートワークにする、ぐらいは全く問題ないと思いますしぜひオススメします。フルリモートな組織づくりは非常に難しいです。組織づくり専任のメンバーが居たほうが良いでしょう。3〜7人ぐらいの1チームぐらいの組織化が不要なサイズ感では、フルリモートワークは取り入れない事が無難だと考えます。
私の所属する企業は顧客がグローバルに分散するため、フルリモートワークが可能な組織を課題と作るため戦い続けます。
