前回、井上が「リモートワークってどうよ?」的なメタな話を「はじめてWEB業界で働いた私が、2年半間の完全リモートワークで感じたこと」 で紹介してくれましたので、今回はエンジニアとしての目線でリモートワークのメリットとデメリットを紹介していこうと思います。
なぜリモートワークを始めたか
ANNAIの社員としてはリモートワークの第1号が私になります。
CEOの紀野に一緒に働かないかと声をかけてもらった時に、毎日通勤したくないので「これから優秀な人材を集めるのであれば、場所や時間の制約は極力なくす必要がある。まず私にリモートワークさせてください。そうすれば優秀な人材が集まってくるでしょう。」と吹っかけた先人に習い「隗より始めよ」的なアプローチをしてみたのがきっかけです。
「じゃあ結構です」って方向になるかなぁと思いきや、あっさりOKが出て今に至ります (実際には色々と葛藤があったようです。無理難題を言ってすみません)。
ちなみに東京や大阪にオフィスもあるので全員がリモートワーク必須とは考えていなかったのですが、エンジニアに関しては全員がリモートワークを希望して働いています。現在は日本以外にも、タイとオーストラリアでエンジニアが働いているという状況です。当初の狙い通り、優秀な人材で構成されるチームができつつあります。
エンジニア視点でのリモートワークのメリット・デメリット
さて、TwitterやQiitaなどのSNSでよく挙げられているリモートワークのメリット、デメリットとしては以下のようなものがあります。
メリット
- 通勤時間がないため、時間に余裕ができる
- 通勤ラッシュに巻き込まれないため、体力的に楽
- 色々なものが仕組み化される (仕組みを作らざるを得なくなる)
- デスクやイス等を自分の好みにカスタマイズできる
- 電話や会議などで邪魔されにくくなり、集中できる
- 猫(ペット)と仕事ができる
デメリット
- 運動しなくなるため体力が低下する
- 周囲の目がないためサボってしまう
- コミュニケーションが減ってしまう
- コミュニケーションコストが高くなる
- コーチングやメンタリングなどがやりにくい場合がある
- 成果が見えにくくなり評価が難しい
実際どうなのか? (メリット編)
当然色々なメリット・デメリットがあるわけですが、「実際どうなの?」的な視点に落とし込んでいこうと思います。
1. 通勤時間がないため、時間に余裕ができる
いきなりですが、これが一番重要なメリットです。オフィスで働く時間を8時間、通勤を片道1時間とすると、「仕事のための時間」のうち移動時間が約15%になります。自宅で仕事をするのであればこれが0になるので、1日の時間が単純に2時間増えることになります。
この時間はプライベートな事に使っても良いですし、忙しい時は仕事に使うこともあります。今まで「仕事のために使う」しか選択肢がなかった時間に「何に使うのか」という選択肢が生まれます。これは非常に重要な変化です。
「通勤中は本を読んで時間を活用している」という話も聞きますが、自宅のソファーで読んだほうが快適です。「自宅だと他に誘惑があるし...」というのもよく聞きますが、それは仕組みではなく人間の性能の問題ですし、そのために通勤したほうが良い、と考えるのはもったいない気がします。
2. 通勤ラッシュに巻き込まれないため、体力的に楽
1つ目のメリットと重複しますが、通勤しないことには時間の節約の他に体力の節約というメリットもあります。首都圏に出張する場合、なるべく出勤ラッシュの時間帯の移動は避けるようにしていますが、それでも毎回体力が削られていきます。体力も時間と同様に貴重なリソースですので、できるだけ本質的な仕事やプライベートやプライベート(重要なので2回言いました)のために使いましょう。
3. 色々なものが仕組み化される (仕組みを作らざるを得なくなる)
申請などを紙媒体でやりとりする仕組みを作る場合、ほとんどは総務の領分になりますので、エンジニアが仕組み化に積極的に関わることは少ないかもしれません(印刷するデータを出力する業務システム書いたりとかはしますけど)。また、全員がオフィスに集まる環境であれば、しっかりと仕組み化しなくても意外と色々な事がなぁなぁでも回ってしまうものです。
しかし、「はじめてWEB業界で働いた私が、2年半間の完全リモートワークで感じたこと」でも紹介したとおり、リモートワークを円滑に回す仕組みを構築する場合、色々なものをデジタル化する必要があります。そして、これはエンジニアが得意とする領分です。
例えば、弊社の場合はslackをコミュニケーションのハブとして利用し、Googleカレンダー、Redmine、Zoom、Bitbucketなどの各種サービスのデータやアクティビティを通知しています。
これはちょっとした例ですが、エンジニアがスキルを活かして主体的に仕組み作りに関わりやすいのがリモートワークの特徴だと思います。主体的に関わることで当事者意識を持てますし、実際に自分が困る問題を仕組みで解決しようとする事も多いため、モチベーションも高くなります。
4. デスクやイス等を自分の好みにカスタマイズできる
オフィスだと全体で統一したデスクやイスが導入されてしまうケースがほとんどです。自宅であれば自分の好みのデスクやイスを購入して作業することができます。
私は環境をシングルディスプレイに最適化しているので外部ディスプレイは使いませんが、もちろんディスプレイは支給してもらえます。PCもOS問わず好きに選べます。
また、気分転換にソファやバルコニーで仕事をしたり、寒い時は布団に入って仕事をすることもできます(笑)。
5. 電話や会議などで邪魔されにくくなり、集中できる
これは「リモートワークならではのメリット」ではないと思います。電話がなくてもskype等の会議システムで簡単に常時接続できてしまいますし、メールやslack等のチャットで、世界中のどこにいようが割り込みは常に入ってきます。また、「無駄な会議が多い」のであれば、それは働く場所を変えるだけではそれほど減らないでしょう。
ANNAIの場合、エンジニアが長時間集中して設計やコーディングをする際は、slack等で「今日は1日集中して〜するのでミュートします」といった形で宣言するようにしています。これにより、周囲は「あ、今日は集中したいみたいなので急ぎの要件以外は控えよう」と考えてくれます。
しかし、これはオフィスにいてもできる行動です (デスクの周辺が騒がしいのであれば、静かなブースがオフィスにある方が望ましいですが)。これがオフィスでできないのであれば、それは働く場所ではなく周囲との信頼関係の問題なので、リモートワークに切り替えたとしても根本的な問題は解決しないのではないでしょうか。
6. 猫(ペット)と仕事ができる
私の周囲のサンプリングですが、エンジニアにはペット好きが多いように見えます。オフィスでペットの面倒を見るという選択肢もありますが、休日や出張でオフィスに誰もいないこともあり、現実的にはなかなか難しいです。また、ANNAIには猫やうさぎと生活している人がいますが、同時に猫アレルギーとうさぎアレルギーの人もいます。
自宅であればこのような問題は全てクリアであり、Win-Winの関係が築けます(笑)。ただし、たまに編集中のコードが消されたり、ノートPCを閉じられたりするので注意が必要です。
実際どうなのか? (デメリット編)
1. 運動しなくなるため体力が低下する
これは意識しないと本当に体力がなくなります。前述したように通勤時間が他の事に使えるようになりますので、運動しましょう。最近の私のブームは低山ハイクです。あと、こういうのが欲しいです(経費で)。
2. 周囲の目がないためサボってしまう
これはリモートワークかどうかには無関係で、サボる人はどこにいてもサボります。オフィスに来て座っているので一見して仕事をしているように見える、というだけの話です。逆に仕事をする人はどんな環境でもしっかりと仕事をして成果を出します。つまり、これが問題になるのであれば、それはリモートワークという仕組みの問題ではなく人間の性能の問題です。
セルフコントロールができることを手放しで信用できないのであれば、その人にはリモートワークをさせないほうがいいでしょう。反対に信用できるのであれば、マイクロマネジメントはせずに裁量を大きくしたほうが良い結果が出ると思います。
3. コミュニケーションが減ってしまう
これもリモートワークかどうかには無関係だと思います。同じオフィスで働いていても一度も話したことのない同僚がいたり、同じプロジェクトを進めているのに会話しない、どんなスキルを持っているか知らない、コードレビューなんて一切しない(恐ろしや..)という残念な環境も普通にあります。
では、「なぜコミュニケーションを取らないのか?」という視点で考えてみましょう。答えはシンプルで「メリットがないから」という事になります。例えば、「忙しいそうだから話しかけられない」というのは、「忙しそうだから話しかけると嫌がられるかもしれないし、こちらも不快な思いをするかもしれない。そうまでして会話するほどのメリットがない」という程度のモチベーションだということです。
逆に「この人と話すと面白い」、「この人と話すと勉強になる」、「この人とディスカッションするといいアイディアが生まれる」というような関係であれば、自然にコミュニケーションを取るようになります。
つまり、コミュニケーションを取るか取らないかは物理的な距離の問題ではなく、お互いに「コミュニケーションを取りたい」というモチベーションや信頼関係があるかどうか、という点に依存すると考えています。もちろん、思いついた時にすぐにコミュニケーションを取れる環境を作っておくのは非常に大事です。
ANNAIでは色々と試行錯誤した結果、メインのコミュニケーション媒体にはZoomとSlackを使っています。Zoomは前述したとおり毎日slackにルームのURLが自動で送られてくるので、会話したい時にいちいち「ここに接続してください」というような煩雑なやり取りは発生しません。集中したい時以外はZoomに接続しっぱなしにしていることも多いため、いきなり「〜さん、これなんですけど、、」のように会話が始まります。
4. コミュニケーションコストが高くなる
トータルで考えるとコストはむしろ安くなると感じています。
ある程度込み入った話になると、オフィスで顔を合わせているより確実に伝えるためのコストは高くなります。ただし、そのレベルの込み入った話はそうそう頻繁には発生しませんし、関係者全員の通勤時間やオフィスの維持費などのコストのほうがよほど高く付くのではないでしょうか。また、遠隔の人に伝えるために文書化や見える化しようという良い力も働きます。
チームの人数やオフィスワークとリモートワークが混在するのか、完全にリモートワークのみなのか等にもよりますが、トータルするとむしろコストは下がるのではと思います。ANNAIでは「遠隔なのでコミュニケーションが取りにくい」と考えるのではなく、普段はリモートワークでコストを抑えつつ、必要に応じて「コストを掛けて一箇所に集まって密なコミュニケーションを行う」というように考えています。
5. コーチングやメンタリングなどがやりにくい場合がある
これは、オフィスで隣の席にいたほうがやりやすいのは確実です。ただ、atomやvscodeを使ってリモートでペアプロしたり、Pull Requestベースでコードレビューしたり、ZoomのScreen shareや相手側の画面を操作するリモートコントロール機能もありますので、ツールを活用することである程度の問題は回避できます。
ANNAIではリモートワークでキャリアの浅い若手の教育をしたことはまだないのですが、その時は色々な課題が出てくるだろうなぁと予想しています。
6. 成果が見えにくくなり評価が難しい
これに関してはまだ明確な答えが見えていません。ANNAIのチームの規模感では今のところ目に見えて困っていることはありませんが、人数が増えてくると問題になりそうですね。やはりオフィスに全員がいるのとは違い見えにくい部分もあるため、「こんなにがんばっているのに評価されない!」というような承認欲求が強いタイプの人は不満が出るかもしれません。
リモートワークかどうかに関わらず、評価軸をしっかり定義することは大事な要素です。ただ、スキルを評価するのか、プロセスを評価するのか、それとも売上等の結果を評価するのか、絶対評価なのか相対評価なのかなど、様々なパラメータがあります。ANNAIのように住んでいる国が違う人がいる場合は、物価に応じて給料の額を調整する必要もあるかもしれません。
一番重要なことは、「私がんばっています」アピールをしなくても適切な評価ができる仕組みと信頼関係を作ることだと考えています。よく、年1,2回の評価面談で頑張ってアピールしないと評価されない、的な話を聞きますが、あれってすごく不毛ですよね。。
まとめ
よく挙げられるリモートワークのメリットとデメリットについて、ANNAIが2年ほどリモートワークを運用してみての所感をエンジニアとしての目線で書いてみました。前回の井上の記事でも少し出てきましたが、デメリットと言われていることのいくつかは、オフィスワークかリモートワークかではなく、もっと根本的な部分に原因があるのではないかと思います。
リモートワークを100%にする必要はありませんが、「通勤せずに働ける」という選択肢を持てるということは非常に重要です。少しずつ普及してきたリモートワークですが、もっと当たり前になっていくと良いですね。
関連コンテンツ
- エンジニア新人研修のご紹介
- Drupal Developer Days Transylvania 2019 参加レポート
- ANNAIの取り組み 月曜午後は勉強・研究タイム ANNAI Researchのご紹介
- Drupal初心者向けセミナーをフィリピンのイースタンサマール州立大学で開催しました
- Drupalcamp CEBU 2018参加レポート
- セブ島でリモートワーク環境を確保をする際の留意点
- はじめてWEB業界で正社員として働いた私が、2年半の完全リモートワークで感じたこと~リモートワークがうまくいかない時の処方箋
- Drupal camp Manila 2018レポート
- セブ「ITパーク」とコールセンターで働く人々
- セブでDrupalの勉強会に参加させていただきました
Drupal 初心者講座バックナンバー
- Drupal 9/10 初心者講座
- 第 1 回 歴史に見る Drupal の DNA
- 第 2 回 Drupal はフレームワークか?CMS か?他の CMS との比較
- 第 3 回 Drupal の特徴
- 第 4 回 Drupal 9 / 10 のインストール (1)
- 第 5 回 Drupal 9 / 10 のインストール (2)
- 第 6 回 Drupal にコンテンツを投稿してみる
- 第 7 回 Drupal のボキャブラリとタクソノミーの使い方
- 第 8 回 コンテンツ管理における Drupal と他の CMS との比較
- 第 9 回 Drupal のブロックシステム
- 第 10 回 Drupal の標準クエリビルダー Views の使い方
- 第 11 回 Drupal と他の CMS のクエリビルダー機能を比較
- 第 12 回 Drupal の多言語機能と他の CMS やサービスとの比較
- 第 13 回 Drupal の権限設定と WordPress や Movable Type との比較
- 第 14 回 Drupal のテーマシステムについて
- 第 15 回 Drupal の拡張モジュールの選定と使い方
- 第 16 回 Drupal をもっと知りたい方に向けた各種情報