健全な制約のみを受け入れる

はじめに

多くの企業は平均へと回帰し、時間とともに減速します。企業が成長し成熟するにつれて必要となる変化もありますが、すべての変化が避けられないわけでも、受け身のままに起こるべきものでもありません。GitLab が成長するにつれて、私たちは自分たちの運用のしかたと、それがどのようにスタートアップの俊敏さでの運用を続けることを可能にしつつ、スケールする企業としての効率を実現するかを意識しています。これは効率の鍵であり、イテレーションを可能にし、結果を推進する助けとなります。また、スピードを維持しサイクルタイムを管理する中で、進捗を見ることにも役立ちます。

スタートアップであり続けることを選ぶことの重要性

私たちは成熟のマイナス面を避けようとします。なぜなら、これにより結果を達成し、私たちの多くの懸念を緩和することがよりよくできるからです。それはまた、より確立された企業をしばしば悩ませる多くの協調の逆風をかわす助けにもなります。詳しくは Still a startup ページを参照してください。

不健全な制約に抵抗する

1. スタートアップのように運用するために、私たちは組織内でスタートアップのエートスを強化する方法を見つけます。私たちは、いまだにスタートアップであるあり方を文書化します。
2. 私たちは GitLab のハンドブックを通じて情報を共有します。ハンドブックの 2000 ページを超えるテキストは、チームメンバーがどう運用すべきかについて、ルールではなくガイドラインを提供します。情報は簡単に共有され、アクセスできます。何かを更新する必要がある場合、すべてのチームメンバー（さらにはより広いコミュニティのメンバーでさえ）が変更を提案する権限を持っています。
3. 私たちには、プロジェクトの成功だけでなく、その成果につながるプロセスの最適化についても Accountable な directly responsible individuals (DRIs) がいます。
4. 私たちは、より成熟した企業が行ってきたことだからという理由だけで、運用のしかたに重要な変更を加えることはしません。その変更がスタートアップとして運用する私たちの能力に挑戦するものである場合、私たちはしばしばその変更の影響を定量化します。たとえば、私たちが上場企業になる準備をしていたとき、人々は透明性に対する GitLab のスタンスに異議を唱え、情報を共有することのリスクに焦点を当てました。私たちは、チームメンバーの効率、見込み客の認知、人材採用（その他のものに加えて）から得られる透明性の大きな価値を定量化できました。GitLab が透明であるべきかどうかを議論する代わりに、私たちは責任ある透明性をどう維持するかへと会話を移すことができました。
5. 私たちは、起業家的な仕事で卓越する能力を示すチームメンバーを積極的にリクルートし採用します。私たちは、彼らが managers of one として自律性をもって働き続けられる経済的な安定と環境を提供します。
6. 私たちは、スケールしながらもスタートアップのエートスを維持することに成功した、より成熟した企業から学びます。たとえば Apple は「世界最大のスタートアップ」と呼ばれてきました。野心的な目標を達成しタイムラインを守りつつ、引き締まった人員数を管理しています。これは確かにバーンアウトを引き起こします。それは私たちが積極的に注視し、緩和しようとしているものです。
7. 私たちは GitLab のブランドに忠実であろうとします。GitLab は、知識へのアクセス、仕事へのアクセス、そして DevOps プラットフォームを通じて、すべての人に力を与えます。知識の共有の一部には、チームメンバーを超えて透明であることが含まれます。その一例が、FY23-Q1 に公開予定の、私たちの IPO から得た CEO、CLO、CFO による 50 の学びとベストプラクティスのリストです。もう 1 つは、GitLab が公開で IPO をライブ配信した最初の企業となり、インターネット接続を持つ誰もがその体験を共有できるようにしたことです。
8. チームメンバーは、自分が依頼されていることの背後にある「なぜ」を理解する権限を持っていると感じるべきです。もし理解していないなら、理解された目標に向けて速く進めるよう、コンテキストを求めるべきです。
9. 私たちはディレクションページを作成します。たとえば、GitLab Direction や Product Direction - Growth です。人々が何を達成しようとしているかを知っていれば、能動的なディレクションが、物事を遅くしうる受動的な承認を置き換えられます。
10. 私たちは、当面のニーズや短期的な問題に応じて導入されたプロセスや決定に、有効期限を設けます。
11. Issue ではなく、可能な限りマージリクエスト (MR) でディスカッションを始めるのがベストプラクティスです。MR は、提案された特定の変更に関連付けられており、誰もがレビューしオープンに議論できるよう透明です。MR の性質は、アクション可能な問題に対する提案されたソリューションを中心とした議論を促進します。MR はアクション可能であるのに対し、Issue はアクションを起こすのにより時間がかかります。
12. 私たちは、管理上の負担を測定する方法を探します。これは、私たちが運用できるスピードに対する官僚主義や管理業務の影響を理解し緩和する助けとなります。
13. 私たちは、制約を取り除く新しい方法を探求します。これらの制約は、ステップ、制限、または承認でありえます。検討中の制約への挑戦には、次のようなものがあります。
    1. 制約を取り除くことを誰かの仕事にする
    2. 効率のバリューのコアな一部として加える
    3. 制約への最良の挑戦に報いる
    4. 制約への挑戦のエスカレーションプロセス
    5. 変化に最適化する。新しい制約を防ぐことよりも、既存の制約を取り除くことに焦点を当てる。最近の制約は取り除ける。
    6. サイクルタイムを測定する（DevOps だけでなく、状態が変化する他のプロセスについても）
    7. 官僚主義バスターズデー (bureaucracy busters day) を立ち上げる、または官僚主義打破を促す他の方法を見つける
    8. チームメンバーが既存の物事のやり方に挑戦し代替案を提案することを奨励される、制約バスターズデー (constraint busters day)
    9. キックオフを行うなら、レトロスペクティブを行うべきです。もし最初に足並みを揃えるための時間を正当化できるなら、将来のプロジェクトを実装する際に改善できることを振り返り、アクションを取るべきです。
    10. チームメンバーのエンゲージメント調査に関連する質問を加える。たとえば、次のようなものです。
        1. チームメンバーの所要時間は？
        2. ハンドブックのプロセスは、あなたの日々をどの程度制約していますか？
        3. 私たちはいまだにスタートアップですか？
        4. Finance/Legal/People/Security は、あなたが物事をより速く行うことをどの程度助けていますか？
14. プロジェクトやイニシアチブがもはや価値を提供していないと感じたら、それを止めることを提案する
15. プロジェクトやイニシアチブが非効率であれば、その効率を改善する方法を提案する
16. 「ずっとそうしてきたから」は、誰かが決定や方向性に異議を唱えるときの妥当な答えではありません。聖域（sacred cow）を避けてください。
17. 私たちは、GitLab のミッションとビジョンに専心する人々を採用します。Pournelle の官僚主義の鉄則が、これがなぜ重要かを説明しています。

あらゆる官僚的な組織には、2 種類の人々が存在する。

第一に、組織の目標に献身する人々がいる。例としては、教育官僚機構における献身的な教室の教師、NASA の多くのエンジニア・打ち上げ技術者・科学者、さらには旧ソビエト連邦の集団農業管理における一部の農学者やアドバイザーが挙げられる。 第二に、組織そのものに献身する人々がいる。例としては、教育システムの多くの管理者、多くの教育学の教授、多くの教員組合の幹部、NASA 本部スタッフの多くなどが挙げられる。 鉄則が述べるのは、あらゆる場合において、第二のグループが組織の支配権を獲得し維持するということである。彼らがルールを書き、組織内の昇進を支配する。

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