組織の構造を計画する

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022

Azure DevOps で作成する組織、プロジェクト、チームの数のガイドとして、ビジネス構造を使用します。 この包括的な計画ガイドは、開発ワークフローとビジネス目標を整合させる最適な組織構造を設計するのに役立ちます。

戦略的計画フレームワーク

主要な構造の決定

Azure DevOps の構造をガイドするために、次の基本的な質問に対処します。

組織レベル:

• いくつの組織が必要ですか? - セキュリティ、コンプライアンス、および部署の分離を検討する
• 組織をビジネス ユニットにマップする方法 - エンタープライズ構造とガバナンスのニーズに合わせる

プロジェクト レベル:

• 必要なプロジェクトはいくつですか? - セキュリティと自律性とのコラボレーションのバランスを取る
• プロジェクト マッピング戦略 - プロジェクトをビジネス機能とチーム構造に接続する

チームとリポジトリのレベル:

• チーム構造の設計 - アジャイル配信と製品所有権の最適化
• リポジトリ組織 - 開発とデプロイのワークフローをサポートする

支援に関する考慮事項

• アクセス管理: どの情報とリソースにアクセスする必要があるかを定義する
• レポート要件: チーム間の可視性とポートフォリオ管理を計画する
• プロセスの標準化: チームの柔軟性を可能にしながら、一貫したプラクティスを促進する
• 文化的整合:アジャイルな考え方とコラボレーション文化を育む

Azure DevOps 組織について

Azure DevOps の組織は、プロジェクトの最上位コンテナーとして機能し、課金、セキュリティ、管理の境界を提供します。 組織によって次のことが可能になります。

• 関連するプロジェクトとチーム全体で課金とライセンスを一元化する
• 個別のアクセス制御とポリシーを使用してセキュリティ境界を確立する
• さまざまな部署またはコンプライアンス要件に対して管理上の分離を提供する
• 統合認証のために Microsoft Entra ID などの ID プロバイダーに接続する

組織の特典と無料レベル

各組織には、最大 5 人のユーザー向けの Free レベル サービスが含まれています。

• 最初の 5 人のユーザーが無料 (Basic ライセンス)
• Azure Pipelines:
  • 1 つの Microsoft ホスト型 CI/CD (1 つの同時実行ジョブ、1 か月あたり最大 30 時間)
  • 1 つのセルフホステッド CI/CD 同時実行ジョブ
• Azure Boards: 作業項目の追跡とボード
• Azure Repos: 無制限のプライベート Git リポジトリ
• Azure Artifacts:organizationあたり 2 GiB 無料

一般的な組織パターン:

• 単一の組織: ほとんどの企業は、1 つの組織で統合コラボレーションを利用できます
• 事業単位組織: 個別のコンプライアンスまたはセキュリティ要件のために組織を分離する
• 地理的な組織: データ所在地またはローカル ガバナンスの地域分離

いくつの組織が必要ですか?

1 つの組織から始めて 、分離を要求する特定のビジネス要件がある場合にのみ拡張します。

複数の組織の決定基準

必要に応じてさらに組織を作成します。

セキュリティとコンプライアンスの分離:

• さまざまな規制要件 (SOX、HIPAA、PCI-DSS)
• 個別の顧客データ分離要件
• 監査証跡とコンプライアンス レポートを分離する

ビジネス構造の要件:

• 独立した IT ガバナンスを備えた独立したビジネス ユニット
• 請求とコスト センターのさまざまな要件
• 個別の ID プロバイダー接続 (異なる Microsoft Entra テナント)

管理境界:

• 重複のない異なる管理者グループ
• 組織のポリシーとコントロールを分離する
• 独立型サービス レベル アグリーメント

評価フレームワーク

チームとは

チームは、チームで構成可能な多くのツール サポートするユニットです。 これらのツールは、作業の計画と管理に役立ち、コラボレーションを容易にします。

個別の製品または機能チームごとにチームを作成する

各チームは独自のバックログを所有しています。 新しいバックログを作成するには、新しいチームを作成します。 チームとバックログを階層構造に構成、プログラム所有者はチーム全体の進行状況をより簡単に追跡し、ポートフォリオを管理し、ロールアップ データを生成できます。 チームを作成すると、チーム グループが作成されます。 このグループは、クエリで使用することも、チームのアクセス許可を設定することもできます。

プロジェクトについて

プロジェクトは、次の統合サービスを含む開発作業のコンテナーを提供します。

