「GitLab に学ぶ世界最先端のリモート組織のつくりかた」という本（以下、本書と呼ぶ。）を読んだので要約と感想を書く記事です。ヘッダー画像は翔泳社の Web サイト からお借りしました。

https://www.shoeisha.co.jp/book/detail/9784798183916

章ごとの要約

本書は全 13 章で、大きく分けて 4 つの部分に分かれている。

• 第 1 部: リモート組織のメリットを読み解く（第 1 ~ 2 章）
• 第 2 部: 世界最先端のリモート組織へ移行するためのプロセス（第 3 ~ 4 章）
• 第 3 部: GitLab が実践する組織を活性化させるカルチャー醸成法（第 5 ~ 8 章）
• 第 4 部: GitLab が成果を出すために実践している人事制度や業務ルール（第 9 ~ 13 章）

以下、章ごとの要約と本書を読み進める上で自分が付け加えた補足を書く。

第 1 章: 世界最先端のリモート組織「GitLab」

GitLab 社は何をしている会社なのか、世界最先端のリモート組織が実現できている状態とはどのようなものかについて書かれている。

GitLab 社は 投資家向けのプレゼンテーション資料によると 2023 年 7 月末時点で 60 か国以上にわたり 2,000 人以上の従業員がいるがオフィスは一箇所もない。

オフィスを持たない GitLab は「all-remote」企業でありドキュメントやメール等を活用した非同期的なコミュニケーションが中心だが、同期的なコミュニケーションが全くないわけではない。

例えば Coffee chat と呼ばれるメンバー間の雑談を毎週数時間行うことを推奨していたり、年に 1 度世界からメンバーが集まる「Gitlab Contributes」というイベントを開催しているそうだ。

補足

なお Coffee chat がどのようなものかについては GitLab で学んだ最高の働き方 - Developers Summit 2022-02-18 に、同期と非同期の使い分けについては 組織の自律自走を促すコミュニケーション というスライドに記載されている。この 2 つのスライドを作った伊藤氏と佐々木氏は本書の監修をされている。

第 2 章: リモート組織によって得られるメリット

GitLab においてリモート組織にどのようなメリットがあるかについて書かれている。

1. 高い透明性により従業員のエンゲージメントが高まる
2. 国や地域、働き方を問わず優秀な人材を採用、パフォーマンスを最大化できる
3. 成果にこだわる風土が形成される
4. コストが効率化され、本質的な業務に集中することができる

2. についてはリモートで通勤がなくなるので国内外の優秀な人材を雇用できるほか、働く場所や時間が異なることを前提とした非同期なコミュニケーションが中心になるのでさまざまな働き方を実現できる。

3. については筆者による解説が非常に納得感があったので紹介したい。本書 49 ページより引用。

リモート環境ではオフィスにいる必要がないため、必死に働いているふりをしても頑張っているから評価してくれる人は存在しません。そのため、周りにいるメンバーから評価されるためには何かしらの成果物を残したり、実際にチームにとって良い影響を与えたりと、目に見える成果を出さなくてはなりません。そうした目に見える成果を公正に評価するために、パフォーマンスを計測する必要性が出てきます。パフォーマンスが可視化されることによって、「何も成果を残せなかった」状況を避けるために、従業員は成果にフォーカスした行動を取るようになります。

4. については、オフィス賃料や通勤交通費のような直接的なコストがかからなくなるのに加えて、時間の使い方が効率化されるという面もある。all-remote な会社では役割分担を明確にしなければならず、かつドキュメント化が根づいているので無駄な会議が減る。

このような仕組みはオフィス中心の会社であったとしても業務を効率化する上で参考になる。

補足

GitLab はどのような identity を持つ人が働いているかの統計情報を公開している。

https://about.gitlab.com/company/culture/inclusion/identity-data/

第 3 章: リモート組織を構築するためのプロセス

リモート組織を構築する上で GitLab が推奨しているアクションプランについて書かれている。

以下のリストは本書 60 ページより引用。

1. リモート組織に関する認識を改め明示する
2. リモート責任者を任命する
3. ハンドブックを制定する
4. コミュニケーションガイドラインを明示する
5. ツールの種類を最低限に抑える
6. 経営陣のデフォルトをリモートにする
7. リモート作業環境を整備する
8. インフォーマルコミュニケーションを設計する

