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

投稿時刻2023年12月12日 15:27

「GitLabに学ぶ世界最先端のリモート組織のつくりかた」を 2,023 年 12 月 09 日に読んだ。

目次

メモ

p9

その際にも参考にした「GitLab Handbook」は、本書の執筆時点で、英語で3,000ページ弱に及ぶ膨大なものになっています。
正直なところ、その量のため、GitLabの従業員でさえすべてを把握するのは困難です。
私も本書の監修をさせていただいたことではじめて触れる話題もいくつかあり、大変参考になりました。

p30

GitLabは世界67カ国以上にまたがり、2,000名を超えるメンバーが在籍している「オールリモート企業」です。
日本ではフルリモートという言葉に馴染みがありますが、GitLabは自分たちのことをオールリモート企業であると宣言しています。
オールリモートとは文字通り「すべて」がリモートを前提としてつくられている組織です。
オフィスを持たず、世界中に従業員がいるので決まった就業時間やコアタイムなどのタイムラインも持ちません。
非同期 (時間を合わせない) コミュニケーションを前提とすることで、世界中いつどこからでも場所と時間に縛られないコラボレーションを可能にしています。

p31

2011年、ウクライナの水道もない家に暮らしていた共同創業者ディミトリー・ザポロゼツ氏が、
優れたコラボレーションを追求するためのプロジェクトとしてGitLabをスタートさせました。
「毎日の井戸への水汲みよりも、ソフトウェア開発者たちがコラボレーションするツールがないことのほうが問題だと感じていた」というモチベーションに基づいて、
OSS (オープンソースソフトウェア) として世界中の開発者からの貢献を受けながら育まれていきます。

その後、オランダ人の共同創業者でCEOのシッツェ・シブランディ氏がこのビジョンに共感して2014年に法人化しました。
翌年にシードアクセラレーター(スタートアップの成長を支援する組織)として著名なYコンビネータに参加するためシリコンバレーにチームは集いましたが、
通勤よりも開発に集中したいと3日目にして誰もオフィスに来なくなったところからリモート組織の探求が始まっています。

p70

また、ハンドブックをせっかく作成したとしても、活用されなくては意味がありません。
ハンドブックはいつでも誰でも参照できるようにアクセスしやすい場所に設置されている必要があります。
ハンドブックを設置する場所ですが、GitLabを活用することもできますし、
Notionなどのツールを利用することも推奨されています。
また、 Suddenly Remote Handbook というハンドブック作成のためのテンプレートも用意されているので、こちらを活用するとスムーズに始められるかもしれません。
なお、ハンドブックをWikiで作成することは将来的に構造を大きく変更することが困難であるため推奨されていません。

創業者のように振る舞う p115

チームメンバー全員が会社を代表する立場として問題に取り組む必要があります。
GitLabでは、これを「創業者のメンタリティ」と呼んでいます。
コラボレーションの価値は助けが必要なときに互いに助け合えることです。
自分の責任を軽くするためにコンセンサスを取ったり、自分一人でできることを無駄に遠回しにしたりすることはコラボレーションではありません。

MVC (最小限の実行可能な変更) を目指す p143

GitLab では、最低限の変更のみでリリースすることを「MVC (Minimal Viable Change)」と呼んでいます。
ユーザーに価値を提供するために、可能な限り早く小さい変更を行うようにします。
変更によって明らかに改善する場合には迷わず実行します。
価値を届ける変更とは、何かを「追加」する場合と何かを「削除」する場合しかありません。
プロダクトの場合には、バグや使いづらさがなく、ユーザーのニーズを満たす機能が提供されているかどうかを徹底します。

すべてが制作途中だと理解する p144

GitLabでは、コンテンツやプロポーザルに「WIP (下書き、制作途中)」であるというマークを付けることはほとんどありません。
なぜならば、すべての仕事は制作途中であり、状況に応じて変更される可能性があるためです。
まずは、いったんリリースしましょう。

まとめてしまいたい欲求に抵抗する p146

一連の小さなイテレーションをまとめてしまいたい衝動に抵抗してください。
いくつもの小規模なプロジェクトをまとめた網羅的なプロジェクトや構想をつくることはワクワクします。
しかし、これはスコープクリープと呼ばれるものを引き起こし、
はじめに予定していたよりもコストが肥大化していき、成果よりも完璧さを優先させるものに変化していきます。

