Tech Racho エンジニアの「?」を「!」に。
  • ライフ

「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」を読んでメンバーとしてできることを考えてみた

cellotakです。

昨年秋に発売され、しばらく話題となっていた「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」という本を今更ながら読んでみました。

どちらかというと組織を作る側・マネジメントする側の立場で書かれた本ですが、メンバーとしてもかなり参考にできそうな内容が多かったため、部分的に要約しつつメンバーとしてこれは意識できそうだなと思ったポイントを織り交ぜてご紹介したいと思います。

どんな本か

創業当時からフルリモートであり、今や世界67か国、2000名以上が非同期で働いている世界最大規模のリモートワーク企業である「GitLab」ですが、リモート組織を運営するノウハウが「GitLabHandbook」として公開されており、非常に有用だということでコロナ禍で各企業がリモートを余儀なくされた時期に話題となっていました。


The GitLab Handbookより

しかし公開されているハンドブックは3000ページ以上と膨大で、全て英語なので自分で読んでいくのは中々ハードルが高い、ということで著者がこのハンドブックを読み込んだ上で簡潔にまとめ、実際に所属組織に実装した経験なども踏まえてノウハウを紹介してくれている本になります。

本書中ではこのノウハウはリモート企業ではなくても活かせる点がたくさんあるとも述べられていましたが、GitLabでは「2000人以上の社員」が「フルリモート」かつ「非同期」が働いているということもあり、それらの要素を持っている企業の方がより直接的に参考にできるノウハウが多い印象でした。

ちなみに弊社は「フルリモート主体組織でのオフラインコミュニケーションの実情」でも紹介されているとおり、現在基本フルリモートであり、かつ最近は私が所属しているチームで週5フルタイムとは限らないメンバーも出てきているので (フルフレックスではない)、このフルリモートかつ非同期のGitLabのノウハウはかなり直接的に役立ちそうです。

内容紹介

先ほど述べた通りどちらかというと組織を作る側・マネジメントする側の立場で書かれた本ですが、メンバー側でも意識するとよさそうな内容を紹介します。

ハンドブック (ドキュメント) を制定する

Gitlabではハンドブック自体にハンドブックの制定と運用についての事細かな記載があります。ハンドブックを非常に重要視しているようです。

ハンドブックに関する大まかな原則としては
あらゆる情報をハンドブックに集約しておき Single Source of Truth (信頼できる唯一の情報源)とする
というものであり、

  • 組織に関するすべてが書かれている
  • 他に隠されたルールがない
  • 文言は誰が読んだとしても可能な限り解釈の余地が少なくなるように言語化が徹底されている
  • ここに書かれていないことによって物事が決まったり制限されたりしないと保証される

という点を守る必要があります。

これにより

  • 異なる文化・価値観を有する人が近い解釈に至ることができる
  • 質問と回答のやり取りを減らせる
  • 明確な基準があることでメンバーの心理的安全性を確保できる

というメリットが得られます。

また重要な点として、このハンドブックはすべての従業員が更新を提案できます。これにより、ハンドブックの透明性が確保され、各メンバーが公正なルール作りを担っているという実感を得ることができます。

新入社員のオンボーディングでハンドブックへの提案プロセスを織り込むことで会社に貢献できる経験を用意し、自然になじめるようにするという工夫も紹介されていました。

メンバーとして意識できそうな点

ハンドブックとなるドキュメントの作成・整備への積極的な参加はメンバーとしてもできそうです。もっといえば、むしろメンバー側が作成・整備の主体となっても良い気がします。

マネジメント側で現場の実情や問題をすべて把握しきるというのはどうしても困難なはずなので、マネジメント側でしか管理されない状況だとこういったドキュメントやルールというものは実情から乖離していきがちだと思います。そのため、各メンバーが直面した状況の中で新しいノウハウを得たり、既存のルールやドキュメントに問題を見つけたときは積極的に更新を提案していくのが理想なのではないかと思います。

弊社では「DocBase」という情報共有ツールを用いて、社内ルール・マニュアル等の公式情報の掲載や技術的なナレッジ共有がなされていて、いわゆるGitlabのハンドブックと同じような扱いをしています。
時々、ルール制定時には想定外だった事象が生じたり、時間経過で手順が変わったりするようなものがでてくるので、そういった場合は各々が適宜修正や刷新を提案できるような仕組みになっています。

経営陣のデフォルトをリモートにする

