GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック（前編）。デブサミ2022
今回は「GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック（前編）。デブサミ2022」についてご紹介します。
関連ワード （円滑、幅広、経験等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
全社員がリモートワークで働くGitLab社が、その働き方に関する社内マニュアル「GitLab Handbook」を公開していることは、2020年2月に公開した記事「1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか？」で紹介しました。
この記事は、新型コロナウイルスの感染拡大によって多くの企業がリモートワークの導入を進めている時期と重なったこともあって非常に多くの読者に読まれました。
そして2022年2月に行われたイベント「Developers Summit 2022」では、このGitLab社で働く伊藤俊廷氏と佐々木直晴氏が実際の体験を基にした働き方についての講演「GitLab社で学んだ最高の働き方」を行っています。
実際にオールリモートで働く二人の講演内容は、多くの示唆に富むものになっています。ここではその内容をダイジェストとして記事化しました。
この記事は前編と後編の2部構成です。いまお読みの記事は前編です。
GitLabで学んだ最高の働き方
伊藤氏と佐々木氏の講演はリモートで行われました今日は「GitLabで学んだ最高の働き方」ということで発表していきたいと思います。
私、伊藤と佐々木はGitLabでソリューションアーキテクトをやっている者です。
GitLabは、オンプレミス用のソフトウェアと、GitLab.comも長年やっておりますのでぜひ使ってください。去年めでたく上場しましたので、さらにいろんな機能を追加して強力なDevOpsプラットフォームとして展開していきたいと思っています。
このセッションで共有したい内容の背景、これは個人的にGitLab社に参画した理由のひとつでもあるのですが、製品が魅力的であることともうひとつ、GitLabはご存じの通り、ご存じない方もいるかもしれませんが、従業員全員がリモートワークをしている企業です。
そこなら最先端のやり方での働きができるのではないか、という仮説が私の中にありまして、入社しました。
で、実際どうだったかというと、はい、最高の働き方をする方法論がありましたので、今日はこの場を借りてそれを皆さんと共有したいと思います。
その前に「オールリモート」（All-remote）について、少し紹介させてください。
今はパンデミック下なのでリモートワークを採用してる会社が多いとは思いますが、我々の定義でオールリモートとは、全員がリモートワークで、かつ、Slackなどの非同期コミュニケーションを最大限活用し、GitLabはグローバルカンパニーなので社員が複数のタイムゾーンにまたがっていてもうまく協力していく、というのが我々のオールリモートという定義です。
同期と非同期コミュニケーション
コミュニケーションの同期と非同期にはそれぞれ特性があるので、分けて考えましょう、というのを紹介したいと思います。
チームで成果を出していくためには同じゴールを見て、こういう進め方でやって行きましょうと協力し合うことが必要だと思います。
その共通の理解を進めていくためにいろんなものを駆使する必要があります。
そこでツールも大事ですが、そもそも前提とするのが同期なのか非同期なのか、という点も我々は強く意識して考えています。
例えば、Slackというツールは非同期ですが同期的な使い方をしてしまうことがあるかなと思います。
GitLabでは同期的な使い方は前提としていません。Slackで「○○さんが入力中……」と表示されていても、普通に席を離れてどこか行って、帰ってきたら続きが書いてあるな、というノリで使ってます。
ほかにも「おつかれさまです」とか「今ちょっといいですか」などを入力することはありますが、それに対する相手の反応を待ってしまうと、それは同期のコミュニケーションのプロトコルになってしまうので、相手からの反応がすぐになくてもそのあとに用件も書いてしまう、という感じですね。
ツールだけが非同期なのではなくて、使うスタイルも非同期を前提にする。相手が画面の前にいつもいるとは限らない、そもそも働いてるかどうかも分からない、という前提で仕事をするのがオールリモートのスタイルになっているのかなと思います。
すると、全体として同期を取るポイントがなくて大変かというと、そんなことはなくて、同期的なコミュニケーションも非常に大事だと考えてます。
複数人で同時に話し合って認識を合わせることはどうしても必要で、それがあるからこそ、ゴールとか、次のポイントまでに何をやらないといけないかとか、進め方とかの認識合わせがバチッとできる。
すると、そこにどうやって到達するかは個人に委ねることができるので、ここはリモートワークとすごく相性がいいと考えてます。
非同期の文化を入社プロセスから叩き込まれる
例として、我々はオンボーディングプロセス（入社プロセス）を公開していて、入社したら1日目、2日目、3日目、4日目からその先1カ月ぐらいまで、やるべきことが決められています。
その中身も細分化されていて、それをどこでもやっても、いつやってもいい、という非同期な働き方が前提になっています。なので、入社時にいきなり文化的にも非同期を叩き込まれるというか。
これか、みたいな感じで、非常に個人的には好きな体験でした。
こういう非同期のコミュニケーションをより円滑にするために「コーヒーチャット」という文化があります。
これは同期的なコミュニケーションなんですけど、雑談という形でいろんな話をするんですね。
「そっちはどうコロナは？」とか、「その横の髪の刈り上げって何ミリなの？」とか、そんな話をします。
その中で急にふと「そういえばこの前リリースされたKubernetes Agentの機能、もう試した？」とか、「サンプルのプロジェクトもアップしてるからURLを送るね」とか、同期的に話をして、そこで出たアイディアとかが、また非同期のコラボレーションやGitLabのIssueとかで育っていくという、そういう有機的な繋がりでコミュニケーションができてるのかなと。
これは非常に心地いい体験だなと思っています。
コミュニケーション手段の使い分け
コミュニケーション手段の使い分けについて、より具体的に見ていきたいと思います
メールはどの会社も使っていると思いますが、これは基本的に非同期ですね。
GitLabでも、外部のお客さんとのやりとりですとか、個人的な連絡には適していたりはするので、あまり使いませんがコミュニケーション手段として残してます。
メールでの連絡は緊急ではないという扱いですので、メールで送って返事がすぐ返ってくることは期待されていません。緊急だったらSlackのpingメッセージを送ることが推奨されています。
Slackも非同期なコミュニケーション手段です。90日後にはメッセージが削除されるポリシーですのでインフォーマルな内容を想定していて、例えばエビデンスが必要なやりとりの内容にはあまり向いてない、という使い方をしてます。
90日後にはメッセージを消すというポリシーにすることで、Issueにちゃんと書くように仕向けることになってもいます。
Slackの用途は社内内部の連絡とか情報共有、通知です。
ダイレクトメッセージは禁止しているわけではありませんが、一対一のメッセージは非推奨にしています。
例えば皆さん、共有できる情報だったり、他の人が答えられる質問をダイレクトメッセージ（DM）で送ってしまいがちだと思います。そういうメッセージはパブリックチャンネルで共有した方がいいので転送することが推奨されています。
グループダイレクトメッセージも非推奨です。これはもうとてもカオスになってどのグループか分からなくなるので、一時的にでもプライベートチャンネルをちゃんと作ることを推奨しています。
GitLab Issueは、これも非同期のコミュニケーション手段として使っていますが、公式なコミュニケーション手段として使います。
メールと似たような使い方もできますが、メールと違うのは情報が残りますし、メールの宛先に入ってない人も見られる、より幅広い範囲で見られるのが一般的な特徴です。
GitLabの場合は公開のIssueで製品やサービスの要望も集めていますし、お客さんやユーザーなど外部のメンバーとやりとりすることもできます。
Google DocsとZoom
Google Docsはかなり使われています。これは珍しく同期と非同期両方に対応できる特殊なツールだと思ってます。
Google Docsは、内部的なお客様の情報や、お客さんとのミーティングのときに使います。後で紹介しますが、公式な文書の草案作りに使うケースもあります。
次にようやく同期ツールが出てきます。GitLabはビデオ会議ツールとしてZoomを使っています。基本はZoomしか使わないようにしています。他のツールを使うとその使い分けで効率が落ちるから、という理由です。
ここで徹底しているのが表示名のルールですね。推奨の設定だったり推奨の操作方法というものもハンドブックに記載しています。
電話。これは特に規定はなくて、使う想定がないという理解です。ちなみにGitLabの代表電話に電話をしても、メールで連絡してねっていうボイスメッセージが転送されるだけってハンドブックに書いてあります。私はかけたことはないんですけれど。
ここで紹介したのは、あくまでGitLabの例です。組織によってはSlackに全部履歴を残して、合意形成にも使う、というやり方もあるかなとは思います。
ただ、ここで伝えたいのが3つ目のところです。
GitLabはいま約1600名のメンバーがいますが、メンバーが同じようなルールでコミュニケーション手段を使い分けることが、無駄なく一緒にコラボレーションができていることに繋がっているかなと思います。
今日はほとんど製品の宣伝をしないつもりなんですけど、こうしたルールの定義をするにはまず、我々のハンドブックのようなものを全社的に共有してメンテしていく必要があると思っています。
ですのでまず皆さんぜひGitLabを全社的に導入して、GitLab Pagesでこういったハンドブックを社内公開すると、我々みたいに同じルールでみんな同じような使い方ができると思います。
ミーティングの進め方
次に、ミーティングの進め方についてご紹介したいと思います。
ただし、ミーティングは同期によるコミュニケーションなのでなるべくやらない、ということがまず念頭にあります。なので、そもそもミーティングが必要かというところから考える必要があります。
ハンドブックにはミーティングの断り方も記載してますので参考に、まず本当にミーティングが必要か検討した方がいいと思います。
一方で、Slackで3回以上やりとりが行われたらミーティングの開催を検討する、ということも記載されています。
さて、いざミーティングが必要になったときには、アジェンダが重要になってきます。ハンドブックにはNo Agenda, No Attenda（アジェンダがなければ参加はない）とも書いてあるんですが、基本的にはアジェンダを用意して準備万端に、これは主催者側も参加者の側もその意気込みで、同期によるコミュニケーションのために非同期で準備を徹底するということを心がけます。
これは佐々木さんの経験でもあるのですが、アジェンダを考えてるうちに、実は非同期でもよかったんじゃないか、と気付くこともあります。
ミーティングノートの取り方もGitLabで推奨してるやり方があります。
GoogleDocsを使って、複数人で協力しながらミーティングノートを取るというやり方ですね。
実はこのセッションの打ち合わせでも、2人でどういう内容にするかをリアルタイムで、同期でやりながらディスカッションしました。
ミーティングノートは全員でとることが重要です。なぜか年次の低い人たちだけがやるというカルチャーがあるのかもしれませんが、ミーティングで発表してない人が一番手を動かせる状態なので、その人がミーティングノートをとればいいのです。
ミーティングの途中で思いついた質問も、その人がミーティングノートに書いておけばその後で触れてもらえるので、そういったことも推奨しています。
≫後編に続く。後編では実際のアジェンダ、ジョブ型雇用についての誤解、オールリモートのマネージャの役割などについて説明しています。