一休新入社員の在宅勤務記録

はじめまして、システム本部CTO室の松村です。
私は去年の4月に一休に入社しましたが、当時は緊急事態宣言の真っ只中でした。
一休も感染拡大防止のために多くの人が在宅勤務になり、私もいきなり週5で在宅で働く事になりました。
それから1年以上働いた経験から、一休での在宅勤務はどんな感じだったのか、新人だった自分はどんな感じで業務を行っていたのかについてご紹介したいと思います。

概要

一休では10人以下のチームで1つのプロダクトの開発を行っていますが、 チームで開発をすすめる上で、重要な要素だと感じた以下の3つについて説明していきます。

1. チーム内外とのコミュニケーション
2. 会話によるコミュニケーション
3. 開発のフロー

チーム内外とのコミュニケーション

一休は日常的なコミュニケーションの手段として、以前からSlackを利用しています。
Slack内には様々なチャンネルがあり、全社共通のチャンネルや部署・チームごとのチャンネル、 開発向けのデータやアラートが送られてくるチャンネル、 趣味のチャンネルなどがあります。
私は以前の会社で社内の連絡手段として主にメールしか使えなかったので、以下のような点でSlackのメリットを感じました。

1. 短文で必要な内容だけ伝える事ができる
2. 過去の報告や議論などを全体やチャンネル毎に検索することができる
3. メンションにより、特定の人やグループに即座に呼びかける事ができる
4. 申請のワークフローや、営業から開発への問い合わせなど部署間のやりとりをシステム的に行うことができる
5. スタンプを使うと雰囲気が柔らかくなる 🎉

また、一休のエンジニアには 「times」という個人のチャンネルを持っている人が多いです。
一般的には「分報」と呼ばれるようなスタイルのチャンネルで、 個人の技術メモや興味を持ったニュース、今日食べたものなど様々な内容を投稿しています。
在宅勤務だと直接会話をする機会が減るので、こういったチャンネルを見れば個人のパーソナリティを知る事ができますし、 特定の誰かに相談したい事があれば、本人のtimesチャンネルに投稿すれば必ず見てもらう事ができます。
ダイレクトメッセージだと二者間の閉じた会話になってしまいますが、timesを使えば 気になった人が会話に割って入る事ができますし、後から検索する事ができます。

timesイメージ1

timesイメージ2

会話によるコミュニケーション

一休ではビデオ会議用ツールとしてZoomを使用しています。
オンラインでは普段は簡単に行っていた「隣の人と会話する」という行動もハードルが高くなるので、 ログインせずにすぐに使う事が出来るZoomのメリットは大きいです。

チームによって方針は異なりますが、以下の2点を行う事で 「何も分からない」や「全然違う」状態を防ぐ事ができていると思います。

1. 朝会、夕会などを毎日行い、認識合わせや報告を密に行う
2. 何かあったらすぐ相談する

チームごとのZoomのURLがあれば定期的なミーティングは毎回そこに入るだけで済みますし、 SlackとZoomが連携しているのでSlackのコマンド1つでミーティングを作成する事ができます。
Slack内のビデオ通話だと能動的に招待しないといけないので、そのあたりが気軽にできるのがとてもありがたいです。

zoomミーティングをコマンドで作成する

開発のフロー

複数人が関わるプロダクトは開発中の各段階で確認や連絡などのコミュニケーションが必ず発生するので、 コミュニケーションのコストが大きくなる在宅勤務では、開発のフローも大事になってきます。

私は入社してすぐ小さなタスクをいくつか任されましたが、実際のプロダクトにデプロイするのが非常に楽だと感じました。 以下のように、開発のフローがきっちり定まっているのが要因だと思います。

1. コードはGithubで管理、レビューする
2. CIが整備されていて、自動テスト、テスト環境や実環境へのデプロイが簡単にできる
3. 重要なアラートはSlackに通知が来る
4. プロダクトのログやサーバのデータなどがDatadogに集約されている

それぞれの点について、詳しく説明していきます。

Githubによるコード管理、レビュー

コードの変更はGithubのプルリクエストを利用して管理します。
PR内で指摘や議論ができますし、SlackにURLを貼ればすぐに変更点を見に行けます。
新人でも 指摘→修正→確認 の流れがスムーズに行なえますし、常に他人にレビューしてもらう事を意識すれば、 自ずとコードやPRの内容も良くなる(はず)です。

コードレビュー

CIによる自動テスト、デプロイ

CircleCIによるCIを導入しているため、PRに対して事前に自動テストが動いています。
また、特定のブランチにマージすれば、テスト環境や実環境に自動でデプロイするようになっています。
これにより、自動テストが通らないようなコードを早い段階で発見する事ができますし、 デプロイ時にやるべき作業が最小限になるので、本当に確認すべき内容に集中して、ボトルネックなく開発していくことができます。

特定のブランチにマージするとデプロイ

重要なアラートはSlackに通知が来る

プロダクトや各種監視ツールがSlackと連携しているため、問題が生じた際には即座にキャッチする事ができます。
デプロイ完了通知なども投稿しているので、他の場所を見にいかずに済みます

グラフ付きアラート

プロダクトのログやサーバのデータなどがDatadogに集約されている

サーバのログやステータスなどはDatadogに記録しています。
エラーや遅延など全て関連付けられて記録されているので、 エラーが起きた時や動作が遅い時などは、原因がDBなのかサーバなのか、どういったメッセージが表示されているのかを簡単に辿る事ができ、 原因の切り分けがスムーズに進みました。
一休のDatadog利用については詳しい記事があるので、こちらもご覧になってください。
Datadog Log Management でアプリケーション稼働モニタリング - 一休.com Developers Blog

おわりに

SIerだった前職とは作るものもスピードも開発手法も全然違う中での在宅勤務でしたが、
おかげさまで「在宅勤務だから辛い」と感じる事もなく仕事を続けていく事ができました。

今回紹介してきた内容に関わるシステムやツールは導入や開発記事が過去の記事にあったりするので、興味がある方はぜひ読んでみてください。