Netlifyのリモートワークにおけるコアプラクティスは、非同期コミュニケーションを優先すること、リモートコミュニティ構築において意図的であること、ワークライフバランスの保護を推奨することである。サスティナブルなリモートワークは、サスティナブルな業務時間から始まる。その中には、時間外の連絡に関する明確な境界とプロトコルによって、自分自身を"ほぼ"連絡不可能な状態に置くことも含まれる。
James McNeil氏はQCon Plus November 2021で、自身がリモートファーストSREとなったことで学んだ教訓について講演した。
Netlifyでは、非同期インタラクションの中心をドキュメンテーションに置いている、とMcNeil氏は説明する。
ロンドンからサインインして、私が眠っている間に同僚から回ってきたアイデアやプロポーザルをレビューすることができるのです。
リモートで作業する場合、ネットワークを切断するのは非常に難しいことだ、とMcNeil氏は言う。
オフィスのない時は、Slackがオフィスです。午後11時に"ちょっとメッセージをチェックする"というのは、デスクに戻るのと同じことなのです。同僚が業務時間外であることが分かっていれば、サインオフするように伝えます。休日の制限もないのですから、必要なだけ休暇を取るようにするべきです。
リモートで作業している時の方が連絡は容易にできる、@で指定するだけでよいからだ、とMcNeil氏は言う。すべてのメンションに応答したり、勤務時間外に生じる興味深い会話のすべてに飛び込んだりするのは、心惹かれるものではあるが、とてつもなく消耗することにもなる。自分自身をほぼ連絡不可能な状態に置くべきだ、とMcNeil氏は提案する。
オンコールエンジニアとして、私はシフト中、いつでも連絡が可能にしておかなくてはなりません。オンコール以外であっても、インシデント発生時には、その問題に関する知識を求められることもあります。"ほぼ連絡不可能"というのは、時間外の通知をすべて切断すると同時に、必要な場合にはページをエスカレートできるようにPagerdutyを設定しておく、ということです。エンジニアに電話やメールを送るのは間違いなく不適切な行為ですが、必要ならば躊躇なくページングできる文化を育むことが必要です。
リモートワークは、対人業務よりよい、あるいは悪いという類のものではない。リモートワークに向いている人と不向きな人がいるので、非同期的な作業を推し進めるのには限界がある、とMcNeil氏は説明する。
例えば、コードレビューが必要だということは、できれば社員を一日中ひとりで作業させたくはない、という意味になります。ですが、規律あるアプローチを使用すれば、チャレンジとサポートの両立が可能な、ハイパフォーマンスな組織を構築することができるのです。
リモートファーストSREとしての経験について、James McNeil氏にインタビューした。
InfoQ: リモートワークをサスティナブルにするために、Netlifyではどのようなプラクティスを採用しているのでしょう？
James McNeil: 当社は世界中に社員がいます。全員をすべてのミーティングやディスカッションのためにオンラインにするのは無理ですが、意思決定に声を上げられる、という感覚は持ってほしいと思っています。
当社は、中心的なドキュメントストアとしてNotionを使用しています。そのダイナミックさが、とにかく素晴らしいのです。行に注釈を付けたり、セクションを再構成したり、タグ付けしてインプットを求めたりできます。その上、キーワード検索もできるので、ナレッジベースとして最高です。
Slackは当社のオフィスです。当社では、ディジタルインタラクションを中心としたコミュニティ感覚を育てようという考えから、プライベートチャネルやDMは推奨せず、オープンなコミュニケーションを行っています。誰でもチャネルを作成できるので、#we-make-things、#we-grow-plants、#we-love-food、#we-talk-mental-healthなど、あらゆる種類のチャネルがあります。絵文字もふんだんに使用して、リアクションを短い表現で強調するようにしています。
InfoQ: リモートでより効率的に作業する上で有効な、精神衛生的なファクタは何ですか？
McNeil: 書くためのプラクティスですね。多くのドキュメントと非同期的な作業のもうひとつの面は、アイデアを共有するためには必ずしも一緒にいなくてもよい、ということなのです。自分が理解させたいことのドラフトを書いて検討する時間を確保すれば、対価としてこのような環境が手に入ります。
私がリモートワーキングで大きく変わったと思う、もうひとつの点は、自分自身のセットアップに対して負わなければならない個人的責任の量です。講演ではヘッドセットと、特にインシデント時において自身をミュートすることの重要さについて取り上げたのですが、実際にはインターネット接続の強度から適切な充電器や周辺機器の入手に至るまで、すべてが自分自身にかかっているのです。十分な準備作業をしていなければ、これが大きなストレスになる可能性があります。私自身は、テザリングでインターネット接続を確保しなければならない場合に備えて、モバイルで必要なすべてのものと無制限通信プランを備えた"外出バッグ"を用意しています。
InfoQ: 非同期の作業とはどのようなもので、どのようなメリットがあるのでしょうか？
McNeil: 私は朝サインインすると、まず最初に私がオフの間に行われた社内ミーティングの記録を確認します。Slackのメンション(私と私のチームのハンドルと)とgithubもチェックして、私たちが関係している開発の最新状況を把握します。Zoomでのミーティングも行いますが、1日の大半は集中する時間にしています。
当社の作業モデルに対して、コラボレーションがない、という誤解があるかも知れません。社員の大多数が私と同じようなタイムゾーンで活動していて、一日中連絡を取り合うことができる、という面もあるのですが、ドキュメントファーストのアプローチによって、ドキュメント上のコラボレーションを通じた対話に習熟している、というのも理由です。
非同期に作業することの明らかなメリットは、ハイテクの中心地に居住していない開発者にも幅広い機会を与えることができる、という点です。これを企業の側から見れば、多国籍企業でない限り不可能な方法で、才能ある人々に幅広くアクセスできる、ということになります。
InfoQ: インシデント管理にはどのようなツールやルールを使っているのでしょう、それらはリモートSRE作業をどのようにサポートしているのですか？
McNeil: 当社のSREへのアプローチは、多くの面において、通常のリモートプラクティスの延長上にあります。インシデント発生時には、その時点で可能なすべてのものをドキュメント化するようにしています。最初はこれを、インシデント用のチャネルで行います。インシデントコーディネータが後でそれを、レビュードキュメントに変換するのです。また、正しく聞き取れていることを確認するために、言われたことを復唱するようにしています。インシデント中のグラフの時刻はすべてUTCで記載するようにしています。レビュー時に、タイムラインがUTCで正規化されていることで、いつ何が起こったのかについて混乱しないようにするためです。そして最後に、IC(インシデント指揮者)が誰であるかを非常に明確にしています。ICのハンドルはインシデントチャネルの先頭にポストされます。ICの交代が必要な場合の引き継ぎは、口頭で明示的に行います("James、ICを引き受けられますか？"、"了解、これからは私がICを務めます。")。
InfoQ: リモートワーキングやハイブリッドワーキングには、どのようなメリットがあると思いますか？
McNeil: 私自身、通勤が大嫌いなのです。リモートワークにしたことで、家族や友人と過ごす時間、エクササイズやサイドプロジェクトに従事する時間が大きく増えました。エンジニアとしての自分の仕事内容も向上したと思います。同僚と個人的な会話をすることはできませんが、自分自身の空間で一日のリズムを以前よりもうまく構成できているような気がしています。