本書では経営者や上級管理職を強制的にリモート化するように勧めています。

理由としては

  • 会社として「本気でリモート組織を目指す覚悟がある」ことを示せる
  • リモート環境でツールやプロセスへの課題に気づくことができる
  • リモートでのコミュニケーションの課題にも気づくことができる
  • 経営陣がオフィスワークをすると、オフィスで顔を合わせるメンバーによるコンセンサスに基づき意思決定がなされ、意思決定に関する透明性が下ってしまう。これにより
    • ハンドブックファーストの土台はないがしろとなる
    • リモートワーカーが非主流派として扱われてしまう
    • リモートにおける課題は改善されず放置される

などがあります。

メンバーとして意識できそうな点

こちらに関しては正直メンバー側ではどうしようもなさそうな気はしますが、「オフィスで顔を合わせるメンバーによるコンセンサスに基づき意思決定がなされ、意思決定の透明性が下がる」とか「リモートにおける課題は改善されず放置される」という部分はかなり陥りやすい状況だと感じていて、リモート組織が失敗するパターンのあるあるな気がするので取り上げました (業界は違いますが前職がそんな感じでした🥲 )。

もし自分の組織がこのような状況であるならば、マネジメント職だろうとメンバーだろうと声をあげて改善を求めた方がいいのではないかと個人的には思います。ただ声を上げたところで経営陣がそもそもリモートに消極的だと結局出社化に舵が切られそうですが、、

ハイブリッドリモートワークでの注意点

「経営陣のデフォルトをリモートにする」と内容が少し被りますが、出社とリモートを併用する「ハイブリッドリモートワーク」での注意点も述べられていました。
ハイブリッドリモートワークだと以下のような問題点が発生しがちです。

  • 情報へのアクセス格差が生じる
  • オフィスワーカーが主流派となってしまうとリモートワーカーが劣等感や罪悪感を抱いてしまう
  • オフィスを中心としたカルチャーが形成されやすい

これを解決するにはハイブリッドリモートワークであってもリモートワークベースにすることが重要とのこと。
具体的な対策は以下です。

  • 意思決定の場をリモートにする
  • 打合せは必ず議事録を残し、議事録の外で物事が決定しないように徹底する
  • 業務に関するやり取り(チャット)は原則DMを使うのではなくオープンなチャンネルで行う

先ほどの内容とも通じる部分がありそうですが、とりあえずリモートを導入したものの出社回帰せざるを得なくなった企業は、こういった対策が徹底されていなかったことが原因であることも多そうです。

メンバーとして意識できそうな点

経営レベルのことでなくても、日々の業務の中での自身の細かい意思決定も開示していくことは意識できそうです。開示することによって、明らかにおかしな方向に進んでいるときにツッコんでもらい軌道修正できるかもしれませんし、後々問題が生じたときにもオープンにしている記録があることである意味自分の身を守ることもできるかもしれません。

もう一つ意識できそうなのは、自分の関連するプロジェクトや議題に対して公開されている意思決定のプロセスをしっかり追っておくことです。せっかく公開してくれていても誰もまともに見てないことが常態化すると、公開することが形骸化してモチベーションも失われるはずです。最低限話の流れは追いつつ、なにかしらでリアクションすることで見ていますよとアピールするのも良いかと思います。

インフォーマルコミュニケーションを設計する

インフォーマルコミュニケーションとは業務とは関係ない非公式なコミュニケーションのことです。GitLabでは、インフォーマルコミュニケーションには従業員のパフォーマンスを上げること、メンタルヘルスの問題を避けることに対して大きな効果があるとして、意図的にインフォーマルコミュニケーションを設計しています。

例えば

  • 1 on 1 で雑談をするコーヒーチャット
  • Slackチャンネルで音楽活動をしているメンバーがあつまって音楽制作をする
  • 年に1度世界中のメンバーがあつまるイベントを開催
  • 同僚が交流するための旅費を支給

等々。

内容は必ずしも真似する必要ないと思いますが、重要なのはインフォーマルコミュニケーションを偶発的なものとするのではなく、意図的に、能動的に設計するという部分かなと思います。

メンバーとして意識できそうな点

枠組みを設計してもらった前提ですが、その枠組みを積極的に利用することは意識できそうです。もちろん人によっては会社でプライベートなやり取りをするのに抵抗がある方もいるとは思うので、それぞれの価値観は尊重されるべきだとは思います。とはいえチームで働く以上職場内で良好な人間関係を築けることに越したことはないと思いますし、そのためにインフォーマルコミュニケーションは有用なものだと思います。

