GitLabに学ぶ！第2弾「GitLabで学んだ最高の働き方」佐々木 直晴 × 伊藤 俊廷

GitLabの最高の働き方

GitLabは、DevSecOpsプラットフォームを GitLab.com、GitLab self-managed、GitLab Dedicated を通じて、開発者に焦点を当てた全体的なDevSecOpsサポートソリューションを提供しています。60カ国以上にまたがる 2,000名以上の従業員を抱える世界最大のall-remote企業です。

GitLabでは、オフィスも優先タイムゾーンもありません。非同期コミュニケーションに偏重することで、ドキュメンテーションを促進し、同期ミーティングを抑制し、より柔軟性のある働き方を実現しています。さて、GitLabの最高の働き方をご紹介するにあたり、まずは資料の位置づけやリモートの定義を記載しておきたいと思います。

本レポートに使用する資料の位置づけ

The GitLab Handbookとは

「The GitLab Handbook」は、GitLabのリモートワーク方法論とカルチャーをまとめたガイドで、透明性を重視して3,000ページ以上にわたりWebで公開されています。情報共有の効率化を目的として始まり、メールやチャットでの情報の繰り返し共有を減らすことを目指しています。誰もがマージリクエストを通じて修正提案ができ、過去の変更の記録が残ります。

リモートワークの定義

この数年リモートワークという言葉が独り歩きしていますが、皆さんが考えるリモートワークの定義はありますか？ 例えば、次のようなシチュエーションは、オフィスにいるだけで非リモートと言えるでしょうか？

オフィスでの作業が自動的に非リモートワークになるわけではありません。多くのオフィスワークは、他のチームメンバーと時間をずらしてコミュニケーションを取る非同期的な作業です。本講演内容は、広く本質的な意味でのリモートに着目するため、すべてのシチュエーションで活用できます。

GitLabが非同期コミュニケーションを重視する理由

GitLabが非同期コミュニケーションを重視する理由は、コミュニケーションの手段とタイミングの選択がリモートワーク環境での効率性と効果性に直結すると考えるからです。一般的なコミュニケーションスキルが相手の感情への寄り添いや傾聴技術に焦点を当てるのに対し、GitLabでは、情報の伝達に最適なコミュニケーション手段の選択も同等に重要視しています。しかし、この手段に関する議論や体系化はまだ発展途上であり、今後より議論が必要であると考えています。

詳細はこちら > GitLab：組織の自律自走を促すコミュニケーション

千田：非同期を前提にしつつも、早く返信が欲しいときってありませんか？

伊藤：そこは工夫するしかなくて、私の場合はSlackで返信がなくどうしても緊急な場合には電話しちゃいますね。Slackに急いでいることは書くので、何日も放置されることはありませんが、返信速度はやはり個人のSlackの使い方に依存しますよね。

佐々木：私も電話は使います。ただ、電話だとログが残らないので、本当に気づいてもらうためだけに使用しています。

コミュニケーション手段の使い分けを明確に

The GitLab Handbookでは、社内で使用するコミュニケーションツール（Email、Slack、GitLab Issues、Handbook、Google Docs、Zoom、Phoneなど）の使い分けが明確に記載されています。これにより、社内で一貫したコミュニケーションを取ることが可能です。複数のガイドラインがあると混乱を招くため、一つのハンドブックにルールを集約し、全員で共有することが重要です。

伊藤：実はSlackのメッセージが90日で消えるんですけど、これが意外といい効果を生んでいるんですよ。特に非エンジニアの人たちが、Slackだけで済ませがちなんですが、この消える仕組みで、みんなドキュメントに書く文化に慣れてきてるんです。いいTipsですよね。

佐々木：それで、カジュアルな話も消えちゃうんですよね。「あれ、あのおいしかったラーメン屋、どこだっけ？」みたいな（笑）

千田：じゃあ、業務外の話とかは別のツール使うんですか？

伊藤：うーん、業務外の雑談にもSlackはよく使いますね。ラーメンチャンネルとかゲームチャンネルもありますね。

千田：そういったチャンネルも90日で消える？

伊藤：ええ、そうですね。でも、まあ消えたって業務にはあんまり関係ないですし。大事なことは別でメモしておきますけどね。