1. はリモート組織に対する会社の考えについて全員の共通認識となるように誰もが見える場所に明示することの重要性を説明している。リモートワークをオフィスワークの補完的要素として捉えると（リモートワークに適した）非同期的な業務が整備されずリモートワーカーのパフォーマンスが低下しがちになる。

3. は GitLab Handbook のような「業務において SSOT: Single Source of Truth となる情報が集約される場所」の重要性を説明している。ドキュメント化には時間と労力を要するが、一度つくってしまえばそれ以降の質問-回答にかかる時間を大きく削減することができる。Handbook のテンプレとして GitLab の社員によって作られた Suddenly Remote Handbook が紹介されている。

4. については無自覚に誰かを傷つけてしまったり攻撃的なコミュニケーションが行われないように社内向けのコミュニケーションガイドラインが制定されており、その内容が解説されている。原文は Handbook の Effective & responsible communication guidelines を参照。

6. については経営陣が率先してリモートワークを行うことで全社に対して会社がリモートを推進するメッセージを伝えるとともに、意思決定プロセスをリモートワークに最適化するための課題に気づけるという点が説明されている。

8. については前述の Coffee chat 以外にもさまざまな informal communication が存在し、それらは Handbook の Informal Communication in an all-remote environment で公開されている。

補足

同期と非同期の使い分けについては本書の監修者である伊藤氏と佐々木氏による 組織の自律自走を促すコミュニケーション というスライドに記載されている。

5. で実際に GitLab で使われているツールについては「GitLab で学んだ最高の働き方 - Developers Summit 2022-02-18」の 19 ページ「コミュニケーション手段の使い分け」に記載されている。

7. については、リモート環境整備のために新入社員には $1,500 分だけ使えるバーチャルカードが提供される。備品を買い替えるための費用として入社後 1 年ごとに $500 が提供される（laptop の交換は別）。詳しくは Handbook の以下の箇所を参照。

https://about.gitlab.com/handbook/finance/expenses/#equipment

第 4 章: リモートワークで発生する問題と対策

リモートワークに共通して発生する課題について説明されている。本書で挙げられているのは以下の通り。

• 作業が中断されないので働きすぎてしまう
• テキストベースのコミュニケーションが苦手な人に合わない
• 業務時間中の雑談が発生しづらく孤独感を覚える
• 仕事と生活の境目が曖昧になり疲弊する
• 新入社員や異動したメンバーが新しいチームに馴染めない
• バーンアウトしてしまい、過度に落ち込んだり威圧的なコミュニケーションを取ったりする

GitLab においてその対策としては

• 丁寧なオンボーディングを行う
• （Coffee chat のような）インフォーマルコミュニケーションの施策を提供する
• 外部のプロフェッショナルによるメンタルヘルスケアを福利厚生として従業員およびその家族に提供する
• 積極的な休暇取得を推奨する
• コミュニケーションのガイドラインを制定する

などがとられている。

補足

GitLab のメンタルヘルスケアについては Handbook の Combating burnout, isolation, and anxiety in the remote workplace に詳しく記載されている。

メンタルヘルスケアの福利厚生については Handbook の Modern Health を参照。

第 5 章: カルチャーはバリューによって醸成される

本書の中で個人的に最も好きなのがこの第 5 章。GitLab Values の内容に加えて、どのように運用されているかが説明されている。

まず、良いカルチャーを醸成するためには「カルチャーマッチではなくバリューマッチ（現在のカルチャーに沿った人材を採用するのではなく、それを継続的に改善するためにバリューを体現できる人物を採用する）」が重要という著者の分析が紹介されている。

次に、GitLab における 6 つの Core Values（Collaboration, Results, Efficiency, Iteration, Diversity & Inclusion, Transparency）とそのヒエラルキー（Value 同士が衝突した際にどちらを優先すべきか）や、他にも多くのページを使って著者の経験や学術的な解説を交えて Values 自体や Values を浸透させる仕組みの説明がされている。これについては本書を買って読んでほしい。

上図は Handbook の Hierarcnhy から引用した。

補足

GitLab の 6 つの Core Values の頭文字を取ると…

Collaboration, Results, Efficiency, Diversity & Inclusion, Transparency

