GitLab のバリュー

CREDIT

GitLab の 6 つのコアバリューは、 🤝 Collaboration（コラボレーション）、 📈 Results for Customers（顧客のための成果）、 ⏱️ Efficiency（効率性）、 🌐 Diversity, Inclusion & Belonging（多様性・インクルージョン・帰属意識）、 👣 Iteration（イテレーション）、そして 👁️ Transparency（透明性） です。 これらを合わせると、私たちが互いに 善意を前提 として与え合う CREDIT（信頼）の頭文字になります。

私たちのバリューについて

私たちは他社からインスピレーションを得ており、常に 退屈なソリューション を選びます。共同創業者の Sid Sijbrandij が CREDIT 各バリューの 起源を共有 していますが、他の私たちの仕事と同じように、バリューも継続的に調整し、よりよいものにしようと努めています。 GitLab のバリューは生きたドキュメントです。 多くの場合、事業を進める中で得た教訓（そして負った傷）にもとづいて、ドキュメント化され、洗練され、改訂されてきました。

以前はもっと多くのバリューがありましたが、すべてを覚えるのは困難でした。そこで私たちはそれらを凝縮し、頭字語（CREDIT）を作り、行動を導くための運営原則を列挙しました。

改善の提案は誰でも歓迎します。これらのバリューを更新する MR は Chief People Officer にアサインしてください。また、GitLab で働いている場合は #values Slack チャンネル でその人を @メンションしてください。

Driving Results with CREDIT from GitLab on Vimeo.

🤝 Collaboration

成果を出すには、チームメンバーが効果的に協力し合う必要があります。GitLab では、他者を助けることが優先事項です。それが、あなたが達成しようとしている目標と直接関係しない場合でも同様です。 同様に、あなたも助言や支援を他者に頼ることができます。実際、そうすることが期待されています。 GitLab で働いていない人を含め、誰でもどんな話題にも意見を述べることができます。 その仕事に責任を持つ人がどのように進めるかを決めますが、その人は常にどの提案も真剣に受け止め、なぜそれが採用されたのか、あるいは採用されなかったのかを説明しようと努めるべきです。

思いやり

私たちは他者を気にかけることを大切にしています。 人を気にかけていることを示すことは、率直に指摘しフィードバックを伝えるための効果的な枠組みになります。 思いやりとは、フィードバックを控えたり意見の相違を避けたりすることではありません。これらは専門的な成長と顧客のための成果を得るために不可欠です。 思いやりとは、仕事と人を切り分けることです。誰かの仕事を批判しても、その人に対しては敬意を持ち続けられます。 ポジティブなフィードバックはできる限り多く、そして公の場で与えましょう。

共有する

意図的な透明性のように、GitLab のカルチャーには外部の人や新しいチームメンバーには直感的でない側面があります。 人に投資し、オープンな対話に取り組むことを厭わないでください。 たとえば、可能な限りプライベートな Issue を公開して、私たち全員がその経験から学べるようにすることを検討してください。公の場で共有する際に、判断や精査を恐れる必要はありません。すべてを知ることは不可能だ ということを、私たち全員が理解しています。

誰でも、社内の誰に対しても私たちのバリューを 思い出させる ことができます。 解釈について意見の相違がある場合、その議論は何の不利益もなく社内のより多くの人にエスカレーションできます。

直面した問題を共有し、助けを求め、進んで情報を提供し、声を上げましょう。

ネガティブなフィードバックは 1 対 1 で

ネガティブなフィードバックは、可能な限り少人数の場で与えましょう。 1 対 1 のビデオ通話が望ましいです。

ネガティブな フィードバック は、ネガティブさや意見の相違とは別物です。直接的なフィードバックが含まれない場合は、敬意を持って 透明性 を保ちながら、公開チャンネルで 意見の相違について議論するよう努めてください。

バリューに関する GitLab Unfiltered のインタビュー で、GitLab 共同創業者の Sid Sijbrandij は次のような文脈を語っています。

私たちは GitLab で常にネガティブなことに向き合っています。もし問題でないなら、なぜそれを議論しているのでしょうか。私たちはネガティブさと多く向き合いますが、それも私たちの野心の一部なのです。

よりよくなりたいなら、何を改善できるかを話します。私たちはネガティブなことを公に議論することを許されています。ただし、より小さな場で実施可能なフィードバックを、大きな場でネガティブに与えることは許されていません。

ネガティブなフィードバックは、相手がマネジメントチェーンの上位にいる場合には、グループの場で与えてもかまいません。これは、誰もフィードバックの対象外ではないことを示します。

タイムリーにフィードバックを提供する

私たちは問題が 小さい うちに解決したいと考えています。 何か（自分の職務、同僚、上司、給与、勤務地、コンピューター）に不満がある場合は、自分の中に抱え込まずに、その懸念を声に出してください。マネージャーを超えてエスカレーションする必要がある場合は、スキップレベル（より上位の人）や people business partner に相談することを検討できます。

感謝を伝える

たとえば私たちの #thanks チャットチャンネル で、あなたを助けてくれた人を公に称えましょう。

公に感謝を伝えるときは、以下を認識することが重要です。

• 私たちのような規模の会社で、できる限り大きな場（全社規模）で感謝を示すのは、当たり前のことではなく例外的なことであり、慣れるには少し時間がかかります。
• 自分では比較的小さい、あるいはわずかな貢献だと思っていることを全社レベルで感謝されると、気まずく感じることがあります。
• #thanks で人に感謝するときは、誠実に行い、なぜ感謝しているのかを要約して、受け取る側がなぜ感謝されているのかを簡単に理解できるようにしましょう。善意を前提 としていても、すべての人が公の称賛を心地よく感じるわけではありません。その人がどのように期待を超えてくれたのか、そしてなぜそのチームメンバーが称えられることが重要だと感じたのかを、相手が理解できるよう手助けしてください。
• 感謝を伝えるよい方法や場所はいくつもあります。感謝を伝えるのを #thanks チャンネル だけに限定すべきではありません。

フィードバックを効果的に提供する

フィードバックを与えるのは難しいことですが、効果的に伝えることが重要です。 フィードバックを提供するときは、常に仕事そのものについて伝えましょう。 人ではなく、ビジネスへの影響に焦点を当てます。 少なくとも 1 つ、明確で最近の具体例を必ず提供しましょう。 相手が私生活で大変な時期を過ごしている場合は、それを考慮してください。 ポジティブなフィードバックを与える例としては、私たちの thanks チャットチャンネル があります。 マネージャーにとっては、チームメンバーがマネージャーからのネガティブな出来事に対して、ポジティブな出来事に対するよりも 6 倍強く 反応することを認識しておくことが重要です。 これを念頭に置くと、あるエラーが取るに足らないもので、批判を提供することで得られる価値が低い場合は、そのフィードバックを自分の中にとどめておくのが理にかなっているかもしれません。 ネガティブなフィードバックを与えなければならない状況では、そのフィードバックの目的、つまり今後のチームメンバーのパフォーマンスを向上させることに焦点を当てましょう。 チームからより多くのエンゲージメントを 引き出す ために、称賛は惜しみなく、オープンに、そして頻繁に与えましょう。

お互いを知る

私たちは多くの テキストベースのコミュニケーション を使っており、テキストの向こう側にいる人を知っていれば、衝突を防ぎやすくなります。 そこで私たちは、インフォーマルなコミュニケーション（たとえばバーチャルな コーヒーチャット）や GitLab Summit を通じて、個人的なレベルでお互いを知ることを奨励しています。

部門を越えて手を伸ばす

自分の職種内の専門家に助言を求めるのは賢明ですが、私たちは GitLab のチームメンバーが部門を越えて同じことをすることも奨励しています。これにより、会社はより速くイテレーションでき、誰もが貢献できるという理解を受け入れ、可能な限り多様な視点を取り入れられます。

肩書きを振りかざさない

社内での自分の立場を相手に思い出させる必要があるなら、あなたは何かを間違えています。 人々はすでに 私たちの意思決定プロセス を知っています。 なぜその決定をするのかを説明し、職種にかかわらず全員を尊重しましょう。 これには、アイデアや決定を通すために他人の肩書き（CEO を含む）を使うことも含まれます。

善意を前提とする

私たちは他者の行動に関して、自然とダブルスタンダードを持ってしまいます。 自分のミスは状況のせいにし、他者のミスは個人のせいにするのです。 このダブルスタンダードは 基本的な帰属の誤り と呼ばれます。 このバイアスを軽減するために、他者とのやり取りでは常に 善意を前提 とし、相手の専門性を尊重し、あなたがミスだと感じるかもしれないことに対して寛容に接するべきです。

意見が異なる とき、人はときとして論点の最も弱い部分や、架空の論点（たとえば 「藁人形論法（ストローマン）」）に反論してしまいます。論点は誠実に提示されていると前提し、代わりに相手の立場の最も強力なバージョンに反論しようとしてください。私たちはこれを、「藁（straw）」の立場ではなく「鋼（steel）」の立場に反論する、と呼んでいます。この考え方は 「鋼の人（steel man）」に反論する という手法から借りたものです。

「鋼」の立場は、相手の立場の最も効果的なバージョン、つまり相手が提示したものよりもさらに説得力があるかもしれないものに対するものであるべきです。よい「鋼」の立場とは、相手があなたの前提や結論に依然として同意していなくても、あなたが相手の立場をよく代弁してくれたと感じるようなものです。

行動には言及するが、人にレッテルを貼らない

私たちのチームに嫌な奴を入れたくないという この記事 には多くのよい点がありますが、私たちは 嫌な奴（jerk） とは人の本質的な分類ではなく、行動に対するレッテルだと考えています。私たちは分類を避けます。

ごめんなさいと言う

ミスをしたら、できるだけ早く謝りましょう。 謝ることは弱さの表れではなく、強さの表れです。 最も多く仕事をする人は、おそらく最も多くのミスをするでしょう。 さらに、私たちがミスを共有してそこに注意を向けると、他の人がそこから学べるようになり、同じミスが他の誰かによって繰り返される可能性が低くなります。 ミスには、誰かに対して思いやりに欠けた場合も含まれます。私たちのバリューを強化するためには、公の場で思いやりに欠ける言動をしてしまったとき（たとえば Slack チャンネルで個人やグループに思いやりのない、あるいはプロフェッショナルでない発言をしたとき）には、公の場で謝ることが重要であり、それにはより多くの勇気が必要です。

エゴを持たない

議論に勝つために主張を守ったり、ミスに対して意固地になったりしないでください。 あなたはあなたの仕事ではありません。自分の主張を守る必要はありません。 他者の助けを借りて正しい答えを探す必要があるのです。

他者の成功を見たいと思う

GitLab 内の多くの人と話したある候補者は、他社と比べて最も際立っていたことを 1 つ挙げました。それは、ここでは誰もがお互いの成功を見たいと言っていたことです。

お互いを失敗させない

苦しんでいたり行き詰まっていたりするかもしれない他者に目を配りましょう。 助けを必要としている人を見かけたら、手を差し伸べて助けてください。これには、ペアプログラミング を申し出たり、同期的なブレインストーミングのセッションを設定したりすることが含まれるかもしれません。目標は、専門知識や支援を提供できる別の誰かとその人をつなぐことです。 私たちはチームなので、お互いを支え合うことで、ともに成功し輝くのです。

人はその人の仕事ではない

提案は常に、人ではなく仕事の例について行いましょう。 「あなたは決して聞かない」ではなく、「あなたはデザインに関する私のフィードバックに返答しませんでした」と言いましょう。 そして、フィードバックを受け取るときは、フィードバックが上達するための最良の方法であり、フィードバックをくれる他者はあなたの成功を見たいと思っているということを覚えておいてください。

自分でやる

私たちのコラボレーションのバリューは、疑問があるとき、批評が必要なとき、助けが必要なときに、お互いを助け合うことに関するものです。 ブレインストーミングをしたり、合意を待ったり、自分一人でできることを 2 人でやったり する必要はありません。Bolt Handbook はこれを 創業者マインドセット（Founder Mentality） と呼んでおり、すべてのチームメンバーは自分が会社のオーナーであるかのように問題に取り組むべきだとしています。

非難なしの問題解決

ミスを調査するときは、人やチームに非難を浴びせるのではなく、失敗のメカニズムの状況的側面と、その失敗に至った意思決定プロセスに焦点を当てる方法で行いましょう。 私たちは、関係者が罰や報復を恐れずに声を上げられるように、非難なしの 根本原因分析 と レトロスペクティブ を実施します。

短いつま先

会社に入ってきた人は、「誰かのつま先を踏みたくない（誰かの領域を侵したくない）」とよく言います。 GitLab では、物事を改善しようとイニシアチブを取る人をもっと受け入れるべきです。 会社が成長するにつれて、関わる人が増えるため意思決定のスピードは低下します。 私たちは、つま先を短くし、他者が自分の領域に貢献することを心地よく許すことで、これに対抗すべきです。 たとえば、GitLab の CEO による 提案 への鋭く敬意ある指摘的なフィードバックが、彼自身のマージリクエストのクローズにつながりました。ただし、コメントに返答することは必須ではありません。

