スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ
ドキュメント文化は健全な組織のスケールのために必要
組織の中でドキュメント/文章を残し活用していくことはとても重要だ。クオリティの高いドキュメントがあることで、組織に情報が流通し、透明性を確保できるようになる。情報を流通させるためにいちいち口頭の説明がいらないから、メンバーの数が増えた時でもスケールしやすくなる。過去の結論にアクセス可能になるので、議論を積み上げていき、意思決定のクオリティを高めることにもつながる。そもそも何かを読むということは何かを聞いて教わるよりも時間あたりの処理量が多いし、非同期に実施できる。良いドキュメントをアセットとして社内に蓄積していくことはスタートアップのみならず、ありとあらゆる組織が成長していく上でとても重要であると言える。
しかしその一方で、良質なドキュメント文化を徹底できている会社は多くないように見える。例えば、社内のドキュメントを蓄積させていく場所として、社内Wikiを導入するという例はよく聞く。しかし、実態としてそのWikiは少数のメンテナの気力によってのみ駆動されているため、次第に情報が古くなってゆき、形骸化してしまうことが多い。
その逆もある。形式上情報が蓄積されていっていたとしても、整理され、管理され、日々の意思決定において活用されていっている会社は多くはない。正しく活用されないドキュメンテーションワークはただの形式的なものに成り下がり、官僚的お役所仕事、仕事のための仕事と揶揄されていくようになる。
そんな中、異常なまでにドキュメント文化が徹底されている企業を発見してしまったので、是非紹介したいと思う。その会社とはGitLab社というスタートアップである。GitLabはGitHubのようなGitリポジトリのホスティングサービスである。
GitLab社の特徴は、1) 1000人を超える社員が全世界に点在しており、フルリモートで稼働していること、2) カルト的なまでにオープンネスを重視していることが挙げられる。
例えば、障害対応もフルリモートでオープンである。2017年にGitLabのデータベースがぶち壊れるという大規模障害があったのだが、この時も色んなエンジニアがフルリモートで対応していた。そして、その様子はなんとYoutube Liveでストリーミング中継（やばすぎる！）されていた。
GitLab社ではリモートワークの中でも生産性高く働けるように、ドキュメント文化が高度に発達している。GitLab社が作っている製品は、開発のコラボレーションツールでもあるので、これはドッグフーディングという側面もある。
とにかくGitLab Handbookというドキュメントがヤバすぎるので見て欲しい
この会社は、”GitLab Handbook”という形で、会社の運用に必要なドキュメント群を一つのGitリポジトリの中で管理している。まずは私が色々言う前に、この膨大なドキュメントを少し眺めてみて欲しい。
ちょっと回遊していれば、このドキュメント群の想像以上のデカさと、そこに詰まった知恵の数々と、偏執的なまでに記述されたプロセスの細かさと、それらのドキュメント文化を支えるカルト的思想性を感じることができるのではないだろうか。
更新頻度もすさまじい、更新履歴から見ることができるが、毎日大量のコミットが反映されているということがわかる。合わせた文書全体のサイズはというと、167万wordsにも及ぶサイズになっており、Page数にすると3705ページほどになるようだ。
このドキュメントはほんとに学びの宝庫なので、スタートアップ経営をしている人などは強くいろんなページをみることをおすすめする。成功しているスタートアップ企業のベストプラクティスがここまで詳細にオープンにされている例はほとんどないと思う。しかし、どこから見ていいのかようわからん！という人もいると思うので、ここで3箇所ほど見所を紹介したいと思う。
Communication: 社内コミュニケーションに対する指針と実践方法
物理的なオフィスを持たない分散型の組織において、課題となるのがコミュニケーションだ。このページでは社内のコミュニケーションのあり方を、コンセプトのレベルから具体のプラクティスのレベルまで網羅的に記載している。
下記は個人的な学びポイント。
・Slackには90日間のアクティビティしか保持されないようにしているらしい。決定の文書化や公式記録、承認を得る等の行動には使用しないようにする/させないという大胆な整理（GitLabでは進行中の作業はGitLab上で行われており、Slackに作業が行われている場所はないという整理のよう）
・プライベートメッセージを使わないように奨励しており、プライベートメッセージを使ったら、DMでこの文章をコピペしろと明示 -> 「連絡ありがとう！チームの人ももしかしたらこの質問やアイデアが役にたつかもしれないから、パブリックチャネルに行くね」
・そして移動先のパブリックチャネルでこの文章を言えと明示「@Person がDMで質問してきたから、みんなの意見が反映できるようにここに書くね」
・それでもプライベートメッセージがたくさん来る場合にはSlackステータスを目立つ絵文字にして「なぜパブリックチャネルじゃなくてDMするの？」という設定にしろ
・「こんにちは」とだけ書いて送るな。直接の質問だけをしろ。
・Slack パブリックチャネルのスターターリストが整理されている
・自分の子供たち写真をうpするチャネルがある
・どこのチャネルで質問していいかわからないものは#questionsチャネルがある
・#thanksチャネルでチームメイトに感謝をオープンに実施する
・Slackが落ちている時は予備の「Slack Down!」というZoomのグループチャットが用意されている
・SlackとZoomが落ちた時にはハングアウトチャットの部屋が用意されている
・GitLabの7つのValueとスタンプを対応させている
・ビデオチャット会議は時間通りに開始し人を待つな、そして時間が来たらぶつ切りにしてよい
・ビデオチャットの時にはビデオを常にONにさせる
・ビデオチャット中に、積極的に子供やペットが画面に映り込むようにしろ（これは想像の逆でおもしろい、やはりリモートだと積極的な雑談のきっかけを作っていかねばならないということなのだろうか）
・ビデオチャットの時は、Shush（ホットキーでマイクをミュートできるツール）を使うことを検討しろ。（ON/OFFをめっちゃ切り替えるということなのだろうか）
・バックグラウンドノイズがある場合には、参加者全員にマイクミュートを促せ
・「みんな聞こえる？」と言うな、本題からはじめろ（聞こえていなかった場合のみ、参加者が声をあげるため、その確認をする必要はない）
Global Compensation: 給与決定のオープンな考え方
評価と給与というのはどんな組織においても重要なイシューであるが、GitLabはこのセンシティブなイシューに対しても高いオープンネスを維持している。上記のページからその考え方と具体的なプラクティスについて知ることが可能だ。
以下、個人的な学びポイントを箇条書き
・報酬の計算式は極めて単純明快で、Your compensation = SF benchmark x Location Factor x Level Factor x Compa Ratio x Contract Factor x Exchange Rate
・SF benchmarkの水準はサンフランシスコの給与水準であり、各種調査データに基づいて決定されている
・SF Benchmarkの値はこのymlファイルで管理される
・SF Benchmarkは毎年変更される
・Benchmarkは業界の上位50パーセンタイルに位置することができるように調整される
・20％以上の人が給与水準を理由にオファーを受諾しない場合はBenchmarkを補正する
・Location係数はサンフランシスコとの報酬水準比較で決定される。3つのデータポイントの平均で出す（なんか出し方についても色々解説してある）
・ちなみにJapanのLocation FactorはSF100に対して56.3らしい（Tokyoはもっと高いだろという気もするが）
・こういうの見ていると人事の仕事っていうのはマジもんの経済データ調査と統計調査だなあという感想になる
・つまり引越しをすると給与は変わる
・地域ごとに給与水準が違う理由として、同じ給与水準だと低賃金地域にメンバーが集中してしまう問題が発生するため。同じ賃金水準にすると多くの雇用を産めなくなるため。
・ここは色んな議論があったようで、Blog Postにおいて詳細に理由を説明している（Why GitLab pays local rates）
・Level係数はmemberが3段階、managerが2段階、directorが2段階の7段階
・この職位階級もroleごとに微妙に違うのだがgit repository以下のymlで管理されている
・Compa係数は直属のマネージャーが持つレバーで、評価に基づいて-15%から+15%までの30％のレンジを調整できる
・Contract Factorは従業員と業務委託の違いによるものであり、業務委託の場合は1.17倍される。これは社会保険等に自分で入らなければいけないから。そして国によっては法規制上、業務委託じゃなければ採用できないことになるため
・年次報酬レビュープロセスには市場環境レビューが含まれる。何も変わらなくてもマクロ要因によって給与が補正されるのはおもろいなと思う
・前職給与水準等に、引きずられすぎずに、労働市場をちゃんとwatchして、その中で競争力を上位xxパーセンタイル水準としておいておくようなモデルは個人的にはすごく納得感がある。経済的に過大評価も過小評価もしにくくなる。
Onboarding Process：型化された新入社員のオンボーディングプロセス
GitLabではメンバーのオンボーディングプロセスも非常に精緻化されている。例えば、最初の1ヶ月にやることが長大なリストになって記載されている。
下記は個人的な学びポイント。
・初週に5人の同僚と5回の30min callをセットし、GitLabのチームや文化について話を色々させる
・オンボーディングチームとしてマネージャーとバディ、ピープルエクスペリエンスチームが関わるようになっている
・新入社員と同じタイムゾーンにいて、少なくともGitLabに3ヶ月滞在している人を指定するようになっている
・遠隔地でもセキュリティを保つため、MacのHDD暗号化のFileVaultが有効化されたことをスクショで共有させる
・1Passwordを利用している
・Oktaを利用してSSOしている
・LinkedInを更新してポジション名をちゃんと入れさせる
・#donut-be-strangersチャネルに参加するとweeklyで1回、ランダムなコーヒーブレイクコールがセットされるようになる
・GitLabのLinkedIn、Twitter、Facebook、YouTubeをフォローしろと言う
・最初の30日が経過したタイミングでOnboardingのNPSアンケートに記入させる
・30日が経過したタイミングでGlassdoorまたはComparablyにレビューを残させる（日本でいう転職会議みたいな会社の従業員側のレビューサイト）、転職関連サイトなどにデータを付け加えることが奨励されているというのは考えてみれば合理的だなと思った
・製品についてGitLab Quizが存在し、マネージャーが正しく製品を理解していっているかをテストする
・アイコンとかに利用するアバターはGravatarを使って作らせる
・SlackとかGCalとかZoomのアカウントのProfile設定をめっちゃしっかりやらせている
・外部リソース、内部リソースを含め、様々な記事がのせられており、「これを読め」とまとまっている
---
以上、三箇所ほどお伝えした。これらの他にも様々なページがあるので是非みなさんものぞいて見て欲しい。おすすめは自分の職種や、今取り組んでいたり議論していたりすることが、GitLab社のプラクティスだとどう処理されているんだろう？というところからたどることである。割と色々ヒントにぶつかる。
日本のスタートアップでも取り込めるポイントはどこか
果たして私たちが真似できるポイント、取り込めるプラクティスはなんだろうか？GitLabはグローバルかつそこそこの大規模組織（1186人のチームメンバー）かつ、拠点分散型の企業なので、日本のスタートアップがそのまま真似すると逆にうまくいかない点も多々あると思う。しかし、それでも学べるポイントは非常に多いように感じる。
上記のページに、ハンドブック運用のポイントがいくつかまとまっていたので、真似できそうな部分を3点ほど挙げてみたいと思う。
1. WikiではダメでGitリポジトリじゃないとスケールできないと理解する
会社のハンドブックはWikiとして始まることが多く、これは作業のとっつきやすさという意味では優秀だが、時間の経過とともに古くなる傾向がある。
Wikiでは、ページの複数の部分や複数のページにまたがるような提案をすることができない。また、作業者とレビュワーの役割を分けることができない。また、提案を取り込むべきか取りこまないべきかの議論もできない。そのため、ハンドブックはリファクタリング不能な状態に陥る。
Gitリポジトリという分散バージョン管理システムを利用することで、この問題は解決できる。提案はメンバーの誰でもできるようになり、承認は該当部分を管理するマネージャーが意思決定できるようになる。Pull Requestの中でオープンなディスカッションもできる。
また、MTGの中でみんなが見ながら内容を編集したい場合などはGoogle Docsを用いているようで、MTGが終わったら内容をMerge Request (GitHubでいうPull Request）にまとめて出すという形で実施しているようである。
2. ハンドブックファースト思想を貫く
GitLabではハンドブックファースト思想を貫いている。ハンドブックは常に最新であり、中に重複がないように書かれている。いわゆるSingle Source of Truth性があるように保たれている。そのため、Wikiでしばしば見られるような、複数の文書が同じ内容を示しており、それらが違いに矛盾しているような状況は見られなくなる。
さまざまな議論をSlackやメールや、インターナルなプレゼンテーションを行う場合に、該当のハンドブックへの参照URLつけることを常に試みることが奨励されている。わざわざ何かを説明する時にプレゼンテーションスライドを作るのではなく、ハンドブックで代用することが奨励される。
3. 内容にアクセス可能にする
ハンドブックは4000ページ弱あり（2020年現在）、その全てを把握できている人はいない。このテキストの山を活用するためにGitLabでは検索機能をつけることを推奨している。GitLabでは第一にAlgoliaというSearchのクラウドサービスを利用している。第二に、PublicにHandbookを公開することで、Google検索にHitするようにしている（これは真似できないかも）。
---
以上、簡単にGitLab Handbookについて解説した。私のいるリーガルテック・スタートアップのMNTSQ（モンテスキュー）でもGitLab社のベストプラクティスの取り込むべき部分を取り込んでいくことで、透明性が高くスケールできる組織を作っていこうとしている。弊社でも社内ドキュメントはGitリポジトリ上で管理されており、エンジニアチームのみならず、パラリーガルチームも含めてみんなGitHubに触れて社内ドキュメントに対してPRするようなプロセスになっていたりする。我々の会社の取り組んでいる領域はリーガル領域であり、ある種の「文書群」を取り扱う業界でもある。このドメインとハンドブック・ファーストな考え方には親和性が高い部分も多くあると考えている。
リーガルテックカンパニーのMNTSQでは現在採用をしているので、このようなスケールするドキュメントカルチャーを作ろうとしているスタートアップに興味がある方がいたら、是非お気軽にご連絡ください！
この記事が気に入ったらサポートをしてみませんか？