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

書物
Page content

Webに公開されてるほうは3000ページもあるってまじ？
https://handbook.gitlab.com/

出版社のページ : https://www.shoeisha.co.jp/book/detail/9784798179421

読んだ理由 :

  • おれ個人としてはリモートワークで問題なく働けている（と勝手に考えている）が、他の社員がどう思っているかはわからない
    • とくに上司が本心ではおれをどう評価しているのかわからない
  • リモートワークがなぜうまく機能しているか（していないか）の要因をよくわかっていない
  • 転職するとして、もうリモートワークでしか働けない身体になっちまった
    • 通勤時間て労働時間ではないだろうか
    • 人が多くて臭い電車に乗りたくない
    • オフィスだと全然集中できない
      • 他人が黙っていても息遣い、足音、衣擦れ音などあらゆる音が思考を遮断してくる

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

関係者であれば誰もがアクセスでき、情報同士の関連性が可視化されている一元管理された（その情報が他の場所に存在しない）揮発性の低い情報源に情報を集約するようにしています。

最新の正確な情報が1ヵ所にしか存在しないのはドキュメント文化を発展させる上で非常に重要な概念です。

おれがいま勤務している会社ではAtlassian社のConfluenceで社内wikiを構築することでドキュメント文化が醸成されている。
ただ、そうした中でも動画像など大容量データや機密性の高いデータはGoogle Driveに保存されるし、作業ログなどはConfluenceだけでなくJiraチケットやらSlackのスレッドやらに散らばって記載されがちである。
情報のある程度の分散は仕方ないと捉えるかどうか。サービスによって日本語の検索能力にバラつきがあるのも影響するかもしれない。

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

愛社精神がパフォーマンスを向上させる、という古くから日本の経営者が信じてきた考え方はいまやグローバルスタンダードになりつつあります。

え、まじで？聞いたことねえや。外資に勤めたことないけど。

従来の企業ではハイパフォーマーの特性を分析し、その傾向がある人材を厳選して採用することでパフォーマンスを発揮させようと取り組んできました。しかし、世の中の価値観が多様化し、働く時間や場所、国籍など状況が異なる人材を活用しなければならなくなっている昨今、多様な人材の能力を最大限に引き出し、あらゆるメンバーのパフォーマンスを発揮させることは重要な経営のテーマです。

ひねくれた見方をすれば、例えば日本なら少子高齢化やコロナといった外部要因が改善されちゃうと、従来のような「普通の」人材しか必要とされなくなるという揺り戻しが起きそうだな。
旧体制の革新のためには社会がちょっとくらい危機的なほうが都合が良いかもしれない。

「我々らしくないから」という理由で採用を見送ったり低い評価を付けたりすることは、組織としての改善のチャンスを逃し、将来的なパフォーマンスの低下につながります。

いやあ、さすがに倫理観の終わってる人間とかとは一緒に仕事したくないけど。「そんな極端な例は題材にしていないしお前には言われたくない」って？

そうした目に見える成果を公正に評価するために、パフォーマンスを計測する必要性が出てきます。パフォーマンスが可視化されることによって、「何も成果を残せなかった」状況を避けるために、従業員は成果にフォーカスした行動を取るようになります。

プログラマなら「今月のプルリクエスト作成数」とかで集計すれば簡単だろうけど、その他の職種はどうするんだろうか。キーエンスみたいにガチガチの監視するとか？んなわけないか。

リモートワークの中では誰がどんな役割を担い、どのプロジェクトを誰が担当しているのかが明確になるため、組織が行っている事業活動の可視化が進みます。

すげえどうでもいいけど、「可視化」じゃなくて「見える化」って表現してる文章、くそ気色悪いと思うのおれだけ？この本は「可視化」と書いているというだけで信頼できる。

もし、何かを生み出す創造的な業務（たとえば、ソフトウェア開発・デザイン・経営など）を担当している人の予定が会議で埋まっていたら要注意です。

あ、おれんとこのマネージャー陣はこれだ。いろんなプロジェクトに関わっていていろんな会議で忙殺されている。
そんな中でもプルリクエストのレビューを依頼するとその日のうちには的確な指摘をしてくれるバケモンみてえな上司がいるが、あれは下っ端から見ても体調面が気になる。

オフィス賃料以外にも交通費、通勤時間、従業員数の増大によるオフィス移転など、事業とは直接関係のないコストも抑えられるようになります。

「持ち家は負債」って言葉もあるしな。

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

オフィスワークの補完的要素としてリモートワークを捉えてしまうと、たとえ経営者がリモートワークを推進したいと考えていたとしても、なし崩し的に「オフィスワーカーが主流派」、「リモートワーカーが非主流派」という流れが自然とできてしまいます。