すべてを知ることは不可能だ

私たちは、自分が持っていない専門知識については他者に頼らなければならないことを知っています。 何かを知らないと認めて助けを求めることは、たとえそうすることで自分が無防備に感じても、問題ありません。 質問するのに遅すぎるということは決してありません。質問することで、成果を出すために必要な情報を得られるだけでなく、自分自身のスキルと GitLab 全体を強化できます。 質問に答えてもらった後は、その答えが共有できるようにドキュメント化してください。

誰かが何かを知らないと言ったときに驚いた態度を見せないでください。誰もが「わかりません」「理解できません」と心地よく言えることが重要です。 （Recurse からインスピレーションを得ました。）

コラボレーションは合意ではない

コラボレーションするときは、常にレーダーの上に出て 透明性 を保ちながら働くことが重要ですが、コラボレーションは 合意ではなく、意見の相違はコラボレーションの一部です。 人々に意見を求める必要はありませんし、彼らも「なぜ私に聞かなかったのか」と尋ねるべきではありません。 人々に意見を求めた場合でも、彼らが意見を提供するのを待つ必要はありません。 全員が同じことに同意する必要はありません。彼らは 異議を唱え、コミットし、支持する ことができます。双方向ドアの決定 は 異議を唱え、コミットし、支持する の一環として元に戻せますが、一方向ドアの決定はより多くの意見があると有益です。より速くイテレーションするために、意見が少なくて済むこうした元に戻せる双方向ドアの決定を見極めましょう。 私たちはパーミッションレス・イノベーション（許可不要のイノベーション）を信じています。人々を巻き込む必要はありませんが、誰もが貢献できます。 これは私たちがどのように イテレーション するかの核心です。なぜなら私たちは、大きなチームがゆっくりと合意に達するよりも、小さなチームが素早く動くことを望んでいるからです。

📈 Results for Customers

私たちは顧客がより多くを達成できるよう支援するために存在しています。私たちが行うすべてのことは、顧客が GitLab で成功するためのものであるべきです。Results for Customers は私たちのバリュー階層の最上位にあります。なぜなら、顧客が成果を出すことが事業全体のパフォーマンスを牽引し、それが他のすべてを可能にするからです。

Results for Customers のバリューは、以下の運営原則を通じて示されます。

野心的かつ測定可能な目標を設定する

私たちは小さな変更でイテレーションしつつ、大きく野心的な成果を目指します。私たちには野心的な ミッション と ビジョン があり、すべての職種で世界最高であることを目指しています。野心的で測定可能な目標を設定することで、私たちは顧客の成果を最大限に提供できます。私たちは測定可能な目標について書面で合意します。私たちは指針となるターゲットを伴う KPI を持ち、それに対して報告します。

顧客を理解する

GitLab のすべてのチームメンバーは、顧客のニーズ、課題、バリュープロポジションを理解すべきです。私たちは、顧客が GitLab をどのように使い、目標を達成するためにプラットフォームから何を必要としているのかを理解します。社内向けのチームは、自分たちの仕事が GitLab の顧客に間接的に与える影響を考慮します。

私たちは以下を通じて、顧客とそのニーズをよりよく理解します。

• 顧客やユーザーからの公開された GitLab の Issue をレビューする
• 製品を ドッグフーディング してユーザー体験を理解する
• マーケティングやセールスからの顧客ストーリーを読む
• 顧客のファイヤーサイドチャットに参加する
• 製品の機能やロードマップに関する顧客やユーザーからのフィードバックを学ぶ

共創する

私たちは顧客とともに創造します。GitLab と顧客の間にはオープンな対話があり、それによって顧客が何を必要としているかをよりよく特定できます。顧客のためにソリューションを構築した結果として、私たちはそのソリューションを世界にも届けることができます。

エンドユーザーを視野に入れ続ける

私たちの焦点は顧客の成果を高めることです。GitLab で顧客の成果を牽引する 1 つの方法は、直接のユーザーに最も価値をもたらすプラットフォームの強化です。これには、Concur 効果 を意識することが必要です。

プリンストン大学教授の Arvind Narayanan は、バズったツイートで Blackboard への不満を次のように述べました。

このソフトには、これまでに考案されたあらゆる機能がある。だが委員会が設計したものの常として、インターフェースは支離滅裂で、どんなタスクにも最低 15 回のクリックが必要だ（しかもそれは、最初から正しい操作手順を覚えていればの話だ）。

ソフトウェア企業は、自分たちとユーザーの間に間接的な層が挟まると、息をのむほど無頓着になりうる。Blackboard を苦しんで使い続けてきた人なら誰もがこれに同じ反応をするだろう。機能を減らしてみたらどうだ、と。

Ryan Falor は Narayanan のツイートに続けて、自身の Concur 効果の定義を示しました。

1. 意思決定者は直接のユーザーではない
2. 機能が過剰でばらばらである
3. ユーザー体験が時間とともに悪化する

具体的な UX の例については、Hacker News の議論 を参照してください。

GitLab では、直接のユーザーに最も価値をもたらすプラットフォームの強化に焦点を当てることで、顧客の成果を牽引したいと考えています。

顧客の成果は、以下よりも重要です。

1. 私たちが作ろうと計画していること。自分たちの計画だけに焦点を当てていたら、私たちには GitLab.com しかなく、GitLab のセルフマネージド型の提供はなかったでしょう。これは、すべての機能リクエストに同意するという意味ではありませんが、既存の計画を、最も多くの顧客価値を牽引するものに取り組む上での障害にはしません。
2. 大口顧客のリクエスト。大口顧客のリクエストに応えることは イノベーターのジレンマ につながります。私たちは小規模な顧客や将来の顧客のための成果にも焦点を当てる必要があります。
3. 私たちの既存のスコープ。たとえば、顧客がよりよいインテグレーションを求め、インテグレーションのコストや労力について不満を述べたとき、私たちはスコープを拡大し、DevOps ライフサイクルのための 単一のアプリケーション を作ることで応えました。
4. 私たちの想定。会社ごとに働き方は異なるので、私たちにとってうまくいくことが顧客のニーズを支えるとは限りません。アイデアがあるときは、その想定を複数の顧客と直接検証して、スケーラブルで非常に関連性の高いソリューションを確実に作る必要があります。
5. 私たちがコントロールできること。私たちは各顧客に可能な限り最高の体験を提供しようと努め、合理的にコントロールできるすべての側面について責任を持ちます。

活動ではなく、インパクトを測定する

私たちは、あなたが何を達成したかを重視します。出荷したコード、動かした指標、満足させたユーザー、助けたチームメンバーです。午後を休んだ人は、自分が責任を負っていた目標や成果にマイナスの影響を与えていない限り、何か悪いことをしたと感じる必要はありません。期待に沿ってパフォーマンスを発揮し成果を出しているのであれば、1 日の過ごし方を弁明する必要はありません。私たちは、硬直したルールを設けるのではなく、チームメンバーが正しいことをすると信じています。私たちは、チームメンバーが現れ、最善の仕事をすると信じています。昨日何時間働いたかを公言して競争を煽らないでください。働きすぎている場合は、マネージャーに相談して解決策を話し合ってください。

ドッグフーディング

私たちは 自分たちの製品を使って、ユーザーと同じように使うことで、よりよい 顧客の成果 につながる改善点を浮かび上がらせます。GitLab は、事業全体の人々が使える DevSecOps プラットフォームです。これが GitLab 内での私たちの使い方です。たとえば、私たちのエンジニアリングチームは、標準的な開発プロセス の一環として Duo Agent Platform を使っています。これにより、チームメンバーは顧客体験を深く理解できます。私たちは以下の方法でもドッグフーディングを行っています。

1. 開発組織は GitLab.com を使って、GitLab 自体の DevOps ライフサイクルを管理しています。
2. すべてのチームメンバーは GitLab を使って、このハンドブックでコラボレーションしています。
3. コンテンツやプロセスを Git リポジトリに記録し、GitLab で管理しています。

何かが壊れたり、うまく機能しなかったり、改善が必要になったりしたとき、私たちはより大きなコミュニティに影響を与える前に、社内でそれに気づいて対処できる可能性が高くなります。

主体性を与える

私たちは、最も有益だと思うことに集中できるよう、人々に主体性を与えます。あるミーティングが興味深くなく、その人の積極的な参加がミーティングの成果に不可欠でない場合、その人はいつでも参加しないことを選べますし、ビデオ通話中に望むなら他の作業をすることもできます。他のタスクに取り組んでいても通話に残ることが理にかなう場合もあります。そうすれば、必要なときに他の仲間があなたに連絡して素早く答えを得られるからです。これは、あなたがほんの数分だけ関わるような多目的のミーティングで特に有用です。

チャレンジャー・マインドセット

現状に挑戦することは、目覚ましい成果につながります。私たちは決して立ち止まってはいけません。チャレンジャー・マインドセット には、自己満足に抗いながら、私たちの事業と私たちが解決する問題について、大胆で難しい問いを自らに問い続けることが求められます。成功するためには、私たちは革新し、私たちが構築する製品の価値で顧客を喜ばせなければなりません。チャレンジャー・マインドセットには、卓越性のたゆまぬ追求が求められます。私たちは 粘り強く なければなりません。顧客のための勝利の 1 つひとつが、競争の激しい市場で見込み客の信頼を勝ち取るために使える評判という資本を築きます。競争は資本主義の特徴ですが、GitLab のチームメンバーとして社内では、市場シェアを勝ち取るために、顧客のための最高の成果を達成することに私たちの努力を内向きに集中させなければなりません。

グロース・マインドセット

常に成果が得られるとは限らず、これは自分自身や他者からの批判につながります。私たちは、自分たちの才能はハードワーク、的を絞ったトレーニング、他者から学ぶこと、実務経験、他者からのインプットを受けることを通じて伸ばせると信じています。機会を探し、謙虚であり続け、決して満足しないことは、会社としても個人としても私たちの DNA です。私たちは 血統ではなく軌跡にもとづいて 人を採用しようとします。私たちはまた、チームメンバーが自分自身とキャリアを成長させる機会を提供され、自ら積極的に求める、好奇心と継続的な学びのカルチャーを育もうと努めています。私たちは、適切な期待と方向性があれば、人々は成長して新しい挑戦に取り組み、期待を超えられると信じています。

部門横断的な最適化

私たちの部門横断的な最適化の定義は、組織全体にとって最善のことを行う、ということです。あなたのチームの目標が他のチーム、私たちのユーザー、または会社の目標にマイナスの影響を与えるとき、自分のチームの目標のために最適化しないでください。それらの目標もあなたの問題であり、あなたの仕事です。たとえば、四半期末に着地する予定の緊急でない職種上のマイルストーンを設定したとします。最後の 1 週間で提供するために GTM チーム の関与が必要なら、GTM チームが収益目標の達成に集中できるよう、その依頼を減らすために、あなた自身のチームのターゲットを 1 週間ずらすのが正しい判断かもしれません。

コラボレーション の文脈では、誰かが質問、あなたの承認、またはマージリクエストのレビューであなたにブロックされている場合、直接的に、あるいは対応できる別の誰かを見つける手助けを通じて、その人のブロックを解除することを優先すべきです。

粘り強さを受け入れる

私たちはこれを「目的への執着（persistence of purpose）」と呼んでいます。The Influence Blog で語られているように、粘り強さとは、自分が信じるものへのコミットメントを示す能力です。あなたは何度でも立ち上がり、泥を払い、少し学びを得て素早く再び歩き出します。私たちは、仕事が困難なときに集中力とモチベーションを維持し、必要なときに助けを求める能力を大切にしています。

オーナーシップとアカウンタビリティを持つ

私たちはチームメンバーに、アサインされたタスクを完遂することを期待します。あなたは、細部に注意を払い、組織全体で点と点をつなぎ、問題を予測して解決しながら、実行する責任があります。オーナーとして、あなたは課題を乗り越える責任があります。サプライヤーや他のチームメンバーではありません。イニシアチブを取り、自分では解決できないかもしれないことがあれば、積極的にステークホルダーに知らせてください。

緊急性の感覚

得たり失ったりした時間には複利の効果があります。私たちの他のバリューや コミュニケーションの仕方 を損なうことなく、可能な限り速く成果を得るようにしましょう。そうすれば成果の複利が始まり、次の改善に集中できます。

行動を優先するバイアスを持って動く

私たちが行動への焦点を保ち、分析麻痺の罠に陥ったり、リスクのない遅く静かな道に固執したりしないことが重要です。決定は思慮深くあるべきですが、速い成果を出すには、ときにミスをすることを恐れず受け入れることが必要です。私たちの行動を優先するバイアスは、素早く軌道修正することも可能にします。私たちの他のバリューや働き方を損なうことなく、可能な限り速く成果を得るようにしましょう。

