こんにちはこんばんは。スクラムマスターの いのもえ です。普段はフルリモート環境で LeSS のスクラムマスターを担当しています。
9/11 に発売された「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」 を読んで、考え方の違いや取り入れ方について考察してみました。

GitLab に浸透している考え方

ハンドブックファースト

GitLab では社内あらゆるルールをハンドブックにまとめているそうです。以下の URL から、誰でもアクセスすることが出来ます。

このハンドブックの扱いについて、書籍にわかりやすい説明があったので引用します。

実際にハンドブックを読んでみると、かなり重厚であらゆることが書いてあります。書籍によると、このようにすべてをドキュメント化することによって以下のメリットを享受しているようです。

時間的なコストを効率化できる
「わからないことがあって誰かに質問する」というシチュエーションを例に、要する時間コストについて考えます。
仮に質問してから 5 分後に回答を得られるとして、 1 回あたりにかかる時間的なコストは (質問者 1 名 + 回答者 1 名) * 5 分 = 10 分 かかることになります。
このようなシチュエーションはありふれており、同じような質問が複数回発生することや、質問する前に「誰に質問するのか」と悩んでいる時間などを加味すると、時間的なコストは無限に増大していくことが予想できると思います。
こういった際に、最新化された唯一のハンドブックがあればそこを自分で参照するだけで済むためコスト削減につながると言えます。

心理的安全性を高め、従業員の自律的な行動を促す
ハンドブックに書いてあることが全てですから、従業員は「自分が間違っているかも」「攻撃されてしまうかも」と怯えることが減ります。
ハンドブックにはコミュニケーションにおけるマインドセットにも明記がありますから、「相手に悪くとられてしまうかも」というのも心配無用です。
このような環境であれば心理的安全性は高まるし、自律的に行動することもできるようになります。

非同期コミュニケーションをデフォルトにする

GitLab の特徴の 1 つとして、世界中の色んな場所の人々が協働しているという点があります。これにより、時差による勤務のズレや公用語の違いによる意思疎通の壁などが発生します。
こういった課題を解決するために、 GitLab では公用語を英語にし、非同期でのコミュニケーションをデフォルトにしているようです。
ハンドブックの中では、「チャットツールを利用する」というよく見かけるようなものや、「プレゼンテーション型の会議は開かない（プレゼンテーション型の場合は事前に動画を収録し展開しておく）」などあまり見かけないものもあるようです。

書籍によると、同期コミュニケーションにも重要性を見出しているようです。ただし、「同期的にコミュニケーションするのであれば時間的なコストの観点から最低限にしたほうが良い」というようなメッセージがあるように感じました。

インフォーマルコミュニケーションを重要視する

「社会的受容」が従業員の退職リスクを減らしたりパフォーマンスを向上させることが示唆される研究や、「心理的安全性」などの観点から、各従業員が安心して過ごすことができることがパフォーマンスに影響があることは理解されているようです。ここまでを読むと「法律ハンドブックを守らないと怒られる組織」と少し怖い印象を抱きますが、それだけでは従業員のパフォーマンスが上がらないため、インフォーマルコミュニケーションについても重要視され、組織づくりの設計にも取り入れられているようです。

インフォーマルコミュニケーションについては先日のイベントでも触れられていました。

取り入れると良さそうと思ったこと

考え方や価値観をまとめた資料を作っておく

GitLab におけるハンドブックのような、社内で活動するにあたって考え方の前提をまとめておくのは非常に有用そうだと感じました。
6 章で出てくる「コミュニケーションガイドライン」や「SAFE フレームワーク」はフルリモート環境ではあると助かると思います。

ハンドブックを作るぞ！となると、実際の LeSS の進め方（今やってること）などについても記載しておく必要が出てきそうですが、それらについてはまとめておかないほうが良いと考えています。
とういうのも、 LeSS では完璧を目指して継続的な改善を推奨していますから、不完全な状態をこのような資料にまとめることで「この状態が正常だ」と誤解されるのは不適切ですし、良い状態を書くのであればスクラムガイドなどを貼れば良い事になってしまうと感じます。
この辺は賛否両論ありそうですね 🤔 議論のネタとしては楽しそうです

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

先日のイベントでも、「設計しなければインフォーマルコミュニケーションはなくなってしまう」というのが印象に残っていましたが、書籍を読んで更に「設計しなくては」という思いが強まりました。
現在は個人の社会的受容を明らかにする仕組みが無いのですが、例えばそれを可視化して定点観測するだけでもまずは価値がありそうです。

ちょっと合わないかもと思ったこと

非同期コミュニケーションをデフォルトにする

GitLab の通りに実行すると、 PBI はかなり詳細に書かねばならず、スクラムイベントの議事録もかなり細かく残す必要が出てくると予想しました。
これにより、スクラムイベントの参加者が「議事録を書く」という行為に集中してしまい、スクラムイベントの価値を活かせなさそうだと感じます。
また、変更の理由を詳細に書くというのも、スクラムや LeSS では必ずしも必要ではない（変更が必要だと思ったらもとの理由に関わらず変更すれば良い。気軽に変更できるのが利点の一つ）と感じており、それ故に議論の結果のみが書いてあっても大きな問題ではないと思ってしまってます。共有についても、参加した人からしてもらえば良いんではないでしょうか。

一方で、リモートワークには非同期コミュニケーションがデフォルトな方が働きやすそうだとは思ってしまいました。プロダクトを複数人で開発するにはスクラムや LeSS の考え方はシンプルで好みだと感じるところは多く、コミュニケーションスタイルについてはこれからも塩梅を探るのが必要だと強く感じました。

まとめ

GitLab Handbook の存在とざっくりのイメージはあったのですが、書籍を通してより解像度が上がりました。非常に刺激的で面白かったです！
GitLab といえばフルリモートで成功を収めている企業というイメージが強かったので、 LeSS と考え方が合わないかもと思ったときには正直ちょっと困ってしまいました。

フルリモートの働き方は気に入っているので、今後もより心地よいプロダクト開発体験にするにはどうしたらよいか、引き続き考えていきたいと思います！