紹介された本はなるべくその場で注文して実際に読んでみる、というのを実践するように心がけています。この本もそうやって紹介されたので、すぐに買って読んでみました。
当たり前ですが、単にリモートワークにすれば全ての問題が解決する、業績が上がる、リモートワーク最高！という内容ではありません。
この本の中心は、GitLab社が作った「GitLab Handbook」をベースに、組織の価値観、それをベースにした仕事のやり方、評価のやり方を定義、可視化することで、よりみんなが満足して、より高い成果を出すための環境作りの方法が解説されています。
- GitLab社はオールリモートで運営されていて、2,000名を超える従業員が特定のオフィスを持たない
- 仕事のやり方は、3,000ページを超える「GitLab Handbook」にまとめられている （3,000ページというと驚くけど、ちょっとしたコミュニケーション主体のタスクをルールに書き起こしてみるだけでも簡単に10ページとか行くので、逆に「少ないな」くらい思ってしまった）
- コミュニケーションが円滑にいくためのガイドラインやツール選定の方針などが書かれている
GitLab Handbookは、以下のサイトにすべて公開されています。
仕事のやり方を作るためにはそれだけの手間をかけて、「設計していく必要がある」、ということなので、「じゃあ明日からそのGitLab Handbookの通りに仕事をやってみよう」と始めてもきっと上手くいきません。
詳しくは本を読んでください、GitLab Handbookを読んでください、としか言えないのですが、なかでも特に良かった箇所は以下の二つです。
経営陣のデフォルトリモートにする
現場のマネージャーでも同じですが、「意思決定をする人の影響力」はやはり無視できないので、この層の人たちが率先して実践することで組織が変わるのは間違いないですし、逆にいえばこの層を変えないで組織は何も変わらないですからね
リモートワークに共通して発生する問題 働きすぎる
『リモートワークの達人』でもこれがすごく強調されていました。仕事と生活の境目が曖昧になり、物理的な出社・退社という区切りが無くなることで、際限が無くなってしまい、働きすぎになり、最後はバーンアウトになってしまう...「成果」でしか測れないからこそ、そこにどれだけの「時間」を使っているか、ということに意識的にならないといけないわけです。
あと、この本を読んで特に思ったことは、自分で「GitLab Handbookに相当する文書が書けるだろうか？」という点でした。
意外と自分たちが普段やっていることを言語化することは難しく、それはきっと「言語化しなくてもできてしまっているから」からだと思うのですが、まずは「名前をつけること」で見えてくることがあります。
「名前をつけて」「その手順を定義し」「特性は何かを考え」「より良いやり方に昇華」させていく……これは完全に普段のプログラミングでやっていることそのものであって、決して特別なことではないのではないかと思います。
ただ、それが普段の自分たちの仕事のやり方になると、そこに投資することが後回しになってしまうだけで。
つまり、スケールさせたい組織は「仕事のやり方も常にリファクタリングが必要」という発想を持てるか否か、に尽きるのかなと。
書かれていることの本質は、10年前、コロナ禍に入る前に書かれた『リモートワークの達人』と変わらないのですが、世界中の色々な状況がアップデートされているのと、より実践されてきた結果が書かれている点が違います。
『リモートワークの達人』はもう少し”啓蒙書”っぽい雰囲気が強かったですからね。
すべての企業や、組織がこの本に書かれている通りのことを実践して、フルリモート組織になる必要は無いですし、できるわけもないのですが（物理的な制約はどうしてもありますから）、自分たちの仕事を振り返って、変えていくためのきっかけには良い1冊だと思います。とにかく後半の記載はどれも具体的だし、実際にやってみよう、という気にさせてくれますね。問題は、この本が散々強調している「ドキュメント化」の稼働が取れないことじゃないかと思いますが......
GitLab社といえば、昔、本番データベース障害からの復旧するまでの様子をストリーミングで生中継したのが印象的でしたね。
このオープンマインドがあるなら、確かにこの本に書かれている世界観に到達するなーと納得しました。
（でも心臓に悪いので、動画は見ていません！！）