信頼できる唯一の情報源 p153

GitLabではハンドブックを唯一の情報源として統一することで、最新の情報を不整合なく効率的に活用できるようにしています。
ドキュメントが分散しているとどちらが正しい情報かわからなくなり、検索にも手間がかかってしまいます。
情報源は1ヵ所に集約しましょう。

オンラインミーティングのガイドライン p175

GitLabでは同じテーマに関して非同期コミュニケーションが三度往復するような場合には、同期ミーティングに移行するよう推奨されています。
GitLabでは社外とのコミュニケーションやセキュリティなどの観点からZoomを用いており、
Zoomプラグインを用いてGoogleカレンダーに連携させて活用しています。

留意点としては、オンラインミーティングを実施する場合にはそれぞれ別々のPCとヘッドセットを用いる点です。
1台のPCから複数人が接続することは、音声や表情がしっかりと確認できず、コミュニケーションの問題が発生するため避けてください。
不要なノイズを出していることに気が付いていない人がいた場合には、ミュートを勧めましょう。

また、GitLabではすべてのオンラインミーティングはYouTubeで録画して共有しています。
ZoomにはYouTubeのライブストリーミングと連携させられる機能があり、
会議後にストリーミングのリンクを議事録に張り付けることで、誰でも後から会議の内容を参照できます。
録画と共有にYouTubeを用いているのは、Zoomはオンラインミーティングのツールであり、YouTubeは動画を視聴するためのツールであるからです。
Zoomの録画機能を用いてGoogleドライブに保存するよりも、
YouTubeのほうが生品質、字幕、サムネイル、特定再生時間帯へのリンク、コメント機能など動画を活用する上で優れている点が多く存在します。

オンラインミーティングを行う場合には、可能な限り映像はオンにします。
第5章で述べたように、 GitLab の場合、参加者は会議中に会議以外の作業に集中していても問題ありません。
もし、議論や質問に回答してほしいときには、必要に応じて声をかければ解決します。
また、前述のように社内会議中はメンバーのペット、子供、パートナー、友人、家族が画面に映り込むことを推奨しています。
もし可能であれば、その人たちからチームメンバーに手を振って母国語で「こんにちは」と言ってもらいましょう。
これによって、チームメンバーの親密さが向上し、人間味のある思いやりが生まれるようになります。

一方で、仕事をする上でオンラインミーティングには適していないシーンも存在しています。
非同期コミュニケーションで対処すればタイムゾーンにかかわらずあらゆる人が議論に参加でき、テキストは後から検索することも容易になります。
そのため、普段の業務スタイルの中では非同期コミュニケーションを前提とし、必要に応じてオンラインミーティングに誘導するプロセスを用意しましょう。
非同期コミュニケーションからオンラインミーティングに誘導することは簡単ですが、
オンラインミーティングを途中で打ち切って非同期コミュニケーションに誘導することは困難です。
テーマや状況を見ながらトレードオフを意識してオンラインミーティングを活用しましょう。

オンボーディング期間の目安とフィードバック p185

新入社員は新しい環境でなるべく早く活躍して認められたいと思うものですが、入社後すぐに活躍することは簡単な話ではありません。
Googleの元人事トップであるラズロ・ボックは『ワーク・ルールズ』(東洋経済新報社)の中で、
Googleの新入社員(ヌーグラー)が一般的な社員と同じパフォーマンスを発揮できるようになるまで、約9カ月の期間がかかると説明しています。
特にソフトウェア開発企業などで顕著ですが、成果を出すためには特定の専門知識や技能だけで完結する個人作業は少なく、チームとのコラボレーションやドメイン知識を得る必要などがあるためです。

p197

Googleのエンジニアが効果的なチームのつくりかたを書いた「Team Geek」の中で、
「(プログラミングの)コードを批判されても、君自身を批判しているわけではない」という言葉が出てきます。
自分の意見や成果物が批判されると、自分の人格まで批判されたような気持ちになってしまうのは理解できます。
上司部下の関係はさらに複雑かもしれません。
上司の意見に対して部下が批判をすると、たとえ部下の指摘が正しくても上司の恨みを買ってしまう可能性があります。

