フル出社からフルリモートになった話

この記事は BABY JOB Advent Calendar 2024 の 19日目の記事です。

はじめに

私はBABY JOBに参画して約３ヶ月の新米社員で、地方在住でのフルリモートで勤務しています。
今回が初めての転職で、前職でも同じくWebサービスを開発していましたが、フル出社でした。

勤務形態の変化と、変化を通して見えてきたこと、感じたことについて共有します。
フルリモートを経験していない読者の参考になれば幸いです。

入社前の開発体制

前職ではいわゆるウォーターフォール開発を行っていました。
５〜６人ほどのチームで毎日朝夕のミーティングを対面で行い、毎週金曜日に全体の工程に対する進捗状況を管理職に報告するのが日々の業務のルーチンでした。

開発作業は全て個人ワークで、朝夕のミーティングで確認したタスクを個人個人で処理します。コミュニケーションは必要に応じて適宜をとります。私はオフィスにあるホワイトボードをよく活用していました。リリース作業などの運用作業のみペアワークで処理していました。

開発部は100人を超える組織で複数チーム横断のプロジェクトもよくありました。
フロアが分かれていることもあり、チーム外とのやりとりはチャットツールが基本で、各々の裁量でメールや電話を用い、場合によっては会議を設定するという感じでした。ビジネス側とのやりとりはチャットツールを導入しておらずメールか電話でした。

入社後の開発体制

BABY JOBでは現在５人のエンジニアとスクラムマスター、及びビジネス側のプロダクトオーナーでスクラムによる開発をしています。
スプリントプランニング、デイリースクラム、バックログリファインメント、スプリントレビュー、レトロスペクティブといったスクラムイベントを毎週行っています。

スプリントプランニングでスプリントでのタスクと担当者を設定して開発作業を進めています。ペアワークでの作業が多めで、作業の開始は担当者同士でコミュニケーションをとって決めています。
スクラムチーム内ではoviceを使った通話＋画面共有での作業、コミュニケーションが多いです。これはプロダクトオーナーとのコミュニケーションも含め、です。

入社前後の比較

コミュニケーションツール

	前職	BABY JOB
チャット	Mattermost	Slack
ソース管理	GitLab	GitHub
ペア作業、通話	対面	ovice
ミーティング	対面、Zoom	Google Meet
文書共有	社内ファイルサーバー	Google Drive
スケジュール共有	基幹システム	Googleカレンダー
課題管理	GitLab	Backlog

Google Workspaceで多くのことが完結するようになった結果、フルリモートへの移行は肩透かしなほど簡単に進みました。ツールの導入も参画数日で全て終わるようにタスクがまとまっているためスムーズでした。

ミーティングがリモートになったことでホワイトボードが使用できなくなってしまいました。
ペンタブで再現することも考えましたが、ホワイトボードの利便性はペンで描くこと自体にはないなとすぐに気がつきました。

そこで私はホワイトボードの役割を「思考の整理」と「思考の共有」に切り分けてカバーしてます。

「思考の整理」は手元で紙に書き殴るようにしました。考えをまとめるにあたってはホワイトボードと全く遜色ありません。
「思考の共有」はdraw.ioを画面共有するようにしました。アイデアを図式で共有するにあたってむしろホワイトボードより優れています。

「思考を整理しながら共有したい場合」だけは完全にはカバーできないのですが、「思考を整理しながら共有したい場合」は日常的には発生しない、ということに気がつきました。

説明者自身が整理できていないことはうまく共有できないし、逆にうまく共有できるのならいきなりその場で清書を描いてみせれば良いためです。

ゼロからイチを生み出す手法として複数人でのブレインストーミングを行いたいことはありえますが、日常的に発生するものではないと思うのです。

チーム開発

前職で感じていた課題は

1. 開発組織全体として開発力が上がっていかない。「できる人」が大半の仕事をこなしていき、負担は「できる人」に集中、それ以外の人が成長の機会を失う傾向にある。
2. 細かなバグも許容しないために様々な品質担保の取り組みがあり、開発スピードを損なっている。特に、頻繁に詳細な設計書の作成・更新を行うのが費用対効果が低い。
3. テキストコミュニケーションの比率が高すぎる。ターン制コミュニケーション特有の遅さ、発言者の心理が見えないことによるギスギスが生じがちになっている。