DRIとは、「誰が最終的な責任者なのか」を明確にするものですが、それにあわせて必要な「意思決定権」も与えられます。効果的なリモート組織を実現するためには、リモート責任者をDRIとして任命し、十分な責任と権限を持たせなくてはなりません。

おれんとこの会社、実はハイブリッドワークだし専任のリモート責任者はいないけど、なぜかうまく回ってるように見える。おれが混乱期を経験してないだけか？

Suddenly Remote Handbook というハンドブック作成のためのテンプレートも用意されているので、こちらを活用するとスムーズに始められるかもしれません。

https://handbook.brownfield.dev/ というのが公開されている。たぶんhugoのBookテーマ製。

なお、ハンドブックをWikiで作成することは将来的に構造を大きく変更することが困難であるため推奨されていません。

おっとまずい。会社だとオンボーディング資料含めてなんでもかんでもConfluenceに記載しちゃってる。お察しの通り、資料の構造はカオス気味。
こういうのもソフトウェア開発と同じくプルリクエスト -> レビュー -> マージ形式にしたほうがええんかね。それこそGitLabがやってるように。
でもこれってGitLabの全従業員が少なくともgitを使えるってことか？ソフトウェア開発者以外も？

こうしたガイドラインで説明されていることは特別なことではありません。自分を大切にするように相手も尊重することや謙虚に自分を省みるような当たり前のことです。しかし、こうした敬意を持ったコミュニケーションがさまざまな価値観の人たちとわかり合える土台になります。

なんというか、「他者を傷つけたら言い訳するんじゃなくてまず謝る」とか小学校の道徳の授業で終えていてくれみたいな話が強調されていると、人類全体の倫理観に対して悲しくなってくる。
この本やGitLabハンドブックに記載されていることを実践できてないってことは、そいつが小卒未満てことだもんよ。義務教育の比較的充実してる日本人が言うのはフェアじゃないかもしれんけど。

利用するツールが多岐にわたることでそのツールを導入していないメンバーがアクセスできないといったコラボレーションを阻害する要因になったり、利用方法を学習するためのオンボーディングの手間が増えたりしてしまいます。

わかる。オンボーディングがめちゃくちゃ大変なわりに頭に全然残らないがち。
そのうえ環境構築に手間取ったので「入社して即クビになるんじゃねえか」とビクつくことになった。まあ新人や業務委託なら必ずぶちあたる光景だったようだが（それはそれで大問題なので少しずつ改善されていってる）。

経営者や上級管理職をまず強制的にリモート化することです。

経営陣がリモート環境で意思決定を行うために、必要な情報を収集する過程でツールやプロセスに存在している問題に気が付くことができます。

鶴の一声ってやつですかね。まあこの本やGitLabハンドブックを手に取ってる時点でリモートワーク導入する気満々なのにそれをしないリーダー陣というなら、社員はどんどん抜けていく気がする。「結局どうしたいねん」って感じで。

パソコン、ネットワーク、カメラ、マイクロホン、イヤホン、モニターなど、必要な備品をオンライン会議中に違和感を抱かない標準的な水準で用意します。

ハーマンミラーは経費で買いたかったなーおれもなー（そんな会社あんのか？）。

チームメイトやチームリーダーから見てパフォーマンスを発揮している新入社員に対しては「社会的交換関係」が影響していることがわかっています。社会的交換関係とは、人間が社会の中で「金銭」などの有形のものや、「尊敬」「愛情」「承認」「共感」「愉快」などの無形の資源を交換し合っている関係を指しています。

おれは単純だから給料良かったらいっぱいがんばっちゃうぜぐへへ。

インフォーマルコミュニケーションが大事であるからといって、従業員の気持ちも考えずにイベントをやればいいわけではなく、

あ、釘さしてら。おれは酒が飲めずたばこしか吸わねえつってんのに、前職ではわけわかんねえパーティに誘われがちだった。もちろん途中から不参加。

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

日本では書類管理や印鑑、郵送物など物理的な制約も多くあるためオフィスはなくせないといった事情もあるかもしれません。

これほんまきついな。都会のクソ高い家賃を払ってまでオフィス構えたくないし、かといってド田舎だと下手したら社長が一人ですべての書類をさばく羽目になるし。

リモートワークでは、仕事以外の雑談が自然発生することが少ないため、気が付いたらまったく雑談をすることなく１日が終わってしまうことがあります。

リモートワークじゃない前職の時点で雑談皆無の日とか普通にあったぞ。あ、おれが疎まれてただけか。

「いつ・どこで」「具体的に何があったか」「それがどんな影響を与えたか」を、事実をベースに伝えることで誤解を生まずにコミュニケーションを取る