• Azure Boards: バックログ、スプリント、作業項目追跡を使用したアジャイル計画
• Azure Pipelines: 継続的インテグレーションとデプロイの自動化
• Azure Repos: ソース コード管理用の Git または TFVC リポジトリ
• Azure Test Plans: 手動および自動テスト統合
• 共有リソース: Wiki、ダッシュボード、およびプロジェクト レベルの設定

次の例では、Contoso Manufacturing は 4 つのプロジェクトを使用して、異なる製品ラインを整理します。

プロジェクトの利点と考慮事項

プロジェクトでは、次の機能が有効になります。

• チーム間で共有されるイテレーション スケジュールと分類
• 一貫性のあるプロセス テンプレートと作業項目の種類
• 統合されたレポートとポートフォリオ管理
• ユーザー管理とアクセス制御の簡素化

プロジェクトは次の境界を提供します。

• セキュリティとアクセス許可
• プロセスのカスタマイズと作業の追跡
• 管理ポリシーとガバナンス
• リソースの割り当てと課金の追跡

必要なプロジェクトはいくつですか?

Azure Boards、Azure Repos、Azure Pipelines などの Azure DevOps サービスの使用を開始するプロジェクトを少なくとも 1 つ用意します。 組織を作成すると、既定のプロジェクトが自動的に作成されます。 既定のプロジェクトには、作業を開始するコード リポジトリ、作業を追跡するためのバックログ、ビルドとリリースの自動化を開始するためのパイプラインが少なくとも 1 つあります。

組織内では、次のいずれかの方法を実行できます。

• 単一プロジェクトを作成して、複数のリポジトリとチームを含める
• 複数プロジェクトを作成して、それぞれに、チーム、リポジトリ、ビルド、作業項目、その他の要素の独自のセットを含める

多数のチームが何百もの異なるアプリケーションとソフトウェア プロジェクトに取り組んでいる場合でも、Azure DevOps の 1 つのプロジェクト内でそれらを管理できます。 ただし、ソフトウェア プロジェクトとそのチームの間でより詳細なセキュリティを管理する場合は、多くのプロジェクトを使用することを検討してください。 最高レベルの分離とは、各組織が 1 つの Microsoft Entra テナントに接続されている組織です。 ただし、1 つの Microsoft Entra テナントは、多くの Azure DevOps 組織に接続できます。

プロジェクトの意思決定フレームワーク

コラボレーションのニーズに基づいて、適切なプロジェクト構造を選択します。

単一プロジェクトのアプローチ:

• 最適:緊密に協力する小規模な組織またはチーム
• 利点: 最大限の可視性、共有リソース、統合レポート
• 考慮するタイミング: チームは、似たようなリリース サイクルを持つ関連製品に取り組む時

複数のプロジェクトのアプローチ:

• 最適な対象: 個別の要件を持つ独立したチーム
• 利点: セキュリティ境界の向上、カスタマイズ可能なプロセス、チームの自律性
• 検討すべきタイミング: 異なるコンプライアンスニーズまたは個別の事業単位

Azure DevOps では、複数のプロジェクト間で作業を管理するためのプロジェクト間エクスペリエンスが提供されます。

次の場合は、複数のプロジェクトを検討してください。

• 特定の情報へのアクセスの制限または管理
• さまざまな部署のカスタム作業追跡プロセスのサポート
• 独立した管理ポリシーを使用して個別の事業単位をサポートする
• 運用環境のロールアウト前のカスタマイズまたは拡張機能のテスト

プロジェクトを事業単位にマップする場合は、会社で単一の組織を取得し、複数プロジェクトを設定して、1 つ以上のプロジェクトで 1 つの事業単位を表すようにします。 会社のすべての Azure DevOps 資産は、この組織内に含まれており、特定の地域 (ヨーロッパなど) 内に配置されます。 プロジェクトを事業単位にマッピングするために次のガイダンスを検討してください。

プロジェクト内でリポジトリとバージョン 管理を構成する

以前に作成した組織の 1 つと、アクセスが必要なユーザーを対象とする特定の戦略的な作業について考えてみましょう。 この情報を使用して、プロジェクトの名前と 作成を行います。 このプロジェクトには、作成した組織で定義された URL があり、〘〘〗〘〗〘 https://dev.azure.com/{organization-name}/{project-name}.

プロジェクトの設定でプロジェクトを構成します。