異議を唱え、コミットし、支持する

決定が下されたら、私たちは人々がその実行にコミットすることを期待します。過去の決定やガイドラインは、それらが変更されるまではそれに従って行動する限り、いつでも疑問を投げかけることができます。これは 一般的な原則 です。 すべての決定は変更できます。 私たちの 最高の決定は、以前の決定を変更したものでした。 マネージャーとレポートの関係では、通常レポートが Directly Responsible Individual（DRI）です。 マネージャーは最終的な決定に異議を唱えるかもしれませんが、それでも DRI の決定にコミットします。

グループの場では、参加者が提案に異議を持っていても、何らかの理由でその見解を表明しないことがあります。ときには、多くの、あるいはすべての個人が異議を持っていても、声を上げないことを選ぶ ことがあります。なぜなら、誰もグループから同意を得られるとは思わないからです。その結果、全員がそのフィードバックを得る機会を失います。ディセント（異議） とは、その異議の表明です。しかし、それは難しく、社会的なコストさえ伴うことがあります。 フィードバックの表明は、誰もが成長し学ぶための方法であり、意見ではなく事実にもとづくもの です。衝突を避けるためや、他の皆に合わせるために単に同意するのではなく、あなたの視点を共有してください。

何かについて会話を再開したいときは、あなたの主張が以前の会話を踏まえたものであることを示し、その決定は最善の意図でなされたと前提 してください。 変更しようとしている最中であっても、ある決定が有効である間は、そのすべての決定について成果を出さなければなりません。 決定を変更できない人ではなく、変更できる DRI とコミュニケーションを取るべきです。

ブロック解除のためにエスカレーションする

意見の相違があり、それが原因で前に進めない場合は、エスカレーションすることに合意し、自分のマネージャーの一方または両方にエスカレーションしましょう。課題の文脈とともに早期にエスカレーションすれば、マネージャーがブロック解除役として機能できます。

⏱️ Efficiency

GitLab において効率性とは、材料、時間、エネルギーを無駄にせずに 成果 を生み出すことを意味します。私たちは、1 人や小さなグループよりも、より広い GitLab コミュニティのために、ソリューションをグローバルに最適化します。効率性への焦点は本質的にグローバルであるべきで、特定の職種にローカルなものだけであってはなりません。グローバルな効率性には、顧客、候補者、コントリビューターとの効率性も含まれます。一貫性は当初はより効率的なことが多く、プロセスの管理をより効率的にするため、効率性よりも一貫性を優先しがちです。一貫性のために最適化するときは、ペースを落とすべきです。変更を評価する際に全社的な視点を持つことは、新しいプロセスが GitLab 全体の効率性を向上させ、会社全体にとって最善の決定であることを確実にする助けになります。

私たちが社内で他のチームメンバーと働くときは、GitLab 独自の働き方と運営原則を活用して最高の効率性を達成します。GitLab 外の人々に GitLab の働き方に従うことは期待せず、彼らと効果的に働くために配慮します。たとえば、私たちは対面で大いにコラボレーションし、非同期コミュニケーションをデフォルトにしないことがあります。

健全な制約のみ

ほとんどの企業は平均に回帰し、時間とともに減速します。会社が成長し成熟するにつれて必要な変化もありますが、すべての変化が避けられないわけでも、受動的に起こるに任せるべきわけでもありません。GitLab が成長するにつれ、私たちは自分たちの運営の仕方と、それが スタートアップ の俊敏さで運営し続ける能力をどう可能にするかを意識しています。私たちは自分たちを 健全な制約 に限定しようとします。

書き留める

私たちはすべてをドキュメント化します。ハンドブックに、ミーティングのノートに、Issue に。 私たちがそうするのは、「最も薄い鉛筆でも、最も鋭い記憶に勝る」からです。 質問して説明してもらうよりも、ドキュメントを自分の都合のよいときに読むほうがはるかに効率的です。バージョン管理に置いておくことで、誰もが改善の提案を貢献できるようにもなります。

退屈なソリューション

問題には最もシンプルで最も退屈なソリューションを使い、「退屈」 を 「悪い」や「技術的負債」と混同すべきではない ことを覚えておいてください。 私たちの組織と製品のイノベーションのスピードは、これまでに私たちが加えてきた複雑さの総量によって制約されるので、複雑さをほんの少し減らすことも助けになります。 仕事をより楽しくするためだけに興味深い技術を選ばないでください。 確立された人気のある技術を使えば、あなたと他のコントリビューターにとって、より安定し、より馴染みのある体験が確実になります。

チーム内の他者の制約を 認識 するよう意識的に努めましょう。 たとえば、セールスは別の組織に依存するため難しく、開発は将来製品を素早く改善する能力を維持しなければならないため難しいのです。

セルフサービスと自己学習

チームメンバーはまず 自分自身で答えを探す べきであり、答えがすぐに見つからない、あるいは答えが明確でない場合は、私たち全員が 低いレベルの恥 を持つべきなので、公の場で質問しましょう。発見した新しい情報はすべて書き留め、それを次の人に引き継いで、後に続く人がコラボレーション、インクルージョン、成果のドキュメント化の実践の上に、よりよい効率性を築けるようにしましょう。

チームメンバーは、セルフサービスと自己学習ができるとき、自分自身を成長させる余地がより多くなります。

適切なグループのための効率性

より広い GitLab コミュニティのために、ソリューションをグローバルに最適化しましょう。たとえば、何千もの顧客がそれぞれ 2 時間を費やす必要がある更新プロセスを破棄し、わずか 60 秒で済むものを採用するのが最善のことがあります。たとえそれによって、社内の月次レポートの効率が下がるとしてもです。決定を下す際には、「これは誰にとって最も効率的である必要があるのか」と自問しましょう。多くの場合、その答えは、あなたの決定に依存しているユーザー、コントリビューター、顧客、またはチームメンバーかもしれません。

他者の時間を尊重する

ミーティングや許可プロセスで他者に求めている時間的投資を考慮しましょう。ミーティングは避けるようにし、必要な場合は、できる限り多くの人にとって参加を任意にするようにしましょう。あらゆるミーティングには、招待からリンクされたアジェンダがあるべきで、成果をドキュメント化すべきです。人々に許可を求めさせる代わりに、彼らの判断を信頼し、質問があれば相談プロセスを提供しましょう。

会社のお金を自分のお金のように使う

私たちが使うすべての 1 ドルは、稼ぎ直さなければなりません。自分のお金と同じくらい、会社のお金にも倹約的でいましょう。とはいえ、私たちはチームメンバーに、購入のコストと、それが会社にもたらす価値を天秤にかけることを求めています。

購入が、コストに対してどの程度あなたの仕事をよりよく遂行しビジネスの 成果 を達成する能力を高めるかを考慮しましょう。間接費を下げることは、事業の運営コストを削減し、他の優先領域に支出を振り向けることを可能にします。

私たちには、チームメンバーが経費精算のプロセスと期待をよりよく理解できるよう、この運営原則に関する ガイドライン があります。

倹約

Amazon が最もうまく述べています。「より少ないリソースでより多くを成し遂げる。制約は機知、自給自足、発明を育む。人員、予算規模、固定費を増やすことに追加点はない。」

口頭での短い回答

口頭の質問には短く答えて、相手がさらに尋ねたり次に進んだりする機会を持てるようにしましょう。

ブロードキャストは短く

この HBR の研究 で述べられているように、一対多の書面でのコミュニケーションは短く保ちましょう。「大多数が、自分の読むものが長すぎる、構成が悪い、不明確、専門用語だらけ、不正確であるために、しばしば効果的でないと答えている。」

Manager of one

私たちは、各チームメンバーが、目標を達成するために毎日のチェックインを必要としない manager of one であることを望みます。チームメンバーには、プロジェクトやイニシアチブをオーナーとして担う自由が与えられ、それを成功裏に最後までやり遂げると信頼されています。

チームメンバーが manager of one であるとき、1 日を通じて時間をどう配分するかについての決定をより主体的に下せるため、ワークライフバランスを高められます。

硬直性より自由と責任

可能な場合、私たちはルールや承認プロセスを課す代わりに、人々に決定を下す責任を与え、その結果について責任を負ってもらいます。あなたには明確な目標と、それに自分が適切と考える方法で取り組む自由があるべきです。自由と責任は、プロセスに硬直的に従うことや 相互依存関係を作ること よりも効率的です。なぜなら、それらはより速い意思決定速度とより高い イテレーション の頻度を可能にするからです。

チームメンバーが硬直性より自由と責任を持つとき、他者を助ける余地がより多くなります。

ミスを受け入れる

すべての問題が、それを防ぐための新しいプロセスにつながるべきではありません。プロセスを追加すると、すべての行動がより非効率になります。ミスは 1 つのことにしか影響しません。ミスを受け入れたら、そこから学びましょう。チームメンバーがミスを受け入れる自由があるとき、より計算されたリスクを取れます。

最小限の価値ある変更を出荷して速く動く

私たちは、月ごとに素早くイテレーションすることによる絶え間ない改善を大切にしています。タスクが 最小で実行可能かつ価値あるもの でないなら、スコープを削りましょう。

変化を受け入れる

機能の採用、ユーザー要件、競争環境は、頻繁かつ急速に変化します。最も成功している企業は、ペースを保つためにロードマップと組織を素早く適応させます。これを難しくするものの 1 つは、私たちのチームへの影響です。人々はチーム、テーマ、あるいは自分をマネジメントする人さえも変える必要があるかもしれません。これは、当然ながら混乱を感じさせることがあります。機会の増加や新しく学べることなど、変化のポジティブな側面を受け入れるよう自分を導けば、会社としてより速く動き、成功の確率を高められます。マネジメントが意図的であることに対して責任を負わせる ことが重要です。

🌐 Diversity, Inclusion & Belonging

多様性、インクルージョン、帰属意識は、GitLab の成功にとって基本的なものです。私たちは、誰もが活躍できる環境を育むための取り組みで、大きなインパクトを与えることを目指しています。私たちは、GitLab があらゆる背景や境遇の人々が自分の居場所だと感じ、貢献できる場所であることを確実にするために、多次元的なアプローチを設計しています。私たちは、インクルーシブ で、すべてのチームメンバーが専門的な目標を達成する過程で等しくサポートされるカルチャーを構築することを積極的に選択しました。私たちは、誰もが歓迎されていると感じられるようにし、私たちのコミュニティと会社における過小評価されたグループの参加を増やすよう努めています。

非同期コミュニケーションへのバイアス

可能な限り 非同期 で動くようイニシアチブを取りましょう。これは、同じタイムゾーンにいないかもしれない人、いつものタイムゾーンの外を旅している人、または家庭やコミュニティでの差し迫った用事を中心に 1 日を組み立てている 人への配慮と思いやりを示します。

これは、ミーティング の録画を共有すること、テキスト・通話・Slack メッセージよりも GitLab の Issue やマージリクエストを使うこと、現地の祝日や休暇のステータスに配慮することによって示されます。他者に勤務時間外もオンラインでいるよう圧力をかけるのではなく、ドキュメント をデフォルトにするよう促しましょう。

居心地の悪いアイデアや会話を受け入れる

多様性を受け入れることの一部は、しばしば居心地の悪い会話や状況を進んで受け入れることです。この考え方はインクルージョンの核心でもあり、多数派ではないかもしれない一部の GitLab チームメンバーが直面する問題を取り除く助けにもなります。

私たちは、居心地の悪さを進んで受け入れることが、すべての人にとって安全でバランスの取れたインクルーシブな職場への道だと信じています。自分自身に挑戦し、異なるカルチャーや理解できないことについて、自分自身の先入観や考えに挑戦しましょう。私たちが居心地の悪さを進んで受け入れるとき、単に「気にかけているように見せる」のではなく、目の前の問題を実際に解決することに集中できます。

マイクロアグレッションの影響を理解する

マイクロアグレッションは、単なる無礼で配慮を欠いたコメントをはるかに超えるものです。それは、時間をかけてゆっくりと帰属意識・安全・インクルージョンの感覚を削り取り、人を疲弊させることがあります。

マイクロアグレッションとは何でしょうか。マイクロアグレッションとは、私たち全員が日々のやり取りの中で遭遇し、しばしば無意識に与えてしまう、微妙な、あるいはあからさまな有害な行動であり、時間とともに安全、帰属意識、そして貢献する私たちの能力を侵食します。マイクロアグレッションは誰にでも影響しうますが、十分に認識されていないグループにより深刻な影響を与えることがあります。

GitLab では、誰もが、自分が何者であるかを表現し、有害な言い方をされる心配なく会話に参加できる、安全な作業空間を持つ権利があると信じています。だからこそ、私たちは全員に、何がマイクロアグレッションであるかを意識し、その潜在的な影響に配慮することを奨励したいと考えています。

多様な視点を求める

