チームの管理

Teams にアクセスできるのは誰ですか?

すべてのユーザーが常にチームの所有権を識別できるようにするため、チームはアカウント レベルではなく組織レベルで管理されます。

• **読み取りアクセス: **すべてのユーザーには、連絡先情報、チーム メンバー、その他の関連詳細などのメタデータを含む、Teams への読み取りアクセス権があります。
• **チームの変更: **Organization Product Admin [組織製品管理者]の役割を持つユーザーはチームを変更できます。 これは、現在All Product Admin role [すべての製品管理者の役割を]持つすべてのユーザーに割り当てられる新しい役割です。
• **チームの作成と削除:**組織マネージャーまたは認証マネージャーの役割を持つユーザーは、チームを作成および削除できます。

チームを作成する

手動でチームを作成する

チームとサービスの所有権データがまだ他の場所にない場合は、このオプションをお勧めします。

1. All Capabilities > Teamsに移動します。
2. Build manuallyをクリックします。
3. チーム名を入力してください。
4. (オプション) Description [説明] と Aliases [エイリアス] を追加します。
5. （オプション）Team members [チームメンバー]を追加します。
6. （オプション）親 [Parent]チームまたはネストされた [Nested]チーム（階層）の設定: このチームを組織構造内に配置するには、設定メニューから親チームまたはネストされた子チームを選択します。
   • 注：これらの関係は、各Team Hub [チームハブ]内のSettings [設定]タブから後で管理することもできます。
7. Create team [チームを作成 を]クリックします。

GitHubチームからチームを作成する

New Relicのチームを既存のGitHubチームと同期させておきたい場合は、このオプションを推奨します。インテグレーションのセットアップの詳細については、GitHub Cloudのインテグレーションを参照してください。

1. All Capabilities > Teamsに移動します。
2. Use a Github integration [Github 統合を使用する]をクリックします。 GitHub インテグレーション設定ページにリダイレクトされます。

IDプロバイダーからチームを自動的に作成します

チーム管理を効率化し、New Relicを組織構造に合わせるために、OktaやActive DirectoryなどのIDプロバイダー（IdP）からチームを自動的に作成および同期できます。

前提条件

• authentication_domain.read.groups権限を含むユーザーロールが割り当てられていることを確認してください。

IdPからチームを自動的に作成するように設定するには、以下の手順を実行してください。

1. IDプロバイダーでグループを設定してください。

   • まず、New Relicで管理したいチームを表すグループをIdP（アイデンティティプロバイダー）内に作成します。例えば、team_backend、team_frontend、team_dataといったグループを作成することができます。

2. SCIM経由でグループを同期します。

   • SCIMプロトコルを使用して、IdPグループをNew Relicと同期します。これにより、New Relicはこれらのグループを動的に認識し、管理することが可能になります。

3. グループの同期が完了したら、New Relicでチーム作成を設定してください。

   1. New RelicのUIで、 All Capabilities > Teamsに移動します。
   2. Fetch groups from external sources [外部ソースからグループを取得する]をクリックします。
   3. Automate with a rule [ルールを使用して自動化を]選択し、グループをチームに変換します。
   4. グループ名に一致するルールを追加します。例えば、「team_」で始まるグループ名に適用されるルールを作成します。
   5. 「ルールを作成」をクリックします。New Relic UIで自分のチームを確認できます。

   注：グループ名に明確なパターンがない場合は、ルールを使用する代わりに、関連するグループを手動で選択することもできます。

   この設定が完了すると、New Relicはルールに一致するチームを自動的に作成および維持し、変更が発生するたびにIdPと同期させます。手動での更新は不要です。

チーム階層の管理

チーム階層を設定することで、会社の実際の組織構造を反映した親子関係の構造でチームを編成することができます。

To manage team hierarchies, ensure that you're assigned a user role that includes teams.manage.organization_settings permissions.

人間関係を管理する方法