プロジェクトの管理の詳細については、「 Azure DevOps でのプロジェクトの管理を参照してください。 データを移行することで、プロジェクトを別の組織に移動できます。 プロジェクトの移行の詳細については、 Migration の概要を参照してください。

リポジトリ戦略とバージョン管理

チーム サイズ、製品アーキテクチャ、デプロイの要件に基づいてリポジトリ戦略を構成します。

バージョン 管理システムの選択

Git と Team Foundation Version Control (TFVC) のどちらかを選択します。

Git リポジトリ:

• 最新の開発ワークフローに推奨されるアプローチ
• プロジェクトごとに無制限のリポジトリ
• 柔軟な分岐を使用した分散バージョン管理
• ほとんどの開発ツールおよび CI/CD システムとの統合

Team Foundation バージョン管理 (TFVC):

• 一元化されたバージョン管理システム
• フォルダーベースの組織を持つプロジェクトごとに 1 つのリポジトリ
• 一元化されたワークフローを優先するチームに適しています

リポジトリの組織パターン

Monorepo 戦略:

• おすすめ: 関連サービスを活用して勢いをつける小規模チーム
• 利点: 共有と調整された変更の簡略化
• 課題: チームの成長に伴い、知識の複雑さが増します。意図しないサービスの結合。変更の追跡が困難

個別のリポジトリ戦略:

• 最適なのは: 独立したサービスデプロイを使用する大規模なチームに最適です
• 利点: サービス境界のクリア、オンボードの容易さ、独立したリリース サイクル
• 考慮事項: より多くの初期セットアップが必要ですが、チームの成長に合わせて効果的にスケーリングする

リポジトリとプロジェクトの配置戦略

複数のリポジトリを持つ 1 つのプロジェクト:

• 最適な対象: リリース スケジュールが調整された製品/サービス
• 利点: 共有プロセス、一貫性のあるアクセス制御、合理化された管理
• 使用するタイミング: 開発者は複数のリポジトリ間で頻繁に作業し、一貫性のあるツールが必要です

専用リポジトリを持つ複数のプロジェクト:

• 最適な条件: 独立したスケジュールまたは個別の要件を持つ製品
• 利点: 独立したカスタマイズ、個別のガバナンス、明確な境界

リポジトリ組織の決定要因:

• コードの依存関係: 個別にデプロイ可能な製品/サービスを個別のリポジトリに配置する
• 調整のニーズ: 調整された変更が予想される場合は、関連するコードベースを一緒に保持する
• アーキテクチャ: 単一のリポジトリで既存のモノリスを維持する。切断されたサービスを分離する
• チーム アクセス: リポジトリの作成を制御するための適切な アクセス許可管理 を実装する

共有リポジトリとフォークされたリポジトリ

信頼された組織内で共有リポジトリを使用することをお勧めします。 開発者は、互いの変更の分離を維持するのにブランチを使用します。 優れたブランチとリリースの戦略を用いて、1 つのリポジトリで 1,000 人超の開発者の同時開発をサポートできるように拡張できます。 分岐とリリースの戦略の詳細については、「 Adopt a Git branching strategy and Release Flow: Our Branching Strategy」を参照してください。

フォークは、メイン リポジトリを更新するための直接アクセスを持つべきではないベンダー チームと作業する場合に有用です。 フォークは、オープンソース プロジェクトのように、数多くの開発者が頻繁にコントリビューションしないシナリオでも有用です。 フォークを使用する場合は、フォークされたリポジトリをメイン リポジトリから分離するために、別のプロジェクトを維持することをお勧めします。 管理オーバーヘッドが増える可能性がありますが、メイン プロジェクトをよりクリーンに保ちます。 詳細については、 Forks の記事を参照してください。

次の図は、"会社" が組織、プロジェクト、作業項目、チーム、リポジトリを構成する方法のサンプルを示しています。

一時リソースと共有リソースの管理

次のベスト プラクティスを使用して、一時的なリソースと共有リソースを効果的に管理する方法を検討します。

• 一時的な環境: 一時的な環境は有効期間が短く、テスト、開発、ステージングなどのタスクに使用されます。 これらの環境を効率的に管理するには:
  • 個別のリポジトリとパイプライン: 一時環境とそれに関連付けられている各リソース (Azure Functions など) には、独自のリポジトリとパイプラインが必要です。 この分離により、環境とそのリソースを同時にデプロイおよびロールバックできるため、必要に応じて簡単に起動および破棄できます。
  • 例: Azure Functions、ストレージ アカウント、その他のサービスなど、必要なすべてのリソースを含め、開発環境専用のリポジトリとパイプラインを作成します。
