Ryukalice

リモートワークの現実

2019-06-17

背景

最近、Twitter で「リモートワークは無理」といった主張をよく見るようになった。そして、その発言の大多数がリモートワークを実践したことがない人から発せられていることがわかった。また、リモートワークを夢見て web 系エンジニアを目指す初学者が、それらの発言を真に受けていることもわかった。

これは業界にとって最悪の傾向である。家事や育児の片手間で収入を得たい主婦や、地方在住で実家を離れられない方の道が閉ざされてしまっているのだ。この多様性を重視する界隈で、ここまでリモートワークに批判が集まっている現状を私は不思議に思っている。リモートワークを目の敵にしている声が、リモートワークの導入に頓挫した人から発せられているのであれば理解できるのだが、実際は前述の通りリモートワークを実践したことがない人から想像で発せられているようなので、引きこもりガチ勢の私がリモートワークの現実について紹介することにする。

前提条件

チームがリモートワークを行うにあたって必要な前提条件は下記の通りだ。

業務に物理的な制約がないこと

言うまでもないが、閉じられたネットワークにあるサーバーを扱う業務や、セキュリティ上限られた場所でしか遂行できない業務等に関しては、物理的な問題があるのでリモートワークは無理だ。

プロジェクトのスケジュールが最低日単位で管理されていること

リモートワークを批判する声の多くは、リモートワーカー個人の働きぶりが視認できないことについて言及しているようだが、彼らは恐らくチームメンバー個人に対してマネジメントしているのだろう。個人が机に向かっているか、個人の業務が停滞していないか、といったマネジメント方法は、リモートワークに限らずチームの規模が大きくなるほどに上手くいかなくなる。

本当にマネジメントすべきはチームメンバー個人ではなくプロジェクトの方だ。業務が停滞しているかどうかは、個人の様子を伺うことにより検出するのではなく、プロジェクトの進捗に影響が出たことによって検出するのだ。そのためには、進捗が滞ったら即時検出できるようなプロジェクトマネジメントが行われている必要がある。本記事の内容の大部分は、そういったマネジメントに関する話になるだろう。

リモートワークだと従業員はサボるのか?

その人は納期を無視してでもサボりたがるのか

業務が停滞したら、チームメンバーに自分が原因で遅れていることがバレ、納期はズレ、評価は下がり、業績は落ちる。それを良しとするような人なら、ハッキリ言って雇った方が悪い。少なくとも私は、そんな人がリモートワークを志願するところを見たことがない。「在宅勤務なんて覚えちゃったら絶対サボっちゃうよ」と言っていた人でも、いざ始めると納期にケツを叩かれてキビキビ働くものだ。

リモートワークができるのは内発的なモチベーションを感じながら仕事に取り組める人だけであると考える人が多いが、納期という外発的モチベーションに頼っても案外上手くいく。"納期駆動開発" という言葉があって、納期があれば自身の評価を下げないために働いてしまうものだ。

物理的な管理をしていないか

上司に物理的に監視されていないとサボる社員がいるという主張がある。何故 "上司駆動開発" は上手くいくのに "納期駆動開発" は上手くいかないのだろうか?納期に間に合わなければ結局上司に怒られるはずでは?確かに、炎上が始まるまで遅れが検出できず納期に間に合わないことに気付いた頃にはてんやわんやで遅れの原因も有耶無耶に葬られる場面は何度か見てきたが、これは単純に炎上するまで気付けないマネジメント方法が悪い。リモートワークに関係なく炎上して当然だ。

納期云々より「今上司に見られているか」でサボるか否かを決める人もいるかもしれない。そういった人のために上司の目線がどうしても必要で、どうしてもリモートワークをさせたければ1つだけ方法がある。常にビデオ会議を繋ぎっぱなしにしておくのだ。実はこれを実践している企業は私が知っているだけでも10社以上ある(当然これらの企業の目的は "監視" ではないが)。常に顔を映していても真面目な顔してネットサーフィンしている可能性があるのであれば、画面共有も強制すればいい。絶対にオススメはしないが。

サボる余裕があることは良いことだ

