プラクティスのナレッジベース
タイムゾーン尊重プロトコル
このプロトコルは、分散チームがオフィスのタイムゾーンに合わせて働かなくても済むように、会議、返信期限、緊急リクエストのルールを定めます。
組織
time-zone-respect-protocol
ドキュメントのセクション
これは何か
これは、異なる都市や国から勤務するチームのための組織ポリシーです。許容される会議時間帯、非同期の返信ルール、緊急の連絡手順を定めます。このプラクティスは、リモートワークが本社以外の従業員にとって隠れた不利にならないようにし、個人の時間を守ります。
役立つとき
- リモートの従業員が、早朝、深夜、または昼休みの個人時間に会議に呼ばれることが定期的にあります。
- チームは、チャットでの即時返信を当然のことと捉えていますが、実際にはメンバーが異なるタイムゾーンで勤務しています。
- 緊急リクエストが明確な緊急度の基準もなく頻繁に届き、人々を常時待機の状態に追い込んでいます。
- 本社チームのオフィスアワーに決定が下され、リモートの参加者は事後的にしか知ることができません。
始め方
- 1 チームのタイムゾーンを把握し、会議が可能な重複する時間帯を特定します。
- 2 返信のルールを定めます：当日中の返信を求める場合と、翌営業日まで待ってよい場合を明確にします。
- 3 緊急度の基準を定義し、本当に延期できないリクエストのための専用チャネルを設定します。
- 4 定例会議を見直し、一部のメンバーの個人時間に常に重なっているものを別の時間帯に移動します。
- 5 ルールのオーナーを任命し、議論のあるケースを解決し、合意を更新してもらいます。
期待される効果
チームはタイムゾーンによる隠れた残業が減り、緊急リクエストと通常のリクエストをより明確に区別できるようになります。マネージャーは、リモートの従業員が意思決定に平等に参加できるように、同期のタイミングを計画しやすくなります。
よくある間違い
- ルールを文章化したものの、定例会議のカレンダーは見直されていません。
- 緊急度を送信者の個人の裁量に任せた結果、緊急リクエスト用のチャネルがすぐに普通のチャットと化してしまいました。
- チームは、各地域の勤務時間を考慮せずに、全員に一律の返信速度を求めています。
- このプロトコルは、当番やインシデント対応において、別途の対応スケジュールがなければ機能しません。
さらに詳しく読む
- 書籍：Jason Fried, David Heinemeier Hansson, Remote: Office Not Required
- 書籍：Darren Murph, GitLab's Guide to All-Remote
- レポート：Buffer, State of Remote Work
- ガイド：GitLab Handbook, Communication
FAQ
このプロトコルは誰が始めるべきですか？
通常は、チームのマネージャーまたはHRが、分散している各チームのリーダーとともに開始します。このルールをリモート従業員からの個人的な依頼としてではなく、計画のための働き方の基準として位置づけることが大切です。
リモートワークに関する大規模なポリシーがなくても始められますか？
はい。タイムゾーンを把握し、定例会議を見直し、主要チャネルでの返信期限を合意するだけで十分です。完全なポリシーは、繰り返し発生する議論のあるケースが出てきたときに後で作成できます。
ビジネス上、緊急の対応が必要な場合はどうすればよいですか？
実際のインシデントと通常の依頼を切り分けます。インシデントには、当番体制と明確なエスカレーションチャネルを設け、全従業員が勤務時間外でも対応可能であることを前提としないようにします。
このルールが機能しているかをどうやって判断しますか？
勤務時間外の会議が減ったか、チャットのプレッシャーによる夜間の返信が減ったか、リモート従業員が意思決定の前に重要な議論に参加しているかを確認します。