現在、階層構造は手動で作成されたチーム、またはAPI経由で作成されたチームでのみサポートされているため、これらの関係を管理するには次の2つの方法があります。

1. 作成時：チームを手動で作成する場合は、 「親チーム」と「ネストされたチーム」のドロップダウンメニューを使用してください。
2. 既存のチーム：任意のチームのチームハブに移動し、 「設定」タブを開いて、 「親チーム」または「子チーム」のフィールドを更新します。

チームマネージャーを定義する

階層内でリーダーシップの可視性を確立するために、各チームのマネージャーとして特定の個人を指定できます：

1. All Capabilities > Teamsに移動します。
2. 目的のチームのTeam Hub [チーム ハブ]に移動し、Settings [設定]をクリックします。
3. Members [メンバー] をクリックして、マネージャーとして指定するメンバーを選択します。

定義したら、マネージャーバッジが階層ビュー全体に表示され、明確な連絡先が提供されます。

階層の自動化

組織の構造は動的に計算されます。子チームに親チームを割り当てて関係が確立されるとすぐに、構造の深さは自動的に更新されます。

これらのバックグラウンド自動化は親子リンクを解析し、チームがツリー内のレベル1、レベル2、またはさらに深いレベルに位置しているかどうかを即座に判断します。これにより、チームを移動または再割り当てする際にも、階層がリアルタイムで正確に保たれます。

階層レベルをカスタマイズする

デフォルトでは、階層レベルには「Level 1」、「Level 2」などのラベルが付けられます。組織の用語により合わせるために、これらのラベルをカスタマイズできます：

• レベル名の変更： Division[ディビジョン]、Department[部署]、Squad[スクワッド]など、一般的な数字以外の名称を使用したい場合は、Teams > Hierarchy へ移動して名前を変更できます。
• グローバルアプリケーション：ここで行われた変更は組織ビュー全体に適用され、すべてのユーザーに対して一貫した用語が保証されます。

Team Hubをカスタマイズする

Team Hubページはカスタマイズできます。チームは、ワークフローに合わせてウィジェットを追加または削除することで、レイアウトを調整できます。Team Hubのレイアウトに加えられた変更は、チームのすべてのメンバーに適用されます。

Team Hubをカスタマイズするには、チームのハブページに移動し、Edit layoutをクリックして編集モードに入ります。ここから、以下の操作を行えます。

• ウィジェットの追加または削除: Manage widgetsをクリックし、表示するウィジェットを選択または選択解除して、Applyをクリックします。
• ウィジェットの並べ替え: ウィジェットを目的の位置にドラッグアンドドロップします。
• ウィジェットのサイズを変更する: ウィジェットの端にあるサイズ変更ハンドルをドラッグします。
• デフォルトのレイアウトにリセット： ...アイコンをクリックし、Reset layout to defaultを選択します。

Done editingをクリックして新しいレイアウトを保存します。すべてのチームメンバーに更新されたレイアウトが表示されます。

Power the Team Hub productivity widgets

The Team Hub includes productivity widgets for Deployment frequency, Mean Time to Recovery (MTTR), Change Lead Time (CLT), PR cycle times, and open pull requests. For an overview of what each widget displays, see The Team Hub. This section covers the data requirements to power each one.

Productivity metrics

Deployment Frequency

Requirement: The team must own APM entities with linked deployments via Change Tracking.

Change Lead Time (CLT)

要件：

• The team must own APM entities with linked deployments via Change Tracking.
• The team must own Git repositories via the GitHub integration. Linked pull requests are used in the calculation.

Mean Time to Recovery (MTTR)

Requirement: Entities must be correctly assigned to your team so that alert data can be attributed. See Configure entity ownership.

PR Cycle Time

This widget breaks the pull request lifecycle into four stages:

Requirements: Active GitHub integration and team ownership of the relevant repositories.

Open PRs

Requirements: Active GitHub integration and team ownership of the relevant repositories.

Setup requirements summary