私たちは、チームメンバーが自分のグループや職種の内外の多様なチームメンバーからフィードバックを求めることが、よりよい決定とより強いチームメンバーの帰属意識につながると信じています。私たちが多様性をどう定義するかについてのさらなるガイダンスは、GitLab の Diversity, Inclusion & Belonging の定義 を参照してください。より異質なグループからのフィードバックは、多様な視点を取り入れ、無意識のバイアスを明らかにするため、しばしばよりよいビジネス成果につながります。

この運営原則が実際に機能している例は、多様な視点を積極的に求めることの価値を示しています。「Brag Document（自慢ドキュメント）」という用語は、個人が自分の業績をドキュメント化することを表すために使われていました。業績のドキュメント化は、チームメンバーの成長にとって極めて重要です。しかし、チームメンバーには、そのドキュメントのタイトルが一部の人を居心地悪く感じさせるかどうかという問いを提起する 心理的安全性 がありました。多様な視点 を求める取り組みとして、いずれかの Team Member and Advocacy Resource Group（TMRG） チャンネルでアンケートが実施されました。投票結果では、投票した人の 100% が別のタイトルを好んだため、タイトルが変更されました。

家族を歓迎する

オールリモートのカルチャー のユニークな要素の 1 つは、コラボレーションしながら相手の自宅を訪れられることです。ミーティングの雰囲気が許すなら、家族やペットが立ち寄って同僚に挨拶するのを気軽に招いてください。家族にやさしい環境を促すために、言葉遣いや汚い言葉の使用に気を配りましょう。

大義のために勤務時間をシフトする

介護、アウトリーチプログラム、地域奉仕は、通常の業務時間が終わるのを都合よく待ってはくれません。大義やコミュニティの取り組みが進行中なら、マネージャーと協力して、最も大きな善のインパクトを与えられる時間帯に対応できるよう勤務時間をシフトすることを気軽に行ってください。こうした大義の最中に他者を支援する同僚のために、すべてをドキュメント化し、彼らが追いつきやすいよう録画を投稿するよう努めましょう。

メンターになる

人々は、サポートされているとき、より受け入れられていると感じます。これを促し、部門を越えた多様な学びを支援するために、GitLab の Internship for Learning プログラムを検討してください。

カルチャーフィットは悪い言い訳

私たちはカルチャーにもとづいて採用したり、一緒に飲みに行きたいからという理由で候補者を選んだりしません。私たちは、このページに詳述されている共有のバリューにもとづいてチームメンバーを採用し、報います。私たちが求めるのはカルチャーフィットではなく、バリューフィット です。 私たちはカルチャーの画一性ではなく、カルチャーの多様性を求めます。言い換えれば、「culture add」＞「culture fit」、あるいは「カルチャーへの貢献のために採用する」ということです。なぜなら、私たちの ミッションは誰もが貢献できること だからです。

職場での宗教と政治

私たちは一般に、公開のフォーラムで政治や宗教を議論することを避けます。なぜなら、少数派の意見を持つ人々を疎外しやすいからです。これは、これらの話題を決して議論しないという意味ではありません。私たちは多様性、インクルージョン、帰属意識を大切にし、すべてのチームメンバーが歓迎されていると感じ、等しく貢献できることを望んでいるので、私たちをよりインクルーシブな会社へと前進させられる運営上の決定については自由な議論を奨励します。

多様性の擁護と政治活動が交差するグレーゾーンが時としてあります。チームメンバーは、グレーゾーンのコミュニケーションでは分別を働かせるべきです。なぜなら、帰属のカルチャーには、私たちの作業環境内の幅広い見解の範囲を尊重することが求められるからです。これは実際には何を意味するのでしょうか。多様性、インクルージョン、帰属意識の問題と、GitLab や GitLab チームメンバーがどう関われるかを浮き彫りにする情報は、ぜひ自信を持って共有してください。私たちの ビジネス行動および倫理規範 に沿って、特定の政治家や政党に言及する記事の投稿は避けてください。

コーヒーチャットや他の同僚との実生活でのミートアップといった社会的な文脈で、個人が政治や宗教を持ち出すことは（理解することを目的とし、判断しないことを目的とする限り）許容されますが、常に潜在的な機微に注意を払い、最善の判断を働かせ、私たちの ビジネス行動および倫理規範 の範囲内にとどまるようにしてください。

私たちは、視点や現地の規範がカルチャーごとに異なりうるグローバルな会社です。多様性、インクルージョン、帰属意識は、世界規模での幅広いインクルージョンに関するものです。質問や懸念があれば、[email protected] または #diversity_inclusion_and_belonging に連絡してください。

風変わりさ

予想外で型破りなことは、人生をより面白くします。 風変わりな贈り物、習慣、行動、視点を祝福し、奨励しましょう。オープンソースは、面白い人々と交流する素晴らしい方法です。私たちは、仕事を自分を表現する素晴らしい方法だと考える人々を採用しようとしています。

安全なコミュニティを築く

GitLab を構成する人々の特性や、彼らがどう自認しているか について、冗談や非友好的な発言を しないでください。 誰もが、GitLab で働くとき、または GitLab コミュニティの一員として、安全だと感じる権利があります。 私たちは、チームメンバーを含むいかなるコミュニティメンバーによる/に対する虐待、ハラスメント、排除、差別、報復も容認しません。 あなたを悪く扱う人々と関わることをいつでも 拒否 でき、居心地が悪いと感じる状況から抜け出せます。

無意識のバイアス

私たちは、無意識のバイアスが誰にでも影響を与えるものであり、それが人間としての私たちと会社に与える影響が大きいことを認識しています。 私たちは、自分自身の暗黙のバイアスを理解し、他者が彼らのバイアスを理解する手助けをする責任があります。私たちはこのトピックを よりうまく扱えるよう継続的に取り組んでいます。

インクルーシブな福利厚生

私たちは 育児休暇 を公開リストにしているので、人々は面接中に尋ねる必要がありません。

インクルーシブな言葉遣いと代名詞

インクルーシブ な言葉遣いをしましょう。 たとえば、「Hi guys」よりも「Hi everybody」や「Hi people」を、「he/she」の代わりに「they」を使いましょう。インクルーシブな言葉遣いについては、Buffer、APA、The Northern Ireland Civil Services などによるよいガイドがいくつかありますが、私たちは網羅的なリストは持っていません。 インクルーシブでないかもしれない新しい言葉が出てきたとき、私たちは先回りして代替案を探すことを好みます。 インクルーシブであることが目標なら、一部の人が問題だと思わないからという理由で変更しない決定をするよりも、一部の人がある言葉に問題を感じたときに語彙を小さく調整するほうが効果的です。 そして、もしミスをしたら（たとえば、うっかり間違った代名詞や時代遅れの言い回しを使ったら）、それを認め、優雅に謝って先へ進みましょう。くよくよする必要はなく、今後そのミスを避けるよう努めればよいのです。 代名詞や、ジェンダー/性的指向に関連する他のトピックについて質問があれば、ジェンダーと性的指向のアイデンティティの定義と FAQ のページもご覧ください。

他者の名前の発音を学ぶ

私たちは自分のアイデンティティの一部を名前に結びつけているので、それが誤って発音されると、インクルーシブでないと感じることがあります。 それが繰り返し起こると、あなたはその人に対して、その人の名前を正しく発音する方法を学ぶことに関心がないというメッセージを、意図せず送っているのかもしれません。これは、あなたが接するすべての人に当てはまります。チームメンバー、顧客、求職候補者、その他の誰に対してもです。

名前が繰り返し誤って発音される人は、自分が重要でない、あるいは自意識過剰だと感じ、それについて声を上げないかもしれません。 他のネガティブな行動には、許可なくその人にニックネームを付けること、または同期通話でその人の名前を使うことを積極的に避けることが含まれます。

自分とは異なる言語やカルチャーの名前を発音するのは難しいかもしれませんが、少しの努力で、名前の発音は誰でも学べます。これを達成する方法には、以下があります。

• プライベートな場でその人に助けを求める。「すみません、あなたの名前を正しく発音できていないと思います。正しい発音を教えていただけますか？」
• Slack の文字と録音による発音ツールを使う。
• YouTube に録画された動画や NameShouts などのオンラインツールを使う。
• 正しい発音を知っている友人やチームメンバーと発音を練習する。
• 名前を発音するのがいかに難しいかについての冗談やコメントは、常に避ける。

ニックネームの使用

たとえば「Robert」の代わりに「Bob」のように、ニックネームを使うことを選ぶ人もいます。 それがその人自身の選択である限り、これはまったく問題ありません。 私たちは、許可なく人にニックネームを割り当てることは避けるべきです。

Slack の発音機能

Slack には、この問題を助ける 2 つの機能があります。発音表記フィールドと、自分の名前の発音オーディオクリップを録音する機能です。私たちはすべてのチームメンバーに、この両方を完了することを奨励しています。プロフィールを編集 して更新してください。

インクルーシブな面接

これは 面接 に関する私たちのページにドキュメント化されています。

インクルーシブなミーティング

ミーティング では、出席している全員に発言し自分の視点を示す機会を与えることで、意識的にインクルーシブでいましょう。これはリモートの環境では特に重要なことがあります。

社内ミーティングでは、質問のためにアジェンダドキュメントを使うことを検討しましょう。たとえば GitLab の AMA では、すべてのミーティングに、GitLab チームメンバーが質問を追加できる番号付きリストがあります。ミーティング中、質問は順番に回答され、議論は同じドキュメントに記録されます。ときには、これらのドキュメントは（ミーティング中に）非常に多くのトラフィックがあり、限られた数の人しかドキュメントを編集できないことがあります。こうした状況では、質問がある人は Zoom チャットに投稿し、ドキュメントを編集できる人はその質問をドキュメントにコピーするのを手伝うべきです。さらに、ドキュメントを編集できる人は、ミーティング出席者がより主体的に会話に貢献できるよう、ドキュメントに追加するのを手伝える質問が誰かにないか、Zoom チャットにも投稿すべきです。

顧客はこの方法で働くことに慣れていません。顧客とのインクルージョンを促すには、参加者に彼らの目標を尋ねる、デモ中は質問のために必ず一時停止する、議論の時間を残す、といったことをしましょう。

従業員が少ない地域へのインクルーシブで公平なポリシー

グローバルに分散していることには、あなたが休んでいるときに誰かが代わってくれるという利点があります。しかし、人口密度はタイムゾーン間で均等ではありません。ポリシーは、密度の低い地域の人々にとっても公平であり続けるべきです。

たとえば、アジア太平洋地域はより多くのタイムゾーンをカバーしますが、チームメンバーは少数です。後のタイムゾーンの人々にタスクを割り当てるアルゴリズムを使うと、すべてのアメリカのタスクが少数のアジア太平洋の従業員に降りかかることになります。これは帰属意識とインクルーシブさを損なう可能性があり、避けるべきです。

イベントを計画するとき、主催者はすべての地域での参加を最大化するために、ロケーションの密度の違いに配慮すべきです。

何かを見たら、何かを言う

グローバルに分散した会社として、私たちには多くの異なる背景やカルチャーを持つチームメンバーがいます。つまり、私たち 1 人ひとりが、仲間に対して敬意を払いインクルーシブであるために、優れた判断を働かせることが重要です。同時に、私たちは時として、誰かを不快にさせる言動をしてしまったことに十分に気づかないことがあります。私たちの仲間がお互いに責任を持ち合い、意図せず、あるいは意図的に何かをしてしまったときには相手に知らせて、その人が学び、自分とは異なる視点への理解を深められるようにすることが重要です。また、私たちの仲間が、私たちが使う言葉や行動によって排除されたり軽んじられたりしていると感じないことも重要です。したがって、私たちは皆、敬意を欠いた、あるいはインクルーシブでない何かを見たときには声を上げる必要があります。

ニューロダイバーシティを受け入れる

ニューロダイバーシティ とは、学習、注意、社交性、気分、その他の精神機能に関する人間の脳の変異を指します。自閉症、ADHD、ディスレクシア、ディスカリキュリア、ディスプラクシア、認知障害、統合失調症、双極性、その他のニューロダイバージェントな機能のスタイルなど、さまざまな神経発達上の状態があります。ニューロダイバージェントな個人は、多くの分野（たとえば サイバーセキュリティ）で 競争優位性 のために活用できる 独自のスキルと能力 をしばしばもたらしますが、ニューロダイバージェントな個人はしばしば差別を受けます。インクルーシブでない採用慣行のために、彼らは時として従来の採用プロセスを通過するのに苦労します。ニューロダイバーシティのインクルージョンのベストプラクティスは、誰にとっても有益であり、GitLab では誰もが貢献できます。ハンドブック、バリュー、戦略、面接プロセスは、誰もが活躍できる能力を支えなければなりません。