これ意外とむずい。正確な文章を書こうとするほど単純に時間かかるし。ああ、非同期コミュニケーション前提なら時間かかってもいいのか。

チャットツールのダイレクトメッセージは原則避け、業務に関係するダイレクトメッセージであった場合には、オープンなチャンネルに誘導するようにしましょう。

確かに、うちでもDMは個人情報にまつわるやり取りのみに限られてる。

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

GitLab Valueはとことん実務的であるために、「世界を変える」といったような派手な言葉は用いられていません。

目標が抽象的なままだとそれにいたる道筋もフワフワするしな。

カルチャーマッチで採用していた時代には、組織カルチャーに近い性格や行動パターンの人物しか採用できませんでした。一方、バリューマッチであれば、明示的なパターンを守るつもりがあるすべての人達を採用対象者として見ることが可能になります。

遵法意識に近いかな。組織に対して愛着がないと育まれないイメージがある。待遇がよくなかったり嫌がらせしてたら、退職際にやべえしっぺ返しを社員から喰らうはめになる。

具体的にどんな成果を実現するのか合意しつつ、1 ~ 2週間単位でパフォーマンスのフィードバックを行いましょう。

月一の1on1でしかやってねえ。てか参加するプロジェクト毎にやり方がばらついてんねんな。これは良くないのかも。

自分が解決できないかもしれないと感じたときには、すぐに関係者に知らせて助けを求めましょう。

やってる。「ひぃぃ！助けてくださいぃぃぃぃ！」みたいな感じで。

Slackなどでたくさんの人に向けて周知するときには、短いメッセージにすることが重要です。文章が長すぎる、整理されていない、明瞭でない、専門用語が多い、不正確であるなどの要素があると、多くの人がしっかりと文章の意味を理解しようとはしなくなってしまいます。

うちのリーダー陣は長すぎる文章をやらかしがちですねえ……。リーダー陣は週報を書くことになってるが、私生活の近況から入って、本題がだいぶ後ろのほうからスタートしてる。雑談専用チャンネルがあるのだから前半部はそっちで書き込めばいいのにと思う。今度それとなく指摘してみようかな。

新しくGitLabに加わったメンバーは、最初のうちは決断のスピードの速さや、誰もが周囲に相談することなく物事が決まっていく様子を見て戸惑うことがあるようです。

このことや1 ~ 2週間のリリースサイクルを設けているGitLabの基準からすると、うちはアジャイルではない。いやまあこの本読む前からウォーターフォールと思ってるけど。こんなこと書いてたら給料減らされるかな。

イテレーションにおいて、変更前に戻すことは問題ではなく、ポジティブな意味を持つことを理解しましょう。

「手戻り」って単語に嫌悪感を覚えちまったおれに、はたしてできるのか。

会議でレビューをもらう際には、他の参加者が効果的な改善案を提案できるように、解決したい本質的な課題のディティールと現状のコンテクストを丁寧に説明するようにしましょう。

上司がバカ忙しいために必然的にこうなってるというかこうせざるをえないというか。そもそも会議までいかずにSlack上の相談で解決することのほうが多い（とくに開発者同士の場合）。

UXなどは長期の視点で計画を立てます。実際の改善は小さな変更の積み重ねですが、ユーザーに対して長期のロードマップを説明しておくことで、徐々に大きなものに成長していく過程を共通認識として持てるようになります。

あ、ここらへん勘違いしてた。恥ずかし。

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

まったく違う国で育った10歳の子供にも正確な意図が伝わるようなコミュニケーションをすることで、誰もがコラボレーションができるようになります。

うちは外国人採用を積極的にやってるわりには、日本限定の言い回しやネットスラングをたびたび見かけるので「あれ？」と思うことがある。
あと横文字がやたらと多いな。「アジェンダ」「ASAP」「クロージング」など。ここまできたら英語でよくないか？まあおれだって「プルリク」「PR」って使っちゃってるけど。最近だと、外国人も参加してる読書会で「逸般の誤家庭」って発言しちゃった。

Zoomの録画機能を用いてGoogleドライブに保存するよりも、Youtubeのほうが再生品質、字幕、サムネイル、特定再生時間帯へのリンク、コメント機能など動画を活用する上で優れている点が多く存在します。

これはおま環かもだが、Googleドライブだと通信速度も遅く、結果として録画動画はスルーしがち。うちもYoutube使ってほしいけど、セキュリティ的に駄目なのかな？

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

GitLabでは入社前から入社後4週間にわたる具体的なスケジュールをオンボーディングプロセスとしてテンプレート化しており、

なっが。うちでもせいぜい1週間ぐらいのはず。

