SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 レポート(AD)

全員100%リモートで働くGitLab流、最高の働く環境の作り方とは?【デブサミ2022】

【18-C-7】GitLab社で学んだ最高の働き方

  • このエントリーをはてなブックマークに追加

 2014年に法人化して以来、全チームメンバーが100%リモートの“All-remote”で会社を運営しているGitLab社。グローバルのメンバーと生産性高く協働するために、どんな工夫をしているのだろうか。「GitLab社で学んだ最高の働き方」と題し、同社APACリージョンのソリューションアーキテクトの伊藤俊廷氏と佐々木直晴氏が、その知見を披露した。

  • このエントリーをはてなブックマークに追加
左上:GitLab Senior Solutions Architect 伊藤俊廷氏、右下:GitLab Senior Solutions Architect 佐々木直晴氏
左上:GitLab Senior Solutions Architect 伊藤俊廷氏、右下:GitLab Senior Solutions Architect 佐々木直晴氏

All-remoteの実現で重要な“非同期”と“同期”の使い分け

 DevOpsプラットフォーム「GitLab」を展開しているGitLab社。現在、67カ国以上にまたがる1,600名以上の従業員を抱えながら、オフィスを持たないAll-remoteで組織を運営しており、昨年10月にはNASDAQへ上場を果たしている。

 伊藤氏がGitLabにジョインした理由は、展開するサービスの魅力に加え、「世界最大のAll-remote企業なら、最先端で最高の働き方ができる環境が整っているのではないか」という仮説があったからだった。

 All-remoteとは、全員がフルリモートで働いているだけでなく、Slackなどの非同期コミュニケーションを最大限に活用して、複数のタイムゾーンでうまく協力していくことを意味している。

 この“非同期”というのが、All-remoteでコミュニケーションを円滑に進めるためのミソだ。Email・Slack・GitLabといった非同期ツールを用いてコミュニケーションを行っている。逆に、私たちが日頃行っている打ち合わせや電話、「ごめん、ちょっと一瞬いい?」と声をかけるのは、すべて相手の今の時間を奪うことを前提とした同期コミュニケーションである。

 「Slackを同期的に使っている企業は少なくないはず。GitLabでもリアルタイムで話すことはあるが、それはあくまでも偶然であって前提ではない。『◯◯さんが入力しています』と出ていたとしてもふつうに席を立つし、相手の反応を待たずに自分の用件だけ書いておく。相手が画面の前にいない前提で仕事をするスタイルが定着している」(佐々木氏)

 もちろん、GitLabでもミーティングや1 on 1といった同期コミュニケーションをしないわけではない。むしろ同期コミュニケーションは、複数人がリアルタイムで集う貴重な機会だと捉え、大切にしている。ここで次のゴールのすり合わせを徹底できれば、そこに辿り着くまでの過程は、個人に委ねることができるからだ。

非同期を加速するための同期コミュニケーション
非同期を加速するための同期コミュニケーション

 GitLabでは、社内のマニュアルのほとんどを「Handbook」としてインターネット上で公開している。その中に書かれてあるコミュニケーション手段の使い分けについて、伊藤氏は次のようにまとめた。

E-mail(非同期)

 お客様や外部メンバーとのやりとりなどのためにコミュニケーション手段として残してはいるものの、社内ではあまり使わない。緊急扱いではないので、メールを送ってすぐに返信は期待しないこと。緊急時にはSlackでメッセージを送ってつつくよう推奨されている。

Slack(非同期)

 非公式なコミュニケーション手段として、主に社内の情報共有や通知のために使う。90日後に削除されるポリシーであることで重要な情報は正式なコミュニケーション手段に残される。DMは非推奨で、可能な限りパブリックチャンネルに転送すること。グループDMも非推奨で、必要であれば一時的なプライベートチャンネルを作成する。

GitLab Issues(非同期)

 課題の対応、承認を伴うアカウント申請などの作業依頼、製品やサービスへの要望などの公式なコミュニケーションに使用。メールの上位互換のような位置付け。メールと異なり、後からジョインした人も閲覧できる特徴がある。

Google Docs(同期/非同期)

 ミーティングや1 on 1の際には、必ず事前にGoogle Docsでアジェンダを作成。それを参加メンバー全員でリアルタイムに更新しながら議事録を作成する「Live Doc Meetings」に活用する。Handbookなど公式な文書の草案として利用するケースもある。

Zoom(同期)

 ビデオ会議ツールは原則Zoomを使用。Zoomを使う際には、カメラはデフォルトでオンにする。表記名のルールや推奨の設定など、詳細はHandbookに記載されている。

