2021年、明けましておめでとうございます！
2年連続で新年一発目の記事を担当しています、佐土原です！
昨年の今頃は世間がここまで新型コロナウイルス一色となり活動に制限がかかることになるとは露知らず、飛行機の予約をミスったなどと騒いでいるようですね。
いま見るととても平和そうで微笑ましい限りです…。（当時は当時で真剣に財布が不味かったのです…。）
さて、そのような新型コロナウイルスの影響下ではありますが、弊社では2020年の3月から全社的にリモートワークを導入し、現在も多くの社員がリモート環境で働いています。
このエンジニアブログでもこれまでリモートワークに関していくつか記事が書かれていますね。
今回はこれまでの記事とは少し角度を変えて、リモートワークに適応するためにチームで行なった取り組みについて書いていきたいと思います。
前提
今回取り上げる僕が所属するチームでは以下の前提があることを理解しつつ読み進めていただけると幸いです。
- チームについて
- 5年ほど運用を続けているプロダクトの開発チーム
- 1週間スプリントでスクラム開発を行なっている
- 毎週のスプリントを締める際にふりかえりを実施しており、そこでチームの課題点出しや新しい取り組みの提案などを行う
- 2020年3月以降、プロダクトチームの全員がリモートワークを行なっている
- これまでのチーム文化について
- 突発的な対面でのコミュニケーションで課題解決をしてしまいがち
- レビューは大きく2種類存在している
- 1日に一度、開発者全員揃って対面で実施するモブでのコードレビュー（以下、モブレビューと表記）
- 同期頻度を高める目的で1.5時間に一度手が空いている人で実施するモブでのコードレビューや相談の場（以下、定期モブレビューと表記）
- 知識や知見は個人で蓄積し、コミュニケーションを取ることで都度共有してもらう
実際の取り組み
リモートワークに適応するために行なった取り組みは大きく3つかなと思っています。
- 同期コミュニケーションのオンライン化
- 会議の目的やアジェンダは事前に明確にする
- 同期コミュニケーションと非同期コミュニケーションのバランスを考える
1, 2についてはあまり特別なことはやっていません。
1に関してざっくりまとめると、「これまでオフラインでやっていたことをオンラインで実施している」というものです。
物理的に顔を合わせることができないため、既存の取り組みをオンラインツールを用いて代替しています。
具体的には、
- スクラムイベントをZoom上で実施
- モブレビューをZoom上で実施
- オンラインホワイトボード(Miro)の活用
などになります。
（モブレビューについてはこちらの記事を参照してみてください。）
2に関しては今思うとリモートワークに限らず当たり前に重要なことですね。
会社に出社していた頃は近くの席にチームのメンバーがいたのでつい話し合いから入ってしまいがちでした。
対面であれば話の流れで議論できていたことも、リモートワークになると会議を設定しないとなかなか話す機会が作れなかったりします。
そのためこれまではなんとなく行なえていた議論も「いまってなんの時間だっけ？」と冷静な視点で見ることが増え、目的やアジェンダが曖昧な会議が露呈しやすくなっているように感じています。
相談や壁打ちとしての個別の話し合いは今でも突発的に行うことはあるものの、結果的に現在ではメンバー複数人の時間を確保して議論を行う場合は会議の目的や概要・アジェンダをまとめたドキュメントを事前に作成するようにしています。
このように1, 2については割と基本的なものなので、リモートワーク初期の段階で適応することができました。
そんな中でリモートワークを始めて半年後くらいから少しずつ課題として上がり始め、対処してきたのが3になります。
今回は特に3に焦点を当てていくつか施策を見ていこうと思います。
同期コミュニケーションと非同期コミュニケーションのバランスを考える
会社に出社していた頃はすぐ近くにチームメンバーがいたため都度コミュニケーションを取ることで補えていましたが、リモートワークによりコミュニケーションに多少のハードルが生じたことで以下のような課題が生まれました。
- 知見や情報が個人に偏っており、特定のメンバーへの相談が頻発
- タスクについての認識がずれることが多く、定期モブレビューが長引く
- 上記の結果、定期モブレビューの時間が長くなり個々人のまとまった作業時間が取りにくくなり作業進捗が悪くなる（個人のストレスもたまりやすい）
そして、これらを解消するために以下のことに取り組みました。
- 情報をオープンにする
- 同期的なコミュニケーションと非同期的なコミュニケーションのメリハリをつける
これらをさらに細かく見ていきたいと思います。
1.情報をオープンにする
リモートワークにより物理的に隔絶された環境で働き始めたことで、お互いに何をやっているのか何に困っているのかを検知しづらくなりました。
個人で情報を抱えてしまうとどうしてもコミュニケーションが必要な場面が増えてしまうため、可能な限り情報をオープンにすることを意識し、以下のことを実施しました。
- プロダクトチームのSlackチャンネルの統合
- 作業や調査のログをドキュメントに残す
- ドキュメント格納場所の整理整頓
- 個々人がtimesで現状を共有
意識したことは、「あれってどうだったっけ？」を個人で見返すことができる状態を作ることです。
情報が個人に依存していたり情報の置き場がわからなかったりすると知ってそうな人に確認するしかありませんが、「あれってどうだったっけ？」から「なるほどこういうことか」までを一人で完結できればコミュニケーションの頻度は下げられると考えたためです。
以下にひとつずつ概要を紹介していきます。
プロダクトチームのSlackチャンネルの統合
僕の所属するプロダクトチームでは、開発者は開発組織、POはビジネス組織とメンバーの所属が複数に分かれています。
それに伴いコミュニケーションをとるための場も複数のSlackチャンネルが存在していたため、プロダクトに関するコミュニケーションは原則一つのチャンネルで行うようにチャンネルの棲み分けを行ないました。
結果的に、現在は主に以下の２つの役割を持つチャンネルのみで成立しています（エラーログなど監視系チャンネルは除く）。
- プロダクトメンバーチャンネル（コミュニケーション用）
- リマインドチャンネル（定例mtgや備忘録など業務上のリマインド用）
作業や調査のログをドキュメントに残す
リモートワーク以前は作業や調査のログを残す文化はほとんどなく、作業方法の伝達も口頭や実演でのレクチャーが主でした。
5年ほど運用を続けているプロダクトでこのような状況だったため、どうしても在籍期間の長いメンバーに負担が寄るなどの課題がありました。
そこで在籍期間によらずフラットに情報を取得できる環境を作るために、作業や調査のログを積極的に残していくことにしたのがこの施策です。
個々人で意識するだけだとなかなか難しいと考え、クォーターの成果指標の一つにドキュメントでのアウトプット数を含め毎週スプリントを締めるタイミングでアウトプット数を確認するようなフローも入れつつ進めていきました。
その結果もあり、今では自然とドキュメントを残す文化になってきているように思います。
ドキュメント格納場所の整理整頓
上記の施策でどれだけドキュメントを残せたとしても、必要な時に見つけることができないと意味がありません。
長年の保守運用でConfluenceの階層も煩雑になっていたため、直感的にドキュメントの場所がわかるよう階層整理を行ないました。
ドキュメントの整理については過去のブログで金谷さんが書いてくれているので詳細はこちらを参照してみてください。
個々人がtimesで現状を共有
リモートワークになり個々人が何をやっているのかをリアルタイムで拾いにくくなったため、Slack上でtimes（分報）を活用することを意識しています。
分報の詳細についてはこちらの記事を参照してみてください。
これにより誰がいま何をしているのかを把握しやすくなり、かつ困っていそうな時にもすぐに声をかけることができるようになりました。
（決して進捗を監視するための施策ではないため、timesの利用に変に圧力をかけないようにすることを個人的には意識しています。）
2.同期的なコミュニケーションと非同期的なコミュニケーションのメリハリをつける
上記1の施策によってある程度情報をオープンにすることができました。
これにより、これまでZoomでの定期モブレビューを1.5時間に一度行なうなど同期的なコミュニケーションに頼っていた部分を、非同期のコミュニケーションでもある程度情報を補完することができるようになりました。
そこで取り組んだのが以下です。
- 定期モブレビューの頻度見直しと非同期レビューの導入
- 非同期レビューはSlackのリアクションで管理
こちらもひとつずつ概要を紹介していきます。
定期モブレビューの頻度見直しと非同期レビューの導入
同期コミュニケーションではコミュニケーション摩擦が発生しにくく情報の細部まで確認・共有ができるという利点がある一方で、つい時間が長くなりやすいという欠点があります。
またチャットなどで非同期にコミュニケーションをとると要点のみを簡潔かつ手短かに伝えられるといった利点はあるものの、表現に気をつけないと背景や意図が伝わりづらかったり文面からネガティブな感情を想像して受け取ってしまうなどの欠点があります。
リモートワーク以前は近い座席で端的に同期コミュニケーションをとることでうまく欠点をカバーできていましたが、リモートワークにより背景情報を交換しつつ端的に同期コミュニケーションをとることが難しくなったためより時間がかかるようになっていました。
しかし先に挙げた1の施策により情報がオープンになったことでそもそも同期コミュニケーションをとる必要性が下がり、非同期コミュニケーションの欠点であった背景や意図が伝わりづらさが薄くなりました。
そこで、特にコードレビューについてはこれまで対面でのモブレビューだけだったところをGitLabのMRを共有する非同期のレビューを取り入れていくことにしました。
非同期だけにしてしまうとそれはそれでコミュニケーション摩擦が生じる懸念もあったため、結果的に基本は非同期レビューでコミュニケーションをとるものの1日に数回は対面でのモブレビューの場を設けるという形で現在は落ち着いています。
具体的には以下の表のようなレビュー頻度です。
| これまで | 現在 | |
|---|---|---|
| 非同期レビュー (文面・チャット) |
なし | 随時 |
| モブレビュー (対面・全員参加) |
1回/日 | 1回/日 |
| 定期モブレビュー (対面・任意参加) |
5回/日 | 2回/日 |
↑ 非同期レビューの依頼の様子
↑ 定期モブレビューの様子
非同期レビューはSlackのリアクションで管理
上記のように非同期コミュニケーションの一環として非同期でのレビューを導入しましたが、導入当初は誰がどこまで確認したのかがわかりづらくレビュー依頼者がモヤりやすいという課題がありました。
これを解決するために、各自レビューのステータスを示すSlackのリアクションをつけることにしています。
- レビュー依頼を確認しました → 🙋
- レビュー済み（問題なし） → 👍
- レビュー済み（コメントあり） → MRへコメント
これによって現在誰がどのようなステータスなのかを依頼者が把握することができるようになり、非同期レビューでの摩擦も減ったように思います。
まとめ
これらの施策を実施したことで、リモートワーク開始当初に比べるとかなりストレスを軽減しつつチーム開発を進められているように思います。
一方で、チーム内での自然発生的な雑談や、会議を開くほどではない壁打ち・相談などの場を作り出すことができずやりづらさを感じるメンバーが僕を含め存在しているといった課題も残っているため、この辺りもうまく解決できるような工夫も引き続き取り入れていきたいなと思っています。
最後に、今回の記事ではさも僕自身がいい感じに施策を考え実施した風に書かれていますが、今回の施策の多くは実際にチームメンバーが挙げてくれた働きづらさやストレスを発端として、チームメンバーの皆さん自身が解決策を提案し解決されてきたものです。
いつもチームを良くしようと考え、しっかりと課題や提案を伝えてくれるメンバーの皆さんに改めて感謝したいと思います。
いつもありがとうございます！そして2021年もよろしくお願いします！
