8冊目 GitLabに学ぶ 世界最先端のリモート組織のつくりかた

概要

項目	内容
タイトル	GitLabに学ぶ 世界最先端のリモート組織のつくりかた
発表年	2023
読んだ日	2023/10/22
お勧め度	⭐️⭐️⭐️⭐️⭐️

読んだ理由

• twitterで多く流れてきて気になった
• リモートでの組織文化を学びたい

狙い

• リモートでのコミュニケーションのポイントを学ぶ
• リモート文化を醸成する方法を学ぶ

実践

• 採用は、カルチャーマッチよりもカルチャーアドを意識する。
  　→ 採用面接時に、カルチャーを成長させてくれそうかで判断する。
• 相手と会話する際は常に「前向きな意図を想定する」。
  　→ 常に相手に敬意を持って。これを実施して自分の言葉に心理的安全性を育む。
• 相手へのフィードバックは、人格ではなく行動に対して実施する。
  　→ どの行動に対する言葉かを意識する。人格への言葉にならないようにする。絶対。

刺さった言葉たち

Gitlabは世界67カ国以上に跨がり、2000名を超えるメンバーが在籍している「オールリモート企業」です。

フルリモートと言う単語が有名だが、GitLabはオールリモート企業と位置付けている。
オールリモートという名前の通り、リモートを前提に社内のルールやオペレーションが設定されている。

Gitlabがオールリモート環境でここまで成長できた背景として、
OSSの概念を組織へと拡大して適応することで効率的なコラボレーションを成し遂げてきたことが
handbookから読み取れます。

3000ページ弱の大作のhandbookに様々なルールなどが言語化されている。
これはOSSの考え方に近く、コラボレーションをするためのルールがドキュメントで記載されており、それを用いて従業員が働く。

Gitlabではこうした組織を実現するために、
組織の意思決定プロセスについて解釈の余地を可能な限り減らすように、
まるでプログラミングのように言語化を徹底しています。

関係者であれば誰もがアクセスでき、
情報同士の関係性が可視化されている一元管理された揮発性の低い情報源に情報を集約するようにしています。
この一元管理された揮発性の低い情報源のことをSSoT(信頼できる唯一の情報源)と呼んでいます。
最新の正確な情報が一箇所にしか存在しないのは、ドキュメント文化を発展させる上で非常に重要です。

ドキュメント化する際に、曖昧さを無くして、最新情報を必ず指定された場所にあることを前提に作成している。
これは理想だけどムズクない？って思うんだけど、これをやってるのがまず凄すぎる。
絶対誰かが足並み外しそうなものだけど。。

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

日本で求められる愛社精神は感覚的なもので根拠に乏しく、
海外のようにどうすれば従業員が会社を愛してくれるようになりパフォーマンス向上に寄与するのかという
具体的な部分の研究はおざなりであるようにも感じます。

これはめっちゃ分かるなぁ。ただの感覚でしかないけど愛社精神は大事だと思う。
同時にこれってめっちゃフワフワしてて、この科学ってされていないというか、個々の経験として散在している気がする。

カルチャーマッチで採用を行っている企業はグローバルのトレンドからはすでに遅れを取っています。
「我々らしくないから」という理由で採用を見送ったり低い評価を付けたりすることは、
組織としての改善のチャンスを逃し、将来的なパフォーマンスの低下につながります。
新しい価値観や知見を取り入れ、「我々らしさをもっとよく改善できないのか」という視点を模索することで、
より良いカルチャーを醸成していくことが可能です。

なるほど〜。確かにカルチャーマッチは大切だけど、多様性を考えるとカルチャーを伸長させられるかの観点の方が大事だなぁ。
これも従来は、「自分よりも優秀な人を」とかの言葉になったりしているけど、目的がカルチャーの成長という言語化をすることで狙いがシャープになる気がする。

リモート環境では何の価値も生み出さない仕事に時間が消費されなくなるため、
結果的にパフォーマンスが向上します。

