このガイドでは、企業にとって最適なアーキテクチャを決定できるように、Organization、チーム、リポジトリの関係性について詳しく説明します。また、Organizationに関して詳しく解説されているGitHubのリソースやその情報を提供できる「チーム」についてもご紹介します。
Organizationの構造が重要である理由
Organizationの構造によっては、コラボレーションを促進したり、発見可能性を高めることができる一方で、開発者のコミュニケーションをさらに難しくする可能性もあります。GitHub Enterpriseを設定する際には直感的に、各プロジェクトまたは部署のために個別のOrganizationを作成しがちですが、それでは分割されたグループが数多く生じて、GitHubの中でサイロ化してしまうおそれがあります。これは、権限を管理し、不要な情報を削減できる手っ取り早い方法のように見えるかもしれませんが、必ずしも理想的な対策ではありません。実際、チームの枠を超えたコラボレーションに弊害が生じ、後で管理者が頭を悩ませることになります。皆さんには、不要な運用作業で身動きが取れなくなることなく、チームがシームレスかつクリエイティブに、そして透明性の高い状態で連携できるアーキテクチャで、GitHubを使い始めていただきたいと考えています。
多数のOrganizationを作成し、ユーザをサイロ化するのではなく、1つまたは少数のOrganizationを使用してリポジトリを共同で所有し、チームを使用してOrganization内のユーザを細分化することをお勧めします。
Organization
Organizationは2人以上のユーザのグループであり、通常は企業内の組織構成を反映しています。Organizationはメンバーによって管理され、リポジトリとチームの両方が含まれています。
リポジトリ
リポジトリはGitHubの最も基本的な要素です。各プロジェクトにとってのメインフォルダであるとお考えください。リポジトリには、ドキュメントやIssue含むすべてのプロジェクトファイルが入っており、各ファイルのリビジョン履歴が格納されます。リポジトリには複数のコラボレータを指定でき、パブリックまたはプライベートのいずれにも設定できます。
チーム
チームを使用すると、Organizationに属しているリポジトリへの読み取り、書き込み、または管理権限を持ったOrganizationのメンバーのグループを作成することができます。また、チームはGitHubのコラボレーション機能の中核になっております。たとえば、チームでの@メンション機能により、情報を提供して欲しいユーザや、情報を見せたいユーザグループに通知することができます。チームは、プロジェクトまたは特定分野の単位で整理することができ、社内の役職または特定のグループに関連付けることもできます。なお、別のOrganizationに属しているチームを@メンションすることはできません。
GitHub EnterpriseにおけるOrganization設定についてのアドバイス
運用の煩雑化を回避するために、Organizationの数は可能な限り少なくしましょう
こうすることで、発見可能性が向上し、管理に関する悩みが減ります。多くのOrganizationで権限を管理するのではなく、Organizationの数を1つまたは少数にすることで、まとまりがあり機動的な権限構成を設けることができます。
チームは、ユーザを分類してリポジトリへのアクセスを提供する最適な方法です
チームを使用すると、個別のアクセスレベルと可視性を指定したグループをOrganization内に作成することができます。Organizationではなくチームを使用することで、アクセス制御を犠牲にすることなく、コラボレーションを向上させることができます。
OrganizationのオーナーはOrganizationレベルでの管理者です
Organizationの設定ページを熟知している管理者は、幅広い権限を持っています。Organizationでのインテグレーションを設定・制御する機能に加えて、Organizationの管理者はデフォルトのメンバー権限を設定することもできます。これは、GitHub EnterpriseやGitHub全体に対して公開せず、Organizationのメンバーのみにリポジトリを表示することができる強力なツールです。Organizationの設定ページについて専門的な詳細を知りたい場合は、GitHub営業担当にご相談ください。
GitHub Enterprise管理者は、Organizationの作成権限を所有しています
ユーザが製品の機能を使いこなしている姿を目にするのは素晴らしいことですが、Organizationの作成権限を誰に許可するかはしっかりと検討する必要があります。そうしなければ、不要なOrganizationを作成してしまうリスクがあるからです。GitHub Enterprise Cloudの場合はOrganization作成権限がEnterprise管理者のみに付与されますが、GitHub Enterprise Serverの場合は全ユーザまたはEnterprise管理者のみにその権限を付与することができます。
必要に応じてアーキテクチャミーティングの予定を組み、現在と将来のニーズについてアカウントチームと話し合いましょう
GitHubの社員である私たちも、毎日GitHubを使用しています。そのため、さまざまな使用事例を理解し、GitHubを効果的に活用するための最良の戦略を実践しています。GitHubのチームからさまざまなアーキテクチャオプションの利点をすべて説明することで、GitHubのユーザがその情報から十分なメリットを得られるようサポートします。
自社に最適なOrganizationアーキテクチャを選びましょう
私たち自身のGitHubの使用経験やユーザとのやり取りに基づいて、GitHubの利用開始に役立つOrganizationの典型例をまとめました。このチャートで、よくあるアーキテクチャのタイプがわかります。
| 例 | 対象企業 | メリット |
| Organizationは1つ。リポジトリへのアクセスは社員全員が可能
|
小規模企業、場合によっては中規模企業
|
• スタートアップチームに最適
• 非常に協力的 • チームとチームメンバーに、全プロジェクトで@メンションできる |
| Organizationは1つ。複数のチームによりリポジトリアクセスを管理
|
厳重なセキュリティを必要とする中小規模企業
|
• セキュリティ規制のある、中小規模の企業に最適
• より細分化されたリポジトリアクセス |
| Organizationは2つ以上。複数チームによりリポジトリアクセスを管理
|
特定のリポジトリへのアクセスを制限する必要がある大企業
|
• より高レベルな分類
• リポジトリへの細分化されたアクセス制御 • GitHub Enterpriseのユーザ数が500名を超える企業に最適 |
Organizationは1つ。リポジトリへのアクセスは社員全員が可能
最初の例では、GitHub Enterpriseに1つのOrganizationがあり、ここに全ユーザが属しています。全ユーザがOrganizationのリポジトリへの書き込みアクセス権限を持っています。これはデフォルトのOrganization権限によって付与されています。チームはリポジトリへのアクセス権限を付与するためにではなく、ロールまたは専門知識の分野別にユーザを分類するために使用します。
このアプローチは、全ユーザが複数のプロジェクトに貢献する小規模企業に最適です。このワークモデルの好例がスタートアップ企業です。このアーキテクチャの最大のメリットの1つは、すべてのメンバーおよびチームに対して@メンションし、全プロジェクトの情報を取得できることです。そのため、この構造を採用するには、信頼性の高い環境と非常に協力的なワークモデルを兼ねて備えていることが理想です。これは緩い構造のOrganizationであるため、事業部門がサイロ化された企業には適していません。
Organizationは1つ。複数のチームによりリポジトリアクセスを管理
これは1つ目の例と似ていますが、主な違いは、チームを使用してリポジトリアクセスをさらに細かくコントロールするという点です。この例は、ほとんどの中規模企業、または規制の対象であり、アクセス制御に厳密な注意を払うことを求められる小規模企業に最適です。ただし、すべてのチームが同じOrganizationに属しているため、互いに@メンションすることができます。
そのため、多くのチームを抱える大企業や、ユーザが不必要にチームを作成する可能性がある小規模企業では、管理者にかなりの作業負荷がかかる可能性があります。また、大企業でも、1名のオーナーだけが内部の安全な環境で管理されているすべてのリポジトリにアクセスできるようにすべきではない場合は、この手法を避けたほうがよいでしょう。
Organizationは2つ以上。複数チームによりリポジトリアクセスを管理
この手法では、事業部門、製品、またはその他のサイロにマッピングしてOrganizationを個別に作成したり、おおむね独立した状態で使用されるリポジトリを作成することが推奨されます。ただし、チームの枠を超えたコラボレーションが重要な場合でも、異なるOrganizationに属するTeam間では互いに@メンションできません。また、社員が社内でプロジェクトを発見しづらくなる可能性がありますが、Internalリポジトリを活用することである程度回避することは可能です。これは、GitHub Enterpriseを構築する際に覚えておくべき文化的な問題です。
貴社にとって最適な構造を決めるにあたり、さらにサポートが必要な場合は、GitHubサービスチームとのミーティングを設定するため、GitHub営業にお問い合わせください。
あわせて、以下の資料もご覧ください。
