リモートワークが定着して数年が経つが、多くの開発チームが「オフィスの働き方をそのままオンラインに移植した」だけの状態に留まっている。朝会はZoomで、相談はSlackの即レスで、レビューはペアプログラミングで——これらは同期コミュニケーションへの依存が高く、タイムゾーンの異なるメンバーや集中作業の時間確保が困難になるという問題を引き起こしている。
筆者が所属するチームでは、エンジニア12名が日本・ベトナム・カナダの3拠点に分散している。かつてはSlackの即レス文化が暗黙の了解となっており、平均的なエンジニアの1日の集中作業時間はわずか3時間程度だった。ここから非同期ファーストへの転換を図り、チーム全体の生産性を大幅に改善した経験を共有したい。
非同期コミュニケーションとは、発信者と受信者が同時にオンラインである必要がない情報伝達方式だ。この原則を「デフォルト」にすることが重要であり、同期コミュニケーションを完全に排除するわけではない。
筆者のチームでは以下の3原則を定めた。
非同期コミュニケーションで最も効果を発揮したのが、設計ドキュメント駆動の開発フローだ。従来は「とりあえず実装してPRで議論」というスタイルだったが、これだと手戻りが大きく、レビュアーの負担も高い。
新しいフローでは、実装前にDesign Docを作成する。このドキュメントには以下を含める。
このドキュメントに対してチームメンバーが非同期でコメントを付け、合意形成を行う。全員の承認が揃ったら実装に進む。結果として、PR段階での設計レベルの議論がほぼなくなり、レビュー時間が平均40%短縮された。
非同期ファーストだからといって、会議をゼロにするわけではない。むしろ、会議の質を上げることが重要だ。筆者のチームでは定例会議を以下の3つに絞った。
以前は毎日の朝会に加えて、週に5〜6回の会議があった。これを週2〜3回に削減したことで、エンジニア1人あたり週に約4時間の作業時間が生まれた。年間に換算すると200時間以上になる。
コードレビューは非同期化の恩恵が特に大きい領域だ。ただし、いくつかの工夫が必要になる。
まず、PRのサイズを小さく保つことが前提条件だ。変更行数が300行を超えるPRは原則として分割する。大きなPRは非同期レビューでは認知負荷が高すぎて、結果的に「LGTMスタンプを押すだけ」のレビューになりがちだ。
次に、PRの説明文の質を高める。変更の意図、確認してほしいポイント、テスト方法を明記することで、レビュアーが質問する回数を減らせる。質問と回答の往復が減れば、非同期でもレビューのリードタイムは短くなる。
さらに、レビュー担当者のローテーションと応答時間のSLAを設定した。「PRが作成されてから24時間以内に最初のレビューコメントを付ける」というルールだ。これにより、PRが長期間放置される問題が解消された。
非同期コミュニケーションの質を支えるのは、情報の構造化だ。Slackの会話ログは流れてしまうため、重要な決定や知見は必ず構造化されたドキュメントに転記する必要がある。
筆者のチームでは、ドキュメントを以下の3層に分類して管理している。
重要なのは、第3層から第1〜2層への昇格プロセスを定めておくことだ。Slackでの議論が有益だった場合、その結論をドキュメントに反映する担当者を明示的にアサインする。
非同期ファーストへの移行は文化の変革であり、技術的な変更よりも難しい。「すぐに聞けないと不安」「テキストだと温度感が伝わらない」という声は必ず出る。
筆者のチームでは、まず2週間のトライアル期間を設けて、効果を数値で可視化した。集中作業時間の増加、PRのリードタイム短縮、会議時間の削減——これらの数字が改善を示したことで、チーム全体の納得感を得ることができた。
また、テキストコミュニケーションのスキル向上にも投資した。文章で意図を正確に伝える訓練は、エンジニアのスキルセットとして非常に重要だ。書く力が上がれば、ドキュメントの質も上がり、チーム全体の生産性が向上する好循環が生まれる。
非同期コミュニケーションは、リモートワーク時代のチーム開発における強力な手段だ。ただし、すべてを非同期にすることが目的ではない。感情を伴う議論や、複雑な合意形成が必要な場面では、同期的なコミュニケーションが適している。重要なのは、デフォルトを非同期に設定し、同期を「必要なときに意図的に選ぶもの」にすることだ。この転換によって、チームの生産性と働きやすさの両方を向上させることができる。
入会申込
ログイン