リモートワークの需要がサボりにあることは間違いない。文脈上、聞こえの悪い「サボり」という言葉を使っているが、仕事の合間に洗濯物を干したり、泣き出した赤ちゃんをあやしたり、子供のお迎えに行ったりできるのがリモートワークの大きなメリットだ。業務のみに集中しなくても、仕事が捗っていれば良いではないか。サボりを抑制しようとするのではなく、プロジェクトが遅れる原因を取り除くのだ。プロジェクトが遅れる原因がリモートワーカーの仕事量の低下であれば仕方ないが、経験上「ちゃんとマネジメントしてるのにリモートワーカーがサボるせいでプロジェクトが進まない」という話は聞いたことがない。

働きすぎる問題

リモートワーカーがサボっている問題については、プロジェクトの遅れにより早期に検出することができる。問題はスケジュール通りにプロジェクトが進行しているが、従業員がこっそりオーバーワークで対処している場合だ。私はリモートワークを実践している会社を何十社と見てきたが、ほとんどの会社は従業員がサボることより働きすぎることを問題視している。仮にコアタイムに常にビデオ会議を繋ぎっぱなしにしていたとしても、タイムカードに打刻した後にこっそり働かれてしまうと検出が難しい。これの解決策は私の知る限り存在しない。組織としては縛りすぎず自由すぎないバランスを考慮して試行錯誤するしかない。現実問題は個人の裁量に任せられるだけの人材を雇うしかないかもしれない。それだけに、一般的に言われるリモートワークのサボり問題やコミュニケーション問題、教育問題よりも、この働きすぎ問題が圧倒的に厄介であることを強調しておきたい。

リモートワークではコミュニケーションが取れないのか?

リモートはコミュニケーションの場所が変わるだけ

この記事を書くきっかけの1つになったのが下記のツイートだ。発信者は伏せるが、リモートワークになるとコミュニケーションが消失すると考えている人もいるようなのだ。

初学者の方が変な情報に惑わされて「リモートがー」とかいってるけど、そのレベルでリモートして、躓いたらどうやってコミュニケーション取って解決するんだよ?と毎度思ってしまう。

コードを見て分かるのは、「今どんな風に処理がなっているか」であって「なぜそうなっているのか」はほぼ分からない。ある程度業務で経験を積んでいるか、その組織でのコミュニケーションに慣れていない限り、フルリモートでのお仕事は結構辛いんじゃないかな?

コミュニケーションを取らずにやれるのって、「会話する必要も無いくらい部品の仕事に切り出されてるから」ってのもあるかなと。つまり、それは作業レベルであって、それ以上のものは無いのかなと。まぁフリーランスとかでフルリモートやったことないので妄想ですが。

これらツイートに対して「いや、それはリモートワークとして間違ってますよ」というリプで溢れているかと思ったが、全くそんなことはなくて心底驚いた。これに賛同している人々はメールと電話以外のオンラインコミュニケーションを知らないのかもしれない。この主張はリモートワーカーがコミュニケーションを取らない前提で行われているが、そんなことは断じてないので安心してほしい。

多くの現場では、普段のコミュニケーションはチャットツールで行われるのだ。チャットはリモートワークとは関係なく、同じオフィスに全チームメンバーが揃っていたとしても、IT企業ではよく使われている。ツールの種類としては slack, discord, chatwork 等だ。エンジニアの集中環境を重んじる企業では、話しかける前に「今ちょっと相談しに行ってもいい?」のようなメッセージを予め送った上で対面する習慣を持っている場合もある。オンラインでも本質は同じだ。普段のコミュニケーションはチャットで行って、対面で話したければビデオ会議を行う。ただ、コミュニケーションの場所がオフィスからオンラインに変わるだけだ。ちなみにビデオ会議は Google Hangout(meets), skype, discord 等のツールを使えば良い。

初学者の方が変な情報に惑わされて「リモートがー」とかいってるけど、そのレベルでリモートして、躓いたらどうやってコミュニケーション取って解決するんだよ?

