GitHubを利用したチーム開発では、「リポジトリはどう分けるべきか」「誰にどの権限を与えるべきか」といった運用ルールを決める必要があります。
GitHub Teamプランを利用すると、OrganizationやTeam機能を活用してメンバーや権限を効率よく管理できます。
本記事では、GitHub Teamプランの導入方法から、実務で利用されるリポジトリ構成や権限管理の考え方までを初心者向けに解説します。
GitHub Teamプランとは
GitHub Teamは、複数人でソースコードを管理するための有料プランです。
主な機能は以下のとおりです。
- メンバー管理
- Team単位の権限設定
- プライベートリポジトリの共有
- Pull Requestによるコードレビュー
- GitHub Actions利用枠の拡張
- Branch Protectionによる運用ルール設定
個人開発であればFreeプランでも十分ですが、チーム開発ではTeamプランの利用をおすすめします。
GitHub Teamプランの料金
GitHub Teamはユーザー単位で課金されるプランです。
例えば、
- 5人のチームで利用する場合は5ユーザー分
- 10人のチームで利用する場合は10ユーザー分
の費用が発生します。
料金は変更される可能性があるため、最新の情報はGitHub公式サイトをご確認ください。
GitHub Teamプラン導入前に理解しておきたいOrganization
GitHub Teamプランでは、まず「Organization（組織）」を作成します。
イメージとしては以下のようになります。
Organization
│
├ Team
│ ├ 開発チーム
│ ├ テストチーム
│ └ 管理者チーム
│
├ Repository
│ ├ ProjectA
│ ├ ProjectB
│ └ ProjectC
個人アカウント配下で管理するのではなく、Organization配下で管理することで、メンバーや権限を一元管理できます。
GitHub Teamプランの契約手順
Step1：Organizationを作成する
GitHubへログインします。
画面右上のプロフィールアイコンから「Your organizations」を選択します。
「New organization」をクリックします。
Organization名を入力して作成します。
Step2：Teamプランへアップグレードする
Organization画面を開きます。
「Billing and plans」を選択します。
支払い方法を登録し、Teamプランへアップグレードします。
これでTeam機能が利用できるようになります。
メンバーを招待する
Organization画面を開きます。
「People」をクリックします。
「Invite member」をクリックします。
GitHubアカウントまたはメールアドレスを入力して招待します。
招待されたユーザーが承認すると、Organizationへ参加できます。
Teamを作成する
GitHub Teamでは、ユーザーごとに権限を設定するのではなく、Team単位で管理することをおすすめします。
例えば、プロジェクトAの場合は以下のようなTeam構成が考えられます。
Organization
│
├ ProjectA-CS
├ ProjectA-WEB
├ ProjectA-QA
└ ProjectA-PM
Team単位で権限を付与することで、メンバーの追加・削除が容易になります。
リポジトリはどう分けるべきか
初心者が最も悩みやすいポイントがリポジトリ構成です。
例えば以下のような構成があるとします。
プロジェクトA
├ クラサバソース
│ ├ モジュール1
│ ├ モジュール2
│
├ Webソース
リポジトリの管理方法にはいくつかのパターンがあります。
パターン1：プロジェクト単位で管理
ProjectA
├ ClientServer
│ ├ Module1
│ ├ Module2
│
├ Web
メリット
- 管理がシンプル
- リポジトリ数が少ない
- プロジェクト全体を把握しやすい
デメリット
- 権限を細かく分けにくい
- 不要なソースも取得することになる
小規模なプロジェクト向けの構成です。
パターン2：システム単位で分割（おすすめ）
ProjectA-ClientServer
├ Module1
├ Module2
ProjectA-Web
メリット
- 権限管理しやすい
- 担当者ごとにリポジトリを分けられる
- 運用負荷と管理性のバランスが良い
デメリット
- リポジトリ数が増える
実務ではこの構成が最も多く採用されています。
パターン3：モジュール単位で分割
ProjectA-Module1
ProjectA-Module2
ProjectA-Web
メリット
- 最も細かい権限管理が可能
- モジュール単位で独立した開発がしやすい
デメリット
- 管理が煩雑になる
- CI/CD設定が増える
- リポジトリ間の連携が複雑になる
大規模システム向けの構成です。
おすすめのリポジトリ構成
中小規模の開発案件では、以下の構成がおすすめです。
Organization
│
├ ProjectA-ClientServer
├ ProjectA-Web
├ ProjectB-ClientServer
├ ProjectB-Web
プロジェクト単位ではなく、システム単位でリポジトリを分割することで、権限管理と運用の両立がしやすくなります。
Teamを利用した権限管理
例えば以下のTeamがあるとします。
ProjectA-CS
ProjectA-WEB
ProjectA-QA
ProjectA-PM
リポジトリごとの権限設定例
| Team | ClientServer | Web |
|---|---|---|
| ProjectA-CS | Write | Read |
| ProjectA-WEB | Read | Write |
| ProjectA-QA | Read | Read |
| ProjectA-PM | Maintain | Maintain |
このように設定することで、担当範囲以外のソース変更を防ぎながら、必要な参照権限は維持できます。
GitHubの権限レベル
GitHubには主に以下の権限があります。
| 権限 | 内容 |
|---|---|
| Read | 閲覧のみ |
| Triage | Issue管理 |
| Write | ソース修正可能 |
| Maintain | リポジトリ管理 |
| Admin | 全権限 |
一般開発者には「Write」を付与するのが一般的です。
Admin権限は最小限にする
Admin権限を持つユーザーは以下を実行できます。
- リポジトリ削除
- メンバー管理
- Team管理
- 権限変更
- Branch Protection変更
誤操作を防ぐため、以下の担当者のみに付与することをおすすめします。
- GitHub管理者
- プロジェクト責任者
- 開発リーダー
Branch Protectionを設定する
Team開発では、mainブランチへの直接Pushは禁止することをおすすめします。
開発者が誤ってmainブランチへ直接Pushすると、レビューされていないコードが反映される可能性があります。
そのため、mainブランチにはBranch Protectionを設定し、Pull Request経由でのみ変更できるようにするのが一般的です。
推奨設定
main
├ 直接Push禁止
├ Pull Request必須
├ レビュー1名以上必須
└ ステータスチェック必須
これにより、コード品質を維持しながら安全に開発を進められます。
実務でよくある構成例
例えば以下の体制を考えます。
ProjectA
├ クラサバ担当 3名
├ Web担当 2名
├ テスト担当 1名
└ PM 1名
GitHubでは次のように管理します。
Organization
│
├ Team
│ ├ ProjectA-CS
│ ├ ProjectA-WEB
│ ├ ProjectA-QA
│ └ ProjectA-PM
│
├ Repository
│ ├ ProjectA-ClientServer
│ └ ProjectA-Web
この構成にすると、
- 権限管理がシンプルになる
- メンバー追加や削除が容易になる
- 誤操作を防ぎやすい
- プロジェクト増加にも対応しやすい
といったメリットがあります。
将来的にGitHub Enterpriseへのアップグレードを検討するケース
GitHub Teamプランで十分なケースがほとんどですが、組織規模が大きくなった場合や、より高度なセキュリティ・管理機能が必要になった場合は、GitHub Enterpriseへのアップグレードを検討します。
GitHub TeamとGitHub Enterpriseの違い
主な違いは以下のとおりです。
| 項目 | Team | Enterprise |
|---|---|---|
| チーム管理 | ○ | ○ |
| Pull Request | ○ | ○ |
| GitHub Actions | ○ | ○ |
| SAMLシングルサインオン（SSO） | × | ○ |
| 高度な監査ログ | × | ○ |
| Enterprise Managed Users | × | ○ |
| 高度なセキュリティポリシー | △ | ○ |
| 大規模組織向け管理機能 | △ | ○ |
中小規模の開発チームであれば、Teamプランで十分運用できます。
Enterpriseへのアップグレードが必要になるケース
社内認証と連携したい
Active DirectoryやMicrosoft Entra ID（旧Azure AD）などの認証基盤と連携し、社員アカウントでGitHubへログインしたい場合はEnterpriseが適しています。
アカウント管理を自動化したい
退職者や異動者のアカウント管理を認証基盤と連携して自動化できます。
監査ログを強化したい
金融機関や製造業などでは、
- 誰がリポジトリへアクセスしたか
- 誰が権限変更を行ったか
- 誰が設定を変更したか
といった監査情報が求められる場合があります。
そのようなケースではEnterpriseの監査機能が有効です。
組織全体のポリシーを統一したい
例えば、
- 全リポジトリでPull Requestを必須化
- Secret Scanningを強制
- セキュリティポリシーを統一
といった運用を行う場合は、Enterpriseの管理機能が役立ちます。
TeamプランからEnterpriseへの移行は簡単
GitHubではOrganizationをそのまま利用した状態でプランをアップグレードできます。
そのため、
- リポジトリの移行
- メンバーの再登録
- Pull Request履歴の移行
などは不要です。
まずはTeamプランで運用を開始し、必要になったタイミングでEnterpriseへ移行する方法がおすすめです。
まとめ
GitHub Teamプランを導入することで、ソースコードだけでなく、チームや権限も含めて組織的に管理できるようになります。
まずは以下の流れで環境を整備するとよいでしょう。
- Organizationを作成する
- Teamプランへアップグレードする
- Teamを作成する
- リポジトリを作成する
- 権限を設定する
- Branch Protectionを設定する
小規模なプロジェクトで運用を始め、組織の成長やセキュリティ要件の変化に合わせて、必要に応じてGitHub Enterpriseへの移行を検討することをおすすめします。
コメント