リモートだと基本テキストでのやり取りになると思いますが、業務上必要なやり取りだけだとどうしても冷たい感じに伝わってしまいがちです。特にレビューコメント等は至極当然な純粋な誤りの指摘であっても、文字だけで伝えられるとまるで人格を責められたような気分になってしまったり、怒っているのかな?と感じてしまうこともあり得ます。そういう場合、普段のインフォーマルコミュニケーションでお互いの性格や背景を知っていれば、余計な不安も減らせそうです。

カルチャーマッチではなくカルチャーアド

従来の採用では社風に合っているかどうかというカルチャーマッチが重視されていました。これは、カルチャーマッチする人材は会社が経験してきた勝利の方程式という暗黙的なやり方を踏襲してくれるためパフォーマンスを発揮しやすいという前提があったためです。
しかしカルチャーマッチによる採用を続けていくとカルチャーが固定化され、変化やチャンスに対応できず経営にとって足かせになってしまうリスクがあります。そこでカルチャーを流動的なものであると捉えて、カルチャーをよりよく成長させられる人材かどうかを評価する「カルチャーアド」という観点が重要になってきているようです。

パフォーマンスの高い組織をつくるためには、カルチャーアドという観点で外部・内部の人材がカルチャーをより良いものに進化させていけるかどうかが重要です。そのため外部から新たに加わるメンバーは、従来のカルチャーからよりビジネス的に有利なカルチャーに改善できる部分を発見するための絶好の機会です。

カルチャーアドというのは、カルチャーを破壊しろということではなく、あくまでも「従来のカルチャーを無批判に信じるのではなく、環境に適応させ続けていくために調整し続ける」という趣旨です。

メンバーとして意識できそうな点

普段の業務の中で改善点をみつけて提案していったり、新しい文化を取り入れていくようなアクションはどのメンバーであっても意識していくことができそうです。

読んでいて発見だったのは、外部から新たにメンバーが加わることをカルチャーアドの絶好の機会として捉えられている点でした。新しく組織に入った場合、改善点を提案したり新しい文化を取り入れたりするのはチームに十分馴染んでからにしようと考えがちですが、むしろ馴染む前だからこそ気づけるポイント、改善していけるポイントもあるはずだということに気づけました。
逆に新しいメンバーを受け入れる側もこれを認識しておく必要があります。新しいメンバーからの提案を煙たがるのではなく、改善のきっかけとして捉えることがカルチャーアドを実現するには必要そうです。

ただ、もちろん既存のカルチャーを尊重する態度は重要です。前の組織ではそうだったからという理由だけでその文化を押し付けたり主張することは、既存のカルチャーを尊重しているとは言えません。提案する側も受け入れる側も常に「組織全体としてプラスになるのか?」という観点で考えることが大切になりそうです。

本書の注意点

GitLabは2000人規模の大所帯だからこそかもしれませんが、人事評価や組織設計のフレームワークがちょっと大仰だったり、組織の役割がかなり細分化されていたりする点があり、100人程度の規模の組織だとちょっと合わないような点はあると感じました。
そこらへんは適宜エッセンスを取り出して解釈するとよさそうです。

感想

読んでいて気づいたのですが、弊社は既にここで取り上げられている多くのノウハウを取り入れられているということに気づきました。話によるとリモートワーク導入時にGitlab Handbookをかなり参考にして仕組みづくりに注力されていたようです。だからこそ、現在でもフルリモートによる業務が成立しているのかなと思います。

とある技術系イベントに参加した際、お話ししたフルリモート勤務の方も「私もそれ読んだんですが、うちの会社も書いてある内容は結構実現できています。」とおっしゃっていたので、やはりフルリモートで成り立たせるためにはここに書いてある内容がある程度実現できていることが条件になる、逆に言うと実現できているのなら割と再現性高くフルリモートの仕組みがうまく回るのかなと感じています。

続編

今年12/9に続編(?) が発売されました。

GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術 数千ページにもわたるハンドブックを活用したテキストコミュニケーションの作法

まだ目次しか確認できていませんが、ハンドブックの内容のうち、ドキュメンテーションの部分に絞って細かく解説してくれているようです。
読んだらまた感想をまとめようと思います!


BPSアドベントカレンダー2024


CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。