Enterprise 内で organization を構築するには複数のオプションがあります。 各アプローチには長所と短所があり、Enterprise にとって最適な構造は、規模やセキュリティの制約など、ビジネスの特性とニーズによって異なります。 現在のカルチャではなく、作成するカルチャに戦略を合わせることをお勧めします。 コラボレーションとインナーソーシングの観点から進める場合は、適宜、ツールを構築します。 その後、ツールは、阻害要因として機能するのではなく、文化的変化に役立つ可能性があります。
この記事では、GitHub の推奨事項の重要なポイントをまとめています。 詳細については、「参考資料」セクションを参照してください。
組織の数を最小限に抑える
一般に、GitHub では、作成する Organization の数を最小限に抑えることが推奨されます。
- Organization のメンバーは簡単にリソースを見つけてコミュニケーションできます。これにより、コラボレーション環境が促進されます。
- 通常は organization を削除するよりも追加する方が簡単であるため、将来的により柔軟に対応できるように、organization を少数から始めることをお勧めします。
- Organization を削除することははるかに困難であり、多くの場合、移行が必要になり、チームが慣れ親しんだ柔軟性が低下します。
複数の organization が必要になるのはどのような場合ですか?
一部のお客様には複数の organization が必要です。
- 複数の organization を作成する主な利点は、それぞれに個別のポリシー、設定、要件を構成できることです。
- Organization 所有者は常に、その Organization が所有するすべてのリポジトリにアクセスできます。 会社の規模が大きく、すべてのリポジトリにアクセスできる所有者を設定すべきではない場合は、複数の organization を作成することを検討してください。
- Enterprise 内に新しい organization を作成する場合の固定かつ透明性の高い規則を作成して適用することをお勧めします。 これにより、誰もが各 Organization の目的と、どの資産がどこにあるかをより簡単に理解できるようになります。
さまざまなお客様が、多数の organization とその organization 内のアクセス許可に対してさまざまな設定を使って成功を収めています。 オプションを確認するには、「エンタープライズ内の組織を構成するためのベスト プラクティス」を参照してください。
Organization 内のベスト プラクティス
Enterprise の各 organization 内で、organization 所有者にベスト プラクティスに従うよう促す必要があります。
- 複数の所有者を追加する: organization に所有者が 1 人しかない場合、その所有者に連絡できないと、その organization のプロジェクトにアクセスできなくなるおそれがあります。 誰もプロジェクトにアクセスできなくなることがないようにするには、各組織内の少なくとも 2 人が所有者ロールを持つようにすることをお勧めします。
- チームを使う: チームを使うと、ユーザー グループのアクセス許可、コードの所有権、通知を管理できます。 認証に ID プロバイダー (IdP) を使う場合は、IdP を通じてチーム メンバーシップを管理することを強くお勧めします。 「チームの作成」を参照してください。
- Organization 所有のリポジトリで共同作業する: 可能な限り、ユーザー所有のリポジトリでのコラボレーションを最小限に抑えます。 組織所有のリポジトリにはより高度なセキュリティと管理機能が備わっており、エンタープライズのメンバーシップが変更されても引き続きアクセスできます。
次のステップ
会社の目的の構造に合わせて organization を作成し、ユーザーのアクセスを管理し始めました。 次に、必要なときに GitHub Support を使ってヘルプを取得する方法について学びます。 「Enterprise サポートの概要」を参照してください。
参考資料
- エンタープライズ内の組織を構成するためのベスト プラクティス
- the GitHub Blog の「GitHub Enterprise Cloud を使う organization とチームのベスト プラクティス」
- GitHub リソースの「GitHub Enterprise Cloud で organization を使うための戦略」