• 共有リソース: 共有リソースは通常、有効期間が長く、複数の環境で使用されます。 多くの場合、これらのリソースのスピンアップ時間が長くなり、コストが高くなります。 共有リソースを効果的に管理するには:
  • 個別のリポジトリとパイプライン: Azure SQL Database などの共有リソースには、独自のリポジトリとパイプラインが必要です。 この分離により、一時的な環境でこれらの共有リソースを使用できるため、デプロイの高速化とコスト効率の向上が実現します。
  • 例: 複数の一時環境で使用できる Azure SQL Database のリポジトリとパイプラインを作成します。
• 共有インフラストラクチャ リソース: 仮想プライベート クラウド (VPC) やサブネット (ランディング ゾーンとも呼ばれます) などの共有インフラストラクチャ リソースにも、独自のリポジトリとパイプラインが必要です。 この方法により、インフラストラクチャが一貫して管理され、さまざまな環境で再利用できるようになります。
  • 例: VPC とサブネット構成のリポジトリとパイプラインを作成します。これは、他のリポジトリやパイプラインから参照できます。

組織構造の詳細

組織の管理者アカウントの種類を選択する

組織を作成するときに、サインインに使用する資格情報によって、組織で使用する ID プロバイダーが定義されます。 Microsoft アカウントまたは Microsoft Entra インスタンスを使用して組織を作成します。 これらの資格情報を使用して、 https://dev.azure.com/{YourOrganization}で新しい組織に管理者としてサインインします。

Microsoft アカウントを使用する

Microsoft Entra ID を使用して組織のユーザーを認証する必要がない場合は、Microsoft アカウントを使用します。 すべてのユーザーは、Microsoft アカウントを使用して組織にサインインする必要があります。 Microsoft アカウントを持っていない場合は、作成します。

Microsoft Entra インスタンスがない場合は、 Azure ポータルから無料で作成するか Microsoft アカウントを使用して組織を作成します。 その後、組織を Microsoft Entra ID に 接続。

Microsoft Entra アカウントを使用する

Azure または Microsoft 365 を使用している場合は、既に Microsoft Entra アカウントを持っている可能性があります。 Microsoft Entra ID を使用してユーザーのアクセス許可を管理する会社で働いている場合は、おそらく Microsoft Entra アカウントを持っている可能性があります。

Microsoft Entra アカウントをお持ちでない場合は、Microsoft Entra ID に サインアップ 組織を Microsoft Entra ID に自動的に接続します。 組織にアクセスするには、すべてのユーザーがそのディレクトリのメンバーである必要があります。 他の組織のユーザーを追加するには、 Microsoft Entra B2B コラボレーションを使用します。

Azure DevOps では、Microsoft Entra ID を使用してユーザーが認証されるため、そのディレクトリ内のメンバーであるユーザーのみが組織にアクセスできます。 そのディレクトリからユーザーを削除すると、ユーザーは組織にアクセスできなくなります。 特定の Microsoft Entra 管理者のみが ディレクトリ内のユーザーを管理するため、管理者は組織にアクセスするユーザーを制御します。

ユーザーの管理の詳細については、「 Manage ユーザー」を参照してください。

組織をビジネス ユニットにマップする

社内の各部署は、独自の Microsoft Entra テナントと共に、Azure DevOps 内の独自の組織を取得します。 チームや進行中の作業に基づいて必要に応じて、個々の組織内でプロジェクトをに設定できます。

大企業では、異なるユーザー アカウント (Microsoft Entra アカウントの可能性が高い) を使用して複数の組織を作成できます。 戦略と作業を共有するグループとユーザーを検討し、それらを特定の組織にグループ化します。

たとえば、架空の Fabrikam 社は次の 3 つの組織を作成しました。

• Fabrikam-Marketing
• Fabrikam-Engineering
• Fabrikam-Sales

各組織には、次のような個別の URL があります。

• https://dev.azure.com/Fabrikam-Marketing
• https://dev.azure.com/Fabrikam-Engineering
• https://dev.azure.com/Fabrikam-Sales

組織は同じ会社を対象としていますが、ほとんど互いに分離されています。 このように何も分離する必要はありません。 ビジネスに意味を持つ場合にのみ境界を作成します。

関連コンテンツ

• 組織を作成する
• プロジェクトの作成
• Microsoft Entra ID に組織を接続する
• 請求の設定
• ユーザー基本設定の設定