で CREDIT となる。こういう覚えやすくする工夫は Values を浸透させる上で非常に重要だと思う。特に Values の数が多い場合…

GitLab が Values を浸透させるにあたりどのような取り組みをしているかについては Handbook の How do we reinforce our values に記載されている。これ一つ一つは本当にちょっとしたことなのだが、繰り返す内に自然と業務で日常的に Value が口から出るようになり行動に繋がっていく。例えば自分が過去に働いていた会社では採用や評価に限らず、会議室の名前を Values から取ったり Values を刻んだグッズを作ったりさまざまな取り組みが行われていた。

第 6 章: コミュニケーションのルール

GitLab が採用しているコミュニケーションに関するルールについて説明している。

例えば SAFE フレームワークについて。GitLab では Transparency という Value があるように基本的にあらゆる情報が公開されているが、公開してはいけない情報もある。情報を非公開にするルールが明確に定義されていることで、それ以外を安心して公開することができるようになる。

SAFE は Sensitive, Accurate, Financial, Effect の頭文字をとったもの。

• Sensitive: 個人のパフォーマンス、入退社日、顧客または取引先の機密情報、投資家の投資判断にとって重要な情報（株式や社債発行や新製品の情報）、セキュリティに関する情報などは公開できない
• Accurate: 外部からの要求があった時にデータの正確性を検証できない情報や DRI の承認を得ていない情報は公開できない
• Financial: 将来の見通しや過去の実績のうち開示されていないもの、それらの算定根拠となり得るものは CFO の許可がなければ公開できない
• Effect: 公開される情報が会社にどのような影響を与えるか公開前に留意しなければならない

上図は Handbook の GitLab SAFE Framework より引用した。

補足

コミュニケーションのルールは Handbook の GitLab Communication に詳細な記載がある。

なお、一般的なコミュニケーションガイドラインの他に障害対応時のコミュニケーションについて規定した Incident Communications Plan や社外へのコミュニケーションについて規定した s Corporate Communications Handbook がある。

第 7 章: リモート組織におけるオンボーディングの重要性

GitLab で行われるオンボーディングについて説明している。

新入社員は入社前に「TaNewKi（タヌキ） Welcome Call」というミーティングでオンボーディング手順の確認やチームメンバーへの紹介、質疑応答などを行う。

オンボーディングでやることは以下の通り。

• 1 日目: アカウント発行や作業環境の構築
• 2 日目: リモートワークのベースと GitLab Values の確認
• 3 日目: セキュリティ設定とコンプライアンスの確認
• 4 日目: コミュニティと福祉構成の確認
• 5 日目: Git の使い方
• 2 週目~: 職種ごとの追加オンボーディング

補足

新入社員がやるタスクは onboarding issue にまとめられている。これは People Connect（オンボーディングに責任を持つ）チームの担当者によって作成される。issue は新入社員自身に dogfooding の一環としてアサインされ、入社後 2 週間以上をかけて完了させる。

上記は全員向けのオンボーディングで、職種によって追加の手順がある。例えば開発者向けには開発フローを記した追加のオンボーディングドキュメントがある。

https://about.gitlab.com/handbook/developer-onboarding/

第 8 章: 心理的安全性の醸成

GitLab Values を題材に心理的安全性について説明されている。

https://blog.jostle.me/blog/psychological-safety-at-work

第 9 章: 個人のパフォーマンスを引き出す

GitLab が個人のパフォーマンスについてどのような思想を持っているかについて説明されている。

個人のパフォーマンスの評価は「成果」と「行動」の 2 つの軸で考えられている。成果については定量的に計測可能だが、行動に関しては各 Core Values や職種、現在のグレード等さまざまな区分に応じたコンピテンシーが制定されており、それを根拠にパフォーマンスを評価する。

また、個人のパフォーマンスを引き出すための目標設定として GitLab の OKR とノーススター KPI（全社員が注目すべき唯一の目標）について説明されている。なお、GitLab 社が重視する KPI は KPI のページに記載されている。

他には意思決定の 2 つのフェーズについて。GitLab では意思決定を「データ収集プロセス」と「意思決定フェーズ」の二つに分離し、意思決定のプロセスを遂行する責任および結果に対する責任は DRI が負う。DRI は意思決定の内容が周囲にどう受け止められるかの責任はない。

