Enterprise 内の Organization のベスト プラクティスについて
Enterprise 内の Organization を構築するための複数のオプションがあります。 各アプローチには長所と短所があり、Enterprise にとって最適な構造は、規模やセキュリティの制約など、ビジネスの特性とニーズによって異なります。
しかし、現在のカルチャではなく、作成するカルチャに戦略を合わせることもお勧めします。 コラボレーションとインナーソーシングの観点から進める場合は、適宜、ツールを構築します。 その後、ツールは、阻害要因として機能するのではなく、文化的変化に役立つ可能性があります。
Organization の数について
一般に、GitHub では、作成する Organization の数を最小限に抑えることが推奨されます。 Organization の数を減らすことで、コラボレーションとインナーソーシングがさらに促進され、効率が向上します。 実際、多くの企業には、次の理由から、単一の Organization が最適です。
- 検索する場所は 1 つだけなので、単一の Organization 内でリソースを見つける方が簡単です。
- @-mentions は同じ Organization のメンバー間でのみ機能するため、単一の Organization 内でコミュニケーションを取る方が簡単です。
- 誰もがアクセス可能な単一の大規模な Organization の一部であると、コラボレーションとロイヤルティが促進されるのに対し、より小規模な Organization に分けると、チームをより分離させることができます。
Organization 所有者は常に、その Organization が所有するすべてのリポジトリにアクセスできます。 1 人の所有者がすべてのリポジトリへのアクセス権を持つべきではない大規模な会社の場合は、複数の Organization を作成することを検討してください。
複数の Organization を作成する主な利点は、それぞれのポリシー、設定、要件を個別に構成できることです。 を持つことができます。
Organization と会社の構造エンティティ (個々のチームや部署など) の間に一対一の関係を作成することは避けてください。 代わりに、ポリシー、設定、要件を共有できる構造エンティティを単一の Organization にグループ化します。 このアプローチにより、規制上の要件を満たしながらコラボレーションが最大化されます。
通常は Organization を削除するよりも追加する方が簡単なので、少数の Organization から始めることをお勧めします。これにより、今後の柔軟性が向上します。 ビジネスに適したエクスペリエンスをさらに開発した後、必要に応じて追加の Organization を作成できます。
Organization の削除ははるかに困難であり、多くの場合、移行と、チームが慣れてきた柔軟性の低下が必要となります。 多くのお客様は、数を減らすという困難で時間のかかるプロセスを経験した後、多数の Organization を作成したことを後悔するようになります。
Enterprise で新しい Organization を作成するために、一定の透過的なルールを作成して適用することをお勧めします。 これにより、誰もが各 Organization の目的と、どの資産がどこにあるかをより簡単に理解できるようになります。
Organization の構造について
Organization の構造には、主に 5 つのアーキタイプがあります。 アーキタイプは、次の 2 つの決定によって定義されます。
- 単一の Organization と複数の Organization のどちらを使用するか
- すべてのメンバーにすべてのリポジトリへのアクセスを許可するか、チームを使用してリポジトリ アクセスをより細かく管理するか
チームの詳細については、「Team について」を参照してください。
リポジトリに直接アクセスする単一の Organization
最も単純な Organization 構造は単一の Organization であり、メンバーには Organization メンバーシップを介してすべてのリポジトリへの直接のアクセス権利が付与されます。 チームは調整とコミュニケーションに使用できますが、リポジトリ アクセスの管理には使用できません。
この構造は、スタートアップ企業などの小規模企業で誰もが共同作業を行う場合に最適です。 信頼が高い場合は、中規模企業でも機能します。
このアーキタイプを使用するには、Organization の基本アクセス許可を [書き込み] または [読み取り] に設定します。 詳しくは、「Organization の基本レベルの権限の設定」をご覧ください。
リポジトリ アクセスのためのチームを持つ単一の Organization
会社でリポジトリ アクセスをより細かく制御する必要がある場合は、Organization の基本アクセス許可を [なし] に設定し、各チームが特定のリポジトリのみにアクセスできるようにすることができます。
この構造は、中規模企業や信頼の低い小規模企業に最適です。 誰もが共同作業を行う高い信頼を持つ小規模企業の場合、チームの管理は時間の投資に値しない可能性があります。
リポジトリに直接アクセスする複数の Organization
大企業の場合、単一の Organization 内でリポジトリへのアクセスを管理することは、チームであっても手に負えなくなる可能性があります。 このアーキタイプでは、代わりに複数の Organization を利用して、リポジトリ アクセスを管理します。 各 Organization のメンバーは、その Organization のすべてのリポジトリにアクセスできます。
この構造は、一緒に作業する必要のない異なるグループを持つのに十分な大きさの企業に最適です。 この構造は、部署間のコラボレーションが重要な場合ほど役に立ちません。
このアーキタイプを使用するには、前述のようにポリシー、設定、要件を共有できるグループごとに 1 つの Organization を作成してから、各 Organization の基本アクセス許可を [書き込み] または [読み取り] に設定します。
リポジトリ アクセスのためのチームを持つ複数の Organization
非常に大規模な企業では、複数の Organization 内であっても、リポジトリ アクセスをより細かく制御する必要がある場合があります。 この場合、チームを使用して、各グループが特定のリポジトリにのみアクセスできるようにすることができます。
このアーキタイプを使用するには、前述のようにポリシー、設定、要件を共有できるグループごとに 1 つの Organization を作成し、各 Organization の基本アクセス許可を [なし] に設定し、各チームが特定のリポジトリにのみアクセスできるようにします。
アクセス方法が異なる複数の Organization
リポジトリに直接アクセスする単一の Organization のコラボレーションの利点を得たくても、グローバル アクセスに対して機密性が高すぎるリポジトリの数が少ない場合は、アクセス方法を組み合わせて複数の Organization を使用することを検討してください。
このアーキタイプを使用するには、すべての従業員とほとんどのリポジトリに対して 1 つの Organization を作成します。 Organization の基本アクセス許可を [書き込み] または [読み取り] に設定して、この Organization 内のすべてのリポジトリへのアクセス権をすべてのメンバーに付与します。
その後、より機密性の高いリポジトリ専用の 2 つ目の Organization を作成します。 この Organization では、基本アクセス許可を [なし] に設定し、機密性の高いリポジトリにアクセスする必要がある人のみを追加し、チーム メンバーシップを使用してリポジトリへのアクセスを管理します。
参考資料
- GitHub ブログの「アドホック チームを使用してエキスパートを整理する」
- 組織のベスト プラクティス