このように「意見や成果物」が「人格」と重なってしまっている環境の中では、正しい意思決定は実現できません。
意見や成果物は客観的な視点で公正に判断されるべきであり、それは個人の人格とは別の次元で議論しなくてはならないのです。

報酬に関する GitLabのスタンス p249

報酬制度も、GitLabが重要視している公正さや透明性をベースに設計されています。
たとえば、GitLabでは流動的に昇給額を決めるのではなく、Salesなどの一部職種を除き、
社内で公開されている報酬計算システムに則って同じルールで報酬額を決定することで透明性と一貫性を保っています。
報酬計算システムで算定された金額に、地域ごとの報酬水準に準ずる係数を掛け合わせて報酬額を決定します。
これによって、報酬水準の低い地域に住むメンバーに過剰に支払うことがなくなり、各地域でも採用競争力を維持できます。
過剰に支払わないことは会社側のコストメリットもありますが、GitLab に在籍することが本人にとって最良でない場合にも高すぎる報酬額はGitLabに縛り付けてしまうことにもなってしまうため、健全でない関係性を避ける意味でも必要です。
メンバーとパフォーマンスがあくまでフェアに釣り合っている状態を維持するためにも、
このように地域の状況を加味することは重要な観点です。

経営課題としてサクセッションプラン(後継者計画)を用意する p251

サクセッションプランとは重要ポストにおける後継者の育成計画を意味する、経営計画上の重要な人事施策です。
東京証券取引所が2015年にコーポレート・ガバナンスコードとして策定し、
2018年改訂、2020年と2022年に経済産業省がまとめた「人材版伊藤レポート2.0」でも言及されるなど、サクセッションプランに対する日本国内の関心も高まりつつあります。
当然ながら替えが効かない重要ポジションが存在することは企業にとってリスクでしかなく、経営を安定化させるためには冗長性の確保が必要です。

別の観点としては、サクセッションプランはリスクを軽減するだけでなく、将来を担う優秀な人材の維持と能力開発による事業成長の推進という役割も果たします。
また、重要なポジションを担当できる人材が増えることによって、属人的な集中を避けて分担できるようになり、ボトルネックの解消やスピードアップにつながる可能性もあるでしょう。

すべての人が昇格を目指す必要はない p252

ここまでGitLabがいかに成果や成長に対する強いコミットメントを示しているか説明してきました。
しかし、GitLabは昔の外資系戦略コンサルタントでいわれていたような Up or Out (見格か退職か) という、限界まで成果や成長に取り組まないメンバーは不要であるという考え方は採用していません。
役割に求められるパフォーマンスを発揮しているのであれば組織にとって貴重な戦力であり、また本人が望んでもいないのにより大きな役割を強制的に求めるのはインクルーシブであるとはいえません。
人生において仕事だけがすべてではありません。
メンバーが人生と仕事をうまくバランスできるように組織として向き合うことによって、
限界まで成長したい人は成長でき、調和した働き方を望んでいる人にはそうした状況を提供でき、
いずれの場合であっても長く良い関係性を維持していけるようになるのです。

SMARTな目標を設定する p260

あらゆる計画がゴールの設定から始まるように、マネジメントの仕事も目標設定によるフォーカスを定めることが重要です。
マッキンゼーなどのコンサルタントが 「So What? / Why so?」を 繰り返していたり、
トヨタが「なぜなぜ分析」で問題を掘り下げて解像度を上げているように、
何を解決するべきなのかというディティールの具体性は結果を大きく左右します。
明瞭な問いがあれば、現実的に取り得る選択肢の幅も決まってくるためアクションが言語化できるようになります。
よくいわれるように「良い問いが立てられれば、問題は半分解決している」のです。

こうした状態を目指すために、GitLabでマネージャーが良い目標を立てるために活用しているフレームワークがSMARTです。
Specific (具体的)、 Measurable (計測可能)、 Achievable (達成可能)、 Related (経営目標との連結)、 Time-bound (時間制約がある) の頭文字を取ったもので、このフレームワークに基づいて目標設定を行えば、
マネージャーが期待しているパフォーマンスとメンバーの解釈のズレを減らす効果が見込めます。

p267

パフォーマンスの不足に関しては、マネージャーがメンバーと合意した基準に基づいて、
どの部分がどの程度不足しているのか可能な限り定量的な状況と実例をもとに説明を行い、
望ましいパフォーマンスを発揮できるように協力していくという前向きなメッセージとしてメンバーに受け止めてもらう必要があります。

