コロナで閉じ込められていた頃、誰もがバーっと眺めたことのある、あのGitLab文書。それに魅せられた著者がリモート組織についてまとめてみた本。元の文書は3000ページにも及ぶらしいですね。…それって、誰も読んでないのでは？ という疑惑というか確信というか。3000ページの本を読破できる人は多くない。しかも英語。オレなら、約100%の確率で、読まないね。今なら、これを読み込ませたLLMが聞かれたことに答えればいいんだろ？ 知ってんだよ。

というわけで、いわゆる「まとめ記事」であるこの本を読む動機ができたってわけ。

非同期コミュニケーションの特性をうまく使ってチームを、組織を成り立たせていく。プロダクトとして見ると、正直GitHubに比べてGitLabが使いやすい部分は少ないけど、基本機能は問題ないし一部はGitHubにない機能もある、という感じ。GitHubはMSに買収されてからかなりパワーが増したからなあ。カネの力はとても強いもので。あとブランチの使い方でGitLab flowというのがあるけどこれがクソで、シンプルなGitHub flowのほうが格段に優れている(異論はあるだろう)。でも最初のGit flowよりはマシか。GitLabのロゴ問題(自称タヌキだが、どう見てもタヌキじゃない)にも終止符が打たれるのか！？

話を戻そう。非同期コミュニケーションだ。

自分の属する組織と比べると、やはり非同期コミュニケーション前提にはなっていない。ていうかアジャイル開発でスクラムとか言ってる人は全員アウトじゃないかな。スクラムイベント(打ち合わせ)多すぎるので。毎日あるやつと、毎スプリントあるやつと。それぞれ、割と長い。スクラムは同期コミュニケーションが基本になるフレームワークと言えると思うし、完全なる非同期コミュニケーションでは成り立たない。物理的にはリモートでもイベントやれるけどねえ。デイリーなんて時間は短いにしても毎日、同じ時間に会話に現れなければならない。イベントの時にチーム内で同期が取られるので失敗しにくい、というのがスクラムのミソなのだ。

あとは文書化の鬼、というところは特徴的ですね。聞かなくても読めばわかる、セルフサービス化。重要ですが、量が増えると辛いのと、これ苦手な人がいるんですよねえ。文章を書く/読むこと自体が。実際に。私は、上手いか下手かはともかく、文章を読み書きするのは好きですよ。そういう人間なら、まあまあやってけるんじゃないかな。

Key Talentの運用も興味深いものがあった。会社にいますよね、いなくなると広範囲に困りそうな人。自分はそういうタイプでもないんですが、そういう人の重要性も言語化されていると安心がある。後進の育成がKey Talentの業務に入るのも合理的だ。disagree, commit & disagreeみたいなのも言語で表現されているのはいいと思うね。