チャットとビデオ会議でコミュニケーションを取って解決するのだ。実機を物理的に見せてもらうのに比べ、画面共有では弱い場合もあるだろう。環境構築で躓いたとか、ブレークポイントで一緒にデバッグしたいとか、初学者とのペアプロではよくあることだ。その場合は、相手のマシンに ssh で繋げるようにしておけば良い。相手のマシンに乗り込むことができれば何とでもなる。同じオフィスで隣の席にいたとしても新人教育に有効な手段だ。最悪の場合、リモートデスクトップのツールを使えばいい。これでリモートワーク特有の問題は基本的に解決できる。初学者のリモートワークの詳細については後述する。

リモートワークでコミュニケーションを絶やさないための工夫

必要なコミュニケーションはチャットとビデオ会議で済むとはいえ、問題は不必要なコミュニケーションだ。俗に言う雑談だ。雑談はプロダクトへのアイデアを生むし、メンタルケアも多少兼ねることができるし、チームの絆を高めることができる。

どのようにしてリモートで雑談を行うかだが、一昔前に流行った slack の times という文化を紹介しよう。興味があれば詳細に調べてみてほしいが、ざっくり言うと slack で1つサーバーを立てて、全チームメンバー(あるいは従業員)ごとに1つずつチャンネルを付与する文化だ。各個人は、自分のチャンネルに独り言を書いたり、人のチャンネルに乗り込んで独り言に反応したりする。仕事を終わるときに「お疲れです、上がりまーす」と挨拶をしたり、「洗濯物取り込んでくる」のような席を外すときに一言、別に5分もあれば解決できそうな問題に出くわしたとしても軽く報告するとか、飯どきに唐突にフードテロするとか、そういった本当に意味のない独り言でも良い。

この文化は、リモートワーカーの悪あがきの様に見えるかもしれないが、リモートワーカー不在のオフィスでも割と有用な文化なので、興味があれば試してみてほしい。ちなみに経験上、チームや従業員の数が50を超えてきたあたりから苦しくなってくるので、無理して続ける必要はない。あくまで「こういうやり方もあるよ」という紹介だ。

初学者にリモートワークは無理なのか?

結論から言うと場合による。初学者の適性やチームの教育方針によるので「無理ではない」と断言することはできない。どういった条件が整えば初学者でもリモートワークを行いやすい環境になるのかを話そう。

必要な初学者の適性

とにかく相談することだ。リモートワークを始める初学者で一番やってはいけないことは、問題を抱え込むことだ。15分以上、自分だけで悩むのはやめよう。そして、今抱えている問題について、適切に説明できるような訓練をしよう。どんな問題なのか、何を試してみたのかを詳細かつ簡潔かつ適切に説明できるように心がけよう。間違っても「なんか動かなくなっちゃったんですが」のような相談をしてはならない。「xxx というエラーが出ていて yyy という方法と zzz と言う方法は試してみたのですが、エラーの内容は変わりませんでした。」のような相談の仕方をしよう。

チームの教育方針

新人が上述のような相談をしやすい教育をしよう。特にメンター担当が忙殺していないことは重要だ。ハッキリと教育が業務として割り当てられている人をメンターに当てよう。決して「新人が困ってたら空いてる人が助けてあげてね」といった教育担当が曖昧な環境を作ってはならない。社内リソース上可能そうであれば、ペアプロで育ててあげられることが望ましい。メンターがテストを書いて新人が実装を書く、あるいは反対にメンターが実装を書いて新人がテストを書くといった教育が個人的なおすすめだ。技術的な問題は前述したビデオ会議、ssh、リモートデスクトップ等である程度解決できるが、メンタルケアをリモートで行うことは難しい。コアタイム全てをビデオ会議で繋いでいたとしてもだ。問題を抱え込んでいないか、問題を抱え込んでしまいやすい環境になっていないかを常に気にしてあげよう。

終わりに

リモートワークを実践している企業は山ほどある。この界隈はリモートワークへの関心が強いので、調べればいくらでもリモートワークを成功させるための情報が手に入る。私の主張とはいくつか違うところがあるが(顔出し文化や入社1年はオフィス勤め必須等)、ソニックガーデンの倉貫社長の「リモートチームでうまくいく」といった本を読んでみると良いかもしれない。とにかく、この記事ではリモートワークを知らない人々が想像しているよりも、リモートワークは一般化し始めていて、ノウハウやツールも充分に揃っていることを話したかった。是非、リモートワークへの夢を捨てずに在宅勤務を流行らせていきましょう。