信頼できる唯一の情報（SSOT）の重要性

情報をどのように保存し、取り出しやすくするかはコミュニケーションにおいて非常に重要です。GitLabでは、信頼できる唯一の情報（SSOT：Single Source of Truth）という概念があります。これは、重要な情報が一箇所にまとめられ、誰でもアクセスでき、関連情報が一目でわかる状態を指します。

例えば、野球を例に取ると、特定の状況で選手がどのように行動するかは、ルールと現状を正確に理解しているかによります。すべての選手が状況を正確に把握していれば、自分の次の行動を決めることができます。逆に、現在の状況が不明確だと、何をすべきか分からず、ゲームは成り立ちません。

この例から、正確で一元化された情報があることで、各人が自律して行動できるようになり、全体がスムーズに機能するということがわかります。これが、信頼できる唯一の情報源の重要性です。

GitLabのドキュメント文化

GitLabにおける社内のコミュニケーション手段を下記のような表で表現しました。縦軸にSSOT的か散在的か、横軸に同期的か・非同期的かをひいています。例えば The GitLab Handbook は、非同期的であり、最も透明性の高いSSOT的な位置付けになります。

GitLabでは、左下の同期的で散在的なコミュニケーション手段を、右上の非同期的でSSOTな手段に集約していくことで、長期的に組織全体の効率性を高めることができるのではないかと考えています。このあたりを意識しドキュメント化していくと効率的な組織づくりのヒントになることでしょう。

千田：ちなみに、ドキュメント管理のアンチパターンってありますか？

伊藤：ドキュメントの管理って本当に大変で永遠の課題ですよね。 The GitLab Handbook は、アンチパターンを潰すために作られているものの、みんなで更新・編集する難しさは感じています。特に、マージリクエストみたいなエンジニア向けの概念が障壁になっちゃってます。でも Google Docs みたいなものにすると、今度はドキュメントがごちゃごちゃして、何が最新かわかんなくなるんですよ。フォルダの掘り方やドキュメントのネーミングルールも体系化していく必要がありますね。

佐々木：The GitLab Handbook は、各セクションに責任者がいるんです。だから、その人が内容を決めたり、整理したりするわけです。これがないと、すぐにごちゃごちゃしちゃうんですよね。

伊藤：ドキュメントのオーナーシップって大事ですよね。でも、誰でも意見は言えるようにしておくべきだと思ってます。そうすると、いいアイデアがどんどん出てくるんです。

千田：ドキュメントってどうやって探しやすくしてるんですか？

伊藤：自分は、検索結果を意識してファイル名をなるべく英語で統一してるんですよ。それだけでも、探しやすさは変わると思います。

千田：ドキュメントのルールに窮屈さを感じる人もいますか？

佐々木：採用の段階で、ドキュメントベースのコミュニケーションを理解してもらうようにしてますから、そういう問題はあまりないですね。技術的なことで困ってる人はいるかもしれませんが、そういう時は周りがサポートします。

同期 × 非同期、無駄なく効率的なコラボレーション

リモート環境では、「ちょっと今いい？」といった即時のコミュニケーションが難しく、多くのやり取りが非同期コミュニケーションに依存します。例えば、Slackのようなツールを使っても、実際にはリアルタイムで会話ができることは稀で、メッセージを送ってから返信を待つ形が一般的です。このため、非同期コミュニケーションを意識して効率的に情報を交換することが求められます。

ただし、これは同期コミュニケーションが不要というわけではありません。実際には、チームの認識を合わせたり、不明瞭な点を明確にしたりするために定期的な同期コミュニケーションは不可欠です。

特に重要なポイントで認識を合わせ、その後の作業を非同期で進める計画を立てることで、各自がより自律的に、そして効率的に作業を進めることができます。したがって、リモートワークでは同期と非同期コミュニケーションを適切に使い分けることが重要です。

GitLab式オンボーディング

同期と非同期コミュニケーションを効果的に使い分ける良い例をご紹介します。