ただし、パフォーマンスを追求するだけの成果主義では組織のモラルが低下し、
殺伐とした環境になってしまいます。
これを避けるため、
マネージャーがプロスポーツのコーチのように親愛の情やジョークなどを交えながら高い目標に対して目を向けさせ、
チームとして尊重しあい、ポジティブでありながら成果を追求している良い状態を維持する必要があります。

リモートワークでは、パフォーマンスを成果物で見せる必要があるため、大切なことしかしなくなる。
しかし、成果主義ではプロセスへのフォーカスが弱くなり再現性のある成長から乖離していくため、マネージャーが良い形で導くのが良い。
成果主義は終焉だよって表現は、はじめての課長の教科書でもあったねぇ。

Gitlabでは、世界中であらゆる時間帯に働いている人が存在するため、
ほとんどの業務において即時レスポンス・リアクションを期待しないことを前提として業務を行っています。

リモートワークを非主流派ではなく主流派として捉え、
「リモートワーカーのパフォーマンスを最大化するためにはどうすればよいか」という視点から発想をスタートさせなければなりません。

ここまでしっかり頭を切り替えるのは凄いことだなぁ。
確かに、リモートはオフィスの延長線上としか考えたことなかったかも。

「同意しない、だがコミットする(disagree and commit)」という言葉があります。
責任者の方針について、他のメンバーは懸念や反対意見があればはっきりと意見を示す必要があります。
そうした意見に対して、責任者も同様に説明責任を果たさなければなりません。
双方が意見を述べる責任を果たした上で責任者が決定したことであれば、
それ以外のメンバーは賛否を問わず全員が決定を尊重してコミットし、全力で支援します。
そうしたメンバーのコミットメントに対して、責任者は結果によって答えるのです。

メンバーの視点からすると、同意してないけど全力でやるのって難しいんだけどね。。
けど、この考え方でやらないとチームの方向性がバラバラになっちゃうんだよね。
だからリーダーはリードするし、その結果に責任を負うんだよなぁ。リーダーの責任たるや・・・。

Gitlabではハンドブックの更新に関してはあらゆる従業員が提案を行えますが、
ハンドブックに取り入れるのは権限を持つ承認者(DRI)が行っています。

OSSっぽいよね。Pull Requestとマージの関係。

リモートかどうかに関わらず、コミュニケーションはとても大切。
このコミュニケーションについてもガイドラインを作成することが重要です。

参考までにGitlabが公開しているコミュニケーションガイドラインは次の9つです。
① 前向きな意図を想定する
② 思いやりを持つ
③ インクルーシブな表現を用いる
④ 発言に責任を持つ
⑤ valueの模範を示す
⑥ フィードバックは必要不可欠
⑦ 1on1を怠らない
⑧ ハラスメントポリシー、行動規範、倫理規定を遵守する
⑨ 自分たちがコントロールできることに集中する

これはめっちゃ大切だと実感してる。
特に①と②。まずこれが前提として大事すぎる。

①「前向きな意図を想定する」とはコミュニケーションの相手は
「何かを良くするために適切に努力している」とまずは想定することです。

人間は本能的に、他人の行動から自分にとって不都合なことが発生すると、
相手が誠実でなかったり、やる気がなかったり、能力がなかったから問題が起きたと考えてしまいます。
「前向きな意図を想定する」とは、そうした考え方をいったん止めて、
相手はあなたや状況を良くするために努力しているのだと想像することです。

これ本当に重要だと思う。
メンバー間じゃなくて、マネージャー間ですらこの前提を疑ってしまう瞬間ってあるもんなぁ。
競争の中に自分を置こうとすると、こうなっちゃうんよ。。自戒。。。

② 「思いやりを持つ」とは、たとえば、あなたが面と向かって直接言えないような言葉をテキストで送らないことです。

この辺りも、距離感を間違えるとこうなっちゃうことあるよね。
なんて言えば良いのかな。適度な距離感というか、社会人としてあるべき姿というかそういうものは大切にしたい。

インフォーマルコミュニケーションが必要な2つの理由。
1つ目は、インフォーマルコミュニケーションが従業員のパフォーマンスを上げるためです。
2つ目は、メンタルヘルスの問題を避けるためにインフォーマルコミュニケーションが重要な役割を果たすためです。