GitLab では、さまざまな異なる働き方やコミュニケーションスタイルを採用することでニューロダイバーシティを受け入れ、透明性、デフォルトの働き方としての非同期、事前に記入されたミーティングアジェンダに傾倒しています。これらのベストプラクティスは、ニューロダイバーシティを受け入れるとき、さらに重要になります。情報を消費する複数の方法（テキスト/動画/音声）を提供することで、誰もが自分の好む理解スタイルに関係なく貢献できます。彼らにとって消費しやすい形式で情報を提供するために、チームメンバーに具体的に好みのコミュニケーション方法を尋ねることが重要です。

覚えておいてください。脳の働きはそれぞれ異なります。誰かが予想外の振る舞いをしたとしても、常に 善意を前提 としてください。それはあなたにとっては予想外の振る舞いかもしれませんが、その振る舞いを示している個人にとっては予想外ではないかもしれません。それが多様性の美しさと価値であり、違いを受け入れ、その結果としてより強く、よりよくなることなのです。

私たちはまた、すべてのチームメンバーが 合理的配慮 のプロセスを確認することを推奨します。チームメンバーへの合理的配慮には、ノイズキャンセリングヘッドフォン、より小さなグループセッションの Zoom 通話のスケジューリング、タスクを与えるときに非常に明確で正確な指示と期日を提供すること、さまざまなサポート用ソフトウェアツールを提供することなどが含まれます。

マネージャーができる最も重要なことは、すべてのチームメンバーが自分の仕事をするために 必要なもの をリクエストできるほど 心理的に安全 だと感じられる環境を促進することです。

家族と友人が第一、仕事は第二

長く続く人間関係は 人生の礎 であり、仕事に優先します。ハリケーンの後、家族を 5 日間助けた後に私たちの #thanks チャンネル で誰かが言ったように、「『家族第一』が本当に意味されているカルチャーを提供してくれた GitLab に感謝します」。ハッシュタグを使いましょう。#FamilyAndFriends1st

平等だけでなく公平

公平 vs. 平等: 違いは何か

公平（equity）と平等（equality）という用語は似ているように聞こえるかもしれませんが、一方を実装するか他方を実装するかは、周縁化された人々にとって劇的に異なる結果をもたらしうます。

平等は、各個人または人々のグループに同じリソースや機会が与えられることを意味します。公平は、各人が異なる境遇にあることを認識し、等しい結果に到達するために必要なリソースと機会を正確に配分します。

👣 Iteration

Merriam-Webster はイテレーションを「反復する、または繰り返す行為またはプロセス。たとえば、一連の操作を繰り返すことで、望ましい結果に次第に近づく結果が得られる手順」と定義しています。GitLab では、速いフィードバックを得て、望ましい最終目標に効率的に到達するために、最小の価値あること を行うためにイテレーションします。フィードバックは、社内ユーザー（ドッグフーディング）から得ることも、より広いユーザーコミュニティからのフィードバックを通じて得ることもできます。私たちは各イテレーションを検証して調整しますが、顧客に提供するユーザー体験を犠牲にしてまではしません。

GitLab でイテレーションするとき、私たちはやる必要があるとわかっている仕事を、目標とする最終状態に向けてイテレーションするために、より小さなまとまりに分割します。

1. コードベースにマージする
2. ドッグフーディング
3. グローバルな最適化を確保する（標準化されたシステムを使う）
4. イテレーションの先を計画する

イテレーションは、初日からすべてのユーザーに開かれた機能を出荷することを求めるものではありません。フィードバックは、まず社内ユーザーから得ることができます。ただし、リリースプロセスを進めることはイテレーションではありません。イテレーションはまた、計画を持つことの代替でもありません。私たちはあなたが自分の向かう先を知っていることを期待しますが、そこに到達するためにイテレーションできます。

イテレーションは、加算的（何かを追加する）であることも、減算的（何かを取り除く）であることもあります。最初のイテレーションから除外できる提案をするなら、それらをリンクする別の Issue に変えましょう。

望ましい成果と、それが顧客のペインポイントにどう対処するか、あるいはユーザー体験をどう向上させるかについて明確なビジョンを持つべきですが、計画には効率的でいましょう。重要な部門横断的な相互依存関係を特定する場合を除き、詳細な計画は最初のステップに焦点を当てましょう。動きが遅すぎると感じるかもしれませんが、実装時に速く動けることを確実にするために、計画は極めて重要です。最初のイテレーションで最小限の機能セットを出荷したと感じるなら、あなたは正しくやっています。このバリューは、人々が GitLab に入社したときに最も過小評価するものです。あなたの仕事のプロセスと、あなたがどれだけ達成するかの両方へのインパクトは、予想よりも大きいのです。多くの場合、価値を提供する最もシンプルなバージョンが、最良のものであることがわかります。

GitLab に入社する多くの人は、自分はすでにイテレーションを実践していると言います。しかし、これは理解し採用するのが最も難しいバリューです。人々は、完璧で洗練されたものを提供しないと問題が起こると訓練されています。何かの 1 つの部分だけをやれば、それに戻ってこなければなりません。全体をやるほうが、実際にはそうでないにもかかわらず、より効率的に思えます。完全な全体像が明確でないと、自分の仕事が望むように受け取られないかもしれません。包括的な製品を作るほうがよいように思えます。彼らは、他の GitLab チームメンバーがイテレーションで本当に効果的であるのを見ますが、どう移行すればよいかわからず、絶え間ないイテレーションが品質の低い仕事やより悪い製品の出荷につながりうるという恐れを振り払うのは難しいのです。実際には、ドキュメント化された品質基準を守り続けながら、最小限の価値ある製品を出荷することは可能です。

これを解決する方法は、このプロジェクトに今使える時間で自分が追加できる価値だけを書き留めることです。それは 5 分かもしれませんし、2 時間かもしれません。その時間で完了でき、現状を改善できることを考えましょう。イテレーションは居心地が悪く、苦痛でさえありえます。正しくイテレーションしているなら、そうあるべきです。仕事を以前の状態に戻すことは、ネガティブではなくポジティブなことです。私たちは素早くフィードバックを得てそこから学んでいるのです。小さな変更をすることが、より大きな差し戻しを防ぎ、差し戻しを容易にしました。

しかし、より小さなステップを踏み、より小さくシンプルな機能を出荷すれば、フィードバックをより早く得られます。間違った機能に取り組んだり間違った方向に進んだりして時間を費やす代わりに、最小の製品を出荷し、速いフィードバックを受け取り、軌道修正できます。なぜそれが完璧でなかったのかと人々が尋ねるかもしれません。その場合は、それがイテレーションであったこと、それに「x」の時間だけを費やしたこと、次のイテレーションには「y」が含まれ「z」に準備ができることを伝えましょう。

イテレーションは 成果 と 効率性 を可能にします。

上に埋め込まれた GitLab Unfiltered の動画 で、GitLab 共同創業者の Sid Sijbrandij が、組織でイテレーションを強化するための主要な運営原則を共有しています。

長期的なビジョンから始める

イテレーションには、長期的なビジョンを追求しながら成果を出すことが含まれます。中間的な目標はイテレーションするにつれて変わるかもしれませんが、自分が何に向かって取り組んでいるかのビジョンから始めなければ、成功する可能性は低いでしょう。そのビジョンをイテレーションで出荷することで、それを使う顧客から学び、必要なら ビジョンを調整できます。イテレーションのためのイテレーションは、非効率につながり、望ましい成果を提供しないことがあります。

イテレーションは計画の代替ではない

計画のないイテレーションは、非効率と標準以下の顧客体験につながりえます。イテレーションする前に、私たちは計画する必要があります。計画には以下を含めるべきです。

1. 期限付きの目標: 1 年後にどこにいたいか
2. UX: 私たちが目指しているユーザー体験
3. 品質: セキュリティを含め、何が十分な品質か
4. 成功指標: 特定の時点で私たちが望む利用状況
5. データスキーマ: プロジェクト目標への進捗を測定するために必要なデータスキーマ
6. GTM プラン: どのように市場に出すか
7. イネーブルメント: サポートチームとフィールドチームをいつトレーニングしイネーブルする計画か
8. マーケティング: いつマーケティングを開始するか（リリース時である必要はない）
9. セキュア・バイ・デザイン: 最もセキュアな構成をデフォルトにする

リリースプロセスはイテレーションではない

リリースプロセスを進めることはイテレーションではありません。

リリースプロセスには以下が含まれることがあります。

• ドッグフーディング
• アーリーアクセス
• フィーチャーフラグ を使った段階的リリース
• 開発ステージの進行（experiment から beta など）
• リリース
• アナウンス

開発ステージ はリリースの進捗を示すために使えますが、それ自体はイテレーションではありません。

グローバルな最大値に向けてイテレーションする

私たちが自分のチームを超えた相互依存関係を認識しておらず、組織全体の他者とコラボレーションしていないと、品質、豊かさ、効率性の「ローカルな最大値」に落ち着く成果物のリスクがあります。このローカル化は、主にチーム構造と組織の境界によって規定されます。イテレーションは単一のチーム内で行われることもありますが、そのチームは相互依存関係を特定し、関連プロジェクトに取り組む他のチームと積極的にコミュニケーションし足並みを揃える責任があります。これは、イテレーションが「生煮え」にならず、組織全体で行われている仕事と整合することを確実にする助けになります。

待たない

小さなことで待たないでください。ブログ記事になりそうなものや小さな修正のような価値のあるものがあるなら、すぐに実装しましょう。今この瞬間、すべてが頭の中で新鮮で、あなたにはモチベーションがあります。インスピレーションは生ものです。よりよいバージョンができるまで待たないでください。よりよい動画を録画するまで待たないでください。イベント（GitLab Summit など）を待たないでください。リリースされていない在庫は、管理しなければならず、古くなり、すぐに実装していれば得られたはずのフィードバックを逃すため、負債です。私たちが待たないとき、私たちは何かを解決する目的があるという意図を他者に示します。注: 「待たない」は、グローバルな最大値に向けてイテレーションしないことや、計画を犠牲にすることの正当化に使うべきではありません。考慮すべき相互依存関係がある場合や、イテレーションが顧客向けである場合は、ペースを落とし、GitLab と顧客にとって何が最善かを確実に考慮しましょう。

期日を設定する

私たちは常に期日を設定しようとします。必要なら、スコープを削ります。 特定の日付に予定したものがあるなら、その日付を守ります。たとえば私たちは 133 を超える月次リリースを出荷しました。しかしそのすべてが、私たちが計画したすべての機能を含んでいるわけではありません。 特定の日付にアナウンスを計画していたなら、少なく発表したり、まだ不確実なものを示したりするかもしれません。 しかし私たちが期日を設定するのは、何かを世に出すことが信頼を築き、よりよいフィードバックを与えてくれるからです。

サインオフよりクリーンアップ

イテレーションに関する Sid のインタビュー で議論されているように、承認を待つことは物事を遅くしえます。私たちはこれを、自動化（データベースマイグレーションのパフォーマンステストなど）や事後のクリーンアップ（一貫性のないものが追加されたら Pajamas をリファクタリングする）で防げますが、人々がサインオフを待つ必要がないようにしようとします。イテレーションは初日にすべてのユーザーに出荷することを求めないので、すべての顧客へのマイナスの影響を軽減するために、社内またはベータリリースの後にクリーンアップできます。

できる限り少ないユーザーに影響を与えることから始める

イテレーションは、初日からすべてのユーザーに開かれていることを意味しません。変更を段階的にロールアウトする場合は、以下を優先しましょう。

• 多くのユーザーよりも少数のユーザー
• 外部ユーザーよりも社内ユーザー（ドッグフーディング）
• 遅いフィードバック（セルフマネージド）よりも速いフィードバックの環境（SaaS）

サイクルタイムを短縮する

短いイテレーションは 私たちのサイクルタイム を短縮します。頻繁にマージすることは、マージコンフリクトも防ぎます。

コミュニティの一員として働く

小さなイテレーションは、より広いコミュニティと働くことを容易にします。彼らの仕事は私たちの仕事により似たものになり、私たちの仕事もより速くフィードバックを受けられます。

最小限の価値ある変更（MVC）

私たちは MVC を可能な限り小さくすることを奨励します。常にユーザーの成果を改善するために可能な限り最速の変更を行うようにしましょう。その変更が今あるものより多くの価値を加えると検証できたら、実行しましょう。これは加算的（何かを追加する）であることも、減算的（何かを取り除く）であることもあります。より堅牢な何かを待つ必要はありません。詳細は 製品ハンドブック にありますが、これはすべての職種で私たちが行うすべてのことに当てはまります。特に製品の MVC については、明白なバグやユーザビリティの問題なしに有用な機能を追加していることを顧客と検証するという追加の責任があります。

提案をする

