GitHub を業務で導入する際、
「契約はどう進めるべきか」「誰にどの権限を与えるべきか」で悩むケースは少なくありません。
初期設計を誤ると、
- ソース管理が特定の個人に依存する
- 権限が肥大化し、事故のリスクを抱えたまま運用する
といった問題が起こりがちです。
本記事では GitHub Team を前提 に、
導入の具体的な手順から、Organization・Team・Ownerといった基本概念、
さらに 実務で安全に回る権限設計の考え方 までを整理します。
20名規模・専任インフラ担当がいない企業でも、無理なく長く使える GitHub 運用 を構築するための実践ガイドです。
- GitHub Team 導入の全体像
- ステップ1：個人 GitHub アカウントを作成する
- ステップ2：最初に Organization を作成する
- ステップ3：Organization 配下でソース管理を始める
- ステップ4：人数が増えたら GitHub Team にアップグレード
- ステップ5：人を招待する（最初は最小権限）
- ステップ6：Team を作る（権限設計の軸）
- ステップ7：Team に人を所属させる
- ステップ8：Repository ごとに Team へ権限付与する
- 権限は「足し算」で決まる
- 管理チーム（Admin Team）の役割
- Owner にする／しないの判断基準
- 20 名規模でのおすすめ構成（完成形）
- よくある失敗パターン
- まとめ
GitHub Team 導入の全体像
GitHub Team の導入で重要なのは、
「契約」よりも「構造づくり」 です。
大まかな流れは次の通りです。
- 個人アカウントを作成
- Organization を作成
- Organization 配下でリポジトリ運用を開始
- 人数が増えたら Team プランへアップグレード
- Team を軸に権限を設計
- 管理者・Owner を最小限に配置
ステップ1：個人 GitHub アカウントを作成する
GitHub では 「人＝個人アカウント」 が基本です。
- Aさん、Bさん、Cさん…
- 全員が Free プランで個人アカウントを作成 します
ここで重要なのは、
「会社用アカウント」という概念は存在しない
という点です。
ステップ2：最初に Organization を作成する
業務利用では、最初から Organization を作成 します。
Organization は、
- 会社・チーム単位の管理箱
- リポジトリ、メンバー、請求の単位
として機能します。
❌ 個人アカウントに業務ソースを置く
⭕ Organization 配下に Private リポジトリを作成する
これは鉄則です。
ステップ3：Organization 配下でソース管理を始める
この時点では まだ Team プランにする必要はありません。
- Organization を無料で作成
- Private リポジトリを作成
- 最初のソースを反映
👉 「後から Team にアップグレードする」前提で問題ありません。
ステップ4：人数が増えたら GitHub Team にアップグレード
チームでの本格運用が始まったら、
Organization を GitHub Team プランにアップグレード します。
ここで混乱しやすいポイントは以下です。
- 個人アカウントを Team にする ❌
- Organization を Team プランにする ⭕
Team プランは Organization 単位の契約 です。
ステップ5：人を招待する（最初は最小権限）
Organization に人を招待する際の原則は、
- 権限：Member のみ
- Owner は付与しない
です。
招待された時点では、
どのリポジトリも見えなくて問題ありません。
ステップ6：Team を作る（権限設計の軸）
次に、Organization 内で Team（グループ） を作成します。
例：
- Dev（開発）
- Review（レビュー）
- Admin（管理）
重要なのは、次の考え方です。
人に権限を付けない
Team に権限を付ける
ステップ7：Team に人を所属させる
- Aさん → Dev
- Bさん → Dev
- Cさん → Review
この段階では、
まだリポジトリにアクセスできなくても問題ありません。
ステップ8：Repository ごとに Team へ権限付与する
Repository に対して Team を紐づけます。
例：
- Repo A
- Dev → Write
- Review → Read
- Repo B
- Dev → Write
👉 同じ Team を複数リポジトリに付与する のが基本です。
権限は「足し算」で決まる
GitHub では、
- 複数の Team に所属すると
- 権限は 合算され、最も強い権限が有効
になります。
そのため、
- 開発チーム ＋ 管理チーム
といった 兼務構成も問題ありません。
管理チーム（Admin Team）の役割
管理チームは、主に Repository 単位の管理を担当します。
- ブランチ保護設定
- Secrets 管理
- GitHub Actions 設定
- Repository 管理全般
一方で、
- Organization 全体の設定
- 請求管理
は Owner の役割 です。
Owner にする／しないの判断基準
Owner は Organization の最高権限です。
Owner にする人
- GitHub 利用に組織として責任を持つ
- 請求・全体設定を管理できる立場
- 長期的に関与する人
👉 原則 1〜2 名まで
Owner にしない人
- 一時的なリーダー
- 優秀な開発者
- 外部業者
20 名規模でのおすすめ構成（完成形）
Organization
├─Owner：2名
│
├─ Team: Dev（Write）
├─ Team: Review（Read）
└─ Team:Admin（RepoAdmin）
- 管理担当者は Dev + Admin の両方に所属
- Owner は最小限に抑える
よくある失敗パターン
- 個人アカウントで業務ソースを管理
- 招待時に Owner を付与
- 全員に Admin 権限を付与
- 人に直接 Repository 権限を付与
これらは 後から必ず破綻します。
まとめ
- GitHub Team 導入は「契約」より「設計」が重要
- 最初から Organization で管理する
- 権限は人ではなく Team に付与する
- Owner は最小限、Admin は兼務でOK
- 20 名規模なら Team プランで十分にスケールする
まずはシンプルに、事故らない構成で始める。
これが、GitHub を長く安心して使うための最短ルートです。
コメント