DRI のような仕組みを用意する理由は GitLab が完全なコンセンサス（全員が納得するような決定をする）もしくはヒエラルキー（組織の上位者が決定する）アプローチはうまくいかないと考えているため（なぜなら、完全なコンセンサスを優先するとスピードが犠牲になり完全なヒエラルキーを優先すると貴重な意見を失うから）。

https://about.gitlab.com/handbook/leadership/making-decisions/

第 10 章: GitLab Value に基づいた人事制度

GitLab が運用する等級制度、評価制度、報酬制度について解説されている。

等級は職種（セールス、カスタマーサクセス、それ以外）ごとに定められており、Management と Individual Contributor の二つのテーブルに分かれている。

https://about.gitlab.com/handbook/total-rewards/compensation/compensation-calculator/#gitlab-job-grades

各等級にどのような能力が要求されどのような責任があるかは Handbook の Organizational Structure で記載されている。

評価制度の中心となる概念は 9 box と呼ばれていて、パフォーマンスと成長力それぞれ 3 段階で 3 x 3 = 9 box の matrix でどこに属するかで四半期ごとに評価を行う。詳しくは Handbook の The Performance/Growth Potential Matrix を参照。

パフォーマンスは過去および現在において目標に貢献する成果を出しており GitLab の Core Values を体現しており将来の成長につながる行動をしているかどうかを評価する。成長力は未来においてパフォーマンスを発揮できるかどうかを Growth Potential Pillar に沿った行動をしているかどうかで評価する。

報酬の計算方法も Handbook の The Compensation Calculator で計算式が公開されている。報酬は以下の 4 つを乗じた金額となる。

1. SF benchmark: サンフランシスコにおけるその職務の相場となる報酬
2. Location Factor: 地域ごとに労働市場のコストをサンフランシスコと比較した割合（例えば東京ではサンフランシスコの半額で同等の職務の労働者を半額で雇用できる場合、Location Factor = 0.5 となる）
3. Level Factor: 職務を遂行するレベルに応じて報酬を加算・減算する割合（例えばジュニアは 0.8 倍、シニアは 1.2 倍）
4. Exchange Rate: 為替レート

補足

評価制度については Handbook の Talent Assessment のページに詳しく記載されている。

なお、GitLab で報酬の計算に使われる為替レートは 12 月 1 日 と 6 月 1 日 の年 2 回で固定される。例えば 2023 年 9 月 17 日時点の日本円は 1 ドルあたり 147 ~ 148 円だが、GitLab のレートでは 6 月 1 日時点のレートが使われるので 138 円となっている。

https://about.gitlab.com/handbook/total-rewards/compensation/#exchange-rates

場合によっては現地通貨ではなくユーロやドルで受け取ることも可能なようだ。

昇進や異動については Promotions and Transfers が参考になりそう。

第 11 章: マネージャーの役割とマネジメントを支援するための仕組み

チームのパフォーマンスを向上させるためにマネージャーがどのように行動すべきかを説明している。

まずは目標設定について。GitLab ではチームの目標はマネージャーによって設定される。目標は Specific（具体的）, Measurable（計測可能）, Achievable（達成可能）, Related（経営目標との連結）, Time-bound（時間制約がある） を満たす “SMART” であることが求められる。

フィードバックに関しては Crucial Conversations というやり方が重視されている。

パフォーマンスが出ない人への対応については、そのパフォーマンス低下の原因がどのようなものかを分析した上でどうしたらパフォーマンスを改善できるかを計画（PIP: Performance Improvement Plan）する。

https://about.gitlab.com/handbook/leadership/underperformance/

マネージャーのコンピテンシーとしては以下の 5 つが挙げられている。

• Emotional intelligence: 感情をコントロールする
• Conflict resolution: メンバー間の意見の衝突を建設的に解決できる環境を作る
• Modeling culture of feedback: メンバーへリアルタイムにフィードバックを提供し、メンバー間のフィードバックを促す
• Building high performing teams: 効率的な意思決定や実行を通じてチーム全体に結果責任を負わせる（行動と結果の関連性をわかりやすいようにするという意味？）
• Coaching: チームメンバーが内面と向き合い強みを自覚しより成長できるよう助ける