チームとして何かを決定する必要がある場合は、全員の意見を得るためにミーティングを招集する代わりに、具体的な提案をしましょう。提案を持っていることは、全員の時間をはるかに効果的に使うことになります。すべてのミーティングは提案のレビューであるべきです。私たちは 声に出してブレインストーミングするのではなく、自分でブレインライティングすべき です。根底にある問題を述べて、人々が合理的な代替案を提案するのに十分な文脈を持てるようにしましょう。提案を受け取る人々は仲間外れだと感じるべきではなく、提案をした人は、まったく異なる提案が実装されても嫌な気持ちになるべきではありません。早期に関わりたいとか、自分のソリューションが実装されるのを見たいという欲求を、最善の成果に到達することの妨げにしないでください。提案がなくても、それを問題を浮き彫りにすることをやめる理由にしないでください。ただし、よい解決策を思いつかなかったことを述べ、検討した解決策があればそれを列挙してください。

提案をすることで、あなたは仕事とそれを取り巻く文脈への、よりよい可視性も提供します。

この GitLab Unfiltered の動画 で、GitLab 共同創業者の Sid Sijbrandij が、エンジニアリングにおけるイテレーションと、仕事をより小さなコンポーネントに分割するために提案を活用することについて語っています。

すべてはドラフト

GitLab では、コンテンツや提案をドラフトとしてマークすることはめったにありません。すべては常にドラフトであり、変更される可能性があります。すべてがドラフトであるとき、チームメンバーやより広いコミュニティからの貢献が歓迎されます。すべてをドラフトにし、他者は低い文脈を持つと前提する ことで、人々が情報に共有のアクセスを持てるため、混乱を減らせます。

工事中

私たちが抱えるユーザーの数を拡大し続けるにつれて、彼らは安定性と信頼性を期待し続けます。私たちは、その過程で安定性を犠牲にすることなく、長期のために最適化しなければなりません。これは、ユーザーが短期的には不便を感じるかもしれませんが、現在および将来のユーザーが最終的にはよりよい製品を享受することを意味します。

より長期的な計画についてユーザーを啓発することは、小さな変更がどのように段階的により大きなものに成長していくかについての共通理解を生み出す助けになります。たとえば、ドロップダウンが将来どのようにはるかに繊細なソリューションへと進化するかを共有できます。私たちは、計画を明確に伝えるために以下のステップを取れます。

1. 最初の MVC についての文脈を提供するフィードバック Issue を開く（例）
2. ディレクションページが長期的な計画を明確に伝えていることを確認する（例）
3. リリース記事で MVC をアナウンスし、フィードバック Issue とディレクションページにリンクする（例）

ドッグフーディングするときは低いレベルの恥

多くの組織では、完璧でない仕事、不測の事態や反論への対策に無限のサイクルを費やしていない仕事を提出するとき、あなたはリスクを取ることになります。このため、たとえリリースが顧客向けでなく、不完全さのリスクが低くても、何らかの仕事を提示する前に「もし〜だったら？」というシナリオへの準備に多くの時間と労力を投資するインセンティブが働きます。

ドッグフーディングしているとき、それの欠点は明白です。最終的に仕事を提出したものの、それがずっと前に軌道修正される必要があったなら、あなたはイテレーションを通じてそれを改善するのに使えたはずの時間を浪費したことになります。

ドッグフーディングしたり社内で働いたりするときに低いレベルの恥を持つには、完璧になるまで仕事を隠そうとする自然な傾向と戦い、代わりに小さな変更を祝う必要があります。

カルチャーのレンズ

カルチャーの違いは、イテレーションに独自の課題や期待をもたらすことがあります。一部の人にとって、「完璧である必要はない…」のような表現は、カルチャーの規範に反することがあります。私たちは、イテレーションするときに、あなたが本物の自分を持ち込み、共通理解を求めることを奨励します。すべての反復的な試みには、フィードバックを与えること と 心理的安全性 を確保することが必要です。

改善に焦点を当てる

私たちは、優れた企業は、うまくいっていることだけでなく、何を改善できるかに焦点を当てるため、ネガティブに聞こえると信じています。 社内外のあらゆる会話で、私たちは 1 つの質問をするべきです。何を改善できると思いますか？ これは、私たちが成功を認めないという意味ではありません。たとえば、私たちの 感謝を伝える バリューを参照してください。

私たちは会社の将来についてポジティブです。私たちは Short Term Critical And Long Term Optimistic（短期的には批判的、長期的には楽観的、略して STeCALTO）です。

スケールについて意図的になる

まず、スピードと成果のために最適化しましょう（そして、あなたの変更が他のプロセス/機能にどう影響するかについて意図的になりましょう）。それが成功したら、どうスケールするかを考えます。Paul Graham のこの記事 に素晴らしい例があります。

バンドルに抵抗する

チームメンバーがプロジェクトを貢献する最後の（または最高の）機会だと見なさないように、一連の小さなイテレーションをバンドルしたい衝動に抵抗しましょう。多くの小さなプロジェクトをまとめる 包括的なプロジェクトやイニシアチブを作る のは魅力的です。このスコープクリープの現れは、コストを押し上げ、より少ないリスクを促し、進捗よりも（より長いサイクルタイムを通じて）完璧さを促します。私たちがバンドルに抵抗するとき、規模やスコープのために仕事がキャンセルされるリスクを減らせます。バンドルに抵抗することで、関わる人やチームが少なくなるため、必要な調整も減らせます。

双方向ドアの決定をする

ほとんどの決定は元に戻すのが簡単です。こうした場合、Directly Responsible Individual は承認なしに先に進んでそれらの決定をするべきです。元に戻せない場合にのみ、より徹底した議論があるべきです。イテレーションを受け入れ、双方向ドアの決定をすることで、私たちはより効率的になり、より多くの成果を達成します。

提案を変更することはイテレーションではない

何かを出荷せずに変更することは、イテレーションではなくリビジョン（改訂）です。変更が、社内ユーザーまたは限定された顧客グループ のいずれかのユーザーにロールアウトされたときにのみ、フィードバックから学べます。異なる意見にもとづいて提案を変更しているとき、あなたはしばしば時間を浪費しています。小さな変更を素早くロールアウトして実世界のフィードバックを得るほうがよいでしょう。リビジョンを決してイテレーションと呼ばないでください。それはほぼ正反対だからです。

イテレーションを受け入れる

イテレーションを受け入れるためには、私たちは短い時間でできる限り多くを達成しようとしているという姿勢を持つべきです。重要なのは、イテレーションの最終状態でどこに着地するかです。イテレーションの利点は、ユーザーから速いフィードバックを得ることです。複数のイテレーションを必要とする 仮説的な将来の状態 ではなく、最初のイテレーションの終わり に文脈を共有することに焦点を当てましょう。イテレーションを受け入れることで、私たちは段階的なコンポーネントでの創造性を高められます。

小さなマージリクエストをする

コード変更や、ハンドブックでのプロセス変更のためにマージリクエストを提出するときは、可能な限り小さく保ちましょう。ハンドブックに新しいページを追加する場合は、少量の初期コンテンツで新しいページを作成し、Handbook Usage ガイドライン を通じて素早くマージし、その後、後続のマージリクエストで追加のセクションを反復的に追加しましょう。 同様に、GitLab に機能を追加するときは、マージリクエストを作成する前に、マージリクエストが可能な限り小さくなるよう、機能の スコープを縮小する 方法を検討しましょう。

常に意図的にイテレーションする

急速なイテレーションは、よく考えられていない場合、成果 の妨げになりえます。たとえば、私たちのマーケティングのメッセージング（一貫性が鍵となる）、製品カテゴリー（私たちが開発計画を立てている）、組織構造 や 製品スコープの整合（実際の人間のストレスやチームの安定性が関わる）、セールス方法論（私たちがチームをトレーニングした）、そしてこのバリューページ（私たちがすべての GitLab チームメンバーを導くためにバリューを使う）を調整するときです。こうした場合、私たちは承認プロセスに追加のレビューを加えます。それは禁止するためではなく、イテレーションをより意図的にするためです。変更プロセスは GitLab Handbook Usage のページにドキュメント化されており、マージリクエストの承認を通じて行われます。

イテレーションではない 12 のこと

イテレーションはしばしば直感に反し、行うのが難しいものです。イテレーションとは何かを明確にするために、イテレーションでないものの例を見ることが役立ちます。以下は、私たちがイテレーションと間違えられているのを見てきたものの、私たちのイテレーションの定義に合致しない 12 の例です。

1. 品質を下げる、またはゴールポストを下げる
2. ドキュメント化を避ける、または減らす
3. セキュリティで妥協する
4. 推奨される経路でない、またはデフォルトでオンになっていないものを提供する
5. 価値のない何かを出荷する
6. 重要でない項目に焦点を当てる言い訳
7. リリースプロセスを進める
8. 出荷も公開もしないリビジョン
9. 非現実的にきついタイムラインを課す言い訳
10. 計画を避ける言い訳
11. 長時間労働を課す
12. 他者があなたの仕事を直すことを期待する

この GitLab Unfiltered の動画 で、GitLab 共同創業者の Sid Sijbrandij が、イテレーションではないこれら 12 のことのそれぞれについて詳しく説明しています。

👁️ Transparency

可能な限り多くのことについてオープンでいましょう。情報を公開することで、私たちは貢献の閾値を下げ、コラボレーションをより容易にできます。可能な場合は、公開の Issue トラッカー、プロジェクト、リポジトリを使いましょう。透明性はコミュニケーションではありません。何かがハンドブックやどこかに存在しているからといって、それを理解または認識する必要がある人々に対して、再び、あるいはより堅牢な方法でコミュニケーションできないわけではありません。個人レベルでは、情報を共有するときは率直であり、ミスをした、あるいは間違っていたときには認めましょう。何かがうまくいかなかったとき、それは「ここでの カイゼン の瞬間は何か？」と問い、感情を傷つけることなくよりよい方法を見つける絶好の機会です。

上場企業 としてさえ、私たちは透明性という私たちのバリューが成功の鍵になることを知っています。このバリューは、時として従うのが難しいことがあります。あなたは自問するかもしれません。何を共有すべきか、どれだけ共有すべきか、声を上げるべきかどうか。しかし、以下の運営原則に従うことで、必ず時間をかけて常に最大限の透明性を選びましょう。多くの場合、企業のバリューは成長するにつれて薄まります。それはおそらく、彼らが何も書き留めないからです。しかし私たちは、私たちのバリューが会社とともにスケールすることを確実にします。上場企業 として、私たちは会社の全員をインサイダーと宣言しており、これによって私たちは数字などについて社内で透明であり続けられます。透明にできる他のすべてのものは、これからも透明であり続けます。

例外がある場合、デフォルトで公開でない 資料はドキュメント化されます。

デフォルトで公開

GitLab のすべてはデフォルトで公開です。 公開のプロセスは 2 つのことをします。他者が会話から恩恵を受けられるようにすることと、フィルターとして機能することです。時間は限られているので、私たちはより広い人々が恩恵を受けられる会話を優先します。

GitLab における透明性の一例は、この 会社のハンドブック も含む このウェブサイトの公開リポジトリ です。他には、GitLab CE と GitLab EE の Issue トラッカー、そして マーケティング や インフラストラクチャ があります。透明性は GitLab への認知を生み出し、私たちのバリューを大切にする人々を採用することを可能にし、社外の人々からより多く、より速いフィードバックを得られるようにし、彼らとのコラボレーションを容易にします。それはまた、オープンソースの精神に則って、素晴らしいソフトウェア、ドキュメント、例、教訓、プロセスを コミュニティ全体 と世界と共有することでもあり、私たちはそれが捉える以上の価値を生み出すと信じています。

透明性とデフォルトで公開という私たちのバリューに沿って、すべての GitLab チームメンバーの プロフィール は公開であるべきです。公開プロフィールはまた、チーム間のより広範なコラボレーションと効率性を可能にします。そうするために、プロフィール設定 で プライベートプロフィール オプションの下のチェックボックスがオフになっていることを確認してください。プロフィールに本名や所在地を載せることに抵抗がある場合は、これらはプライベートプロフィールでも表示されるので、自分に適切と感じるものに変更してください。

私たちはデフォルトで公開であり、SAFE フレームワーク を持っているので、なぜ物事が透明であるべきかの理由を述べる必要はありません。何かが unSAFE で、公開でない ままにする必要があるなら、そうすることができます。

公開でない

私たちは情報をデフォルトで公開にします。なぜなら 透明性は私たちのバリューの 1 つ だからです。 しかし、成果に焦点を当てることが最も重要 です。 したがって、ある情報のカテゴリーは、そうでない理由がない限り 公開 です。何かが公開でない場合、機密の決定がなされたことを述べ、私たちの Not Public ガイドラインへのリンクを記載した参照がハンドブックにあるべきです。ただし、GitLab Legal and Corporate Affairs がそれが過度なリスクを伴うと考える場合を除きます。私たちは デフォルトで公開でない ものを、私たちのコミュニケーションページにドキュメント化しています。