といったことでした。それぞれに対する私の見解は

for 1. ペアプログラミングやコードレビューを導入して開発経験を共有するべき
for 2. バグを一切出さないことよりもバグ修正を素早くデリバリーする方向性を
for 3. 全ての関係者とすぐに顔を合わせて会話できる体制を

といったことを望んでいました。そんなときにIPAのアジャイル開発宣言の読みとき方を見つけて、「ああ、私のやりたいことってアジャイル開発だな」と。1.、2.に関しては「入社後の開発体制」の項目でペアワークやスクラムの運用を紹介した通り、実現しています（アジャイルに関しての深掘りは今回は割愛します）。

面白いことに3.はフルリモートになった今の方がやりやすくなったと感じています。
出社が当たり前だと物理的に近いチーム内のコミュニケーションは円滑ですが、物理的に遠いメンバーとのコミュニケーションのコストを相対的に重く感じがちでした。
フルリモートでは物理的な距離の概念が消え、チーム内外のコミュニケーションのコストの相対差がなくなりました。超えるべき境界は心理的なハードルだけです。

越境コミュニケーションの障壁を一つ取っ払えることは、元々心理的ハードルの低いチーム内コミュニケーションを円滑にすることよりもプラスの寄与が大きいと考えてます。

ライフサイクル

以前は勤務開始時刻の40-50分前に家を出ていたので、プライベートの時間がかなり増えました。

フレックス制度を活用して早い時間から勤務してもいるので、早い時間に仕事を終えたらスーパーに買い物に行ってちょっと凝った夕食を作っても19時頃には食べ始められます。
会社の一員であると同時に家庭の一員であるべきと考えているので、この点は私の中で非常に大きな恩恵です。

また時間が浮いたことで退勤後にジムに行くようにもなりました。
出社しないと運動不足になることを心配していましたが、むしろ出社しないことで運動不足が改善しています。退勤直後は頭が疲れてることが多いので、無心で身体を動かすのが捗ります。

典型的な1日の比較

心理的安全性

フルリモートは孤立感を覚えやすいという話を聞いたことがあったので幾ばくか心配していましたが、こちらも杞憂でした。

出社と比べて失われるものは

• 周りに人がいる安心感
• オフィスのガヤガヤ感

あたりでしょうか。

周りに人がいる安心感に関しては、oviceに常駐していることで無意識に補われているのかもしれません。10代の長い期間をオンラインゲームに捧げてきた私には、実家のような安心感で受け入れられました。

オフィスのガヤガヤ感はむしろ苦手としていたので、話している人とだけ音声を共有し、個人作業のときに完全な静寂に包まれるのがとても捗っています。

自分の発言を内省したいときや集中してザクザク進捗を上げたいときに関係のない話が耳に入ってくることをとても辛く思っていたので、この点はフルリモートでの明確な改善点になっています。

BABY JOBのビジョンとリモートワーク

これは個人の解釈になりますが、「すべての人が子育てを楽しいと思える社会の実現」を目指す会社として、社会の一員でいらっしゃる弊社サービスのユーザーはもちろん、従業員自身もその社会の一員として家庭を大事にすべきだと考えています。

住む場所を縛られずプライベートの時間を確保できるフルリモートという働き方は、BABY JOBによくマッチしています。私の家庭は夫婦共働きで、自分が子育てをすることは前職にいた頃はイメージできませんでしたが、BABY JOBでなら両立できそうかも、と思うことができています。

参考：BABY JOBで働く人々。

確信したこと

出社の方が

• コミュニケーションが捗る、生産性が高い
• 心理的安全性が高い、健康的である

といった一般論は、私には当てはまりませんでした。

所詮、出社かリモートかは手段の話でしかなく、本当に目を向けるべきことは出社/リモートのどちらを選ぶか自体よりも

• なぜ出社/リモートか
• 出社/リモートでどう取り組むか

なのだと思います。優位性をはっきり説明でき、劣位性をどういった取り組みで補うかは、出社/リモートのどちらを選ぶにせよ考えるべきことのはずです。

私の場合であれば個人としても会社としてもリモートワークが適している理由が優位であり、リモートワークでの業務のために必要な開発体制やツールが整備されていることで、快適なリモートワークを送ることができています。

もし読者がフルリモートを検討中の方なら「理由」と「取り組み方」に着目してみると良いかもしれません。