GitLabでは、新入メンバーのオンボーディング（職場への適応プロセス）が上手に組織化されています。例えば、1日目に達成すべきタスク、2日目に取り組むべきタスクなど、最初の1週間の計画が明確に文書化されています。これにより、新入メンバーは自分のペースで仕事を進めることができ、必要なタスクを完了させた後は、他の活動に取り組む自由があります。最初に同期的なコミュニケーションを通じて、新入メンバーに何をいつまでに達成すべきかを明確に伝え、その後は非同期で彼らが自分のタイムラインと方法でタスクを進めることを可能にします。これにより、個人の自律性が促進され、柔軟で効率的な働き方が実現されます。

ちょっとした感謝を共有 #thanks チャンネル

GitLab は、素晴らしいオンラインコミュニケーションのために、いくつかのSlackチャンネルを用意しています。その中でも、GitLab チームメンバーが素晴らしい仕事をしたり、顧客を助けたり、あなたを助けてくれた時などに、感謝の気持ちを伝えることができる「#thanks チャンネル」は、良い雰囲気づくりのために非常に有効活用されています。

佐々木：GitLabには、自分がここにいてもいいんだ、と感じさせる帰属意識を高める仕組みがあります。例えば「#thanksチャンネル」がそうですね。自分が感謝されると嬉しいものですし、それが自分も他の人に感謝を伝えたくなる気持ちにつながります。このような文化が、GitLabでは醸成されています。

伊藤：確かに、「#thanksチャンネル」は常にアクティブ。誰かが自分に感謝を示してくれたら、次は別の誰かにその感謝を伝えたくなる、そんな前向きな連鎖が生まれていますね。

Coffee Chatでカジュアルなコミュニケーションを

非同期コミュニケーションのみでは、相手の性格や考え方など  “人となり” を深く理解することが難しい問題があります。GitLabは、このような問題に対応するため「Coffee Chat」という制度を取り入れています。この制度は、特別な議題を設けず誰でも気軽に他の人に声をかけることができます。このような日常的なやり取りの中から新たな仕事のアイデアが生まれたり、チーム内の人間関係が深まることがあります。Coffee Chatは、非同期コミュニケーションが主流のリモートワーク環境においても、人と人とのつながりを大切にし、創造性や協力関係を促進するための有効な手段として活用されています。

千田：Coffee Chat は強制ですか？

佐々木：いえいえ、参加したい人だけでOKです。ただ、入社時のオンボーディングでは、5名以上との Coffee Chat がタスクに組み込まれています。

千田：相手はどう選ぶのでしょう？

伊藤：ランダムに相手を見付けて予定を入れてくれる Donut というSlackアプリを使っているメンバーも多いです。もちろん、自分で相手を選ぶこともできます。

千田：全然知らない人とマッチングしちゃったら？

伊藤：そういうこともあります（笑）私の場合は、事前にLinkedInやSlackのプロフィール見たりしますね。だいたい海外の人とマッチングすることが多いので、GoogleMapsを出しながら、お互いの家の付近を見ながらすると盛り上がります。

佐々木：私も自分のインスタアカウントを見せながら話したりします。やっぱり、お互いの国の文化についての話が盛り上がりますよ。例えば、餅つきの写真を見せて「この木のハンマーとバケツは、どの家庭にもあるのか？」と質問されたり（笑）

ミーティングは必要なのか？

ミーティングは参加者の時間を要するコミュニケーション手段です。そのため、できる限り開催を避け、必要な場合には明確なアジェンダを設定することが望ましいです。ミーティングの開催を検討する際には、その目的と効果を再評価し、効率的な代替手段がないかを考えることを推奨します。 The GitLab Handbook では、ミーティングの断り方 や、3回以上、非同期の手段でやり取りをしたらミーティングを検討することが明記されています。

▲会議の参加者は協力してドキュメントを残す文化

No agenda, no attenda

また効率的なミーティングのために、No agenda, no attendaというルールも存在します。