仕事に直接関係ない会話(インフォーマルコミュニケーション)の重要性。
相手があまりこういうのを好きじゃない場合もあるから難しいけど、相手に合わせてこういう会話をしていきたい。

新入社員や現在活躍できておらず悩んでいる人など、
ここが自分の居場所なのか迷いのあるメンバーに対してこそ、
インフォーマルコミュニケーションを通じて親密さを示し、
実績を積み重ねていくことで自分の居場所なのだと確信を持って貰わなくてはならないということでしょう。

あまり活躍できていない人ほどこれが必要ってことよね。
まじでこれうまくできるようにしときたい。

ハンドブックでは「退屈でシンプルな解決策」を提供することを目指していると説明されています。

解釈がしやすいことが重要なため、複雑な解決策はなるべく避ける。
ただし、後述するが成果を最大の狙いとして置いており、成果を出すために複雑になるなら一定仕方がない。

従来の採用では社風に合っているかどうかというカルチャーマッチを重視する企業が大半でした。
しかしGitlabに限らずグローバル企業の採用トレンドとしては、
カルチャーマッチではなくカルチャーアドという観点を重視するようになっています。
カルチャーアドとは、カルチャーが流動的なものであると捉え、
カルチャーをより良く成長させられる人材かどうかという観点で採用や評価を行うことです。

カルチャーアド(add)って良い言葉。これ意識したい。

これはカルチャーを破壊しろと言っているわけではありません。
従来のカルチャーを無批判に信じるのではなく、
環境に適応させつづけていくために調整し続けていく必要があるという趣旨です。

カルチャーを調整していく覚悟を持ち、より高みをみんなで目指す。
こうありたい。

他人から見られているときにシンプルな作業は大幅に効率が上がるが、
複雑な作業の効率は下がるという「ソーシャル・ファシリテーション」や、
集団で共同作業を行う際に１人当たりの生産性が人数の増加に伴って低下する「リンゲルマン効果」などが存在します。

単純作業は他者の目があると効率が上がるけど、複雑な作業は効率が下がるのか。。直感的に分かるなぁ。

Gitlabのコラボレーション基準

これが素晴らしかったので、多いけど全部載せる。
特に「1. 思いやりを持つ」、「9. 前向きな意図を想定する」、「10. 謝れる方が強い」、「11. エゴを捨てる」が刺さった。
前向きな意図を想定するって最高に好き。

1. 思いやりを持つ
正論で追い詰めるのではなく、理解できるように接する。

2. 情報をシェアする
情報は、意図的に公開する。

3. ネガティブなフィードバックは１対１で問題は起きた瞬間に対応する
問題を家に秘めておくことは誰のためにとっても悪い影響しかない。

4. 沢山の人の目に付くように感謝を示す
可能なら全員が目にする場所で気軽に感謝が行われている状況を維持する。

5. フィードバックを効果的に用いる
マネージャーからメンバーに対するネガティブなメッセージは、ポジティブなメッセージと比較すると６倍も強い影響を与えることがわかっている。

6. お互いを知る
モニターの裏側にいる相手に人間味を感じていると思いやれる。

7. 部門を超越する
質問がある際には全社員に向けてアドバイスを求めるように推奨している。

8. 役職や肩書で物事を語らない
「CEOもこの意見に賛同している」など、自分の主張を通すために使うのもダメ。

9. 前向きな意図を想定する
みんな物事を良くするために発言している。

10. 謝れる方が強い
挑戦するほど失敗しやすくなるため、謝りやすい状況を作るのが大事。

11. エゴを捨てる
あなたの意見が否定されたからといって、あなたが否定されたわけではない。

12. 誰も失敗をさせない
苦しんでいる人を見つけたら、手を差し伸べるか、専門知識で支援ができる人を引き合わせる。

13. 仕事を基準にして話す
人格についてではなく、具体的な仕事内容について提案する。

14. 創業者のように振る舞う
チームメンバー全員が会社を代表する立場として問題に取り組む。

15. 責任ではなく問題に集中する
人やチームの責任を追求するのではなく、失敗に至ったメカニズムと意思決定のプロセスに注目する。

16. 短いつま先
つま先は権限や領土のことで、縄張り的な感覚をなくせ。

17. すべてを知ることは不可能
自分が知らないことがあることを自覚し、助けを求めることが重要。

全ての言葉が素晴らしい・・・！

GitLabでは成果（Results）をValueの最上位として重要視しています。
成果とはさまざまな意味を持つ言葉ですが、GitLabでは成果を「コミットした責任を果たすこと」と明言しています。

売り上げとかではなく、責任を果たすことが成果だって考え方良いな。

反対に「顧客の成果に貢献しない」プロダクトを意識しておく必要があります。
顧客の成果に貢献しないプロダクトは、
①直接のユーザーではないサービス導入の意思決定者への訴求を狙っている、
②機能が多岐にわたり、まとまりがない、
③ユーザーエクスペリエンスが時間と共に悪化する、といった特徴があります。

成果が出ない機能を落とす時の判断基準。
②のように、「機能がいっぱいあって成果は上がっているが、まとまりがない」という場合はどうするのが良いのかな。。

GitLabでは、会議への参加が重要でないと感じる場合には、いつでも参加しないという選択ができます。
また、必要に応じてミーティング中に他の業務に取り組んでも問題ありません。

この辺のバッサリ感が素晴らしいよね。
日本だと、雰囲気で参加だけするみたいになったりするからね。

GitLabでは粘り強く目標に向き合い続ける「目標への持続性」を求めています。
粘り強さとは、たとえうまくいかなくても自らを勇気づけ、立ち上がり、少しずつ学びながら前進することです。

成果を出すために大切な価値観としてこれを名言しているのがすごい。これが仕組みとして発生するようにしたいなぁ。

不確実性を受け入れる取り組んでいる仕事について、不確実性が存在していると受け入れます。
不確実性を排除する方法は、長い時間をかけて分析や推測を重ねることではなく、
不確実性を受け入れて前進しながら問題を取り除いていくことです。
間違っていた解決策は後から修正できますが、臆測のうちは何も改善できません。

「不確実性を受け入れて前進しながら問題を取り除いていく」って最近ぶつかっている内容なんだけど、これも記載されているのが素敵。

【周知は短く】
Slackなどでたくさんの人に向けて周知するときには、短いメッセージにすることが重要です。

改めて大切。相手の気持ちを考えて長くなったりするけど、gitlabの文化の元ならこれで良いんだろうなぁ・・・！

ミスを許容する
あらゆるトラブルに対して、必ずしも新しいプロセス（再発防止策）を用意するべきではありません。
何か新しいプロセスを追加すると、そのプロセスを活用するすべてのアクションが１段階非効率になります。

これ結構大事だよねぇ。なんでもかんでも再発防止のための仕組みっていう人いるけど、効率悪い場合ある。

ダイバーシティとは組織における多様性を意味しています。
人種や性別、年齢といった「表層的なダイバーシティ」と
性格や価値観、宗教、性的指向といった「深層的なダイバーシティ」という
２つのダイバーシティが存在しており、どちらの多様性も意識して育んでいくことが重要です。

一方で、ダイバーシティは多様な価値観を理解し合うため、
コミュニケーションのコストが高まるというネガティブな要因も指摘されています。
このネガティブな要因を乗り越え、パフォーマンスにつなげるために必要な要素がインクルージョンです。

深層的なダイバーシティがほんと難しいんだよね。表層的なところにフォーカス行くけど、本質はこっちだと思う。
しかし、ちゃんとネガティブな面も説明した上で大切って言ってるのが凄いんよなぁ。
しっかり理解して先に進める。

ビロンギング（Belonging）について説明します。
比較的最近の概念で、「自分の居場所はここである」という感覚です。

これもめっちゃ良い言葉。
zero to oneに、ペイパルマフィアの話の中でこんな概念が出てきてたと思う。
自分の居場所はここだ！って思ってみんなが仕事してくれたら最高だよね。

ここまでの説明を整理すると、
ダイバーシティは実際に組織に多様性が存在していること、
インクルージョンは所属しているすべての従業員が活躍できるという方針の確約、
ビロンギングはその結果として従業員に生まれるものだと捉えると良いでしょう。

なるほど〜、結構ごっちゃになるけどこういう捉え方をすると良いのか〜！
こう見ると、インクルージョンが一番大切だね。
これがあれば多様性を受け入れられるし、ビロンギングが醸成されていくはず。

マイクロアグレッションの影響を理解する

マイクロアグレッション（小さな攻撃性）とは、
意図せずに他人を傷つけてしまう無意識の差別的な行動のことです。
たとえば、「君は日本人なのに積極的だね」とか、「女性なのに数字に強くてすごいですね」といった言葉がそうです。
言葉を発した本人は褒めているつもりですが、
本人も気付かずに「日本人は臆病」「女性は数字に弱い」という先入観が言葉の背景に隠れており、
言われた側としては遠回しに下に見られていると感じてしまうことがあります。

マイクロアグレッションは徐々にインクルーシブな環境を悪化させ、人々を疲弊させていきます。
マイクロアグレッションを減らすためには、属性を通して相手を見るのではなく、独立した一人の人間として向き合う必要があります。

これめっちゃ大切。すぐ忘れる。
こういうのを常に意識して仕事をするか、意識しないで仕事するかで、マジで5年後凄い大きな差になる気がする。
どうすれば仕組み化できるかなぁ。毎週チェックする？？？？？？？

インクルーシブな会議

出席者全員が自分の見解を説明することで、
会議に主体的に参加してもらうことはリモート環境では特に重要です。
社内会議では事前アジェンダを書いたドキュメントを使用して、
あらかじめ質問を記入してもらうようにします。
質問は会議中に順番に回答され、ドキュメントに議論を記録するようにしています。

これも重要だってずっと言われ続けてるけど、会話に参加してくれないメンバーは常にいるよね。
GitLabでは質問を入れた人だけ参加って感じになったりするのかな？

GitLabでは「イテレーション」というValueを掲げており、
迅速なフィードバックを得て確実に前進するために
検証が可能な最小単位で物事を実行していくことにこだわりを持っています。

効果的にイテレーションを活用するためには、
まず、取り組んでいるプロジェクトがどんな価値を提供しているのか書き出すことです。

基本的だけど大切なこと。常に意識する。

MVC（最小限の実行可能な変更）を目指すGitLabでは、
最低限の変更のみでリリースすることを「MVC（MinimalViableChange）」と呼んでいます。

ユーザーに価値を提供するために、可能な限り早く小さい変更を行うようにします。
変更によって明らかに改善する場合には迷わず実行します。
価値を届ける変更とは、何かを「追加」する場合と、「削除」する場合しかありません。

MVPが有名だけど、MVCのchangeね！確かにね！
削除の意識も重要だよねぇ。

何か変更を行う際には、まずはスピードと成果を最優先に設定します。

「スピードと成果を最優先に」ですよねぇ。検討が長いんだよなぁ結構みんな。
自分も気をつけたい。

GitLabが透明性のValueを採用している理由は、透明性はコラボレーションを促進させ、
社外からの認知度を高めるといった組織にとってのメリットがあるからです。
それに加えて、組織の健全性を維持し続けることに寄与し、規模の拡大に伴う組織の劣化を抑止していくことにも役立ちます。

透明性は協働を進めるだけでなく、将来の組織のためでもある。

こうしたコラボレーションや認知度向上のメリットも重要ですが、
最も重要なのは組織の健全性の観点です。
組織は成長するにつれ、情報の透明性に対する意識が希薄化していき、
約束していた基準とは異なる意思決定をするようになったり、例外をつくりやすくなってしまいます。

透明性は常に意識しないと希薄化していく。
なのでvalueとして明言することが必要。

考えが変わったらはっきり言う 
自分の考えを述べた後に、その方向性を変える場合にははっきりと周囲に伝えてください。
新たなデータから示唆を得た結果、自分の考え方が変わることはまったく問題ありません。
以前のスタンスが現在のスタンスでないことを明確に示すことで、
他の人たちが困惑することを避け、その姿を見ることでデータに基づいた意思決定をしようと考える人が増えるでしょう。

これも結構やれないことが多い。
確定していない状態で頭の中で方針変換しちゃってるパターン結構あるなぁ。

結論だけでなく理由も説明する 
変更を行う際には結論だけではなく、変更の理由を明瞭に記録します。
それによって、後から変更の理由を知りたい人が現れた際には質問する必要がなくなり、
組織のナレッジの蓄積としても役立ちます。
変更の理由が書かれていない場合、推測によって動く必要が出てくるため、混乱や非効率につながってしまいます。

コード作成時に、コメントやcommitメッセージに理由を書くって色んなところで言われるけど
ドキュメントについても重要。

Valueが実践されていない場合には、率直な態度でいつ、
どんなシーンでどのように守られておらず、
それがどんな影響を及ぼしているのかといった具体例を伴ってフィードバックを行うことが重要です。

フィードバック苦手だからこの辺は意識したい。

Valueの対立を乗り越えるためには、相手を責めるために正しさを主張するのではなく、
まずは相手に対して前向きな意図を想定するところから始めます。

この「前向きな意図を想定する」って言葉が好きすぎる。
常にこうありたい。多分これをやると、相手からも前向きな意図を受け取ってもらえるようになる。

たとえば、同僚の人間性に対して不満を漏らしているところを見かけたら、
コラボレーションの「仕事を基準にして話す」というハンドブック項目へのリンクを送り、
同僚の人格ではなく、どういった行動がどんな影響を及ぼしているのか、
という方向に視点を持って行くようにアドバイスします。

このフィードバックの方法よさそう。人格ではなく行動に対して指摘するのもポイント。

オープンにお互いが感じていることを表に出して対話することが必要ですが、
率直に意見を交わしても明確な結論が出ない場合もあります。
そうした場合は、敬意を持って説明を尽くし、
最終的にはDRIが決定を下したものに対してコミットすることで前進していくのがGitLabのやり方です。

説明を尽くして、決まったことにコミットする。
みんなでこれができたら良いんだけど、スッゲーむずいよねこれ。

曖昧な言葉を削除する 「ほぼ」「おおむね」といった曖昧な言葉は論点がぶれるため用いません。

これも意識していきたい。続けると癖になっていくはず。

GitLabでは同じテーマに関して非同期コミュニケーションが三度往復するような場合には、
同期ミーティングに移行するように推奨されています。

非同期で解決しなければサクッとオンラインでMTGしちゃうのが良い。

心理的安全性とは、「チームの他のメンバーが自分の発言を拒絶したり、罰したりしないと確信できる状態」を指しています。

よく誤解されますが、心理的安全性とは「生ぬるさ」を指しているわけではありません。
どんな発言をしても、「無知・無能・邪魔者・ネガティブ」だと扱われないと信じられるだけであり、
高い成果に対する責任は求められることになります。

これを醸成するためには、これを実際に体験することが必要である。
「他人がして欲しいと思う行為を、他人に対してせよ」という観点が重要である。

尊敬と信頼がある状態で、前進するための会話に躊躇が発生しないってことだね。

意見や成果物は客観的な視点で公正に判断されるべきであり、
それは個人の人格とは別の次元で議論しなくてはならないのです。

これは何度も何度も出てくる考え方。何度も書きたい。

たとえ反対意見を持っている人であっても、決定事項であれば実行され、
検証されるまではコミットして全力で協力しなくてはなりません。
検証で明らかになったことこそが正しい事実であるため、
もし間違っていたならば次は違うやり方を試せばいいのです。
ここに人の優劣や恨みなどといった感情は入りません。

これね〜。ウメハラ味を感じる。
みんなでこの考え方で進んだら最強だと思う。

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

フィードバックをするためには、日頃の関係性構築が重要で前提ってことね。
途中から関係性を構築する場合を考えると、最初のコンタクトの重要性が際立つね。

特にネガティブなフィードバックはドキュメントとして書き留めとくことが重要です。

そのフィードバックに前向きな意図が込められていることを忘れないようにすることが重要です。

ドキュメントか〜。一瞬どうかな？って思ったけど、やっぱり良いかも。
振り返ったり、過去発生した内容を誰かに伝えることもできるし。

Gitlabでは、会社の状況を左右する重要な人材を「key talent」として認定を行い、管理します。

こういうのも明言されているのが凄い。Key Talentはしっかり管理する必要がある。

GitLabでは成長力を測定するために、次の4つの視点から見極めるフレームワークが存在する。
1つ目が「適応性」と呼ばれる、新しいスキルを学んで活用し、困難な状況でも成功する意欲と能力です。
2つ目が「拡張性」と呼ばれる、自分の領域外へと責任を拡張する性質です。
より複雑で、影響力が大きく範囲が広い役割を引き受ける意欲と能力によって計測できます。
3つ目が「一貫性」で、効果的な問題解決能力を有しているかという視点です。
最後が「セルフアウェアネス」と呼ばれ、自らを内省し、客観的に見つめる能力です。

最後が特に刺さった。最近の自分がまさにこれを感じている。
色々と内省して、自分を変えていくことで組織に適合したり、長期的な成果創出に重要だと思う。

サクセッションプラン(後継者計画)はリスクを軽減するだけでなく、
将来を担う優秀な人材の維持と能力開発による事業成長の推進という役割も果たします。

この観点も重要だよね。後継者の育成も意識したいなぁ。

現在、Googleではプロジェクトで明らかになった行動をマネジメント能力の開発に活用しています。
具体的には、部下の指導、意思決定、コラボレーション、ナッジ、モチベーション管理、
成果重視の姿勢、コミュニケーション、L＆D、ビジョンの共有といった行動を
チームに適切に提供できるようにノウハウやトレーニングを提供しています。

マネージャーになろうとする人間として、この項目は覚えておきたい。

リーダーがメンバーのパフォーマンスを十分に発揮させるためには、
マネージャーは価値観や性格の異なるメンバーやパフォーマンスが出ていないメンバーに対しても
積極的に関係性を構築する必要があります。

全員で成果を出していくのがマネージャー。
急成長を導くマネージャーの型 ~地位・権力が通用しない時代の“イーブン"なマネジメントですな。

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

これもあるよね。目的ではないけど、計測可能な重要KPI。

よく言われるように、「良い問が立てられていれば、問題は半分解決している」のです。
こうした状態を目指すために、Gitlabでマネージャーが良い目標を立てるために
活用しているフレームワークがSMARTです。
specific(具体的)
measurable(計測可能)
achivable(達成可能)
related(経営目標との連結)
time-bound(時間の制約がある)の頭文字を取ったもの。

目標設定の時に改めて思い出したい。

クルーシャルカンバセーション(重要な対話)とは、1つ目は、意見が異なっている場合(反対意見)です。
たとえば、メンバーが自分は昇格に値すると感じているが、上司はそう思っていない場合です。

2つ目に、重要な結果を伴う場合です。
このままでは目標が達成できないときに、何か新しいことに挑戦しなければならない際の会話がこれにあたります。

最後に強い感情が伴う話し合いです。
たとえば、本人は自覚がない状態で横暴な態度を取っていると指摘されたとき、
カッとなって言い返すシーンを想像してください。

こういうシーンでの会話が苦手だけど、イメージしておいて備えたい。
急にこういう話になるのではなく、日頃からこうならないように会話していくのが重要って散々上で出てる。

フィードバック内容が送られた人が現実的に実行可能な内容になっているかチェックします。
次にSBIモデルを用いて解釈の余地が少ない明瞭さを持っているかを確認します。
そして、フィードバック内容がマネージャーが言いたいことを伝えるだけではなく、
相手の役に立つ内容になっているかを受け手の立場から考えてみます。

最後の「相手の役に立つ内容になっているかを受け手の立場から考えてみます。」ってほんと大切だよね。
小さめなフィードバックをあえて実施して、練習していこうかな・・・

ネガティブ、ポジティブいづれのフィードバックであっても、最も効果的に機能するのはフィードバックすべき事象が起きた直後です。

刻む。