上図は Competencies の Manager and Leadership Competencies より引用。本書には著者による日本語への翻訳が載っています。

補足

GitLab がパフォーマンスの高いチームを作るために行っていることについて詳しくは Handbook の Building High Performing Teams を参照。

新入社員と同じように、新しくマネージャーとなった場合も onboarding issue が作られる。三ヶ月かけてマネージャーに必要なドキュメントを読んだりメンバーと話したりするようだ。

第 12 章: コンディショニングを実現する

有給休暇を取る。適度な運動をする。

https://about.gitlab.com/handbook/paid-time-off/

有給休暇を取らないことは GitLab では「自分の役割に対する謙虚さに欠ける」とされている。上記のページより引用。

Not taking time off is viewed as a weakness and people shouldn’t boast about it. It is viewed as a lack of humility about your role, not fostering collaboration in training others in your job, and not being able to document and explain your work. You are doing the company a disservice by being a single point of failure. The company must be able to go for long periods without you. We don’t want to lose you permanently by you burning yourself out by not taking regular time off.

第 13 章: L&D を活用してパフォーマンスとエンゲージメントを向上させる

L&D（Learning & Development）つまり能力開発について説明されている。

GitLab では一人一人が自分の将来の目標やキャリアを IGP: Individual Growth Plan として作成し、自分の計画に基づいてコミットした行動を実行していく。

IGP の実行にあたっては 360 度評価による周囲のサポートや、学習にかかる費用や資格取得費など（Udemy や Coursera のようなオンライン講座や大学・大学院の学費、ビジネスコーチの費用など）のサポートがある。

なお、360 度評価は主として能力開発によって使われるもので、パフォーマンスの評価には重要視されなさそう（参考: 360 Feedback - Guidance for Managers）。

本書を読んだ感想

著者は GitLab の従業員ではないが、GitLab 社の従業員による監修が行われているので内容の正確性については問題なさそう。私自身も GitLab Handbook を読むことはあるのだが、とにかく量が膨大（2,700 以上のページがあり、監修者の言によると GitLab 社員ですら全て把握するのは難しい）なのでこのような本で全体像を提供してくれるのはありがたい。

本書の特徴として、著者が長く人事の仕事をしてきた経験や学術的な背景などを交えながら GitLab の先進的な取り組みを紹介してくれるという点がある。GitLab が all-remote な会社であることもあってリモートワークを中心に取り上げているが、オフィスワーク中心であっても非同期的に仕事をすることは多いので参考になる部分はあろうかと思う。個人的には

気になった点として、GitLab Handbook を引用する箇所で引用のリンクがない箇所がある。例えば、第 3 章で『GitLab が公開している「より良いリモート組織のための 12 ステップ」というチェックリストも紹介します。』という文があり、続けて The GitLab Test - 12 Steps to Better Remote を日本語に要約したリストが並んでいるのだが、引用元が提示されていない。

自分で調べればどこから引用しているかは分かるのだが、より詳しく知りたいと思ったときリンク先が明示されている方が辿りやすいので引用元を書いて欲しい。本書を監修した伊藤氏と佐々木氏のスライド GitLab で学んだ最高の働き方 - Developers Summit 2022-02-18 および 組織の自律自走を促すコミュニケーション については Handbook からの引用は全て引用元がリンク等で明示されている。

しかしながら、これが本書の価値を損ねるとは思わない。何か意図があるかもしれない（例えば、GitLab の Handbook には handbook.gitlab.com から about.gitlab.com に移行中のものがあり URL は変わるかもしれない）し、あくまで個人的意見です。

リモートワーク中心の会社は買って読んで損はない（たった 1,800 円+税！！）し、オフィスワーク中心の会社はこれを買ってリモートワークの良い箇所だけを取り入れるのがいいと思う。

おまけ: GitLab の売上

Investor Presentation - Second Quarter Fiscal Year 2024 によると Run-Rate Revenue は $558M で、YoY +38% 成長している。

GitLab の上場時に Form S-1 を読んだのだが、2021 年 7 月末時点での Run-Rate Revenue は $233M なので、2 年で 2 倍以上になっている。

• GitLab が上場するので Form S-1 を読んだ話