こんにちは！ぐるなび開発部門でマネージャをやっている豊濱です。
趣味はモータースポーツ観戦全般です。さらっとご紹介しようかと思いましたが、本題に入るまえに記事が終わっちゃいそうな勢いになったのでまた別の機会に……。
ということで今回は、開発部門で導入したリモートワーク制度についてご紹介します。
リモートワークとは
言うまでもなく、オフィス以外の場所で働く、という意味です。
昨年2017年からは総務省など政府が中心となって「テレワーク・デイズ」も実施されており、今後リモートワークは世の中的にもワーキングスタイルの1つとして定着していくと思われます（もちろん弊社も参加しています！）。
弊社で実際に利用されている方々の記事はこことかこことかここにありますので、ぜひこちらもご参照いただければと思います。
なぜ弊社で導入をすすめたのか
主な導入目的は以下の3つでした。
- 業務に集中できる環境の実現による業務効率の向上
- 通勤ストレスの軽減、通勤時間の短縮などによる社員のモチベーション向上
- パンデミック（感染症流行）の際の事業継続対応
上記にはありませんが、今年2018年は非常に強い台風が数回日本に上陸し、リモートワークを利用することで普段と変わらない、もしくはそれ以上の成果を出せたのは大きかったです。
これも制度として導入してあったからできたことだと思っています。
なぜ開発部門から導入をすすめたのか
エンジニアというのは不思議な生き物で、単純な時間に比例して成果が上がるということは稀です。
集中できているときは普段の数倍の成果が出ることもありますし、逆に打ち合わせなどで時間が飛び飛びに区切られてしまったときは何も進まなかった、という事象も発生しえます。
ですのでリモートワークという環境を先陣を切って試し、制度化する部署としては最適でした。
「制度」として導入するまで
トライアルから正式導入までの期間
2017年の3月から12月まで、ルールをチューニングしながら2段階のトライアル（試しにやってみる）を実施し、アンケートからフィードバックをいただき、人事部門と調整しながら2018年の1月から正式導入をしました。
トライアル段階と制度として導入する段階で一番違うところは「会社としてそれを認めているか」の部分です。
何か不具合があったときに止められるトライアルと違い、もし制度に不備があったときは気軽に変更ができないので、以下のような部分を中心にきっちりと細部まで設計することに重点を置きました。
対象となる社員
「常時の作業指示・業務管理が不要であり、業務内容の予実管理や成果物などで業務成果が図れる業務に従事している者」を対象としました。
入社して間もない方など、開発部門のメンバーでもこの条件に該当しない方は対象外としました。
誰が利用しているのかをどう把握するのか
有給休暇や時間休の連絡と同じ基準を適用しました。平たく言うと「事前に連絡をもらう」ことで上長はもちろん、関係者も把握できるようにしました。
労働時間の管理方法
こちらもオフィスワーカーと差が出ないよう、会社として定められている「定時」に業務を開始し終了する形をとりました。22時以降の深夜残業は障害対応など特別な理由がない限り原則禁止としていますが、こちらもオフィスワークと同じ基準です。
また、勤務開始と終了時は上長（と関係者）にSlack等で開始終了連絡を入れることもルールとして設定しました。出社時と退社時の挨拶みたいなもんですね。
対象外とする際の基準
当たり前といえばそうなんですが「対象者の基準から外れた場合」になります。 担当業務が変わった場合、成果物の品質が著しく下がった場合など、上長や管理監督者と相談しながら判断する、と定めました。
こう書くと「なんか堅苦しいな、めんどくさいな」と思われるかもしれません。 実際こういった定義がきちんとされていなかったトライアル期間でも、ほぼほぼ問題は起こっていませんでした。
ですが、仮に0.何％の確率で何か起こった場合の対処法を示しておかないと、制度そのものが成り立たなくなってしまいます。どういう制度を作るときにも細部の設計やあいまいな点がないかの確認は大事だなと、改めて思いました。
特に苦労した点
これはもう「オフィスワーカーとのコミュニケーション」につきます。 特に打ち合わせのやりづらさは課題としてあがりました。
上述した制度対象者についての設計と違い、一緒に業務をするオフィスワーカーに不利益や不便さが出ないかどうか、トライアル時点で実際に出てしまってる部分をどうしていくかといった課題が一番大きかったです。
環境整備
物理的な距離が離れていてもコミュニケーションが取りやすいツールの導入を進めました。
Slack Callをはじめ、Zoom、ハングアウトなど多人数で音声・画面の共有ができるツールを複数試用し意見をいただいたり、部門全体の会議のときはカメラを用意して中継をするなど、なるべく情報伝達に差がでないような手段を充実させていきました。
打ち合わせのやり方・あり方を変える
たとえば前述の全体会議では、事前・事後に資料をしっかり共有することと、Slackに専用チャンネルを立て、場所に依らず意見を述べられる場を作ったり、といった環境整備をした上でのやり方のアップデートを進めていきました。
副産物として、ライブ中継もアーカイブして事後に見られるようにすることで、当日参加できなかったメンバーがSlackや資料と一緒に見ることで、その場でどういう意見が交わされたのかわかるようになったのも大きかったです。
リモートワークをする上で、すべての環境をオフィスワークと同等にすることは不可能なので、ある程度理解して受け入れてもらう部分もありましたが、このような施策とともに、リモートワーカー自身が直接コミュニケーションを取れない環境でも業務に支障が出ないように意識していただく、などを運用しながら改善していきました。
実際にすべての課題を事前に解決してから導入、というのは非常に難しいと思います。
走りながら考えていった部分もあり、一時的に不便さが出てしまったのは事実ですが、制度として浸透し、開発以外の部門でもトライアルが開始されていることからも、一定の理解は得られ軌道に乗っていると感じています。
これから
今回はリモートワーク制度という切り口だけでご紹介しましたが、生産性や社員の満足度向上を含めた、会社が抱える課題解決というのは、ただ制度を入れただけで解決できるものではありません。
また、1つの制度ですべてが解決できるというわけでもありません。 勤務地や業種・職種、会社や部署のミッションによって解決策は大きく違いますし、数年経てば同じ会社でも違う解決策がよりベターということも十分にありえます。
今回、このタイミングでのリモートワーク制度の導入は、弊社開発部門にとってはよい解決策だった、というだけの話だと思っています。
今後も一緒に働くメンバがより快適に、より気持ちよく働ける環境を提供すべく、制度も進化させていきたいと考えています。
最後まで読んでいただきありがとうございました。
