- 1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか？
- スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ
- その コメント
- GitLab Handbookで面白かったもの@コミュニケーション編
- GitLabのリモート統括責任者が語る 日本企業が「まずやるべきこと」
を読んだ。主題はGitLab社の https://about.gitlab.com/handbook/ である。
2022.02追記
GitLabで学んだ最高の働き方 Developers Summit 2022-02-18
2022.01追記
リモートワークのいま学びたい、GitLab Handbook非同期コミュニケーションのススメ - Qiita
Handbook要点
「GitLab社ではリモートワークの中でも生産性高く働けるように、ドキュメント文化が高度に発達している。GitLab社が作っている製品は、開発のコラボレーションツールでもあるので、これはドッグフーディングという側面もある。」
ハンドブックとはこれ。
Activityを見るとガンガンUpdateされていることがわかる。
例えば週末もこんなMerge Request。
Draft: Reorganizes Support on-call handbook
Draft: Move Rapid Action from engineering/development to engineering top level
Keeping stakeholders updated.
- Defining the update frequency and Keeping stakeholders updated. Depending on the nature or state of the Rapid Action this could be something like every 30 minutes or more relaxed, every regional handover.
端的には以上なのだが、会社の運用に必要なドキュメント群を一つのGitリポジトリの中で管理しているとのこと、詳細を見て、いま現在の自分のリモートワークや文書化に活かしていきたい。
1. Communication
物理的なオフィスを持たない分散型の組織において、課題となるのが非同期コミュニケーション。社内のコミュニケーションのあり方を、コンセプトのレベルから実践レベルまで記載している。このあたりは冒頭の note 記事 の通り。
- Onboarding Process：型化された新入社員のオンボーディングプロセス
- Global Compensation: 給与決定のオープンな考え方
等をピックアップしているので詳細はそちらを参照されたし。以降の項は、当方でも読んでみて素敵だなというポイントを選出した。以下翻訳は DeepL を利用していることご了承のほど。
2. Top tips and best practices
- メールやチャットを転送する必要がある場合もあるため、1対1で送信する場合でも、すべての文書によるコミュニケーションは英語で行います。
- 可能な限り非同期のコミュニケーションを使用しましょう：マージリクエスト（優先的に）や課題など。アナウンスが適切なSlackチャンネルで行われれば、人々はチャットに邪魔されることなく仕事をすることができるはずです。
- 課題やマージリクエストでの議論は、他のすべてのものよりも優先されます。緊急に応答が必要な場合は、課題やマージリクエストのコメントへのリンクを誰かにSlackで送信し、そこで応答してもらうことができるが、すぐには見られない可能性があることに注意してください。詳しくは Slack を参照してください。
- チャットではなくメールを選択した場合は、チャットと同じように短いメッセージを含む内部メールを送信しても構いません。
- あなたがいつでもAvailableであることは期待されていません。予定された勤務時間外にメッセージに返信することも期待されていません。
- **同期コミュニケーションの方が良い場合もありますが、それをデフォルトにしてはいけません。**例えば、ビデオ通話ですぐに物事を片付けることができることもあります。詳細については、ビデオチャットのガイドラインを参照してください。
- 質問はいくらでもしても構いません。多くの人が答えられるように、また多くの人が答えを見ることができるように質問してください。ダイレクトメッセージや1対1のメールではなく、問題集や公開チャットチャンネル（#questionsなど）を使ってください。ハンドブックで調べても答えが見つからなかったり、明確にする必要がある場合は、あなたが調べていたハンドブックのリンクを含めて、「ハンドブックを探している間、私はx,y,zを見つけることができませんでした」と言ってください。
- 誰かがあなたにハンドブックのリンクを送ってきた場合、彼らは私たちが答えを文書化したことを誇りに思っていますが、あなたが自分で見つけるべきだったとか、これが完全な答えだという意味ではありません。
- 質問の答えが文書化されていない場合は、すぐにマージリクエストをして、探した場所にあるハンドブックに追加してください。質問に答えてくれた人が、あなたが模範となって質問に答えてくれるのを見ることは、質問に答えてくれた人にとっても嬉しいことです。マージリクエストは、助けてくれたことへの感謝の気持ちを伝えるための最良の方法です。
- 何か (マージリクエスト、課題、コミット、ウェブページ、コメントなど) に言及した場合は、そのリンクを含めてください。
- すべての会社のデータはデフォルトで共有可能なものにしてください。ローカルのテキストファイルを使うのではなく、課題にコメントを残すようにしましょう。
- 誰かが何かを尋ねてきたときは、期限や自分がやったことを返してください。「will do」、「OK」、「it is on my todo list」などの回答は参考になりません。2分を費やしてもそのタスクを行う方が良いです。大事なことであれば、いつやるかを考える必要がありますが、その情報を返すことで、相手は時間がかかりすぎると別の方法で解決することになるかもしれません。
- CC ("cc @user") を使って問題を誰かの注意を引くのは構いませんが、誰かから具体的なアクションが必要な場合は、CCだけでは十分ではありません。言及されたユーザは問題を読んでそれ以上の行動を取らないかもしれません。何かを必要としている場合は、誰から必要としているのかを@と一緒に明示的に伝えてください。
-
内部での議論のためにプライベートなグループを作るのは避けてください。
- 迷惑です(グループ内のすべてのユーザがメッセージごとに通知されます)。
- 検索できない。
- 共有できない：グループ内の人を追加する方法がない（これが複数のグループ作成につながることが多い）。
- 誰もが参加者に基づいて各プライベートグループのトピックを覚えたり、内容を読むために再度グループを開いたりしなければならない。
- グループを離脱したり、90日を過ぎると履歴が消えてしまいます。
- チャンネルを作成しても全く問題ありません。1回の顧客ミーティングのためのチャンネルであっても問題ありません。これらのチャンネルは「a_<顧客名>-内部」という名前にして、「内部」であることを示すべきです（顧客とは共有されません）。
- **コミュニケーションを明示的にすることで、ローコンテクストのコミュニケーションをしましょう。**当社は世界中に拠点を置くリモート・オンリーの会社です。混乱を避けるために、できるだけ多くのコンテキストを提供します。また、コミュニケーションの効率化のために、ユビキタスな言語を使用します。
- **概念を議論する際には、仮説に傾倒しすぎないように注意してください。**仮説は価値が下がり、全員の意思決定が統一されたものになるように建設的でなくなるという点があります。
3. CEOのReadMe, 取扱説明書ページ
id Sijbrandijは、「DevOpsライフサイクルのための単一アプリケーションであり世界最大のオールリモート企業であるGitLab」の共同設立者兼CEOです。
Sidのキャリアパスはトラディショナルなものではありませんでした。彼は2007年に初めてRubyのコードを見て、それがとても気に入ったので、独学でプログラミングを学びました。彼が初めてGitLabに出会ったのはRubyプログラマー時代で、オープンソースへの情熱をすぐに発見しました。
2012年にはGitLabの商用化を支援し、2015年にはY-Combinatorの2015年冬のバッチで会社を率いた。彼のリーダーシップの下、同社は過去6年間で50倍の成長を遂げ、9人から66以上の国と地域にまたがる1,300人以上のリモートチームメンバーにまで拡大しました。
オープンソースコミュニティのチャンピオンであり、リモート組織をスケーリングするパイオニアであるシドは、DevOpsの実践に関する従来の常識を変えつつあります。
Sijbrandij 発音のヒント なども書いてある。
4. リーダーシップ
- GitLabでは、個人のコントリビューターであれ、リーダーチームのメンバーであれ、すべての人にリーダーシップが求められます。
- リーダーとして、GitLabのチームメンバーはあなたの行動に従いますので、常に正しいことを行いましょう。
- GitLabに参加するすべての人は、自分自身がGitLabの価値観のアンバサダーであり、GitLabの文化を守る存在であると考えるべきです。
- **行動は社内外で一貫したものでなければなりません。**会社の外でも正しいことをします。
- GitLabは、何があなたにとって最善かというあなたの判断を尊重します。もし他の場所にもっと良い機会があったとしたら、会社への忠誠心からGitLabに留まる必要はありません。
- 困難な時には、人はお互いのために最善の努力をするものです。
- 私たちは非同期にて仕事をします。模範となるように指導し、起こったときにはすぐに課題に書き留めておく必要があることを理解させるようにします。
- 私たちは、民主主義的な会社ではありませんし、コンセンサスを重視する会社でもありません。人々はコメントや意見を述べることが奨励されていますが、最終的には、すべてのフィードバックを聞いた後に一人の人間が問題を決定します。
- 意見の相違や建設的な議論をすることは奨励されていますが、知的な議論をしてください。
- 私たちは、結束力よりも真実を求めることを大切にします。
- ミーティングは、非同期のワークフローをサポートしておらず、時差の関係で実施が難しいため、可能な限り避けます。
- **時間通りにミーティングを開始し、自分自身も時間通りに行動し、全員が出席しているかどうかは尋ねないようにします。時間通りに来た人を待ったり、遅れて来た人のために繰り返したりして、時間通りに来た人をひどい目に遭わせるのはやめましょう。**会議がプロセスや決定のブロックを解除したときは、それを祝うのではなく、こう尋ねましょう。今後、会議を必要とせずにブロックを解除するにはどうすればいいのか？
- 私たちはたくさんのフィードバックをします。改善のための提案をためらわないようにしましょう。
- 外部の人に会った場合、彼らが改善すべきだと思うことは何かを常に尋ねてください。
- ポール・グレアムのアドバイスを踏襲する。組織をよりシンプルにするように努力しなさい。
- **言葉の効果を期待して、「聞いたことがあるでしょうが」、「井の中の蛙でないなら」、「誰でも知っているように」、「ご存知でしょうが」などと言うのは有毒です。**知っている人は言われなくてもいい。知らない人は何かを見逃したように感じ、その背景を聞くのを恐れるかもしれません。
- 他人の名前を使ったり、自分の肩書きを思い出させたり、あるいは物事を成し遂げるために「ランクを上げる」ようなことはしないようにしましょう。
- 目標と適切なタイムラインを設定する責任を負うことで、自分自身と自分の役割のCEOとして行動しましょう。
- 目標の状況について、チームや人のリーダーと明確にコミュニケーションをとりましょう。課題となっている分野に迅速に対処したり、割り当てられた時間枠内に達成できない目標を再評価したりするために行動しましょう。
5. オフボーディング
リストアップされた各ステークホルダーは、それぞれのチームメンバーの状況を取り巻く独自のニーズとセンシティブさに合わせて、効率的で最善の方法でオフボーディングが行われるようにするために重要な役割を果たします。
チームメンバーの退職に伴う自主的なオフボーディングの場合、ビジネスパートナーは、退職するチームメンバーのマネージャーと共に、そのオフボーディングが「遺憾」とみなされるか「遺憾」とみなされないかを検討する必要があります。
後悔しないオフボーディング
退職は、会社/顧客/プロジェクト/チームへの影響を最小限に抑えることができます。
オンボーディングはもちろんなのだが、オフボーディングについて先に記載されている点に共感。
6. Support Team Handbook
お客様を大切にする
常に自分が顧客の成功を保証する責任者であると考えてください。
顧客をサポートしているときは、問題や事故、損失はすべてGitLabの損失です。
顧客がトラブルやダウンタイムに見舞われたときは、GitLabがダウンタイムに見舞われたときと同じように、緊急性を持って対応しましょう。
顧客が生産性を落としているときは、GitLabが生産性を落としているときと同じような緊急性を持って行動しましょう。
経験則としては、2,500人のユーザーがダウンしている顧客に対しては、GitLabが1日あたり1,000,000,000ドルの損失を出している場合と同じ緊急度で対応します。この扱いは、彼らがいくら支払っているかに関係なく平等です。
早期にエスカレートする CEOを含めたGitLab全体の可視性を確保するには、後回しにするよりも早めの方が良いでしょう。顧客のために必要なすべてのリソースを早期に投入するようにしましょう。
サポートチームの一員である私たちは、誰かが問題や質問をしたときに最初に対応する立場であることを忘れないでください。そのため、会社を代表して、自分自身を適切に表現することが私たちの役目です。そのため、私たちは以下のことを求められています。
常に友好的であり、敬意を払うこと。
新しいアイデアや視点を受け入れてください。
分からないことがあっても平気です。いつでも他の人に聞くことができます。
顧客にノーと言っても平気であること（ただし、回避策を提案し、必要に応じてシニアにエスカレーションするようにしてください。
7. Our Product Principles
- 採用は仕事。AプレイヤーがAプレイヤーを引き寄せる PMの役割が戦略的に重要であることを考えると、強力なPMは巨大なレバレッジを生み出します。私たちは、新しい人を採用するたびに、チームの平均的なコンピテンシーを上げるように努力すべきです。
- 個人に気を配り、直接挑戦する。安心して働ける社員と、正直にコーチングするマネージャーがいるからこそ、人は最高の仕事をすることができるのです。私たちは、タイムリーで実行可能なフィードバックを奨励しています。また、マネージャーは、リソースだけでなく、感情や個人的な生活を持った人間としての社員を知るために時間をかけています。
- **常に学び続けること。**スキル開発に継続的に投資し、個人としてもチームとしても成長のマインドを持つこと。
- あなたはお客さんではありません。彼らと話をしましょう。顧客を理解していると思い込みたくなりますが、しばしば間違っています。私たちは、定性的および定量的な顧客からの入力を通じて、想定を検証します。
- 解決策ではなく、問題から始める。それは解決に右に飛び込みたくなるが、私達はしばしば根本的な問題について間違っている。よく形作られた問題の声明は成功したプロジェクトへのキーである。
- **冷酷に優先順位をつける。多くのことを下手にやるよりも、いくつかのことをうまくやる方がいい。**私たちはまず、自分たちが最も得意とすること、そして顧客が最も必要としていることに焦点を当て、シンプルさを優先するべきです。顧客が必要としているものが不足している場合は、顧客は教えてくれるでしょうが、不要な機能で顧客を圧倒している場合は教えてくれることはほとんどありません。
- **自分が間違っていると思い込む 人間の直感は間違っていることが多い。**これと戦うためには、仮説を持っている＆すぐにそれを無効にしようとします。
- 反復します。すべてを前もって計画しようとするのではなく、良い解決策に至るまでの道のりを反復していくために、テンポの速いビルド・メジャー・ラーニング・フィードバック・ループを活用してください。
- **データドリブンであること。**常に成功の指標を持ち、それらを追跡し、私たちの行動でそれらを正しい方向に動かすようにしてください。
まとめ
スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ に戻ると、以下がフォーカスされている。
1. Wikiではダメで、Gitリポジトリじゃないとスケールできない
会社のハンドブックはWikiとして始まることが多くとっつきやすいが以下問題がある。
- 時間の経過とともに古くなる傾向がある。
- ページの複数の部分や複数のページにまたがるような提案をすることができない。
- 作業者とレビュワーの役割を分けることができない。
- 提案を取り込むべきか取りこまないべきかの議論もできない。
Gitリポジトリを利用することで、この問題は解決できる。
- 提案がメンバーの誰でもできるようになる。
- 承認は該当部分を管理するマネージャーが意思決定できるようになる。
- Pull Requestの中でオープンなディスカッションもできる。
会議の中でみんなが見ながら内容を編集したい場合などはGoogle Docsを用いているようで、MTGが終わったら内容をMerge Request (GitHubでいうPull Request）にまとめて出すという形で実施しているようである。
2. ハンドブックファースト思想を貫く
GitLabではこのハンドブックファースト思想を貫いている。
- ハンドブックは常に最新であり、中に重複がないように書かれている。
- さまざまな議論をSlackやメールや、インターナルなプレゼンテーションを行う場合に、該当のハンドブックへの参照URLつけることを常に試みることが奨励されている。
- わざわざ何かを説明する時にプレゼンテーションスライドを作るのではなく、ハンドブックで代用することが奨励される。
まとめのまとめ
ハンドブックは4000ページ弱あり、その全てを把握できている人はいない。しかしこのテキストの山を活用するためにGitLabでは検索機能をつけることを推奨している。冒頭にも書かれているが、GitLabがそういう版管理製品を作っている会社だから徹底できるという理由はある。Glassdoor でも批判的意見はあり、それは納得。
"If remote work doesn't agree with your mindset, this isn't the place for you"
"Working fully remote isn't for everyone" (in 10 reviews)
しかしリモートワークが中心になりつつある我々も彼らと同様、考えて見る価値のある箇所がかなりありそう。という意味で、以上自分のため含めたまとめでした。参考になればさいわいです。
//その後調べた話 追記 : Slack社はSlackをどう使っているのか - Slack利用ガイドラインの話
//Organization
https://about.gitlab.com/company/team/structure/