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 チャンネルで @mention もしてください。

Driving Results with CREDIT from GitLab on Vimeo.

🤝 Collaboration（コラボレーション）

結果を出すには、チームメンバーが効果的に協力する必要があります。GitLab では、すぐに自分の目標と関係がない場合でも、他者を助けることが優先されます。同様に、あなたも他者に助けやアドバイスを求めることができ、実際そうすることが期待されています。 GitLab で働いていない人を含め、誰でもどんな話題にも参加できます。仕事の責任者がそのやり方を決定しますが、すべての提案を真剣に受け止め、なぜそれを採用したか、あるいはしなかったかを説明するよう常に努めるべきです。

Kindness（思いやり）

私たちは他者を思いやることを大切にします。人を思いやっていると示すことは、率直に挑戦したりフィードバックを届けたりするための効果的な枠組みになります。思いやりとは、フィードバックを控えたり意見の相違を避けたりすることではありません。これらは専門的な成長や顧客のための結果を出す上で不可欠です。思いやりとは、仕事と人を切り分けることを意味します。誰かの仕事を批判しつつ、その人を尊重することはできるのです。ポジティブなフィードバックはできる限り多く、公開の場で行いましょう。

Share（共有する）

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

誰もが、社内の誰に対してもバリューについて 思い出させる ことができます。解釈について意見の相違がある場合、報復を恐れずに社内のより多くの人にエスカレーションして議論することができます。

問題に直面したときは共有し、助けを求め、情報を進んで開示し、声を上げる ことです。

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

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

ネガティブな フィードバック は、ネガティブさや意見の相違とは異なります。直接的なフィードバックを伴わない場合は、敬意を持って透明性のある形で、公開チャンネルで意見の相違を議論するよう努めましょう。

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

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

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

マネジメントチェーンの上位の人へのフィードバックであれば、グループ環境でネガティブフィードバックを与えてもかまいません。これは、誰もフィードバックの対象外ではないことを示します。

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

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

Say thanks（感謝を伝える）

助けてくれた人を、たとえば #thanks チャットチャンネルで、公の場で認識しましょう。

公の場で感謝するときには、次のことを認識することが重要です。

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

効果的にフィードバックを与える

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

互いを知る

私たちはテキストベースのコミュニケーションを多く用いており、テキストの背後にいる人を知っていれば、対立を防ぎやすくなります。ですから、非公式のコミュニケーションを通じて、たとえばバーチャル coffee chat や GitLab Summit を通じて、お互いを個人的なレベルで知り合うことを推奨します。

部門を越えて手を伸ばす

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

階級を振りかざさない

社内での自分の役職を誰かに思い出させる必要があるなら、何かが間違っています。人々はすでに私たちの意思決定プロセスを知っています。なぜその決定をしているかを説明し、職能に関係なくすべての人を尊重しましょう。これには、アイデアや決定を売り込むために他者の階級（CEO を含む）を使うことも含まれます。

ポジティブな意図を前提とする

私たちは他者の行動について、自然に二重基準を持ってしまいます。自分の間違いは状況のせいにし、他人の間違いは個人のせいにします。この二重基準は基本的な帰属の誤りと呼ばれます。このバイアスを軽減するため、他者とのやり取りでは常にポジティブな意図を前提とし、彼らの専門性を尊重し、あなたが間違いと感じるかもしれないものに対しても寛容であるべきです。

意見の相違があるとき、人々は時に議論の最も弱い点や架空の議論（例: “藁人形論法” ）に対して反論することがあります。論点が誠実に提示されていると仮定し、代わりに相手の立場の最も強いバージョンに対して反論するよう試みましょう。これを「藁」の立場ではなく「鋼」の立場に対して反論すると私たちは呼びます。この概念は「steel man」テクニックから借用したものです。

「鋼」の立場とは、相手の立場の最も効果的なバージョン、彼らが提示したものよりもさらに説得力のあるバージョンに対するものであるべきです。良い「鋼」の立場とは、相手があなたの仮定や結論に反対していても、自分の立場をうまく表現してくれたと感じるようなものです。

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

この記事には、チームに嫌な奴を望まないことについて多くの良い点が述べられていますが、私たちは 嫌な奴 は人の固有の分類ではなく行動のレッテルだと考えています。私たちは分類を避けます。

Say sorry（謝る）

間違いを犯した場合は、できるだけ早く謝りましょう。謝ることは弱さの印ではなく、強さの印です。最も多くの仕事をする人は、最も多くの間違いを犯す可能性が高いです。さらに、私たちが間違いを共有しそれに注目を集めるとき、他者は私たちから学ぶことができ、同じ間違いが他の誰かによって繰り返される可能性が低くなります。間違いには、誰かに対して親切でなかった場合も含まれます。バリューを強化するためには、公の場で親切でなかった場合（たとえば Slack チャンネルで個人やグループに対して親切でない、あるいは非専門的な発言をした場合）に公の場で謝罪することが重要であり、より勇気を必要とします。

エゴを持たない

議論に勝つために自分の主張を守ったり、間違いに固執したりしないでください。あなたはあなたの仕事ではありません。あなたは自分の主張を守る必要はありません。あなたは他者の助けを借りて正しい答えを探さなければなりません。

他者の成功を見る

GitLab 内の多くの人と話した候補者が、他社と比較して最も際立っていたことはこう述べました。ここでは皆がお互いの成功を見たいと願っているのです。

互いに失敗させない

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

人は仕事ではない

提案は常に仕事の例について行い、人については行わないでください。「私のフィードバックに応えなかった」と言いましょう。「あなたは決して聞かない」ではなく。そして、フィードバックを受け取るときは、フィードバックは改善のための最良の方法であり、フィードバックを与える他者はあなたが成功するのを見たがっていることを心に留めておきましょう。

自分でやる

私たちのコラボレーションのバリューは、質問があるとき、批評や助けが必要なときに互いを助けることです。ブレインストーミングしたり、合意を待ったり、自分でできることを 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 をレビューする
私たちの製品をドッグフーディングしてユーザー体験を理解する
マーケティングや営業からの顧客事例を読む
顧客の Fireside chat に参加する
製品機能やロードマップに関する顧客やユーザーからのフィードバックを学ぶ

共創する

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

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

私たちの焦点は顧客の結果を増やすことです。GitLab において顧客の結果を駆動する 1 つの方法は、直接ユーザーに最大の価値を駆動するプラットフォームの強化です。これには Concur 効果を意識する必要があります。

Arvind Narayanan、プリンストン教授は、Blackboard への不満をバイラルなツイートで述べました。

これまで夢見られたあらゆる機能を備えています。しかし、委員会で設計されたものと同様、インターフェースには一貫性がなく、どんなタスクでも少なくとも 15 回のクリックが必要です（しかも初回で正しい順序を覚えていればの話）。

ソフトウェア会社は、自社とユーザーとの間に間接的な層があると、息をのむほど無頓着になります。Blackboard で苦しんだ人は皆、これに同じ反応をするでしょう。「機能を減らしてみては？」

Ryan Falor は Narayanan のツイートを受けて、Concur 効果の定義を投稿しました。

意思決定者が直接のユーザーではない

機能が圧倒的で散漫

ユーザー体験が時間とともに悪化する

具体的な UX の例については、Hacker News のディスカッションを参照してください。

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

顧客の結果は、次のものより重要です:

