はじめに
こんにちは、株式会社カナリーでVPoEをしている高山です。
今回は、弊社のプロダクト組織でフルリモートワークを可能にするために行っている工夫や設計についてシェアをさせて頂ければと思います。
（記事タイトルは某有名本からのオマージュです笑）
事業拡大に伴い、カナリーのプロダクトメンバーもここ1年間で大きく増えていますが、「フルリモートワークが成り立つ」ための組織作りを以前から意識して行ってきたため、ある程度スムーズにスケールが実現できています。
最近ではAmazonが「2025年1月から出社を週5日に戻す」という通達を出すなど、テック業界全般として出社回帰の流れもある中、そもそものリモートワークに対する捉え方や、実現のために必要な取り組みなどについて、1つでも参考になるものがあれば幸いです。
リモートワークできる環境が重要だと考える背景
前提として、特にプロダクト組織においては(フル)リモートワークができる環境は重要だと考えています。
主な背景は下記です。
1. パフォーマンスを最大限発揮できる環境は人によって異なる
「自宅ではどうしても怠けてしまうので、出社した方が仕事が進む」という人もいれば、「自宅の静かな環境でコーディングをした方が集中できる」という人もいて、最大限のパフォーマンスを発揮できる環境は各人で異なると考えています。
後述するように、「オフラインで一緒になって議論・作業することで効率的に進めることができる業務」は一定存在しますが、普段の仕事においては 生産性高く働ける環境を各人が選択することで全体のパフォーマンスを上げていきたい というのが弊社プロダクト組織におけるスタンスです。
※ 会社全体として きちんとパフォーマンスが出ている限り、本質的でない部分での制約はできるだけ課さない という考え方が浸透していることも、上記のスタンスを持つことに繋がっています。
2. 優秀な方と一緒に働ける機会を逃さないため
採用面談などで他社のエンジニアの方とお話しする中で、「今の会社の方針が "フルリモート可" から "週2出社必須" に変わってしまった」「遠方からのフルリモートを前提に働いていたが、それができなくなったので転職を検討している」などの声を聞くことが多くなっています。
このように「出社必須」が障壁となり、優秀な方と一緒に働ける機会を逃してしまうのは、会社としても大きな損失と考えていることが背景の2つ目です。
実際のリモートワーク状況
北海道や秋田、和歌山など、在来線での出社が難しいエリアに住んでいるメンバー（全体の約3割）については、フルリモートでの業務を行っています。
フルリモート以外だと、「週の半分くらい出社」「ほぼ毎日出社」などグラデーションがありますが、いずれにせよ普段の出社頻度については各メンバーの判断に任せている状況です。
一方で、アーキテクチャ設計やプロダクトの方向性に関する議論など、ホワイトボードを使いながらオフラインで一緒に議論した方が圧倒的に進めやすい業務があることも確かです。
そのような業務がある場合は、事前に日付を決めた上で、無理のない範囲で可能な限り出社してもらうような運用も行なっています（もちろん、業務都合で遠方から出社いただく場合は交通費を支給します）。
フルリモートを可能にするための工夫・設計
上述した(遠方からの)フルリモートワークを可能にするにあたり、「生産性の低下」「コミュニケーションの量・質の低下」といった懸念に対処するための工夫や設計をこれまで行ってきました。
そのいくつかを下記にて紹介します。
1. ドキュメンテーション文化の醸成
各自がリモートで働く中でも開発の生産性を落とさず、効率的な学習やスムーズな連携を実現するためにも、「ドキュメンテーション文化」は非常に重要です。
そのような文化醸成のため、「積極的にドキュメントを書きましょう！」という声掛けをチーム内で行うだけでなく、「ドキュメンテーションガイドライン」を作成し、ドキュメントを書く目的やメンテナンス対象などの明文化を行っています。
このガイドラインを新規メンバーが読み、理解するステップをオンボーディングのプロセスに組み込むことで、チーム全体が常にドキュメンテーションに対する共通認識を持って業務を進められる状態になっています。
ドキュメンテーションガイドラインの目次(一部)
また、不動産業界特有の用語やプロダクト内で使われる言葉（≒ ユビキタス言語）の用語集を作成・更新することで、各メンバーが非同期でもドメイン知識のベースを揃え、不安なく開発を進めることができるような工夫をしています。
不動産業界やプロダクトに関わるドメイン用語集（ユビキタス言語）
その他、「日々のプロダクト運用対応」や「オンボーディング項目」、「心理的安全性を保つためのガイドライン」など、あらゆる領域で「ドキュメントを書く」ということが文化として根付いています。
必要なオンボーディング項目をカンバン形式でまとめたリスト(一部)。新メンバーはこれらの項目を1つずつこなすことでスムーズに開発へと入っていくことができる。
（※これらは現在一部チームで行っているものですが、今後は本部全体の取り組みとして広げていく予定です）
2. コミュニケーション設計
リモートワークによる弊害として「コミュニケーションの量・質の低下」が挙げられることがありますが、その対策として下記のような取り組みを行っています。
-
Gather（バーチャルオフィス）導入による協働感の醸成
- Gather はいわゆる「バーチャルオフィス空間」を提供するサービスで、前職などで利用経験のあるメンバーから「カナリーでも使ってみたらどうか」と提案があり、早速トライアルで試したところ感触も良かったため、すぐに本部全体での活用が広がりました。
- 総じて、「一緒に働いている」という"協働感"を得るのに役立っていると感じています。
- 特に新規メンバーから「他メンバーに気軽に声をかけやすくなった」などのポジティブなフィードバックもありました。
- 業務中は各メンバーがバーチャルオフィスに「入室」していることをルールとし、ちょっとした相談などは相手の席や雑談スペースで気軽に行うことができます。
- 特に作業に集中したい時や離席時は「応答不可モード」を選択することで、今は会話できない旨を周囲に知らせることも可能です。
- 定例やミーティングなども原則バーチャルオフィス内の会議室で行っています。
バーチャルオフィス イメージ(Gather公式サイトより)
- 「Slackコミュニケーションガイドライン」の作成・周知
- チャットツールとして利用している Slack でのコミュニケーションを効果的に行うためのガイドラインを作成し、社内で周知しています。
- ガイドラインの例
- 「新たにチャンネルを作成する際は、原則Publicチャンネルとする」
- 「業務上のやり取りは、原則DM(グループ)を避け、Publicチャンネルで行う」
- 「メンションを受け取ったら必ず反応する」
- 「業務時間外のメンションは受け取る側がコントロールする」
- etc...
3. 働く時間に関する工夫
「働く時間」という観点でもリモートワークが成り立ちやすくするための運用がされています。
開発本部ではフレックス制を採用しており、コアタイムが存在するのですが、家庭の事情などがある場合は（チームで認識を持った上で）途中抜けなども可能です。
定例などのミーティングについても、曜日を寄せるなどして生産性を高める動きをしています。
4. 定期的にオフラインで顔を合わせる機会を作る
普段のフルリモート業務でのコラボレーションを円滑に進めるために、定期的なオフラインでの交流も重要だと考えています。
その交流の機会の1つとして、遠方の方も含め原則全社員が集まる「全社キックオフ」を半年に一度開催しており、各本部の半期振り返り&方針プレゼンやMVP社員の表彰、懇親会などを行っています。
（当然、遠方の方の交通費・宿泊費は会社の方で負担する形です）
普段フルリモートの方も含め、この場で全社・各本部の方針など共通の方向性を確認し、リアルに顔を合わせ話をすることで、日々の業務におけるコミュニケーションをより効果的に行うことができているという実感を持っています。
その他、オフラインで集まる大きめのイベントとして、開発本部では2022年に2泊3日の開発合宿を実施しました。
今後さらにメンバーが増えれば、また実施の機会があるかもしれません…！
おわりに
弊社でフルリモートワークを可能にするために行っている工夫や設計についてシェアさせて頂きました。
今後のプロダクト組織の方針としても、フルリモートができる環境整備は継続していきたいと考えています。
その根底にあるのは、記事内でも述べた 生産性高く働ける環境を各人が選択することで全体のパフォーマンスを上げていきたい という考え方であり、これが大きく変化することはあまり無いと思っているためです。
※ 一方で、「本質的でない出社は不要だが、時には（前述したような機会に）皆で集まることも大事」という考え方を共有できるかについては、採用段階でも確認をさせて頂いています。
ここまで読んで頂いた上で、「現在フルリモートで働ける会社を探している」という方がいらっしゃれば、記事下の Entrance Book なども是非覗いてみて頂けると幸いです。
それでは次回、またお会いしましょう！
Discussion