p272

3つ目が「コーチング」のコンピテンシーです。
コーチングはマネージャーが将来の目標に向かってメンバーを導くための能力です。
メンバーへの問いかけを通じて、学習や洞察を深めるための示唆を提供していきましょう。
メンバーが自分の強みを自覚し、能力を伸ばせる可能性に気付かせていきます。
メンバーに寄り添って深く傾聴することで、メンバー自身が自分の内面に気付けるようにサポートします。

コーチングを提供するために GROW モデルを活用するのもひとつの方法です。
GROW モデルは、 Goal (目標) ・ Reality (現実) ・ Option (オプション) ・ Way Forward (前進) からなるフレームワークです。
Goalではメンバーにモチベーションを高めるようなインスピレーションを与える目標を設定します。
Reality では、現在の状況と将来の目標を達成するために越えなければならない課題が何かを特定します。
Option は前進するために取り得る手段を検討します。
Way Forward では、何をいつまでにするか具体的なアクションと期日を設定します。
ここでコミットした行動を振り返りながら、改めてGoalに立ち戻ってサイクルを回していきます。
コーチングはこうした問いをメンバーに与え、メンバー自らが進むべき道を発見できるように導きます。

p282

GitLabではしっかりとした休暇を取るために、どのようにチームメンバーに通達するかといった点にも工夫が見られます。
たとえば、休暇を取る前には休暇取得する予定の日取りから数えて、休暇日数の2倍以上前にチームに通達をしなくてはなりません。

運動によって脳を整える p284

運動が身体に良いことは子供でも知っていますが、運動の重要性は想像を超えて大きな影響を与えることがわかってきました。

たとえば、ディーン大学のジェームズ・ブルーメンソールの研究によると、
うつ病患者に対して「運動を提供したグループ」と「ゾロフトという抗うつ剤を投与したグループ」を比較したところ、うつ病改善の効果はどちらも同じ程度改善しました。
それに加えて、うつ病の再発率は運動を提供したグループのほうが低い (抗うつ剤38% / 運動8%) という結果が出ました。
つまり、抗うつ剤よりも運動のほうが効果的ということです。
こうした研究から毎日20 ~ 30分程度のウオーキング (早足での散歩) を続けることでうつ病を防ぐ効果があることがわかっています。

また、ストレスの抑制や記憶を司どっている「海馬」の細胞は加齢と共に毎年1 ~ 2%ずつ減少することがわかっています。
毎日40分程度のウオーキングをすることで海馬の細胞の減少は止まり、逆に海馬の細胞が増えるとの研究もあります。

この他にもアンデシュ・ハンセンの著書『運動脳』(サンマー出版)では、
定期的な有酸素運動が集中力や創造性を向上させ、メンタル疾患や認知症を抑え、知力にまで影響を与えると説明されています。

リモートワークになることで今まで通勤のため駅まで歩いていた時間もなくなり、階段の上り下りもなくなり、季節や街並みの変化を感じる機会も減ってしまっているかもしれません。
こうした状況は知らず知らずのうちに、脳と肉体をむしばんでいる可能性があります。
リモートワークで働くからこそ、意図的に週2回・20分以上の有酸素運動を生活に取り入れ、人体の機能をメンテナンスしていくことを推奨します。

個人開発計画 (IGP) を作成してキャリア開発ディスカッションを続ける p293

能力開発を効果的に行うためには、ひとりひとりが自分のキャリア計画を立てた上でコミットした行動を実行していく必要があります。
GitLabが推奨している IGP (Individual Growth Plan) は、自分が実現したい目標や将来のキャリアを定め、その実現のためにどのようなチャレンジを行っていくのかアクションプランが書かれたものです。

自分がどんな場面にやりがいを感じたり、どのような仕事を中心にキャリアを形成していきたいかといった自らの内面を整理し、今後のキャリアについて具体性を高めていきます。
目指す開発目標を達成するためにどのような機会にチャレンジするべきかを見定め、具体的なプロセスやスケジュールを宣言します。
GitLab ではマネージャーと月に1回以上IGPについて話し合う機会を設け、コミットするアクションプランを定期的に見直しています。