私たちが作ろうとしているもの。自分たちの計画だけに焦点を当てたら、GitLab.com だけになり、GitLab のセルフマネージド配布はなかったでしょう。これは、すべての機能リクエストに同意することを意味しませんが、既存の計画が、最大の顧客価値を駆動する取り組みの障害になることを許しません。
大きな顧客のリクエスト。大きな顧客のリクエストに応えることはイノベーターのジレンマにつながるため、小規模および将来の顧客への結果にも焦点を当てる必要があります。
既存のスコープ。たとえば、顧客がより良い統合を要求し、統合のコストや手間に不満を述べたとき、私たちは DevOps ライフサイクルのための単一アプリケーションを作るためにスコープを拡大することで応じました。
私たちの仮定。すべての企業は異なる方法で運営されているため、自分たちにとってうまく機能するものが顧客のニーズをサポートすると仮定することはできません。アイデアがあるとき、スケーラブルで非常に関連性の高いソリューションを作るために、複数の顧客と仮定を直接検証する必要があります。
私たちがコントロールするもの。私たちは、それぞれの顧客に最良の体験を提供するよう努め、合理的にコントロールできるすべての側面に責任を持ちます。

活動ではなく影響を測る

私たちは、あなたが何を達成したかを大切にします: 出荷したコード、動かした針、満足させたユーザー、助けたチームメンバー。午後を休んだ人は、責任を持っていた目標や結果に否定的な影響を与えていない限り、何か悪いことをしたと感じるべきではありません。期待に対してパフォーマンスを発揮し、成果を出しているなら、自分が 1 日をどう過ごしたかを弁明する必要はありません。私たちは厳格なルールではなく、チームメンバーが正しいことを行うと信頼します。チームメンバーが現れて最善の仕事をすると信頼します。昨日何時間働いたかを宣言して競争を煽らないでください。働きすぎているなら、マネージャーと話して解決策を議論してください。

Dogfooding（ドッグフーディング）

私たちは自社製品を使用し、ユーザーが使うようにそれを使うことで、より良い顧客の結果につながる改善点を表面化させます。GitLab はビジネス全体で使用できる DevSecOps プラットフォームです。GitLab 内では次のように使用しています。たとえば、エンジニアリングチームは標準的な開発プロセスの一部として Duo Agent Platform を使用しています。これにより、チームメンバーは顧客体験について深い理解を得られます。私たちはまた、次の方法でドッグフーディングしています。

開発組織は GitLab.com を使用して GitLab 自体の DevOps ライフサイクルを管理しています。
すべてのチームメンバーは、このハンドブックを共同作業するために GitLab を使用しています。
私たちはコンテンツやプロセスを Git リポジトリに取り込み、GitLab で管理しています。

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

主体性を与える

私たちは、人々に最も有益だと考えるものに集中する主体性を与えます。会議が興味深く思えず、参加が会議の結果に重要でない場合、参加しないことを選ぶか、ビデオ通話中に他のことに取り組むことができます。あなたが他のタスクに取り組んでいても、通話に残ることは依然として理にかなっているかもしれません。そうすれば、必要なときに他の同僚があなたに ping を送り、迅速に答えを得ることができます。これは、わずか数分間しか関与しない多目的の会議で特に役立ちます。

Challenger mindset（チャレンジャーマインドセット）

現状に挑戦することは目覚ましい結果につながる可能性があります。私たちは決して止まってはなりません。チャレンジャーマインドセットは、ビジネスや解決する問題について大胆で困難な質問を継続的に自分自身に問い、満足を拒むことを要求します。成功するには、革新し、構築する製品の価値で顧客を喜ばせなければなりません。チャレンジャーマインドセットは卓越性の絶え間ない追求を要求します。私たちは粘り強くなければなりません。顧客のための各勝利は、競争市場で見込み客の信頼を得るために使える評判の資本を構築します。競争は資本主義の特徴ですが、社内では GitLab のチームメンバーとして、市場シェアを獲得するために顧客のための最善の結果を達成するよう、内向きに努力を集中する必要があります。

Growth mindset（成長マインドセット）

常に結果が出るわけではなく、これは自己や他者からの批判につながります。私たちは、才能は努力、的を絞ったトレーニング、他者からの学習、仕事を通じての経験、他者からのインプットによって発展すると信じています。機会を探し、謙虚さを保ち、決して満足しないことは、企業として、そして個人としての DNA に刻まれています。私たちは血統ではなく軌跡に基づいて人を雇用するよう努めます。また、好奇心と継続的な学習の文化を育み、チームメンバーが自分自身とキャリアを成長させる機会が提供され、積極的に求められるよう努めています。私たちは、適切な期待と方向性があれば、人々は新しい挑戦に取り組み、期待を超えて成長できると信じています。

Cross-functional optimization（部門横断の最適化）

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

コラボレーションの文脈で、もし誰かがあなたの質問、承認、マージリクエストのレビューでブロックされている場合、直接または他の人を見つけられるよう手助けすることで、彼らをアンブロックすることを優先すべきです。

Embrace Tenacity（粘り強さを受け入れる）

私たちはこれを「目的の持続性」と呼んでいます。The Influence Blog で語られているように、粘り強さとは、自分が信じることへのコミットメントを示す能力です。あなたは自分自身を起こし、ホコリを払い、少しだけ多くのことを学んで、すぐに動き出します。仕事が困難なときに集中とモチベーションを維持し、必要なときに助けを求める能力を私たちは大切にします。

Have Ownership & Accountability（オーナーシップと説明責任を持つ）

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

緊急感

獲得した時間や失われた時間は複利効果を持ちます。他のバリューや私たちのコミュニケーション方法を妥協することなく、結果をできるだけ早く得るようにしてください。そうすれば、結果の複利効果が始まり、次の改善に集中できます。

行動志向で運営する

行動への焦点を維持し、分析麻痺やリスクのない遅く静かな道に陥らないことが重要です。決定は思慮深いものであるべきですが、迅速な結果を届けるには、時折間違いを犯すことを恐れずに受け入れる必要があります。私たちの行動志向は、迅速に軌道修正することも可能にします。他のバリューや働き方を妥協することなく、結果をできるだけ早く得るようにしてください。

意見の相違を持ち、コミットし、提唱する

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

グループの場では、参加者が提案に異議を持ちながらも、何らかの理由で見解を表明しないことがあります。時には、多くの、あるいはすべての個人が異議を持ちながら、声を上げないことを選ぶことがあります。グループから合意が得られないと誰も信じていないからです。その結果、皆がフィードバックを失います。異議はその意見の相違の表現です。しかし、これは難しく、社会的にコストがかかることもあります。フィードバックの表現は、誰もが成長し学ぶ方法であり、意見ではなく事実に基づいています。対立を避けるためや皆に合わせるために単に同意するのではなく、自分の視点を共有してください。

何かについての会話を再開したいときは、自分の主張が以前の会話を踏まえていることを示し、決定が最善の意図で下されたと仮定してください。立っている各決定について、たとえそれを変更しようとしているときでも、結果を達成しなければなりません。変更できない人ではなく、決定を変更できる DRI と話すべきです。

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

意見の相違があり、それが原因で前進できない場合、エスカレーションに合意し、自分のマネージャーの 1 人または両方にエスカレーションしましょう。課題のコンテキストとともに早期にエスカレーションすることで、マネージャーはアンブロッカーとして機能できます。

⏱️ Efficiency（効率）

GitLab における効率とは、材料、時間、エネルギーを無駄にせずに結果を生み出すことを意味します。私たちは、1 人または小さなグループよりも、より広い GitLab コミュニティのためにグローバルにソリューションを最適化します。効率への焦点は、特定の機能に局所的なものではなく、グローバルな性質を持つべきです。グローバルな効率には、顧客、候補者、貢献者との効率も含まれる可能性があります。一貫性は通常、最初はより効率的でプロセスの管理がより効率的なため、効率よりも一貫性を優先しがちです。一貫性のために最適化するときは、減速すべきです。変更を評価する際に全社的なレンズを採るのが、新しいプロセスが GitLab 全体の効率を向上させ、会社全体にとって最良の決定であることを保証する助けになります。

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

Only Healthy Constraints（健全な制約のみ）

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

書き留める

私たちはすべてを文書化します: ハンドブック、議事録、issue。それは、「最も薄い鉛筆は最も鋭い記憶よりも優れている」からです。質問して説明されるよりも、自分の都合の良いときにドキュメントを読むほうがはるかに効率的です。バージョン管理に何かを置くことで、誰もがそれを改善するための提案に貢献できます。

Boring solutions（退屈な解決策）

問題に対して最もシンプルで最も退屈な解決策を使い、“退屈” は “悪い” や “技術的負債” と混同すべきではないことを覚えておきましょう。私たちの組織と製品のイノベーションのスピードは、これまでに追加した複雑さの総量によって制約されているため、複雑さを少しでも減らすことが助けになります。仕事を楽しくするために興味深い技術を選ばないでください。確立された人気のある技術を使うことで、あなたや他の貢献者にとってより安定し、より馴染みのある体験が保証されます。

チーム内の他者の制約を認識する意識的な努力をしてください。たとえば、営業は別の組織に依存するため難しく、開発は将来製品を迅速に改善する能力を維持しなければならないため難しいです。

セルフサービスとセルフラーニング

チームメンバーは最初に自分で答えを探すべきであり、答えがすぐに見つからない、または明確でない場合は、皆が低いレベルの恥を持つべきなので、公の場で尋ねるべきです。新しく発見した情報を書き留めて、コラボレーション、インクルージョン、結果の文書化を実践した上に、続く者がより効率的になれるようペイ・イット・フォワードしましょう。

セルフサービスとセルフラーニングができるとき、チームメンバーは自分自身を成長させる余地が増えます。

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

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

他者の時間を尊重する

会議や承認プロセスで他者に求めている時間の投資を考慮してください。会議を避けるようにし、必要な場合は、できるだけ多くの人にとって参加を任意にするようにしてください。会議には、招待からリンクされたアジェンダがあるべきで、結果を文書化すべきです。許可を求めさせる代わりに、彼らの判断を信頼し、質問があれば相談プロセスを提供しましょう。

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

私たちが使うすべてのドルは、稼ぎ直さなければなりません。会社のお金にも、自分のお金と同じくらい倹約してください。とはいえ、チームメンバーには購入のコストを、会社にもたらす価値と比較して計量してもらいたいと考えています。

購入が、コストに対してあなたの仕事をよりよく達成しビジネスの結果を出す能力をどの程度向上させるかを考慮してください。間接費を下げることは、ビジネスを運営するコストを削減し、他の優先分野に支出をシフトさせます。

この運営原則について、チームメンバーが経費プロセスや期待をよりよく理解できるよう、ガイドラインがあります。

Frugality（倹約）

Amazon が最もよく述べています: 「より少ないリソースで、より多くを達成する。制約は機略、自給自足、発明を生む。人員、予算規模、固定費の増加に追加点はない」。

短い口頭の答え

口頭の質問には短く答え、相手にもっと尋ねるか先に進む機会を与えましょう。

同報を短く保つ

この HBR の研究で言及されているように、1 対多の書面のコミュニケーションを短く保ちましょう。「大多数は、彼らが読むものは長すぎ、整理が悪く、不明瞭で、専門用語に満ち、不正確であるため、頻繁に効果的でないと述べている」。

Managers of one（マネージャー・オブ・ワン）

各チームメンバーが、目標を達成するために毎日のチェックインを必要としないマネージャー・オブ・ワンであってほしいと考えています。チームメンバーには、プロジェクトやイニシアチブを所有する自由が与えられ、成功した結末まで見届けると信頼されています。

チームメンバーがマネージャー・オブ・ワンであるとき、彼らは自分の時間を 1 日にどう配分するかを決定する権限が増えるため、ワークライフバランスが向上します。

厳格さよりも自由と責任

可能であれば、ルールや承認プロセスを課すのではなく、人々に決定する責任を与え、それに対する説明責任を負わせます。明確な目標を持ち、それに対して自分が適切と考える方法で取り組む自由を持つべきです。自由と責任は、プロセスを厳密に守ることよりも、または相互依存を作り出すことよりも効率的です。なぜなら、それらはより速い意思決定速度とより高いイテレーション率を可能にするからです。

チームメンバーが厳格さよりも自由と責任を持つとき、他者を助ける余地が増えます。

間違いを受け入れる

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

最小限の価値ある変更を出荷することで素早く動く

私たちは、月ごとに迅速にイテレーションする継続的な改善を大切にします。タスクが最小限で実行可能で価値あるものでない場合は、スコープを切り詰めましょう。

変化を受け入れる

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

🌐 Diversity, Inclusion & Belonging（ダイバーシティ、インクルージョン、ビロンギング）

ダイバーシティ、インクルージョン、ビロンギングは GitLab の成功にとって基本的なものです。私たちは、誰もが繁栄できる環境を育むための取り組みに大きな影響を与えることを目指しています。あらゆる背景や状況の人々が GitLab を「自分の居場所」と感じ、貢献できるような多次元的なアプローチを設計しています。私たちは、インクルーシブで、すべてのチームメンバーが専門目標を達成するプロセスを平等にサポートする文化を構築することを積極的に選びました。私たちは、コミュニティと会社で、すべての人を歓迎し、過小評価されているグループの参加を増やすよう取り組みます。

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

可能な限り非同期に運営するイニシアチブを取りましょう。これは、同じタイムゾーンにいない、通常のタイムゾーン外を旅行している、または家庭やコミュニティでの差し迫ったコミットメントを中心に 1 日を構成している人々への配慮と思いやりを示します。

これは、会議の録画を共有し、テキスト、通話、Slack メッセージではなく GitLab Issue やマージリクエストを使用し、地元の祝日や休暇のステータスに敏感であることで実証されます。勤務時間外にオンラインであることを他者にプレッシャーをかけるのではなく、ドキュメンテーションをデフォルトにすることを推奨してください。

不快なアイデアと会話を受け入れる

ダイバーシティを受け入れることの一部は、しばしば不快な会話や状況を受け入れる意欲です。この概念は、インクルージョンの中核でもあり、過半数ではない GitLab チームメンバーが直面する問題を排除するのに役立ちます。

私たちは、不快さを受け入れる意欲が、すべての人にとって安全でバランスのとれたインクルーシブな職場への道だと信じています。自分自身に挑戦し、自分の事前の概念や、理解していない異なる文化や物事についてのアイデアに挑戦してください。私たちが不快さを受け入れる意欲があるとき、単に「気にかけているように見える」のではなく、実際に手元の問題を修正することに集中できます。

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

マイクロアグレッションは、単に失礼または無神経なコメントよりもはるかに多くを意味します。それらは、時間とともに帰属感、安全感、インクルージョンを徐々に削り取ることで、人々を消耗させる可能性があります。

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

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

多様な視点を求める

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

この運営原則を実践した例は、多様な視点を積極的に求めることの価値を示しています。「Brag Document」という用語は、個人が自分の業績を文書化する際に使用されていました。業績を文書化することは、チームメンバーの成長に不可欠です。しかし、チームメンバーは、ドキュメントのタイトルが一部の人を不快に感じさせるかどうかを尋ねる 心理的安全性 を持っていました。多様な視点 を求める努力として、Team Member and Advocacy Resource Group (TMRG) チャンネルの 1 つで調査が実施されました。投票結果は、調査対象の 100% が異なるタイトルを好むことを示し、タイトルが変更されました。

家族を歓迎する

オールリモート文化のユニークな要素の 1 つは、コラボレーション中に人の家を訪問できる能力です。会議のテノールが許せば、家族やペットを呼んで同僚に挨拶させてください。家族向けの環境を奨励するため、言葉遣いや冒涜的な言葉の使用に気を配りましょう。

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

介護、アウトリーチプログラム、コミュニティサービスは、通常の営業時間が終了するのを都合よく待ちません。大義またはコミュニティの取り組みが行われている場合、マネージャーと協力して勤務時間をシフトし、最大の良い影響を与えられる期間に対応できるよう歓迎します。これらの大義の間に他者をサポートする同僚にとって、すべてを文書化し、追いつきやすいように録画を投稿するよう努めてください。

メンターになる

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

Culture fit は悪い言い訳

私たちは、文化に基づいて雇用したり、一緒に飲みたいと思うから候補者を選んだりしません。私たちは、このページに詳述されている共有のバリューに基づいて、チームメンバーを雇用し報酬を与えます。私たちは values fit を望んでおり、culture fit は望んでいません。私たちは文化的な順応ではなく、文化的なダイバーシティを望んでいます。別の言い方をすれば、“culture add” > “culture fit”、または私たちのミッションは誰もが貢献できることであるため、「文化への貢献のために雇用する」ということです。

職場での宗教と政治

私たちは一般的に、少数派の意見を持つ人々を疎外しやすいため、公開フォーラムで政治や宗教について議論することを避けます。これは、これらのトピックを決して議論しないという意味ではありません。私たちはダイバーシティ、インクルージョン、ビロンギングを大切にし、すべてのチームメンバーが歓迎されていると感じ、平等に貢献できるようにしたいので、よりインクルーシブな会社へと進む運営上の決定について自由な議論を奨励します。

ダイバーシティの提唱と政治活動が交差するグレーゾーンが時にあります。チームメンバーは、ビロンギングの文化が職場環境内の幅広い視点に対する尊重を求めるため、グレーゾーンのコミュニケーションでは裁量を行使すべきです。実際にはこれは何を意味するのでしょうか？ダイバーシティ、インクルージョン、ビロンギングの問題と、GitLab および GitLab チームメンバーがどのように関与できるかを強調する情報を共有することに権限を感じてください。Code of Business Conduct and Ethics に従い、特定の政治家や政党に言及する記事を投稿することは避けてください。

コーヒーチャットや他の同僚との対面ミートアップなどの社交的な文脈で、個人が政治や宗教を持ち出すことは許容されますが（理解が目的で、判断ではない）、潜在的な敏感さを常に意識し、最善の判断を行使し、Code of Business Conduct and Ethics の境界内に留まるようにしてください。

私たちはグローバルな会社であり、視点や地域の規範は文化によって異なる場合があります。ダイバーシティ、インクルージョン、ビロンギングは、世界規模での広範なインクルージョンに関するものです。質問や懸念がある場合は、[email protected] または #diversity_inclusion_and_belonging に連絡してください。

Quirkiness（奇抜さ）

予期しない非従来的なものは、人生をより興味深くします。奇抜な贈り物、習慣、行動、視点を祝い、奨励しましょう。オープンソースは、興味深い人々と交流する素晴らしい方法です。私たちは、仕事を自己表現の素晴らしい方法だと考える人々を雇用しようとしています。

安全なコミュニティを構築する

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

無意識のバイアス

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

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

私たちは Parental Leave を公開しているため、面接中に尋ねる必要はありません。

インクルーシブな言語と代名詞

インクルーシブ な言語を使ってください。たとえば、「Hi guys」よりも「Hi everybody」または「Hi people」を、「he/she」よりも「they」を好みましょう。Buffer、APA、The Northern Ireland Civil Services など、インクルーシブな言語の使用に関する優れたガイドはいくつかありますが、私たちは網羅的なリストを保持していません。新しい潜在的に非インクルーシブな単語が出てきたら、私たちは積極的に代替を探すことを好みます。インクルーシブであることが目標なら、一部の人がそれを問題と感じている場合に、変更しないと決めるよりも、語彙の小さな調整を行うほうが効果的です。そして、間違い（たとえば、誤って間違った代名詞や時代遅れのフレーズを使うなど）を犯した場合は、それを認め、優雅に謝り、先に進みましょう。それを思い悩む必要はなく、将来その間違いを避けるよう取り組めます。代名詞や性別/性的指向に関連する他のトピックについて質問がある場合は、Gender and Sexual-orientation Identity Definitions and FAQ ページもご覧ください。

他の人の名前の発音を学ぶ

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

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

自分のものとは異なる言語や文化からの名前を発音するのは難しいかもしれませんが、少しの努力で、誰でも名前の発音を学ぶことができます。これを達成するいくつかの方法は次のとおりです:

プライベートな空間で、その人に助けを求める: 「すみません、あなたの名前を正しく発音できているとは思いません。正しい発音について助けてもらえますか？」
Slack の書面と録音された発音ツールを使う。
YouTube に録画されたビデオや NameShouts などのオンラインツールを使う。
正しい発音を知っている友人やチームメンバーと発音を練習する。
彼らの名前が発音しにくいことについて、決して冗談やコメントをしない。

ニックネームの使用

一部の人は、ニックネームを使うことを選ぶかもしれません。たとえば、「Robert」の代わりに「Bob」など。これが彼らの選択である限り、これは完全に許容されます。許可なく人にニックネームを割り当てることは避けるべきです。

Slack の発音機能

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

インクルーシブな面接

これは、面接に関する私たちのページに文書化されています。

インクルーシブな会議

会議では、出席者全員に話したり視点を提示したりする機会を与えることで、意識的にインクルーシブになりましょう。これは、リモート環境で特に重要です。

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

顧客はこのように働くことに慣れていません。顧客とのインクルージョンを促進するには、参加者にゴールを尋ね、デモ中に質問のために間を置き、ディスカッションの時間を残しましょう。

従業員が少ない地域に対するインクルーシブで公正な方針

グローバルに分散していることの利点は、あなたが休んでいるときに他の誰かがカバーしてくれることです。しかし、人口密度はタイムゾーン全体でバランスが取れていません。方針は、密度の低い地域の人々に対しても公正であるべきです。

たとえば、Asia Pacific 地域はより多くのタイムゾーンをカバーしていますが、チームメンバーは少ないです。後のタイムゾーンの人々にタスクを割り当てるアルゴリズムを使うと、すべての American タスクが少数の Asia Pacific 従業員にかかってしまいます。これはビロンギングとインクルーシビティを損なう可能性があり、避けるべきです。

イベントを計画するとき、オーガナイザーはすべての地域での参加を最大化するために、場所の密度の違いに対応すべきです。

See Something, Say Something（何かを見たら、何かを言う）

グローバルに分散した会社として、私たちは多くの異なる背景や文化からのチームメンバーを抱えています。それは、私たち一人ひとりが、チームメイトに対して敬意を持ちインクルーシブになるために、優れた判断を行使することが重要であることを意味します。同時に、誰かを傷つけたことに完全には気づかないことがあります。チームメイトがお互いに説明責任を持ち、意図せずまたは意図的に何かをしてしまった場合、それを学び、自分とは異なる視点をさらに理解できるよう、伝えることが重要です。チームメイトが私たちが使う言葉や行うことによって排除されたり最小化されたりしないと感じることも重要です。したがって、私たちは皆、敬意を持っていない、またはインクルーシブでない何かを見たときに声を上げる必要があります。

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

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

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

脳の働き方は異なる ことを忘れず、誰かが予期しない方法で行動した場合でも、常にポジティブな意図を前提としましょう。それはあなたにとって予期しない行動かもしれませんが、その行動を示している個人にとっては予期されているかもしれません。それがダイバーシティの美しさと価値です。違いを受け入れ、結果としてより強くより良くなることです。

すべてのチームメンバーが Reasonable Accommodation プロセスをレビューすることもお勧めします。チームメンバーへの Reasonable Accommodation には、ノイズキャンセリングヘッドフォン、より小さなグループセッションの zoom 通話のスケジュール、タスクが与えられたときの非常に明示的で正確な指示と期限の提供、または多様なサポートソフトウェアツールの提供が含まれる可能性があります。

マネージャーができる最も重要なことは、すべてのチームメンバーが仕事をするために必要なものについて要求できると感じる十分な心理的安全性のある環境を促進することです。

Family and friends first, work second（家族と友人が第一、仕事は二の次）

長続きする関係は人生の岩であり、仕事よりも先にあります。ハリケーンの後 5 日間家族を助けた誰かが、私たちの #thanks チャンネルで次のように述べました: 「家族第一」が真に意味される文化を提供してくれた GitLab に感謝します。ハッシュタグを使用してください: #FamilyAndFriends1st

平等だけでなく公平

Equity vs. Equality: 違いは何か？

equity と equality という用語は似ているように聞こえるかもしれませんが、一方の実装はもう一方とは劇的に異なる結果を疎外された人々にもたらす可能性があります。

Equality は、各個人または人々のグループに同じリソースまたは機会が与えられることを意味します。Equity は、各人が異なる状況にあることを認識し、平等な結果に達するために必要な正確なリソースと機会を割り当てます。

👣 Iteration（イテレーション）

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

GitLab でイテレーションするとき、私たちは目標とする最終状態に向けてイテレーションするために、行う必要があると分かっている作業をより小さなチャンクに分割します:

コードベースにマージする
ドッグフード
グローバル最適化を確保する（標準化されたシステムを使用する）
イテレーションを超えて計画する

イテレーションは、初日からすべてのユーザーにオープンな機能を出荷することを必要としません。フィードバックは、最初に社内ユーザーから来ることがあります。リリースプロセスを進めることはイテレーションではありません。イテレーションはまた、計画の代わりではありません。私たちはあなたが行く先を知っていることを期待しますが、そこにたどり着くためにイテレーションできます。

イテレーションは加算的（何かを追加する）または減算的（何かを削除する）であるかもしれません。最初のイテレーションから除外できる提案がある場合は、それらをリンクされた別の issue に変換してください。

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

GitLab に参加する多くの人は、すでにイテレーションを実践していると言います。しかし、これは理解し採用するのが最も難しいバリューです。完璧または洗練されたものを届けないと、問題があると訓練されています。何かの 1 つの部分だけを行うなら、戻ってこなければなりません。全体を行うほうが効率的に見えますが、そうではありません。完全な絵が明確でない場合、あなたの仕事はあなたが認識されたいように認識されないかもしれません。包括的な製品を作るほうが良さそうに見えます。彼らは他の GitLab チームメンバーがイテレーションで本当に効果的であることを見ますが、移行する方法を知らず、絶え間ないイテレーションがより低品質の作業や悪い製品を出荷することにつながるという恐れを振り払うのは難しいです。実際には、文書化された品質基準に準拠しながら、最小限の価値ある製品を出荷することが可能です。

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

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

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

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

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

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

イテレーションは計画の代わりにはならない

計画なしのイテレーションは、非効率と平凡な顧客体験につながる可能性があります。イテレーションする前に計画する必要があります。計画には次のものを含めるべきです:

時間制限のある目標: 1 年でどこにいたいか
UX: 私たちが取り組んでいるユーザー体験
品質: セキュリティを含む、十分な品質とは何か
成功指標: 特定の時間に望む使用量
データスキーマ: プロジェクトの目標に向けた進捗を測定するために必要なデータスキーマ
GTM 計画: 市場に出る方法
イネーブルメント: サポートチームと現場チームをトレーニングし有効化する予定の時期
マーケティング: マーケティングを開始する時期（リリース時である必要はない）
Secure by design: 最も安全な構成にデフォルトで設定する

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

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

リリースプロセスには次のものが含まれます:

ドッグフーディング
Early access
feature flag を使用したインクリメンタルリリース
Development stage progression（experiment から beta など）
リリース
アナウンスメント

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

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

チームを超えた相互依存関係を認識せず、組織全体の他者と協力していない場合、品質、豊かさ、効率の「ローカル最大値」に落ち着く成果物のリスクがあります。このローカリゼーションは、主にチーム構造と組織の境界によって定義されます。イテレーションは単一のチーム内で行われることがありますが、そのチームは相互依存関係を特定し、関連プロジェクトに取り組む他のチームと積極的にコミュニケーションし整合させる責任があります。これは、イテレーションが「半焼き」ではなく、組織全体で行われる作業と整合することを保証する助けになります。

待たない

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

期日を設定する

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

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

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

影響を受けるユーザーが最も少ない状態から始める

イテレーションは、初日からすべてのユーザーにオープンであることを意味しません。変更を段階的にロールアウトする場合、次のものを優先してください:

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

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

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

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

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

Minimal Valuable Change（MVC、最小限の価値ある変更）

MVC をできる限り小さくすることを推奨します。常にユーザーの結果を改善する最も迅速な変更を見つけてください。変更が現状よりも多くの価値を加えると検証できれば、実行してください。これは加算的（何かを追加する）または減算的（何かを削除する）かもしれません。よりロバストなものを待つ必要はありません。詳細は製品ハンドブックにありますが、これはすべての職能で行うすべてに当てはまります。具体的に製品の MVC については、明らかなバグや使いやすさの問題なしに有用な機能を追加していることを顧客と検証する追加の責任があります。

提案を作る

チームとして何かを決定する必要がある場合、皆のインプットを得るために会議を呼ぶのではなく、具体的な提案を作りましょう。提案を持っていることは、皆の時間をより効果的に使うことになります。すべての会議は提案のレビューであるべきです。私たちは声に出してブレインストーミングする代わりに自分でブレインライティングすべきです。人々が合理的な代替案を提案するのに十分なコンテキストを持つように、根本的な問題を述べてください。提案を受け取る人は除外されたと感じるべきではなく、提案を作った人は完全に異なる提案が実装されても気を悪くするべきではありません。早く関与したい、または自分のソリューションが実装されるのを見たいという欲望を、最良の結果に到達することの邪魔にしないでください。提案がない場合、それが問題を強調することを止めるべきではありませんが、良いソリューションを思いつくことができなかったことと、検討したソリューションをリストしてください。

提案を作ることで、作業とそれを取り巻くコンテキストへのより良い可視性も提供できます。

この GitLab Unfiltered ビデオでは、GitLab 共同創業者の Sid Sijbrandij が、エンジニアリングでのイテレーション、提案を活用して作業をより小さなコンポーネントに分割することについて会話しています。

すべてはドラフト

GitLab では、コンテンツや提案をドラフトとしてマークすることはほとんどありません。すべては常にドラフトであり、変更の対象です。すべてがドラフトのとき、チームメンバーや広いコミュニティからの貢献が歓迎されます。すべてをドラフトにし、他者がコンテキストが少ないと仮定することで、人々が情報への共有アクセスを持つため、混乱を減らせます。

Under construction（構築中）

ユーザー数を増やし続けるにつれて、彼らは安定性と信頼性を期待し続けるでしょう。私たちは、途中で安定性を犠牲にすることなく、長期的に最適化しなければなりません。これは、ユーザーが短期的に不便を感じる可能性がありますが、現在および将来のユーザーは最終的により良い製品を楽しめることを意味します。

長期計画について教育することは、小さな変更が段階的により大きなものに成長する方法についての共有理解を作る助けになります。たとえば、ドロップダウンが将来どのようにより微妙なソリューションへと進化するかを共有できます。私たちは計画を明確にするため次のステップを取れます:

最初の MVC についてのコンテキストを提供するフィードバック issue を開く（例）
方向ページが長期計画を明確にすることを確認する（例）
リリース投稿で MVC をアナウンスし、フィードバック issue にリンクし、方向ページにリンクする（例）

ドッグフーディング時の低い恥のレベル

多くの組織では、完璧でない作業、または不測の事態や反論のために果てしないサイクルを計画していない作業を提出するとき、リスクを取ります。これにより、リリースが顧客向けではなく、不完全さのリスクが低い場合でも、作業が提示される前に「もし？」のシナリオに備えるために多くの時間と労力を投資するインセンティブが生まれます。

ドッグフーディングしているときの欠点は明らかです: 結局作業を提出するけれど、ずっと前に軌道修正される必要があった場合、イテレーションを通じて改善するのに費やせた時間を浪費しました。

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

文化的レンズ

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

改善に焦点を当てる

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

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

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

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

バンドリングに抵抗する

チームメンバーがプロジェクトを最後の（または最良の）貢献の機会と見なさないように、一連の小さなイテレーションをバンドルする衝動に抵抗してください。多くの小さなプロジェクトをまとめた包括的なプロジェクトやイニシアチブを作ることは魅力的です。このスコープクリープの化身は、コストを引き上げ、より少ないリスクを奨励し、進捗よりも完璧（より長いサイクルタイムを通じて）にインセンティブを与えます。バンドリングに抵抗するとき、規模やスコープのために作業がキャンセルされるリスクを減らします。バンドリングに抵抗することで、より少ない人やチームが関与する可能性があるため、必要な調整も減らします。

二方向ドアの決定をする

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

提案の変更はイテレーションではない

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

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

イテレーションを受け入れるためには、短い時間でできるだけ多くを達成しようとする態度を持つべきです。重要なのは、イテレーションの最終状態でどこに着地するかです。イテレーションの利点は、ユーザーから素早くフィードバックを得ることです。複数のイテレーションを必要とする 仮説的な将来の状態 ではなく、最初のイテレーションの最後 にコンテキストを共有することに焦点を当てましょう。イテレーションを受け入れることで、増分コンポーネントの創造性を高めることができます。

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

コード変更またはハンドブックのプロセス変更のためにマージリクエストを提出するときは、できるだけ小さく保ってください。ハンドブックに新しいページを追加する場合、最初のコンテンツを少しだけ含む新しいページを作成し、Handbook Usage ガイドラインを介して素早くマージし、その後のマージリクエストで追加のセクションを反復的に追加してください。同様に、GitLab に機能を追加するときは、マージリクエストを作成する前に、機能のスコープを削減する方法を検討して、マージリクエストができるだけ小さくなるようにしてください。

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

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

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

イテレーションはしばしば直感に反し、行うのが難しいです。イテレーションが何であるかを明確にするのに、イテレーションでないものの例を見るのが役立ちます。以下は、私たちがイテレーションと誤解されているのを見た 12 の例ですが、私たちのイテレーションの定義には合致しません。

品質を下げる、またはゴールポストを下げる
ドキュメンテーションを避ける、または減らす
セキュリティで妥協する
推奨されるパスではない、またはデフォルトでオンではないものを届ける
価値のないものを出荷する
重要でない項目に焦点を当てる言い訳
リリースプロセスを進めること
出荷または公開しないリビジョン
非現実的にタイトなタイムラインを課す言い訳
計画を避ける言い訳
長時間の労働を課す
他者にあなたの仕事を修正するように期待する

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

👁️ Transparency（透明性）

可能な限り多くのことについてオープンになりましょう。情報を公開することで、貢献の閾値を下げ、コラボレーションを容易にできます。可能な場合、公開の issue トラッカー、プロジェクト、リポジトリを使用してください。透明性はコミュニケーションではありません。何かがハンドブックや他の場所に存在するからといって、それを理解または承認する必要のある人々に再度、またはよりロバストな方法でコミュニケートできないわけではありません。個人的なレベルでは、情報を共有するときに直接的になり、間違いを犯した、または間違っていたと認めましょう。何かがうまくいかないとき、傷つくことなくカイゼンの瞬間がここにあるか？と尋ね、より良い方法を見つける素晴らしい機会です。

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

例外がある場合、デフォルトで公開されない資料は文書化されます。

Public by default（デフォルトで公開）

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

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

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

私たちはデフォルトで公開しており、SAFE フレームワークがあるので、なぜ物事が透明であるべきかについてケースを作る必要はありません。何かが unSAFE で非公開のままにする必要があれば、そうすることができます。

Not public（非公開）

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

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

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

ほとんどの企業は、間違いを受け入れないため、時間とともに非透明になります。代わりに、慎重さや無作為と透明性の間で選択がある場合、私たちは常に透明性の側に立つべきです。間違いを犯したら、私たちはこの会社の透明性の限界が何であるかを知り、これを文書化するべきです。このルールの唯一の例外は、法的な懸念がある場合です。

一部の情報は非公開であるため、公開情報にはコンテキストが欠けている可能性があります。私たちはそれを意識すべきです。

Directness（直接性）

直接的であることは、お互いに透明であることについてです。私たちは Ben Horowitz の内なる声を導き、率直で親切であろうとしています。フィードバックは常にあなたの仕事についてであり、あなた個人についてではありません。それでも、それを与えたり受け取ったりするのが簡単であるとは限りません。

自分の意見が変わったら明確に表明する

ある事を述べた後、コースを変更し異なる方向、ポイント、または結果をサポートする場合、これを明確に表明してください。新しいデータによって自分の立場が変わるのは大丈夫です。以前の 立場が 現在の 立場ではないことを明確に表明することで、他者に明確さを提供し、データ駆動の意思決定を奨励します。

問題を建設的に表面化する

正しい人（上）に正しい時間（まだ実行可能なとき）に透明であってください。間違いを犯したら、心配しないでください。修正し、影響を受ける人、チーム、CEO に 積極的に 何が起こったか、どう修正したか、必要に応じて将来の間違いを防ぐためにプロセスをどう変更したかを知らせてください。

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

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

透明性にはコスト（注意散漫、誤解など）がありますが、大きな利益（生産性、採用、定着、ブランド認識など）もあります。コストがあるときに透明性を減らす反射的な反応を防ぐため、コストと利益の間のトレードオフを慎重に計量すべきです。

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

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

Findability（見つけやすさ）

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

Say why, not just what（何だけでなく、なぜを言う）

透明な変更には、変更自体とともに、変更の理由が明確に示されています。これにより、人々がすでにある程度の理解を持っているため、後から質問が少なくなります。公開の説明のない変更は、より多くの追加の質問につながり、効率が低下します。

これは制度的記憶にも役立ちます: 1 年後に決定が下された理由を知りたいとき、決定を持つ issue または MR にも、決定が下された理由が共有されています。これは Chesterton のフェンスに関連しており、最初に存在する理由を知っていれば、何かを削除または変更することを提案するのがはるかに簡単です。

「業界標準」や「ベストプラクティス」のような一般化された用語を使う場合、コンテキストなしでは曖昧または不透明と見なされる可能性があるため、必ずコンテキストを与えてください。

同様に、単に単一のバリューを述べるだけでは、特定の決定をする理由の素晴らしい説明にはなりません。多くのものが「イテレーション」または「効率」と見なされる可能性がありますが、私たちのバリューの定義に合致しません。単一のバリュー名だけを言うのではなく、バリューの運営原則にリンクするか、より多くのコンテキストを提供してみてください。

なぜを言うことは、複数のバリューに影響を与える可能性のあるトピックの周りの議論を可能にします。たとえば、退屈な解決策の効率と顧客の結果への焦点を計量するときです。決定がすべてのバリューと一致するとき、議論し決定するのは簡単です。複数のバリューが関与しているとき、私たちのバリュー階層を使い、トレードオフを直接的に議論することは、より多くのコンテキストで容易になります。

なぜを明確に表明することはまた、人々が自分の意見が変わったことを明確に表明するときに、何かがどう変わったかを理解する助けにもなります。

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

GitLab チームメンバーが、十分なコンテキストとともに「なぜ」を提供しない依頼または資料（MR、ハンドブックなど）に出会ったとき、チームメンバーは「なぜ」を取得し、必要に応じて DRI と協力して、それが他のチームメンバーにコンテキストを与えるよう適切に文書化されコミュニケートされていることを確認する責任があります。「なぜ」がない場合、チームメンバーは「なぜ」を推測する可能性があります。これは混乱と非効率につながる可能性があります。

Reproducibility（再現可能性）

関与する全員が、あなたと同じ結論に達することを可能にしましょう。これは推論だけでなく、たとえば次のものを提供することも含みます: プロットだけでなく生データ、彼らが行った作業だけでなくタスクを自動化するスクリプト、問題を分析する間のステップを文書化すること。彼らが同意しないかもしれないとしても、思考の流れを他者に透明にするよう最善を尽くしてください。

なぜバリューを持つのか

私たちのバリューは、どう振る舞うかについてのガイドラインを提供し、実践可能になるよう書かれています。これらは、私たちが GitLab チームメンバーに期待する行動のタイプを記述するのに役立ちます。組織でどう振る舞うか、他者に何を期待するかを知るのに役立ちます。

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

最後に、バリューは意識的な文化を作り、これは仕事を通じてあなたが繁栄し例外的な個人的成長を経験するのを助けるよう設計されています。

5 つの機能不全

私たちのバリューはまた、5 つの機能不全を防ぐのにも役立ちます:

対立の恐れ 建設的で情熱的な議論よりも人工的な調和を求める => 透明性、特に 直接性 とコラボレーション、特に 短いつま先 によって防がれる
信頼の欠如 グループ内で脆弱になる意欲がない => コラボレーション、特に 思いやり によって防がれる
説明責任の回避 低い基準を設定する非生産的な行動について同僚を呼ぶ責任を逃れる => 結果、イテレーション、 透明性 によって防がれる
結果への注意不足 チームの成功よりも個人の成功、地位、エゴに焦点を当てる => 結果 によって防がれる
コミットメントの欠如 グループの決定への賛同を装うことは、組織全体に曖昧さを生み出す => 透明性、特に 直接性 によって防がれる

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

運営原則

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

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

バリューは私たちが行うものだけでなく、良い行動を積極的に駆動するものです。それらを削除するとき、それを信じなくなったわけではなく、行動を駆動するのを積極的に助けていなかったということを意味するだけです。運営原則を剪定しなければ、私たちは他のすべての企業のようになるでしょう。理にかなっているけれども、より良い文化につながらないものです。

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

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

ほとんどの企業はバリューのリストを持っています。強いバリューのない企業では、人々はバリューを参照するときに一般化を使うことがよくあります。たとえば、「価値の追加ではない」または「インタビューでバリューでよくスコアした」など。強いバリューのある企業では、人々は特定のトピックや状況に当てはまる特定の関連するバリューに名前を付けます。バリューは、チームメンバーによって個別に理解され適用されたときにのみ強力です。

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

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

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

「彼らは自分の仕事をしないのか？」のような反応はあるべきではありません。さらに、私たちは「うるさい車輪」と認識されているチームメンバーを判断すべきではありません。 GitLab では、私たちは活動ではなく影響を測ります。チームメンバーが必要な結果を生み出している限り、彼らは自分の時間をどう過ごすかを決定する権限があります。

一方、GitLab がサイズで成長するにつれて、決定を下す必要があり、決定はすべての人によって同意されないかもしれません。決定やプロジェクトが敏感または論争的で、大量のフィードバックを受ける場合、プロジェクトの DRI が処理するのが難しい場合があります。これらの場合、タイムラインに時間制限のあるフィードバックを組み込むのが最善です。

DRI がシチューに赤いポテトと金のポテトのどちらを入れるかを決定する必要がある仮説的な例で、彼らは次の感情で issue を作成するでしょう:

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

考慮すべきアレルギーはあるか？

ポンドあたりのコスト

チームメンバーの好み

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

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

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

企業は GitLab のバリューをコピーし実装することを推奨されています。これらは Creative Commons であり、文字通りコピーできます。

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

すべての人が私たちのバリューを見て一致を感じるわけではなく、それは大丈夫です。バリューを公開することで、見込みのある雇用主についてデューデリジェンスを行う求職者の時間に対する敬意を示します。GitLab のバリューに一致する人々がオープンな空席に応募するとき、これは私たちの採用チームが面接プロセスを通じて候補者をより効率的に動かすことを可能にします。

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

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

しかし、これらの企業は事前にあなたにそれを評価する機会を与えません。私には全く意味がありません。人々があなたのバリューを共有することがそれほど重要なら、それを公開してください。

階層

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

階層を重み付けシステムとして考えてください。階層の上位のバリューは、階層の下位のバリューを自動的に上書きしません。いくつかの例を示します:

変更が透明性にポジティブな影響を与えるが、効率にほぼ同じ量でネガティブな影響を与える場合、透明性が効率よりも階層の上位にあるため、私たちは進めます。
変更がダイバーシティに大規模なポジティブ影響を与えるが、イテレーションにネガティブな影響を与える場合、ダイバーシティはイテレーションよりも階層の下位にあっても、全体の影響がよりポジティブだから、私たちは進めます。

Values

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

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

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

これらの階層は本当に重要です。すべての議論を先取りしませんが、助けになります。

バリューの更新

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

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

コンピテンシーは、チームメンバーに学んでほしいことの Single Source of Truth（SSoT）の枠組みです。

最善の結果を達成するために、他者（社内外両方）のインプット（助けとフィードバック両方）を含め、他者を助ける行動を取るとき、私たちはコラボレーションを実証します。
お互い、顧客、ユーザー、投資家に約束したことを行うとき、私たちは顧客のための結果を実証します。
正しいことに取り組み、必要以上に多くを行わず、作業を重複させないとき、私たちは効率を実証します。
誰もが繁栄でき、あらゆる背景や状況の人々が GitLab を「自分の居場所」と感じ、貢献できる環境を育むとき、私たちはダイバーシティ、インクルージョン、ビロンギングを実証します。
最小の実行可能で価値のあることを行い、フィードバックのために素早く出し、そのフィードバックに基づいて変更を加えるとき、私たちはイテレーションを実証します。
貢献の閾値を下げ、コラボレーションを容易にするため、可能な限り多くのことについてオープンであるとき、私たちは透明性を実証します。

GitLab でのダイバーシティ、インクルージョン、ビロンギングに関連するトピックについてスキルを向上させたり知識を広げたい場合は、私たちのリソースをチェックしてください:

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

バリューをどう強化するか

報われる行動はあなたのバリューになります。私たちはバリューを次のように強化します:

昇進に使う基準と、アナウンス時に全社に伝える基準。
採用で選択するもの。
オンボーディング中に強調するもの。
年次報酬レビューに使う基準。
意思決定で参照するもの。
魚は頭から腐るため、E-group が会社のために設定する例。
すべてのチームメンバーに期待することは、私たちのバリューの大使としてです。
詳細を追加するコミットの流れで最新の状態を保つこと。
お互いに 360 フィードバックを与える行動。
賞賛する行動。
裁量ボーナスに使う基準。
オファーレターに含めるもの。
パフォーマンス不足の管理に使う基準。
人を解雇するときに行うこと。
GitLab Summit でバリュー賞を授与する。
GitLab チームメンバーと資格のある個人に、CEO Shadow Program を通じて会社のすべての側面への透明性を提供し、彼らがより部門横断的に関わり協力できるようにする。
Crucial Conversations トレーニングについて行ったように、コースの教訓をバリューにリンクする。
使うソフトウェアのデフォルト設定（たとえば、Speedy meetings、ドキュメント共有、アジェンダなど）。
GitLab の機能、たとえば Iterations 機能で私たちのバリューを強化する。
ビデオ通話でバリューバーチャル背景のいずれかを適用する。
GitLab の Song Book。歌の歌詞はしばしば GitLab のバリューに言及しています。
e-group オフサイトで定期的にバリュー演習を行う。

私たちのバリューを強化する最も重要な瞬間は、個々のチームメンバーに最も影響を与える決定です: 採用、昇進、ボーナス。これが、GitLab のすべての昇進ドキュメントが全社と共有され、バリューをコア構造として使う理由です。

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

あなたのバリューは、雇用するもの、人を称賛するもの、人を昇進させるものです。定義により、これらの場面で行うことが、あなたのバリューです。それはあなたが言うものではありません。バリューは、私たちの採用プロセス、ジョブプロファイル、レビュープロセスの明示的な一部であるべきです。

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

バリューが生きられていない場合に何をすべきか

無関心と無感動が許容されたとき、バリューの侵食が起こることがあります。個人がバリューを「会社のバリュー」ではなく「自分のバリュー」と解釈することで望ましくない行動を正当化するときにも起こり得ます。たとえば、チームメンバーは、専門的に同僚と協力しないことを正当化するため、個人の効率の重要性に話すかもしれません。これは、効率とコラボレーションの観点からチームメンバーに期待することではありません。

特定のシナリオでバリューが生きられていないと感じたら、声を上げ、敬意を持ってコンテキストを尋ねてください。バリューの対立をナビゲートすることは、他のチームメンバーからポジティブな意図を前提とすることから始まります。問題を議論するときに、関連するバリューや運営原則へのリンクを提供してください。バリューの解釈について混乱や意見の相違がある場合は、GitLab の #values Slack チャンネル（GitLab チームメンバー向け）で議論を表面化するか、X/Twitter で @gitlab を @-mention してください（GitLab で働いていない人向け）。

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

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

Permission to play（プレイする許可）

私たちのバリューから、明らかな行動を除外しました。これらを permission to play 行動と呼びます:

真実で誠実であること。
信頼でき頼りになること。
約束を守るようにすること。約束を守れないかもしれない場合、疑った時点で積極的にコミュニケーションすること。
チームメンバー、ユーザー、顧客の信頼に値すること。
組織全体の成功にコミットすること。
会社、チームメンバー、顧客、ユーザー、投資家の最善の利益のために行動すること。
GitLab にとって最善の決定をすること。
法律に従って行動すること。
ひいきを示さないこと。それは恨みを生み、従業員の士気を破壊し、良いパフォーマンスへのディスインセンティブを作るからです。すべての人に公正であろうとする方法を探してください。

政治を行うことは GitLab のバリューに反する

私たちは GitLab で人々に政治を行ってほしくありません。

政治の例として、提案を議論し、誰の提案であるかに過度に集中することがあります。これは Belief Bias の現れであり、私たちは議論の強さを、結論をどれだけ強くサポートしているかではなく、私たち自身が どれだけ強く結論をサポートしているかで判断します。提案は、誰が提案したかではなく、その価値で計量されるべきです。別の例は、人々が他者に好かれているか多くの同盟を持っているために昇進されることです。私たちは人々が結果に基づいて昇進されることを望んでいます。私たちはコラボレーションを大切にしますが、それは人々があなたを好きだから単に昇進されることとは異なります。

以下は、政治的および非政治的な仕事環境の特性です。GitLab は非政治的なものを維持する計画です。

政治的な環境	非政治的な環境
バリューが武器化され、意図された文脈の外で使用される	チームメンバーがポジティブな意図でバリューを活用する
チームメンバーが自己利益によって駆動される	チームメンバーが会社の利益によって駆動される
チームメンバーがサイロで働く	チームメンバーがグローバルに最適化する
人々が領土的な行動を持ち、提案をすぐに攻撃と認識する	人々が短いつま先を持つ
人々が裏部屋の会話で不健全な同盟を持つ	人々が良い意図を持ち、人々と積極的にコラボレーションする
情報が意図的に保留される	情報が早く（しばしば WIP）、すべての関心ある関係者に同時に共有される
人々が議論の最も弱い部分で議論することで、お互いの信頼性を損なおうとする	人々が「鋼」の立場を取り、相手の立場の最も強いバージョンに対して議論する
人々は直接フィードバックを提供しない。代わりに、彼らは思考を保留したり、お互いの背後で話したりする	フィードバックは直接与えられる。これにはマネージャーのチームについてのフィードバックも含まれる
自分の提案を直接ではなくレポートを通じて伝える	フィードバックは、それを持っている人から直接与えられる
提案や仕事を、その内容ではなく、誰が言ったか、誰がやったかで評価する	提案や仕事は、誰がそれに取り組んだかに関係なく評価される
エスカレーションでの透明性の欠如。チームメンバーが、最初に同僚と問題を整合させようとしたり、同僚に知らせたりせずにマネージャーに行く	チームメンバーが、自分の対立を解決するために、フィードバックや要求についてお互いに直接話す。エスカレーションするとき、彼らはそれを効果的な方法で行う

バリューは選択を行う

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

バリューでないもの

オールリモートはバリューではありません。これは、透明性、効率、結果、ダイバーシティ・インクルージョン・ビロンギングという私たちのバリューを実践するのに役立つため、私たちが行うことです。

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

すべての新入社員との GitLab 101 セッションで、私たちはバリューについて議論します。質問と回答は GitLab Culture についてのよくある質問に文書化しています。

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

ミッション

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

懸念の軽減

私たちは Mitigating Concerns を文書化したページを持っています。私たちのバリューの多くは、これらの懸念のいくつかを軽減するのに役立ちます。

原文: https://handbook.gitlab.com/handbook/values/ · 翻訳: 2026/4/25