佐々木：「アジェンダがなければ参加しない」というルールは大切ですが、時にはそのアプローチを変えることも必要かもしれません。ひとつ例をあげると、以前日本チームのメンバー向けにカジュアルに技術的なことや製品について質問できるミーティングを設定しました。「事前に聞きたいことをアジェンダに入れてもらえたらミーティングを開催して回答します。もしなければスキップします。」という方針でした。しかし、これはスムーズに機能しなかったんです。アジェンダに質問はあまり書かれず、結果として誰もミーティングに参加しなくなってしまいました。でも技術的な不明点がないかというと実際にはあるんですね。そのような状況になった理由としては「知らないことは質問できない」「知らないと表明して質問することに少しハードルがある」という点もあったのかもしれません。事前に全員が自分の中の不明点や質問を整理できるわけではなく、雑談の中で新たな疑問や情報が出てくることもあるのです。そこで、「アジェンダがなくてもミーティングは開催します。本当に質問がなければ、ただ集まって食事をするだけにしましょう。でも、その場で質問をしてもらっても大丈夫ですし、もちろん事前に質問がある場合は書いておいていただいても大丈夫です。」という方針に変更しました。これによって、今は以前よりメンバーも集まって質問も多く出るようになりました。時には「No agenda, no attenda」というルールを適用しないほうが良いという気づきが得られました。

GitLabで、実際に効果を実感していること

佐々木：GitLabでは、業務関連の申請などもイシューで管理しているんです。他の人の申請見て「お、これいいな」とか思ったり、自分の申請内容なども共有して「これどう？」って。例えば「オンライン英会話受講料の経費清算の申請って、どうやった？」と聞かれたときに、「あぁ、自分の申請はこれだから、参考にしてみて」といったようにURLでサッと渡せるのですよね。透明性が高いことにより、イチから申請内容を教える手間が省けるので非常に効果的かなと思います。

千田：気に入っているバリューはありますか？

伊藤：The GitLab Handbook で、アンコンシャスバイアス（無意識の偏見）が明確に定義されていること。特にグローバルな会社で働いていると「あの人は、日本人と違うから考え方が違う」という勝手なバイアスがかかることがある。そのバイアスをどう防ぐかは別の議論として、まずアンコンシャスバイアスが定義された前提で、2,000人が働けること。これは非常に意義のあることだと考えています。

私たち人間は、無意識に多様性を受け入れることができません。私たちの脳には、アンコンシャスバイアス（無意識の偏見）が存在するためです。人間は自然に自分と同じようなものに惹かれ、異なるものに対して抵抗感を持つ傾向があります。このようなバイアスは、多様性の受け入れを妨げ、時に非効率や誤解を生む原因となります。

https://pr.forkwell.com/tech_event_reports/gitlab-remote-organization-guide/

佐々木：Assume Positive Intent（前向きな意図を前提とする）価値観ですね。「根本的帰属の誤り」といって、人間って自分の失敗はその原因や背景が手に取るように分かるけど、他人の失敗は理解しにくい。相手がどんな状況でなぜ失敗したかなんて基本的にはわかりにくいんですよね。同じオフィスにいれば「あの人、今週は大変そうだったからかな」と、事情を察することもできるけど、リモートワークだとよりわからなくなりがちです。だから、誰かが失敗したり、できないことがあっても、悪気があるわけじゃないよねという前提に立つこと。これって、リモートワークにおいては必須だと思っています。

まとめ：GitLabは、これらを完璧にできているのか？

ここまで紹介してきた理想的な実践がGitLabにおいても完璧に適用されているかというと、必ずしもそうではありません。全員がITのバックグラウンドを持っているわけではなく、新しく参加したメンバーが戸惑うこともあります。そのような場面では、実践的なアドバイスやサポートを通じて、一緒に問題解決を図ることを心がけています。

• 「Googleカレンダーで他の人の予定を編集する方法、今からやりますね！」
• 「私が画面映すので、今一緒にやっちゃいましょう！」

できない状況に遭遇したときの心構え

「ポジティブインテント（前向きな意図）」を前提とし、誰かが何かできない時はそれを教え、サポートする文化を大切にしています。これは、誰もが失敗から学び、成長できる環境を作るためです。このアプローチをぜひ実践に活かしていただきたいと思います。

「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」

モデレーター千田さんによる「GitLabに学ぶシリーズ第1弾の記事はこちらをご覧ください。

●キャリアとスキルアップ

GitLabに学ぶ！第1弾「世界最先端のリモート組織のつくりかた」千田 和央

2024.01.19

約4分