GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック（後編）。デブサミ2022

2022年2月に行われたイベント「Developers Summit 2022」で、GitLab社で働く伊藤俊廷氏と佐々木直晴氏が実際の体験を基にした働き方についての講演「GitLab社で学んだ最高の働き方」を行っています。

実際にオールリモートで働く二人の講演内容は、多くの示唆に富むものになっています。ここではその内容をダイジェストとして記事化しました。

この記事は前編と後編の2部構成です。いまお読みの記事は後編です。

1on1のアジェンダ例

これが実際に、私とマネージャーの1on1（一対一のミーティング）のアジェンダ例です。1時間やっています。

私のマネージャーのアジェンダの特徴として1個目に雑談と書いてあるので、アイスブレイク的にも雑談を毎回議題としてやっています。お互いの趣味のことだったりプライベートのことを共有し合ったりしてます。

一番最後には何でも相談コーナーもアジェンダとして用意されています。

次は、我々ソリューションアーキテクトチームが毎週やっている打ち合わせのアジェンダの例ですね。

ポイントとしては、出席してない人のために「レコーディングボタンを押す」ということが書いてあったりですとか、事前に共有事項を記入しておこうとか。すると、みんながさらにフィードバックを事前に書いてくれたり。

ミーティング中にも書いてくれることがありますし、フィードバックがあることでモチベーションにつながることがあります。

決定事項とかアクションが決まれば、Google Docsの機能でアサインしてToDoにする、ということも、その場でやります。

カメラはオンにしよう

ここまではミーティング全般のことを紹介してきましたが、ここからはリモートでやる場合のWebミーティングの注意点を紹介します。

まず1点目にお伝えしたいのは、カメラはデフォルトでオンにしましょう、ですね。

いろんな理由でそうした方がいいと思っていますが、特に、リモートしかできないような環境下では、普段は非同期でコミュニケーションすることが必要なのですけど、ミーティングではちゃんと顔を出して接触の機会を増やすことによって、その後の非同期がやりやすくなると考えています。

それから、カメラがオンの方が、表情やボディーランゲージで伝わる情報が増えることがあります、特に英語が第一言語でない場合には、これがかなり重要だったりします。

また、お客さんと相対する場面では、カメラをオンにしないのはプロフェッショナルではないのではないかと個人的には思っています。

より効果的なのは、リーダーやマネージャーが率先してカメラをオンにすると、他のメンバーもやりやすくなるというのもあるかなと思います。

それから、良いWebカメラを買えば経費精算できるような状態にすると、みんなWebカメラを使いたくなってオンにする率が高くなるかとなとも思います。

これまで社内で助けを求めて助からなかったことがない

気持ちよくメンバーとコラボレーションするには。

まず、ジョブディスクリプションを超えた動きの紹介です。

自分はGitLabに入社して7カ月ぐらいで実務もそれなりにやってきた中で、これまで何か困ったことがあったとき、そこに助けを求めやすいような雰囲気があって、しかも助けを求めたときに助からなかったことがないんですね。

必ず誰かが、「こうしたらいいよ」って答えてくれたり、もしくはその人の担当範囲ではないけど「このSlackのチャンネルで聞いてみたらいいかも」とパスを投げてくれたり、誰かが必ずしてくれるんですね。

Twitterでも見かける発言として、「メンバーシップ型雇用」の方が助け合いが生まれやくて、外資系企業のような「ジョブ型雇用」だと、自分の仕事が終わったら他の人の手伝いなんてしないから結構ギスギスするんですよね、と言われていますよね。

私は、そういうこともあるのかなと思いつつ、ちょっと違う面もあるのかなと考えてます。

というのも「ジョブ型雇用」が、「タスク型雇用」みたいなものと混同されているのかもしれません。

ジョブ型雇用で会社から与えられるのはタスクではなくて、ビジョンとか責任が与えられるのではないかと思います。

ここに弊社の「フロントエンジニア」と、フロントエンジニアで職位が一番が高い「スタッフフロントエンジニア」のジョブディスクリプションがあります。

例えばフロントエンジニアのジョブディスクリプションには「○○を開発します」というものも、もちろんありますが、「チームに協力します」とか、「チームに新しく○○を貢献します」とか、タスクではなく責任や役割が定義されてるのがジョブ型なのかなと思います。

そして職位が高くなると、ほとんどの責任にチームという概念が入ってきます。

もちろんフロントエンジニアとしての専門性も高まっていくんですけど、全体の成功責任というか、コラボレーションをどう起こしていくかを、より求められていく。そういうジョブディスクリプションになるので、自分のタスクが終わったら終わりということにはならないのかなと思います。

こういうジョブディスクリプションが書かれていて、これができる人たちが集まってるからこそ助け合いができているのかなと考えています。

そして成長性というか、自分がどこまで領域の外に関心を示して、人を助けたりチームに貢献するかが実際にこの評価の一部になってます。そこも評価のポイントかなと思います。

オールリモートのマネージャの役割

オールリモートで働いていると、つねにマネージャーが側にいて、次はあれやってこれやってという指示はないので、チームが自律して自走できる必要性がより高まってくると思います。

自分たちでやることを決めたら、あとは非同期でそれぞれのメンバーがやることをやって、また集まってそれがどうだったかを考え、これを繰り返す。

この流れが滞りなくスムーズに流れていくようにするのがオールリモートでのマネージャーの役割なんだろうなと、自分はマネジメントを受けてそう思います。

