「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」を読んだ前編
前提と概要
自分はフルリモートな会社で働いている
出社は月に1度あるかないかぐらい
GitLabの本を読んだ
情報量が多く、気になったハイライトを整理したい
自分の言葉に置き換え咀嚼して、自分の行動に組み込みたい
後半
GitLab Value
GitLab Valueは、「コラボレーション（Collaboration）」「成果（Results）」「効率性（Efficiency）」「ダイバーシティ＆インクルージョン、ビロンギング（Diversity, Inclusion & Belonging）」「イテレーション（Iteration）」「透明性（Transparency）」の６つで構成されています。
複数のValueがぶつかり合うケースも発生します。セキュリティ上の問題が発見されたとき、透明性のValueに基づくと一刻も早く公開するべきですが、何も考えずにセキュリティの弱点を外部に公開してしまうと、それを悪意ある人物が利用することでユーザー全体を大きな危険にさらしてしまうかもしれません。こうしたValueが衝突するときにどのような順番で考えるべきかの参考として、Valueのヒエラルキーが用意されています。
GitLabではValueを大事にしている。ぶっちゃけ自分は会社のValueを咀嚼して具体的な行動まで落とし込めてないし、そもそも全部を諳んじて言えない。文化醸成までのコストはかかるだろうが、こうやってValueを大事にしてかつそれを行動まで落とし込めているのは社員同士の目線が合うだろうし良さそう。
コラボレーション
他人から見られているときにシンプルな作業は大幅に効率が上がるが、複雑な作業の効率は下がるという「ソーシャル・ファシリテーション」や、集団で共同作業を行う際に１人当たりの生産性が人数の増加に伴って低下する「リンゲルマン効果」などが存在します。
例えばリリース作業のような定型的な作業は他人と一緒に複数人で実施、複雑な設計や調査はまずは1人で実施するのが良さそう。
ダイバーシティ&インクルージョン、ビロンギング
ダイバーシティは実際に組織に多様性が存在していること、インクルージョンは所属しているすべての従業員が活躍できるという方針の確約、ビロンギングはその結果として従業員に生まれるものだと捉えると良いでしょう。
インクルーシブな会議
出席者全員が自分の見解を説明することで、会議に主体的に参加してもらうことはリモート環境では特に重要です。社内会議では事前アジェンダを書いたドキュメントを使用して、あらかじめ質問を記入してもらうようにします。質問は会議中に順番に回答され、ドキュメントに議論を記録するようにしています。
出席者全員が自分の見解を説明するって大事だけど全然出来てないなと思って刺さった。自分が出席する会議は何かしらコメントや意見を出すようにしているけれど、全部はできていない。他の人はコメントしないままの人も多く居て、全員が見解を説明できるような仕組みに自分の組織はなれてないと感じる。
GitLabは昔の外資系戦略コンサルタントでいわれていたようなUp or Out（昇格か退職か）という、限界まで成果や成長に取り組まないメンバーは不要であるという考え方は採用していません。役割に求められるパフォーマンスを発揮しているのであれば組織にとって貴重な戦力であり、また本人が望んでもいないのにより大きな役割を強制的に求めるのはインクルーシブであるとはいえません。
会社は人間を成長させたがりがちなの分かる。実際問題それなりに働いて成長を求めない人は一定数いる。
コミュニケーション
形容詞をデータに置き換える 「ほとんど」や「大多数」といった表現を、「全体の95％」など具体的な数字に変更します。 曖昧な言葉を削除する 「ほぼ」「おおむね」といった曖昧な言葉は論点がぶれるため用いません。
こういう言葉めちゃくちゃ使ってしまう。この「めちゃくちゃ」も曖昧な言葉だ。。
人格についてではなく、具体的な仕事内容について提案します。「あなたは私の意見を聞かない人である」というのではなく、「デザインに関する私のフィードバックに対して返信がなかった」と伝えましょう。また、フィードバックを送る際には、相手を非難するためではなく、パフォーマンスを向上させたいという目的を最初にしっかりと伝えるようにしましょう。
次にフィードバックをする際には「SBIモデル」を活用するようにします。SBIモデルとは状況（Situation）- 振る舞い（Behavior）- 影響（Impact）を組み合わせて伝える方法です。たとえば、「今週月曜日の営業会議であなたがAさんの発言に対してリアクションするときに（S）、あなたは腕を組みながらみんなの前でAさんに対して“なぜこんなこともできないのか？”と発言しました（B）。失敗をみんなの前で責められると、他の人が問題を表明しづらくなってしまい、改善の機会やリスクに気付けなくなってしまうと感じた（I）」という形で活用します。
影響に関して説明する際には、決めつけるのではなく「自分は感じた」「自分からは見えた」というように、個人としての見解を伝えます。
フィードバックの言葉遣いは難しい。こういった言い回しを適切に使える人になりたい。youメッセージじゃなくてIメッセージ。自分を主語にしてどう感じたかを伝える。
会議
すべての会議ではGoogleドキュメントによるアジェンダが添付されている必要があります。会議の主催者は、最初に１～２分間でポイントとコンテクストを要約して説明できますが、プレゼンテーションであってはいけません。プレゼンテーションを行いたい場合には、YouTubeで録画済みの動画を作成し、会議までに動画に目を通してもらえるように進めます。質問がある場合には、前もってアジェンダに質問を記載しておきます。
事前にプレゼンテーションを録画するは非同期コミュニケーションを徹底しているなと感じた。非同期の練度を高めないとコストのほうを感じて難しそう。
会議では相談ではなく、具体的な内容に踏み込んだプロポーザルを行うようにします。
この考えは大事。何かの相談を聞いていて「で、あなたはどうしたいの？」「あなたはどういう意見なの？」と思うことが多々ある。「相談ではなく提案をする」というのが組織レベルで共通認識を取れている状態を目指したい。
意思決定
「データ収集」と「意思決定」というプロセスを明確に分離し、データ収集をする際にはコンセンサス型のビジネスプロセスを行い、意思決定をする際にはヒエラルキー型のプロセスを実行する形です。
ジョブスみたいな独裁はスピードはあるが、反発を生むデメリットがあると思っていたけれど、こういうふうに情報収集と意思決定プロセスを分離するというのは組織としてうまいやり方だと思った。
休暇
休みを取らない人の業務が単一障害点になってしまう
このような属人性を高めるような振る舞いは、GitLabのようなグローバル企業では「知的謙虚さに欠けている」とみなされており、休暇を取らないことや長時間労働を自慢するようなことはやめるようにいわれます。
GitLabの場合は、１年間で少なくとも連続した２週間、合計で25日以上の休暇を取ることが推奨されています。
人間をシステムのように捉えているのは面白いし大事な考え方だと思う。2週間も休みを取ればその人が居ない状態で仕事をどう回すかを考えないといけなくなり、属人化が減り強い組織になりそう。
GitLabではしっかりとした休暇を取るために、どのようにチームメンバーに通達するかといった点にも工夫が見られます。たとえば、休暇を取る前には休暇取得する予定の日取りから数えて、休暇日数の２倍以上前にチームに通達をしなくてはなりません。つまり10日間休暇を取るのであれば、遅くとも20日前にチームメンバーに知らせます。
こういう細かい数字も決められているの良い。
この記事が気に入ったらサポートをしてみませんか？