# Organization のチームについて

Team は、アクセス権限とメンションをカスケードして会社またはグループの構造を反映する Organization メンバーのグループです。

## Team について

チームを使って、組織内のユーザーのアクセス権と、通知を送信するアクセス権を管理できます。 Organization のオーナーとチームメンテナは、Organization のリポジトリに対する管理、読み取り、または書き込みのアクセス権を Team に付与できます。 Organization のメンバーは、Team の名前をメンションすることで、Team 全体に通知を送信できます。 Teams は組織のメンバーのみで構成できます。外部コラボレーターはチームに参加できません。

Organization のメンバーは、チームのレビューを要求することで、そのチーム全体に通知を送信できます。 Organization のメンバーは、pull request が開かれているリポジトリに対する読み取りアクセス権を持つ特定の Team のレビューを要求できます。 コードの特定の種類や領域に対して Team をオーナーとして CODEOWNERS ファイルで指定できます。

詳細については、次を参照してください。

* [Organization のリポジトリに対するチームのアクセスを管理する](/ja/enterprise-server@3.22/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-team-access-to-an-organization-repository)
* [基本的な書き込みと書式設定の構文](/ja/enterprise-server@3.22/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#mentioning-people-and-teams)
* [コードオーナーについて](/ja/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)

LDAP 同期を使用して、 お使いの GitHub Enterprise Server インスタンス チーム メンバーとチーム ロールを、確立された LDAP グループと同期させることもできます。 これにより、 お使いの GitHub Enterprise Server インスタンス内で手動で行う代わりに、LDAP サーバーのユーザーに対してロールベースのアクセス制御を確立できます。 詳しくは、「[LDAPの利用](/ja/enterprise-server@3.22/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap#enabling-ldap-sync)」をご覧ください。

## Team の可視性

Teamは可視にも秘密にもできます。

* 公開チームは、すべての組織メンバーが[閲覧し、@mentioned](/ja/enterprise-server@3.22/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#mentioning-people-and-teams)できます。
* シークレット チームは、チームと組織の所有者にのみ表示されます。 外部パートナーやクライアントと連携するチームのメンバーを非表示にする場合に最適です。 ただし、チーム メンバーまたは組織の所有者がシークレット チームをメンションすると、メンション テキストにチーム名が表示されます。 シークレット チームは、親チームの下にネストしたり、子チームを持ったりすることはできません。

組織のメンバーではない人は、チームを表示できません。

自分が所属するすべてのTeamは、パーソナルダッシュボードで表示できます。 詳しくは、「[個人用ダッシュボードのクイック スタート](/ja/enterprise-server@3.22/account-and-profile/get-started/personal-dashboard-quickstart#finding-your-top-repositories-and-teams)」をご覧ください。

## Team のページ

各 Team は、Organization 内に独自のページを持ちます。 Team のページでは、Team メンバー、子チーム、Team のリポジトリを見ることができます。 Organization のオーナーとチームメンテナは、Team のページから Team の設定にアクセスし、Team の説明とプロフィール画像を更新できます。

> \[!NOTE]
> チーム ディスカッションは 引退 になりました。 この詳細は、「[GitHub ブログ](https://github.blog/changelog/2023-02-08-sunset-notice-team-discussions/)」を参照してください。
>
> GitHub Discussions を使って、組織レベルのディスカッションを作成できます。 GitHub Discussions について詳しくは、「[GitHub Discussions ドキュメント](/ja/enterprise-server@3.22/discussions)」をご覧ください。

## 入れ子チーム

複数階層のネストされたチームを使用して、GitHub 組織内にグループや会社の階層構造を反映できます。 親 Team は複数の子 Team を持つことができますが、各子 Team は 1 つの親 Team のみを持ちます。 シークレット Team を入れ子にすることはできません。 入れ子になった各チームは、組織内で独自の一意の URL とディレクトリを持つ個別のエンティティとして機能します。

子 Team は親のアクセス権限を継承し、大規模なグループの権限管理を簡素化します。 子 Team のメンバーは、親 Team が @mentioned された場合にも通知を受けるので、複数グループの人とのコミュニケーションがシンプルになります。

たとえば Team の構造が「従業員 > エンジニアリング > アプリケーションエンジニアリング > アイデンティティ」となっているなら、エンジニアリングにリポジトリへの書き込みアクセスを許可すれば、アプリケーションエンジニアとアイデンティティもそのアクセス権を得ることになります。 ID Team または Organization 階層の最下位にある任意の Team に @mention すると、通知を受け取るのはその人たちだけになります。 チームに言及するときは、完全な階層パスを含める必要はありません。 チームが入れ子になっている場合でも、メンション用のフラットハンドルが保持されます。

親チームの権限とメンションを誰が共有するのかを簡単に知るには、親チームのページの \[Members] タブで親チームの子チームのすべてのメンバーを見ることができます。 子チームのメンバーは、親チームの直接のメンバーではありません。

Team を作るときには親を選択できます。あるいは、作成済みの Team を Organization の階層の中で移動させることもできます。 詳しくは、「[組織の階層内でのチームの移動](/ja/enterprise-server@3.22/organizations/organizing-members-into-teams/moving-a-team-in-your-organizations-hierarchy)」を参照してください。

LDAP 同期は、最適化構成の一部として、入れ子チームの構造を転送しません。 親子Teamの関係を作りたい場合は、入れ子チームの構造を手動で再作成し、対応するLDAPグループに同期させなければなりません。 詳細については、「[組織チームの作成](/ja/enterprise-server@3.22/organizations/organizing-members-into-teams/creating-a-team#creating-teams-with-ldap-sync-enabled)」を参照してください

## Organization 内で Team を入れ子にする準備

Organization がすでに既存の Team を持っている場合、その Team の上あるいは下に Team を入れ子にする前に、各 Team のリポジトリのアクセス権限を監査しておくべきです。 また、Organization に実装したい新しい構造についても考慮しておくべきです。

Team 階層の最上位では、親チームとその子チームのすべてのメンバーにとって安全なアクセス権限を、親チームのリポジトリに与えるべきです。 階層を下っていくにつれて、より注意が必要なリポジトリへの、より細かいアクセスを、子チームに許可していくことができます。

1. 既存の Team からすべてのメンバーを削除する
2. 各 Team のリポジトリのアクセス権限を監査して調整し、各 Team に親を与える
3. 必要な新しい Team を作成し、それぞれの新 Team の親を選択し、それらにリポジトリのアクセス権を与える
4. Team に直接人を追加する

## 参考資料

* [組織チームの作成](/ja/enterprise-server@3.22/organizations/organizing-members-into-teams/creating-a-team)
* [チームに組織メンバーを追加する](/ja/enterprise-server@3.22/organizations/organizing-members-into-teams/adding-organization-members-to-a-team)