電話(同期)

 プライベートな議論を個人的に行う場合のみ使用。GitLabの代表電話に電話をかけても、「E-mailで連絡してね」というボイスメッセージが流れるだけ。それくらい電話は使わない。

 「紹介した使い分け方はあくまでもGitLabの例。大切なのは、コミュニケーションルールを定義して、多くのメンバーが無駄なく効率よくコラボレーションできるようにすることだ。ルールの定義には全社員が閲覧できるHandbookのような文書サイトが必要になる。ぜひ全社用のGitLabを導入して、GitLab Pagesで静的サイトのオリジナルHandbookを社内公開してもらいたい」(伊藤氏)

気持ちの良いコラボレーションを促進するためにできること

 GitLabのHandbookには「No agenda, no attenda.(アジェンダのないミーティングには参加しない)」という言葉が記されている。ミーティングの主催者側は必ずアジェンダを用意して準備万端にしておく必要があるし、参加者側も事前にアジェンダを確認して質問ノートへ記載するなど全力で準備に協力することが求められる。これも同期コミュニケーションの効率化を最大限に図るための工夫である。「そもそもこのミーティングは本当に必要なのか?」伊藤氏が作成した以下のワークフローに当てはめて考えるといいだろう。

ミーティングを実施/参加判断するまでのワークフロー
ミーティングを実施/参加判断するまでのワークフロー

 この非同期のコミュニケーションを前提とするGitLabの文化を表す一例として、佐々木氏は新しく入社したメンバーのオンボーディングプロセスを紹介した。GitLabでは、入社初日から1カ月先ほどまでのオンボーディングプログラムの内容が公開されている。そこには1日単位でやるべきことが細かく定められており、そのタスクをこなしてさえいれば、いつ・どこで・どのようにやっても構わない。「このオンボーディングプロセスを通じて、GitLabの文化を叩き込まれた」と、佐々木氏は振り返る。

 入社したばかりで右も左もわからない中、オンボーディングプロセスを1人で進めていくことに不安を感じる人もいるだろう。そんなときはGitLabの雑談する文化である「Coffee Chat」を活用すればいい。伊藤氏のワークフローにもある通り、Coffee Chatであればアジェンダなしで、カレンダーの空き時間に“Coffee Chat”と入れておけば、すぐにメンバーに雑談をスケジュールすることができる。

 「よくジョブ型雇用の外資系企業だと、自分の職務範囲外のことで他人を助ける文化がないと言われるが、GitLabでは決してそんなことはない。自分は入社して半年ちょっとだが、これまで助けを求めたときに助からなかったことは一度もない」と語る佐々木氏。「役職が上がれば、よりチームへの貢献やコラボレートが求められる。ジョブ型雇用で与えられるものはタスクではなくビジョンと責任だ」と強調した。

 加えて、GitLabでは毎週1時間のマネージャーとの1 on 1の機会も用意されている。佐々木氏と伊藤氏が所属するチームには7名のメンバーがいるため、マネージャーは週に7時間を1 on 1だけに割いていることになる。

 1 on 1の場で確認されるのは、決してKPIの達成度などではない。チームメンバーが理想的な状態にあるかどうかを確認するために、「仕事を楽しめているか?」「自己研鑽する時間は取れているか?」「働きすぎていないか?」といった質問を投げかけ、しっかり自分の仕事にフォーカスしてくれている印象があるという。「チームが自立するために、しっかり綿密にメンバーの様子を把握しておくのが、GitLabのマネジメントスタイルだと思う」(佐々木氏)

 さらに、メンバー間の信頼関係を醸成する仕組みには、「公開称賛」がある。「これは私たちが考えた造語」と前置きしながら説明されたこの仕組みとは、要は、みんなの前で他のメンバーの成果を共有して褒め称えるということだ。

 公開称賛には3つの種類がある。1つ目は、メンバーが1 on 1で成果をアピールすると、それをマネージャーがSlackで共有してくれること。2つ目は「Discretionary Bonus」という褒賞制度。ジョブディスクリプションに記載された職務範囲を超えて、生産性の向上や成果につながる働きをした他のメンバーを推薦して認定されると、1,000 USDのボーナスがもらえる。3つ目はSlackの「#thanksチャンネル」。ちょっとしたことでも感謝を伝えられる場所として活用されている。

 今回、紹介されたGitLabの文化やTipsは、メンバー全員が完璧にできているわけではない。個人のスキルや意識に依存する部分が大きいからだ。できなかったとしても、相手に悪意があるわけではない。そんなときは“Assume Positive Intent(ポジティブな意図を前提とする)”の価値観のもと、できないことを指摘するのではなく、できる人が率先して一緒にやって手本を見せればいい。

 「最高の職場は自分たちで作るもの。紹介した内容が絶対的なものとは考えてはいないが、自分たちが働く環境をより良くしていくために、少しでも役立てていただけたら」と語り、伊藤氏はセッションを締め括った。

GitLabで実践している、最高の働く環境を得るためのマニフェスト
GitLabで実践している、最高の働く環境を得るためのマニフェスト

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15727 2022/04/13 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング