Forkwell Press | フォークウェルプレス

目次

SHARE

キャリアとスキルアップ

GitLabに学ぶ!第2弾「GitLabで学んだ最高の働き方」佐々木 直晴 × 伊藤 俊廷

GitLab Solutions Architect の佐々木さん・伊藤さんによる「GitLabの最高の働き方:特別セッション」をレポート。GitLab の日常や「The GitLab Handbook」の活用法、リモートワークを成功に導くための実践的アドバイスなど、GitLab流 リモートワークの極意を伝授します。モデレータは『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』著者の千田さんです。

【ちょっと宣伝】上級エンジニア特化のキャリア支援サービスをはじめました!

市場の変動がキャリアへの不確実性をもたらす昨今、これまで以上にエンジニアに寄り添いたいという想いから、上級エンジニア特化のキャリア支援サービスをはじめました。スポーツ選手のエージェントのようにエンジニアの立場で次のキャリアを提案いたします。一般的な転職エージェントのように募集中の案件を紹介するだけでなく、あなたの理想のキャリア実現に向けて、ニーズがありそうな企業へ交渉し、望ましい案件を創出する働きかけも行います。無料で利用できますので、お気軽にお申し込みください。

GitLabの最高の働き方

GitLabは、DevSecOpsプラットフォームを GitLab.comGitLab self-managedGitLab Dedicated を通じて、開発者に焦点を当てた全体的なDevSecOpsサポートソリューションを提供しています。60カ国以上にまたがる 2,000名以上の従業員を抱える世界最大のall-remote企業です。

最高な働き方をするためのマニフェスト

  • 同期と非同期のコミュニケーションの前提を考え直そう
  • 非同期で自律自走できるために、可能な限りタスクの細分化、明文化をしよう
  • Coffee Chatをしよう
  • コミュニケーション手段の使い分けを定義しよう
  • GitLabのHandbookのように、社内のsingle source of truthのハンドブックを構築しよう
  • ミーティングを持つ前に非同期でできないか検討しよう
  • Live Docs Meetingsの方式でミーティングノートを完成させよう
  • カメラはデフォルトでオンにしよう
  • 不必要なハイブリット通話はしないようにしよう
  • 自分の担当範囲(job description)を適切にはみ出してチームに貢献しよう
  • マネージャーは目標や成績の管理じゃなくて、メンバーの理想状態を保つようにしよう
  • 部下の成果を組織に共有しよう
  • 他人の成果に称賛しよう
  • Thanksを言おう
  • 上記がうまくできていない場合も、非難するのではなく教えてあげよう

GitLabでは、オフィスも優先タイムゾーンもありません。非同期コミュニケーションに偏重することで、ドキュメンテーションを促進し、同期ミーティングを抑制し、より柔軟性のある働き方を実現しています。さて、GitLabの最高の働き方をご紹介するにあたり、まずは資料の位置づけやリモートの定義を記載しておきたいと思います。

本レポートに使用する資料の位置づけ

  • 紹介する内容はリモートかどうかに関わらず参考可能な内容を意図している
    • オフィス勤務でも非同期の考えやコラボレーションは重要である
    • 筆者同士は対面でのコワークを定期的に実施し、推奨もしている
  • The GitLab Handbook」を完全に代表する内容ではない
    • 半分程度はGitLabのHandbookで記載される考え方の紹介
    • 半分程度は筆者の実経験に基づいている実践方法の紹介
  • どのような環境においても最適解となる絶対的なものではない
    • 顧客からのアジェンダのないミーティング依頼に対応することもある
    • 緊急性の高い要件であれば、同僚へ電話もすることもある
    • 重要な情報をイシューやHandbookへ反映できないこともある

The GitLab Handbookとは

The GitLab Handbook」は、GitLabのリモートワーク方法論とカルチャーをまとめたガイドで、透明性を重視して3,000ページ以上にわたりWebで公開されています。情報共有の効率化を目的として始まり、メールやチャットでの情報の繰り返し共有を減らすことを目指しています。誰もがマージリクエストを通じて修正提案ができ、過去の変更の記録が残ります。

リモートワークの定義

この数年リモートワークという言葉が独り歩きしていますが、皆さんが考えるリモートワークの定義はありますか? 例えば、次のようなシチュエーションは、オフィスにいるだけで非リモートと言えるでしょうか?

  • 自席の向かいに座るメンバーへメールやチャットツールでコミュニケーションをする
  • 対面ミーティングの不参加メンバーのために、ミーティングノートを残す
  • 新しい社内ツールの操作方法を学ぶために、録画済みのチュートリアルビデオを見る
  • 外出時、ホワイトボードに「外出中」のマグネットを貼る

オフィスでの作業が自動的に非リモートワークになるわけではありません。多くのオフィスワークは、他のチームメンバーと時間をずらしてコミュニケーションを取る非同期的な作業です。本講演内容は、広く本質的な意味でのリモートに着目するため、すべてのシチュエーションで活用できます。

GitLabが非同期コミュニケーションを重視する理由

GitLabが非同期コミュニケーションを重視する理由は、コミュニケーションの手段とタイミングの選択がリモートワーク環境での効率性と効果性に直結すると考えるからです。一般的なコミュニケーションスキルが相手の感情への寄り添いや傾聴技術に焦点を当てるのに対し、GitLabでは、情報の伝達に最適なコミュニケーション手段の選択も同等に重要視しています。しかし、この手段に関する議論や体系化はまだ発展途上であり、今後より議論が必要であると考えています。

詳細はこちら > GitLab:組織の自律自走を促すコミュニケーション

千田:非同期を前提にしつつも、早く返信が欲しいときってありませんか?

伊藤:そこは工夫するしかなくて、私の場合はSlackで返信がなくどうしても緊急な場合には電話しちゃいますね。Slackに急いでいることは書くので、何日も放置されることはありませんが、返信速度はやはり個人のSlackの使い方に依存しますよね。

佐々木:私も電話は使います。ただ、電話だとログが残らないので、本当に気づいてもらうためだけに使用しています。

コミュニケーション手段の使い分けを明確に

The GitLab Handbookでは、社内で使用するコミュニケーションツール(Email、Slack、GitLab Issues、Handbook、Google Docs、Zoom、Phoneなど)の使い分けが明確に記載されています。これにより、社内で一貫したコミュニケーションを取ることが可能です。複数のガイドラインがあると混乱を招くため、一つのハンドブックにルールを集約し、全員で共有することが重要です。

Slackの使い分けの例

  • 非公式な内容
    • 承認、決定事項の文書化、公式な文書には使用しない
  • 90日後に削除されるポリシーによる文書化の動機づけ
    • チャットツールは使い方によっては真の非同期文化を損なう可能性がある
  • 主に会社内部の情報共有、通知、簡単な質問などの用途
  • DM や Group Direct message は、非推奨
    • 可能な限りパブリックチャンネルに転送

伊藤:実はSlackのメッセージが90日で消えるんですけど、これが意外といい効果を生んでいるんですよ。特に非エンジニアの人たちが、Slackだけで済ませがちなんですが、この消える仕組みで、みんなドキュメントに書く文化に慣れてきてるんです。いいTipsですよね。

佐々木:それで、カジュアルな話も消えちゃうんですよね。「あれ、あのおいしかったラーメン屋、どこだっけ?」みたいな(笑)

千田:じゃあ、業務外の話とかは別のツール使うんですか?

伊藤:うーん、業務外の雑談にもSlackはよく使いますね。ラーメンチャンネルとかゲームチャンネルもありますね。

千田:そういったチャンネルも90日で消える?

伊藤:ええ、そうですね。でも、まあ消えたって業務にはあんまり関係ないですし。大事なことは別でメモしておきますけどね。

信頼できる唯一の情報(SSOT)の重要性

情報をどのように保存し、取り出しやすくするかはコミュニケーションにおいて非常に重要です。GitLabでは、信頼できる唯一の情報(SSOT:Single Source of Truth)という概念があります。これは、重要な情報が一箇所にまとめられ、誰でもアクセスでき、関連情報が一目でわかる状態を指します。

例えば、野球を例に取ると、特定の状況で選手がどのように行動するかは、ルールと現状を正確に理解しているかによります。すべての選手が状況を正確に把握していれば、自分の次の行動を決めることができます。逆に、現在の状況が不明確だと、何をすべきか分からず、ゲームは成り立ちません。

この例から、正確で一元化された情報があることで、各人が自律して行動できるようになり、全体がスムーズに機能するということがわかります。これが、信頼できる唯一の情報源の重要性です。

GitLabのドキュメント文化

GitLabにおける社内のコミュニケーション手段を下記のような表で表現しました。縦軸にSSOT的か散在的か、横軸に同期的か・非同期的かをひいています。例えば The GitLab Handbook は、非同期的であり、最も透明性の高いSSOT的な位置付けになります。

GitLabでは、左下の同期的で散在的なコミュニケーション手段を、右上の非同期的でSSOTな手段に集約していくことで、長期的に組織全体の効率性を高めることができるのではないかと考えています。このあたりを意識しドキュメント化していくと効率的な組織づくりのヒントになることでしょう。

千田:ちなみに、ドキュメント管理のアンチパターンってありますか?

伊藤:ドキュメントの管理って本当に大変で永遠の課題ですよね。 The GitLab Handbook は、アンチパターンを潰すために作られているものの、みんなで更新・編集する難しさは感じています。特に、マージリクエストみたいなエンジニア向けの概念が障壁になっちゃってます。でも Google Docs みたいなものにすると、今度はドキュメントがごちゃごちゃして、何が最新かわかんなくなるんですよ。フォルダの掘り方やドキュメントのネーミングルールも体系化していく必要がありますね。

佐々木:The GitLab Handbook は、各セクションに責任者がいるんです。だから、その人が内容を決めたり、整理したりするわけです。これがないと、すぐにごちゃごちゃしちゃうんですよね。

伊藤:ドキュメントのオーナーシップって大事ですよね。でも、誰でも意見は言えるようにしておくべきだと思ってます。そうすると、いいアイデアがどんどん出てくるんです。

千田:ドキュメントってどうやって探しやすくしてるんですか?

伊藤:自分は、検索結果を意識してファイル名をなるべく英語で統一してるんですよ。それだけでも、探しやすさは変わると思います。

千田:ドキュメントのルールに窮屈さを感じる人もいますか?

佐々木:採用の段階で、ドキュメントベースのコミュニケーションを理解してもらうようにしてますから、そういう問題はあまりないですね。技術的なことで困ってる人はいるかもしれませんが、そういう時は周りがサポートします。

同期 × 非同期、無駄なく効率的なコラボレーション

リモート環境では、「ちょっと今いい?」といった即時のコミュニケーションが難しく、多くのやり取りが非同期コミュニケーションに依存します。例えば、Slackのようなツールを使っても、実際にはリアルタイムで会話ができることは稀で、メッセージを送ってから返信を待つ形が一般的です。このため、非同期コミュニケーションを意識して効率的に情報を交換することが求められます。

ただし、これは同期コミュニケーションが不要というわけではありません。実際には、チームの認識を合わせたり、不明瞭な点を明確にしたりするために定期的な同期コミュニケーションは不可欠です。

特に重要なポイントで認識を合わせ、その後の作業を非同期で進める計画を立てることで、各自がより自律的に、そして効率的に作業を進めることができます。したがって、リモートワークでは同期と非同期コミュニケーションを適切に使い分けることが重要です。

GitLab式オンボーディング

同期と非同期コミュニケーションを効果的に使い分ける良い例をご紹介します。

GitLabでは、新入メンバーのオンボーディング(職場への適応プロセス)が上手に組織化されています。例えば、1日目に達成すべきタスク、2日目に取り組むべきタスクなど、最初の1週間の計画が明確に文書化されています。これにより、新入メンバーは自分のペースで仕事を進めることができ、必要なタスクを完了させた後は、他の活動に取り組む自由があります。最初に同期的なコミュニケーションを通じて、新入メンバーに何をいつまでに達成すべきかを明確に伝え、その後は非同期で彼らが自分のタイムラインと方法でタスクを進めることを可能にします。これにより、個人の自律性が促進され、柔軟で効率的な働き方が実現されます。

ちょっとした感謝を共有 #thanks チャンネル

GitLab は、素晴らしいオンラインコミュニケーションのために、いくつかのSlackチャンネルを用意しています。その中でも、GitLab チームメンバーが素晴らしい仕事をしたり、顧客を助けたり、あなたを助けてくれた時などに、感謝の気持ちを伝えることができる「#thanks チャンネル」は、良い雰囲気づくりのために非常に有効活用されています。

佐々木:GitLabには、自分がここにいてもいいんだ、と感じさせる帰属意識を高める仕組みがあります。例えば「#thanksチャンネル」がそうですね。自分が感謝されると嬉しいものですし、それが自分も他の人に感謝を伝えたくなる気持ちにつながります。このような文化が、GitLabでは醸成されています。

伊藤:確かに、「#thanksチャンネル」は常にアクティブ。誰かが自分に感謝を示してくれたら、次は別の誰かにその感謝を伝えたくなる、そんな前向きな連鎖が生まれていますね。

Coffee Chatでカジュアルなコミュニケーションを

非同期コミュニケーションのみでは、相手の性格や考え方など  “人となり” を深く理解することが難しい問題があります。GitLabは、このような問題に対応するため「Coffee Chat」という制度を取り入れています。この制度は、特別な議題を設けず誰でも気軽に他の人に声をかけることができます。このような日常的なやり取りの中から新たな仕事のアイデアが生まれたり、チーム内の人間関係が深まることがあります。Coffee Chatは、非同期コミュニケーションが主流のリモートワーク環境においても、人と人とのつながりを大切にし、創造性や協力関係を促進するための有効な手段として活用されています。

千田:Coffee Chat は強制ですか?

佐々木:いえいえ、参加したい人だけでOKです。ただ、入社時のオンボーディングでは、5名以上との Coffee Chat がタスクに組み込まれています。

千田:相手はどう選ぶのでしょう?

伊藤:ランダムに相手を見付けて予定を入れてくれる Donut というSlackアプリを使っているメンバーも多いです。もちろん、自分で相手を選ぶこともできます。

千田:全然知らない人とマッチングしちゃったら?

伊藤:そういうこともあります(笑)私の場合は、事前にLinkedInやSlackのプロフィール見たりしますね。だいたい海外の人とマッチングすることが多いので、GoogleMapsを出しながら、お互いの家の付近を見ながらすると盛り上がります。

佐々木:私も自分のインスタアカウントを見せながら話したりします。やっぱり、お互いの国の文化についての話が盛り上がりますよ。例えば、餅つきの写真を見せて「この木のハンマーとバケツは、どの家庭にもあるのか?」と質問されたり(笑)

ミーティングは必要なのか?

ミーティングは参加者の時間を要するコミュニケーション手段です。そのため、できる限り開催を避け、必要な場合には明確なアジェンダを設定することが望ましいです。ミーティングの開催を検討する際には、その目的と効果を再評価し、効率的な代替手段がないかを考えることを推奨します。 The GitLab Handbook では、ミーティングの断り方 や、3回以上、非同期の手段でやり取りをしたらミーティングを検討することが明記されています。

▲会議の参加者は協力してドキュメントを残す文化

No agenda, no attenda

また効率的なミーティングのために、No agenda, no attendaというルールも存在します。

  • 主催側
    • Coffee Chatを除き、必ずアジェンダを用意し、準備万全にしておく
    • 効率の良い同期コミュニケーションのための、非同期での準備を徹底する
  • 参加側
    • 参加者は事前にアジェンダを確認し、同期で参加するか決められる
    • 参加する場合は、内容の事前レビュー、質問のノートへの記載など全力で準備する

佐々木:「アジェンダがなければ参加しない」というルールは大切ですが、時にはそのアプローチを変えることも必要かもしれません。ひとつ例をあげると、以前日本チームのメンバー向けにカジュアルに技術的なことや製品について質問できるミーティングを設定しました。「事前に聞きたいことをアジェンダに入れてもらえたらミーティングを開催して回答します。もしなければスキップします。」という方針でした。しかし、これはスムーズに機能しなかったんです。アジェンダに質問はあまり書かれず、結果として誰もミーティングに参加しなくなってしまいました。でも技術的な不明点がないかというと実際にはあるんですね。そのような状況になった理由としては「知らないことは質問できない」「知らないと表明して質問することに少しハードルがある」という点もあったのかもしれません。事前に全員が自分の中の不明点や質問を整理できるわけではなく、雑談の中で新たな疑問や情報が出てくることもあるのです。そこで、「アジェンダがなくてもミーティングは開催します。本当に質問がなければ、ただ集まって食事をするだけにしましょう。でも、その場で質問をしてもらっても大丈夫ですし、もちろん事前に質問がある場合は書いておいていただいても大丈夫です。」という方針に変更しました。これによって、今は以前よりメンバーも集まって質問も多く出るようになりました。時には「No agenda, no attenda」というルールを適用しないほうが良いという気づきが得られました。

GitLabで、実際に効果を実感していること

佐々木:GitLabでは、業務関連の申請などもイシューで管理しているんです。他の人の申請見て「お、これいいな」とか思ったり、自分の申請内容なども共有して「これどう?」って。例えば「オンライン英会話受講料の経費清算の申請って、どうやった?」と聞かれたときに、「あぁ、自分の申請はこれだから、参考にしてみて」といったようにURLでサッと渡せるのですよね。透明性が高いことにより、イチから申請内容を教える手間が省けるので非常に効果的かなと思います。

千田:気に入っているバリューはありますか?

伊藤:The GitLab Handbook で、アンコンシャスバイアス(無意識の偏見)が明確に定義されていること。特にグローバルな会社で働いていると「あの人は、日本人と違うから考え方が違う」という勝手なバイアスがかかることがある。そのバイアスをどう防ぐかは別の議論として、まずアンコンシャスバイアスが定義された前提で、2,000人が働けること。これは非常に意義のあることだと考えています。

私たち人間は、無意識に多様性を受け入れることができません。私たちの脳には、アンコンシャスバイアス(無意識の偏見)が存在するためです。人間は自然に自分と同じようなものに惹かれ、異なるものに対して抵抗感を持つ傾向があります。このようなバイアスは、多様性の受け入れを妨げ、時に非効率や誤解を生む原因となります。

https://pr.forkwell.com/tech_event_reports/gitlab-remote-organization-guide/

佐々木:Assume Positive Intent(前向きな意図を前提とする)価値観ですね。「根本的帰属の誤り」といって、人間って自分の失敗はその原因や背景が手に取るように分かるけど、他人の失敗は理解しにくい。相手がどんな状況でなぜ失敗したかなんて基本的にはわかりにくいんですよね。同じオフィスにいれば「あの人、今週は大変そうだったからかな」と、事情を察することもできるけど、リモートワークだとよりわからなくなりがちです。だから、誰かが失敗したり、できないことがあっても、悪気があるわけじゃないよねという前提に立つこと。これって、リモートワークにおいては必須だと思っています。

まとめ:GitLabは、これらを完璧にできているのか?

ここまで紹介してきた理想的な実践がGitLabにおいても完璧に適用されているかというと、必ずしもそうではありません。全員がITのバックグラウンドを持っているわけではなく、新しく参加したメンバーが戸惑うこともあります。そのような場面では、実践的なアドバイスやサポートを通じて、一緒に問題解決を図ることを心がけています。

  • 「Googleカレンダーで他の人の予定を編集する方法、今からやりますね!」
  • 「私が画面映すので、今一緒にやっちゃいましょう!」

できない状況に遭遇したときの心構え

「ポジティブインテント(前向きな意図)」を前提とし、誰かが何かできない時はそれを教え、サポートする文化を大切にしています。これは、誰もが失敗から学び、成長できる環境を作るためです。このアプローチをぜひ実践に活かしていただきたいと思います。

「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」

モデレーター千田さんによる「GitLabに学ぶシリーズ第1弾の記事はこちらをご覧ください。

ForlkwellPress ロゴ画像

フォークウェルプレス編集部

Follow

記事一覧へ

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

上級エンジニア向けのキャリア面談
佐々木 直晴
GitLab Inc.

Senior Solutions Architect

2010年野村総合研究所に入社、Webシステムを中心とした開発のテクニカルメンバーとして様々な業種のアジャイル開発プロジェクトに参画し、アーキテクチャ設計やCI/CD環境構築などを担当。2021年7月よりGitLabに入社し、Senior Solutions Architectとして、導入に際する技術検証や、顧客社内の開発プロセスの可視化・刷新などに従事。

伊藤 俊廷
GitLab Inc.

Staff Solutions Architect

日本のSIerでソフトウェア開発、プロジェクト管理、技術調査、海外勤務等の業務に従事した後、米国のアプリケーションセキュリティベンダーにて、戦略顧客にソリューションを導入する任務を担う。現在は、GitLabのソリューションアーキテクトとして、技術とビジネス戦略の両面から顧客がDevOps/DevSecOpsでの成功を実現できるように導く。

千田 和央
LAPRAS株式会社

HRBP

東証プライム企業から創業期スタートアップまで人事責任者を歴任。『作るもの作る人作り方から学ぶ 採用人事担当者のためのITエンジニアリングの基本がわかる本』『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』などの著書があり、国内外のITエンジニアに関連する組織づくり制度設計採用などの人事領域を専門としている。