例えば我々はアジアパシフィック（APAC）のソリューションアーキテクトのチームに所属しています。チームには8人ぐらいのメンバーがいて、この人がマネージャーのエイドリアンですが、この人がこうみんなに「今週どうだった？」とかミーティングで聞きます。

でも彼は、お客さんと何回打ち合わせをしたかや、それで売り上げが何ドル上がったか、などのノルマを課したり管理することは全くしてなくて、私たちがちゃんと価値を出せてるのかどうか、自己研鑽などをする時間があるか、楽しいか、滅入ってないか、なんていうことを話しています。そういうスタイルのマネジメントなんだなというふうに考えています。

マネージャーとの1on1も、週に1回1時間やっています。

さきほどアジェンダも決まってると言いましたが、雑談が多くて、昨日はスシを食べに行ったよ、シドニーにもスシはあるんですね？ などの話をして、そこから今週のお客さんはどうだったとか、資格取得おめでとうとか、経費精算は忘れないようにとか、普段の自分のデイリーの仕事にかなりフォーカスして話をしてくれる印象があります。

メンバーの理想の状態とか、自分がどう働きたいとか、どういう仕事をしたいかを分かってくれているから、週1回話すことができるのかなと思っています。

チームには7人のメンバーがいるので、マネージャーのエイドリアンは1on1だけで週7時間使っているってことになります。これが多いと感じるか少ないと感じるかは人それぞれだと思いますが、少なくとも1on1を半期に1回しかやらないのは、正直少なすぎると思います。

よくあるのは、この4月に上期の目標を決めて、上期が終わったら、上期のあなたはこれをやって偉かったよとか、もっと改善が必要ですね、みたいなことを言われる。結構ビッグバンリリースっぽい評価になって、いやなんか全然自分の仕事を知らない人に勝手に評価されて、なんかアレなんですが、みたいなことになりがちですよね。

ですので、自律した仕事をしてもらうには、綿密にしっかりとメンバーの仕事を把握する、そういうスタイルが必要なのかなと思いますし、ここはすごくマネジメントされて心地がいいかなと感じてます。

公開称賛をするための制度

「公開称賛」は造語なんですが、みんなの前で成果を共有して認め合い褒めるっていうことを、我々は大事に思っています。

その結果、お互いに認め合う文化になりますし、他の人の仕事を想像するきっかけにもなっているかなと思っています。

そのための仕組みが3つほどありますので、それを紹介します。

1つ目。これは文化的なところに依存するかもしれませんが、マネージャーがとにかくよく部下を褒める。

とにかく何かあればSlackで成果を共有して、ありがとうって言ってくれたりですとか。メンバーとしては、そうしてもらうためにいろんな成果を集めなきゃいけなくてそこが大変だったりするんですが。しかも超ハイテンションでいろんな文字を使ってやってくれる、というのがGitLabのマネージャーのやり方ですね。

2つ目。これは制度的なものですが、ほかのメンバーの成果を称賛し推薦することによってボーナスが出てくるという制度があります。

私はこれで去年2000ドル稼いだんですけど、お金が重要というわけではなくて、こういった制度があることによって、推薦されて認定されると嬉しいですし、他のメンバーのいいところを探そうという力学ができると思います。

認定の基準も、ジョブディスクリプションの期待以上という記載がありますので、ここもそういうことが推奨されているというのが分かると思います。

最後の仕組みは、#thanksチャンネルというのがありまして、このように日々、皆さんがありがとうを伝えています。

これは普通のSlackのチャンネルでも言うんですけど、特別な場所にすることで、言いやすかったり、改めて言っていい、という雰囲気にすることができますので結構おすすめです。

できなくてもOK、そこに悪意を見出さない

ここで紹介したカルチャーやTipsは、GitLabの全員が全員、全部できているかというと、そういうわけでもありません。

新しく入った人とか、IT系の仕事ではない人だと、Zoomの使い方とかSlackの使い方が分からないことはよくあります。

そういう人がいても我々としては全然OKで、「できてないよ」って指摘するよりも、画面共有をして教えたりとか、「出来ない人がいたら今日みんなでやりませんか？」って感じでみんなで一緒にやってやれば、いい雰囲気で一斉にできるようになるので、そういった形でやってます。

おすすめする価値感として「Assume Positive Intent」という、直訳すると「ポジティブな意図を前提とする」みたいな感じになるのですが、誰かが失敗したりできてなかったとしても、そこにありもしない悪意を見い出すのはやめよう、という考え方です。悪気があってやるわけじゃないし、みんなができるようになればいいという、そういう価値観です。

まとめ

最後はまとめです。今日ご紹介したものをTips的にリスト化しました。

これを最高の働く環境を得るためのマニフェスト、と呼ぼうと思います。

会社の仕組み的に、やりやすいものと、難しいものがいろいろあると思うんですけれど、ひとつでも持ち帰っていただいて、自分たちの環境をより良い状態に変えていっていただければと思います。

今日はご清聴ありがとうございました。

公開されている資料

• GitLabで学んだ最高の働き方 Developers Summit 2022-02-18

（その後GitLabの発表者の2人に確認したところ、初版の資料で誤解される可能性のある箇所についてのアップデートを近々行うとのことです）

追記：資料がアップデートされました。

反響が大きかった「GitLabで学んだ最高の働き方」について、@naoharu とアップデートを行いました！https://t.co/zKyVoa6bs1
主な変更点：
- 紹介内容の前提追加
- マニフェストの多言語化
- Donutの紹介
- コミュニケーション手段にHandbook追加
- Email、Slackの説明増強
- 非同期に関する補足

— Toshi (@toshihue) April 4, 2022