現在公開されている何かが公開されるべきでない（またはその逆）と思う場合は、関連するページに変更を提案する マージリクエストを作成 して、他者とコラボレーションし、DRI と議論できるようにしてください。コンテンツに 公開でない 情報が含まれている場合は、公開でない特定のセクションを取り除き、それらを社内ハンドブックの独自のページに置き、「公開でない/社内のみ」の注記とともにそこへリンクすることを推奨します。常に、公開できるものは公開で共有しましょう。

情報が公開でない場合、プライバシーへの配慮、契約上の義務、または著者や DRI が指定できる他の理由により、特定の GitLab のロール、チーム、またはチームメンバーとのみ共有される、限定アクセスとして扱われることもあります。 特定の種類の情報は、情報を共有する許可を与えなかったチームメンバーや顧客に関する詳細を含め、デフォルトで限定アクセスになります。

ほとんどの企業は、いかなるミスも受け入れないため、時間とともに非透明になります。代わりに、私たちは慎重さや不作為と、透明性のいずれかを選ぶ必要があるときには、常に透明性の側に立つべきです。もしミスをしたら、私たちは今、会社にとっての透明性の限界が何かを知ったことになるので、これをドキュメント化 すべきです。このルールの唯一の例外は、法的な懸念がある場合です。

一部の情報は 公開でない ため、公開の情報はいくらかの文脈を欠いていることがあります。私たちはそれを認識しておくべきです。

率直さ

率直であることは、お互いに透明であることに関するものです。私たちは、率直でありながら親切である ことで、内なる Ben Horowitz を引き出そうとします。 フィードバックは常にあなたの人ではなくあなたの仕事についてのものです。だからといって、それを与えたり受け取ったりするのが簡単だという意味ではありません。

考えを変えたら明確に伝える

あることを述べた後、方針を変えて別の方向、論点、または結果を支持する場合は、それを明確に伝えましょう。新しいデータによって自分の立場が変わるのは問題ありません。以前の スタンスが 現在の スタンスではないことを明確に伝えることは、他者に明確さを提供し、データ駆動の意思決定を促します。

問題を建設的に浮き彫りにする

適切な人々に（上に向かって）適切なタイミングで（まだ対処可能なうちに）透明でいましょう。ミスをしても心配しないでください。それを修正し、影響を受けた当事者、あなたのチーム、そして CEO に、何が起こったか、どう修正したか、そして必要なら将来のミスを防ぐためにどうプロセスを変えたかを 積極的に 知らせましょう。

透明性は、コストがあるときにも続けてこそ最も価値がある

事実を隠すほうが簡単なときでも、私たちは透明性を実践します。たとえば、多くの企業は、法的措置の可能性が高まるため、あなたの応募を断った本当の理由を伝えません。私たちは正しい理由でのみ人々を断りたいと考え、彼らにこのフィードバックを得ることで成長する機会を与えたいと考えています。したがって、私たちは意思決定に高い基準を自らに課し、私たちが考えたことを彼らに伝えることで正しいことをするという、高まったリスクを受け入れます。他の例は、セキュリティインシデント について透明であることや、ライブブロードキャストに参加し貢献することです。

透明性にはコスト（気が散ること、誤解されることなど）がありますが、大きな利点（生産性、採用、定着、ブランド認知など）もあります。私たちは、透明性にコストがあるときにそれを減らそうとする反射的な反応を防ぐために、コストと利点の間のトレードオフを慎重に天秤にかけるべきです。

信頼できる唯一の情報源（Single Source of Truth）

ほとんどの会社のコミュニケーションと作業成果物をインターネットに公開することで、私たちはすべての GitLab チームメンバー、ユーザー、顧客、その他のコミュニティメンバーにとっての、信頼できる唯一の情報源を持つことになります。私たちは、異なる人々のために異なる権限を持つ別々の成果物を必要としません。

見つけやすさ

私たちの透明性のバリューは、単に情報をすべての人がアクセスできるようにすること以上のものを意味します。パフォーマンスを向上させる ためには、情報がアクセス可能であることを確実にするだけでなく、それが正しい場所に流れ、それを必要とする人々によって 見つけられる ことを確実にすることも重要です。情報の流れに焦点を当てることで、たとえば、あなたは マルチモーダルなコミュニケーション を活用したり、Slack に MR へのリンクを投稿することで ステークホルダーに変更を知らせ続けたり するようになります。

何をだけでなく、なぜを言う

透明な変更には、変更そのものとともに、変更の理由が明確に示されています。これは、人々がすでにいくらかの理解を持っているため、後でより少ない質問につながります。公開の説明のない変更は、多くの追加の質問のラウンドにつながりえます。これはより非効率です。

これはまた、組織の記憶にも役立ちます。今から 1 年後、ある決定がなぜなされたか、あるいはなされなかったかを知りたいとき、その決定を含む Issue や MR が、なぜその決定がなされたかも共有しているのです。 これは チェスタトンの柵 に関連しています。そもそもなぜ何かが存在するのかを知っていれば、それを取り除いたり変更したりすることを提案するのははるかに容易です。

「業界標準」や「ベストプラクティス」のような一般化された用語を使う場合は、文脈なしではそれらが潜在的に曖昧または不透明に見えうるため、必ず文脈を与えてください。

同様に、単一のバリューを単に述べることは、なぜ私たちが特定の決定をしているのかのよい説明ではありません。多くのものが、私たちのそれらのバリューの定義に合致しない「イテレーション」や「効率性」と見なされうます。単一のバリューの名前を言うだけでなく、そのバリューの運営原則にリンクするか、より多くの文脈を提供するようにしましょう。

何をだけでなくなぜを言うことは、複数のバリューに影響しうるトピックをめぐる議論を可能にします。たとえば、退屈なソリューションの効率性 を 顧客の成果 への焦点と天秤にかけるときです。決定が私たちのすべてのバリューと整合しているとき、それらは議論し決定するのが容易です。複数のバリューが関わっているときは、私たちの バリュー階層 を使い、トレードオフを 率直に 議論するほうが、より多くの文脈があれば容易です。

なぜを明確に伝えることは、あなたが 考えを変えたことを明確に伝える ときに、人々が何がどう変わったかを理解する助けにもなります。

なぜを言うことは、他のすべての提案に対して決定を正当化することを意味しません。 DRI は自分の決定に責任があります。 DRI は他の人々を説得する責任はありませんが、変更に対する自分の理由を明確に伝えられるべきです。

GitLab チームメンバーが、十分な文脈とともに「なぜ」を提供しない依頼や資料（MR、ハンドブックなど）に出くわした場合、そのチームメンバーは「なぜ」を入手し、必要なら DRI と協力して、それが十分にドキュメント化され、他のチームメンバーに文脈を与えるためにコミュニケーションされることを確実にする責任があります。「なぜ」がないと、チームメンバーは「なぜ」を推測するかもしれません。これは混乱と非効率につながりうるものです。

再現性

関わるすべての人が、あなたと同じ結論に到達できるようにしましょう。これには 推論 だけでなく、たとえば以下を提供することも含まれます。プロットだけでなく生データ、彼らが行った作業だけでなくタスクを自動化するスクリプト、そして問題を分析しながらステップをドキュメント化すること。たとえ 相手があなたに同意しないかもしれない としても、思考の筋道を他者に透明にするために最善を尽くしましょう。

なぜバリューを持つのか

私たちのバリューは、どう振る舞うかについてのガイドラインを提供し、実行可能であるように書かれています。 それらは、私たちが GitLab チームメンバーに期待する振る舞いのタイプを説明する助けになります。 それらは、私たちが組織でどう振る舞うべきか、そして他者から何を期待すべきかを知る助けになります。

バリューは、GitLab の TeamOps マネジメント哲学に詳述されている、分散した意思決定のための枠組みを提供します。それらは、個人がマネージャーに尋ねることなく何をすべきかを判断することを可能にし、チームが一貫した決定をすることを可能にします。組織全体のチームが意思決定で同じバリューを参照するとき、決定がどうなされるかに一貫性があります。これは、私たちのカルチャー が私たちのバリューによって駆動され続けることを確実にします。

最後に、バリューは、あなたが繁栄し、仕事を通じて並外れた個人的成長を経験する助けになるよう設計された 意識的なカルチャー を生み出します。

5 つの機能不全

私たちのバリューはまた、5 つの機能不全 を防ぐ助けにもなります。

1. 衝突への恐れ 建設的で情熱的な議論よりも人工的な調和を求める => 透明性、特に 率直さ、そしてコラボレーション、特に 短いつま先 によって防がれる
2. 信頼の欠如 グループ内で無防備になりたがらない => コラボレーション、特に 思いやり によって防がれる
3. アカウンタビリティの回避 低い基準を設定する非生産的な振る舞いについて仲間を問いただす責任を回避する => 成果、イテレーション、そして 透明性 によって防がれる
4. 成果への不注意 チームの成功よりも個人の成功、地位、エゴを優先する => 成果 によって防がれる
5. コミットメントの欠如 グループの決定への賛同を装うことは組織全体に曖昧さを生む => 透明性、特に 率直さ によって防がれる

一部の機能不全は、私たちのバリューによって直接対処されていません。たとえば、信頼は私たちのバリューの 1 つではありません。 幸福と同様に、信頼は結果であって、直接的に努力して得られるものではありません。 私たちは、人々に信頼を強制するのではなく、私たちの働き方とバリューが信頼を植え付けることを願っています。信頼は与えられるものではなく、勝ち取られるものです。

運営原則

運営原則は、GitLab チームメンバーが、ある与えられたバリューを確実に実践することを可能にする振る舞いです。 それらは、ある与えられたコアバリューが GitLab で 何を意味し、どう見えるかを明確にします。 この区別を理解することは、GitLab で繁栄するために極めて重要です。 特に、（例として）イテレーションやコラボレーションについての以前の組織の解釈に馴染みがあるかもしれない 新しいチームメンバー にとっては重要です。

運営原則を削除するプロセス

バリューは、私たちが単に行うことだけでなく、よい振る舞いを積極的に駆動するものです。私たちがそれらを削除するとき、それは私たちがそれを信じるのをやめたという意味ではなく、単にそれが振る舞いを駆動する助けに積極的になっていなかったという意味です。もし私たちが運営原則を剪定しなければ、私たちは他のすべての会社のようになるでしょう。理にかなっているが、よりよいカルチャーにつながっていないものです。

1. ハンドブックページから運営原則を 削除 するには、マージリクエストを通じて変更を提出し、マージリクエストの説明であなたの理由を説明してください。
2. GitLab Value Handbook Page のオーナーが、リクエストを承認しマージしなければなりません。

特定のバリューに言及する

ほとんどの会社にはバリューのリストがあります。強いバリューを持たない会社では、人々はバリューに言及するときにしばしば一般化を使います。たとえば、「価値の追加ではない」や「面接でバリューについて高く評価された」などです。強いバリューを持つ会社では、人々は、ある与えられたトピックや状況に当てはまる、特定の関連するバリューに名前を付けます。バリューは、チームメンバーによって個別に理解され適用されたときにのみ強力です。

GitLab のバリューを保ちながら事業をスケールするには？

特定のビジネス上の決定やプロジェクト（報酬 や エンドポイント管理 など）については、GitLab チームメンバーが多くの意見や関心を持ち、フィードバックやコメントを提供したいと思うことがあります。 一方で、プロジェクトの DRI がこれらすべてのインプットを消化し応答するのは難しいかもしれません。 このシナリオでは、あなたはどうすべきでしょうか？

GitLab では誰もが貢献できます。 私たちはチームメンバーがフィードバックを共有し、Issue にコメントを残すことを奨励します。 フィードバックやコメントを残すことは、チームメンバーがあるトピックや会社としての GitLab を大切にしていることを示します。 これらの視点はまた、プロジェクトの潜在的なリスクや問題を明らかにすることもあります。

「彼らには自分の仕事があるのでは？」 というタイプの反応があるべきではありません。 さらに、私たちは「うるさい人（squeaky wheel）」と見なされるチームメンバーを判断すべきではありません。 GitLab では、私たちは 活動ではなく、インパクトを測定します。 チームメンバーが求められる成果を生み出している限り、彼らは自分の時間をどう過ごすかを決める権限を持っています。

一方で、GitLab が規模を拡大するにつれて、私たちは決定を下す必要があり、その決定は全員に同意されないかもしれません。 ある決定やプロジェクトが機微または物議を醸すもので、大量のフィードバックを受ける場合、プロジェクトの DRI が対処するのは難しいことがあります。 こうした場合、タイムラインにタイムボックス化されたフィードバックを組み込むのが最善です。

DRI がシチューに入れる赤いジャガイモと金色のジャガイモのどちらかを決める必要がある仮説的な例では、彼らは次のような趣旨の Issue を作成するでしょう。

私たちはシチューに入れる赤いジャガイモと金色のジャガイモのどちらかを決めています。水曜日 2020-07-15 に食料品店に注文を出せるよう、火曜日 2020-07-14 までに決める必要があります。その時点までインプットとフィードバックを集めます。Jane が DRI で、その時点で得られたすべての情報をもとに 2020-07-14 に決定を下します。これが私たちが決定に使う枠組みです。