即戦力採用を行っている企業では、採用した中途社員を重要なポジションにアサインすることがあります。そうした企業では、お手並み拝見とばかりに独力で活動することを期待する様子が見られることがありますが、重要なポジションであるからこそパフォーマンスを発揮させるためには周囲の支援が必要なのです。

まじか、これは全然知らなかった。

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

本来は必要なコンフリクトを行うために心理的安全性が必要になります。心理的安全性があれば、どちらが正しいかどうかは関係なくなり、チーム共通の目的のために何が妥当なのかを健全に考えられるようになります。

ゼミの担当教授の言葉を思い出す。「子供に健全な衝突をさせるため、小学校教師はイベントを企画させるのが大好き」ってやつ。

大前提として必要なことは、ネガティブなフィードバックを送る前に日常的にポジティブなフィードバックや人間味のあるコミュニケーションを行って良い関係性を構築しておくことです。

意外なことに、マネージャー陣からネガティブなフィードバックを受けた記憶がない。でも給料はしっかり低い（たぶん社内ワースト1位）ので、マネージャー側も面と向かって発言したり、（おれも閲覧できる）評価シートに記載するのに抵抗があるのかもしれない。

会社によっては3ヵ月に一度の評価タイミングでフィードバックを行っているかもしれませんが、それでは遅すぎます。

さいですか……。うちは1ヵ月に一度だが、これでもまだGitLabから見たらトロいのかも。

組織がコラボレーションや心理的安全性を高めるためには、定められたルールがしっかりと遵守されることが重要です。それに加えて、フリーライダーが存在しているのであれば、しっかりと対処しなくてはなりません。

とくに指摘を喰らったことはないが、自分がフリーライドしてるんじゃないかと不安に思ったりはする。

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

人間関係から生じる問題に関しては、GitLabではチームメンバー・リレーションズ・スペシャリストという専門のグループが対応します。

日本でも人事がこうした人間関係のトラブルに対処することはありますが、その目的は会社の法的リスクをいかに回避するかに焦点が当たっていることが多いように思います。

すごいけど、リソースが慢性的に不足してるベンチャー企業にはハードル高くない？言い訳になるかな？

GitLabの場合は、毎年ルールやプロセスに無駄がないか見直す時期を設定しています。

こういう定期的な棚卸しイベント設けるの良いな。

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

GitLabに在籍することが本人にとって最良でない場合にも高すぎる報酬額はGitLabに縛り付けてしまうことにもなってしまうため、健全でない関係性を避ける意味でも重要です。

雇用者目線でも被雇用者目線でも、給料は高いほど良いと雑に考えてた。

基本的に報酬額を下げることはありません。報酬額を下げることでモチベーションは下がることはあっても上がることはありません。

IT業界で給料下げたら即バックれられちゃうイメージあるな。いや、もう時代的に業界は関係ないか。

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

GitLabでは、メンバーをどれだけつなぎ留められているかという在職率をマネージャーの定量的な数値目標として管理しており、マネージャーはメンバーをつなぎ留める責任を負わされています。

うへえ、おれにはマネージャー職は無理そうだな。「会社辞めたい？おう、達者でな」で終わるし。

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

リモートワークでは直接会うことが少ないため、支援を必要としているメンバーに気付けない場合があります。

たとえオフィスワークでも気づけない場合のほうが多くないか？気づいてて放置してるだけかもしれんけど。あ、おれが前職までしょぼい企業にしか勤めてないだけか。

休みの日にスマートフォンやパソコンでつい仕事の連絡を見てしまっているのであれば、休暇の間は完全に仕事から離れて徹底してリフレッシュするべきです。

これなあ。やめたいけどついSlack見ちゃうわ。

毎日20 ~ 30分程度のウォーキング（早足での散歩）を続けることでうつ病を防ぐ効果があることがわかっています。

うつ病じゃなくて不眠症の解消目的で、週に3 ~ 4回早足ではない散歩してる（最近不眠症がぶり返してるけど）。

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

個人が暗中模索しながら時間をかけて解決策を見いだすよりも、すでに先人が整理した知識を活用することで汎用化されている部分までは早期にキャッチアップできるようになります。

よく言われる「巨人の肩に乗る」ってやつか。たしかTwitterでみかけたけど「巨人の肩によじ登ることすら難しくないか？」って投稿あった気がする。

検索したら見つけた。こういうの。

研修は受講することが目的ではなく、研修によって得られた概念を積極的実践として活用し、スキルとして定着させていくことが目的です。多くの研修では定着まで追跡せず、座学で終わらせてしまっているので意味がないのです。

うーむ、耳が痛い。役に立った研修なんて人生でない気がする。

雑な感想

  • スキル以前に性格が終わってるから、おれはGitLabには採用されないと思いました。
  • 組織運営って大変すね。