• 考慮すべきアレルギーはあるか？
• 1 ポンドあたりのコスト
• チームメンバーの好み

決定が下されたら、それがシチューに入るものになります。

この方法は、チームメンバーが意見を聞いてもらえたと感じることを確実にしながら、タイムラインを脱線させない生産的なフィードバックを引き出すのに 効果的であることが示されています。

なぜ私たちのバリューは公開なのか

企業は GitLab のバリューをコピーして実装することを奨励されています。それらはクリエイティブ・コモンズであり、一字一句コピーできます。

私たちは 多くの理由 から、私たちのバリューを公開にしています。会社のバリューを共有するチームには、大きな力と効率性があります。誰かを組織に採用した 後 までバリューを隠すことは、賢明な戦略ではありません。

すべての人が私たちのバリューを見て、それらに整合していると感じるわけではありませんが、それで問題ありません。バリューを公開にすることは、見込みの雇用主についてデューデリジェンスを行う求職者の時間への敬意を示します。GitLab のバリューに整合している人々が 空いている求人 に応募するとき、これは私たちの採用チームが 面接プロセス を通じて候補者をより効率的に進めることを可能にします。

バリューに関する GitLab Unfiltered のインタビュー で、GitLab 共同創業者の Sid Sijbrandij は次のような文脈を語っています。

企業はあなたに白紙の小切手を書くよう求めるかもしれません。彼らは言うでしょう。「私たちの組織に加わってください。そしてここにいる間は、私たちのバリュー、私たちの働き方、私たちの戦略に賛同する必要があります。それはとても本質的で、私たちのアイデンティティの一部なのです！」

しかしこうした企業は、それを評価する機会を前もって与えてくれません。私にはまったく意味がわかりません。もし人々があなたのバリューを共有することがそれほど重要なら、それを公開しておくべきです。

階層

時として、バリューは互いに矛盾しうます。私たちのコアバリューと一貫性を保ちながら、特定の状況で何をすべきかについての混乱を解消するために、この階層を念頭に置いておくと役立ちます。

階層を重み付けのシステムだと考えてください。階層の上位にあるバリューが、自動的に下位のバリューを上書きするわけではありません。いくつかの例を挙げます。

• ある変更が透明性にはポジティブに、効率性にはほぼ同じ量だけネガティブに影響する場合、透明性は効率性よりも階層の上位にあるので、私たちは前に進みます。
• ある変更が多様性に大きなポジティブな影響を与えるが、イテレーションにはネガティブに影響する場合、多様性はイテレーションよりも階層の下位にありますが、全体的な影響がネガティブよりもポジティブなので、私たちは前に進みます。

バリューに関する GitLab Unfiltered のインタビュー で、GitLab 共同創業者の Sid Sijbrandij は次のような文脈を語っています。

それは少なくともいくらかの緊張を和らげる試みです。それは絶対的ではありません。バリューを二者択一だと考えると、うまくいきません。常に解釈があり、考慮すべき大きさが常にあります。

私たちは、最終的には成果が最も重要だということを明確にするために階層を作りました。たとえば、私たちは透明であるために透明であろうとはしません。私たちは透明性において過激ではありません。私たちがそれをするのは、それがよりよい成果につながると考えているからです。

こうした階層は本当に重要です。それらはすべての議論を未然に防ぐわけではありませんが、助けになります。

私たちのバリューを更新する

私たちのバリューは、頻繁に、そして必要に応じて更新されます。誰もがそれらを改善する提案をすることを歓迎されます。更新するには、マージリクエストを作成し、それを CEO にアサインしてください。チームメンバー または コアチーム の場合は、#values Slack チャンネル に MR へのリンクを投稿してください。これらのグループの一員でない場合は、@sytses に X/Twitter のダイレクトメッセージを送ってください。

バリューのコンピテンシー

コンピテンシー は、チームメンバーに学んでほしいことのための、信頼できる唯一の情報源（SSoT）の枠組みです。

1. 私たちは、他者を助けるために行動し、可能な限り最善の成果を達成するために他者（社内外双方）のインプット（助けとフィードバックの双方）を取り入れるとき、コラボレーションを示します。
2. 私たちは、お互い、顧客、ユーザー、投資家に約束したことを実行するとき、顧客のための成果を示します。
3. 私たちは、正しいことに取り組み、必要以上のことをせず、仕事を重複させないとき、効率性を示します。
4. 私たちは、誰もが活躍できる環境を育み、GitLab があらゆる背景や境遇の人々が自分の居場所だと感じ貢献できる場所であることを確実にするとき、多様性、インクルージョン、帰属意識を示します。
5. 私たちは、最小で実行可能かつ価値あることを行い、フィードバックのために素早く世に出し、そのフィードバックにもとづいて変更を加えるとき、イテレーションを示します。
6. 私たちは、可能な限り多くのことについてオープンで、貢献の閾値を下げ、コラボレーションをより容易にするとき、透明性を示します。

GitLab での Diversity, Inclusion, & Belonging に関連するトピックでスキルを向上させたり知識を広げたりしたい場合は、私たちのリソースをチェックしてください。

• アライになる
• インクルーシブであること
• バイアスを認識する

すべての CREDIT バリューのコンピテンシーは、Job Levels リソースでロール別に概説されています。

どのように私たちのバリューを強化するのか

あなたが報いるどんな振る舞いも、あなたのバリューになります。私たちは以下によってバリューを強化します。

1. 昇進 に使い、アナウンス時に全社に伝える基準。

2. 採用 の際に私たちが選択するもの。

3. オンボーディング の際に私たちが強調するもの。

4. 年次報酬レビュー に使う基準。

5. 意思決定 をする際に私たちが参照するもの。

6. 魚は頭から腐る ので、E グループが会社に示す模範。

7. 私たちのバリューのアンバサダー として、私たちがすべてのチームメンバーに期待するもの。

8. 詳細を追加するコミットの流れ で、それらを 最新に保つ こと。

9. 私たちがお互いに 360 度フィードバック を与える振る舞い。

10. 私たちが 称賛する 振る舞い。

11. 裁量ボーナス に使う基準。

12. オファーレター に含めるもの。

13. パフォーマンス不足を管理する ために使う基準。

14. 人々を解雇する ときに私たちが行うこと。

15. GitLab Summit でバリュー賞を授与すること。

16. CEO Shadow プログラム を通じて、GitLab チームメンバーと 資格のある個人 に会社のあらゆる側面への透明性を提供し、彼らが部門を越えてよりよく関わりコラボレーションできるようにすること。

17. Crucial Conversations トレーニング で行ったように、コースの学びを私たちのバリューに結びつけること。

18. 私たちが使うソフトウェアのデフォルト設定（たとえば: スピーディーミーティング、ドキュメント共有、アジェンダなど）。

19. GitLab の機能で私たちのバリューを強化すること。たとえば Iterations 機能。

20. ビデオ通話で私たちの バリューのバーチャル背景 の 1 つを適用すること。

21. 私たちの GitLab Song Book。歌詞はしばしば GitLab のバリューに言及しています。

22. E グループのオフサイト で定期的にバリューのエクササイズを実施すること。

私たちのバリューを強化する最も重要な瞬間は、個々のチームメンバーに最も影響を与える決定、つまり採用、昇進、ボーナスです。だからこそ、GitLab のすべての昇進ドキュメントは全社に共有され、その中核構造としてバリューを使っています。

ネガティブなフィードバックでは、私たちは問題が何であるかについて具体的であるべきです。たとえば、誰かが「バリューを実践していない」と言うことは役に立ちません。

あなたのバリューとは、あなたが採用する基準、人々を称賛する基準、そして昇進させる基準です。定義上、こうした場面であなたが行うこと が あなたのバリューです。それはあなたがバリューだと言うものではありません。バリューは、私たちの 採用 プロセス、私たちの職務プロファイル、私たちの レビュープロセス の明示的な一部であるべきです。

私たちが ボーナス や 昇進 を与えるとき、それらは常にバリューに結びついています。それが極めて重要なことです。そこでそれらを強化すれば、それがあなたにできる最も強力なことです。 — Sid Sijbrandij, GitLab 共同創業者

バリューが実践されていない場合にすべきこと

バリューの侵食は、無関心や無気力が容認されたときに起こりえます。それはまた、個人がバリューを「会社のバリュー」ではなく「自分のバリュー」と解釈することで望ましくない振る舞いを正当化したときにも起こりえます。たとえば、チームメンバーが、仲間とプロフェッショナルにコラボレーションしないことを正当化するために、個人の効率性の重要性を語ることがあります。これは、効率性とコラボレーションの観点で私たちがチームメンバーに期待することではありません。

ある与えられたシナリオでバリューが実践されていないと感じる場合は、声を上げ、敬意ある方法で文脈を尋ねてください。バリューの衝突を乗り越えることは、他のチームメンバーからの 善意を前提とする ことから始まります。問題を議論するときは、関連するバリューや運営原則へのリンクを提供しましょう。あるバリューの解釈について混乱や意見の相違がある場合は、GitLab の #values Slack チャンネル（GitLab チームメンバー向け）で議論を浮き彫りにするか、X/Twitter で @gitlab を @メンションしてください（GitLab で働いていない人向け）。

バリューに関する GitLab Unfiltered のインタビュー で、GitLab 共同創業者の Sid Sijbrandij は次のような文脈を語っています。

GitLab で難しい決定に直面するほぼ毎回、それはバリューが衝突しているからです。それは二者択一の論理ではありません。それには会話が必要で、ときには明白な答えがありません。私たちは、お互いに敬意を持って話し合い、DRI が最終的な決定を下すことを信頼することによってのみ、解決に到達できます。

プレイする許可

私たちのバリューから、私たちは明白ないくつかの振る舞いを除外しました。私たちはそれらを プレイする許可（permission to play） の振る舞いと呼んでいます。

1. 誠実で正直であること。
2. 頼りになり信頼できること。
3. 約束を守るよう努めること。約束を守れないかもしれない場合は、そう疑った時点ですぐに積極的にコミュニケーションすること。
4. 私たちのチームメンバー、ユーザー、顧客の信頼に値すること。
5. 組織全体の成功にコミットすること。
6. 会社、私たちのチームメンバー、私たちの顧客、ユーザー、投資家の最善の利益のために行動すること。
7. GitLab にとって最善の決定をすること。
8. 法律に従って行動すること。
9. えこひいきは 恨みを生み、従業員の士気を破壊し、よいパフォーマンスへの逆インセンティブを生む ので、それを示さないこと。誰にでも公平である方法を探すこと。

政治的な駆け引きは GitLab のバリューに反する

私たちは、人々が GitLab で政治的な駆け引きをすることを望みません。

政治の一例は、人々が提案を議論する際に、それが誰の提案かに過度に焦点を当てることです。 これは 信念バイアス の現れであり、私たちは議論の強さを、それが結論をどれだけ強く支持するかではなく、私たち がその結論をどれだけ強く支持するかによって判断してしまいます。 提案は、誰がそれを提案したかではなく、その内容によって評価されるべきです。 別の例は、他者に好かれていることや多くの同盟を持っていることにもとづいて人々が昇進することです。私たちは、人々が自分の成果にもとづいて昇進することを望みます。私たちはコラボレーションを大切にしますが、それは単に人々に好かれているから昇進することとは異なります。

以下は、政治的な作業環境と非政治的な作業環境のいくつかの属性です。GitLab は非政治的なものを維持する計画です。

バリューは選択をする

バリューは選択をし、選択を明確にします。よく選ばれたバリューには、擁護できる反対のものがあります。たとえば Apple は、透明性よりも秘密主義を、イテレーションよりも製品の完璧さを大切にしています。彼らは私たちの反対のバリューの周りで構築することで成功しています — ただし、その結果は非常に異なる会社になっています。

バリューでないもの

• オールリモート はバリューではありません。それは、透明性、効率性、成果、そして多様性・インクルージョン・帰属意識という私たちの バリューを実践する 助けになるため、私たちが行っていることです。

新しいチームメンバーからの質問

すべての 新入社員との GitLab 101 セッション で、私たちは私たちのバリューについて議論します。私たちは質問と回答を GitLab カルチャーに関するよくある質問 にドキュメント化しています。

新しいチームメンバーは 新しいリモートの役割を始めるための GitLab のガイド を読み、GitLab Unfiltered YouTube チャンネル 内のバリューを中心とした インタビュー を参照すべきです。

ミッション

私たちの ミッション は、誰もが、私たちの世界を動かすソフトウェアに貢献し、共創できるようにすること です。このミッションが私たちの道を導き、私たちはその道に沿って私たちのバリューを実践します。

懸念の緩和

私たちには、私たちの 懸念の緩和（Mitigating Concerns） をドキュメント化したページがあります。私たちのバリューの多くは、これらの懸念のいくつかを緩和する助けになります。

ページのソースコードを見る - ページの編集 - please contribute.