組織 とは何ですか？
Devin Enterprise における 組織 は、開発チームを編成・区分するための論理的なグループです。各 組織 は、環境構成、リポジトリへのアクセス権、およびメンバー権限をそれぞれに持つ、独立した単位として運用されます。主な特徴
共有環境: 各組織には独自の環境構成があり、Enterprise ブループリントの上に重ねて適用されます。この構成はスナップショットとしてビルドされ、組織内のすべてのセッションはこのスナップショットから起動します。そのため、すべてのメンバーが同じリポジトリ、ツール、依存関係が揃った状態から作業を開始できます。 リポジトリの分離: 組織に付与されたすべてのリポジトリには、その組織内のすべてのメンバーがアクセス可能です。リポジトリへのアクセスは個々のユーザー単位ではなく、組織単位で管理されます。 メンバーの境界: ユーザーは複数の組織に所属できますが、アクセス権と権限は組織ごとに独立して管理されます。 請求の分離: 各組織は独自の ACU (Agent Compute Unit) の上限と利用状況のトラッキングを持ち、チーム間でのコスト配分を明確にできます。組織構造
Enterprise 階層構造
アクセス制御フロー
- Enterprise 管理者 が組織を作成し、Enterprise 全体の設定を管理する
- 組織管理者 が自分の組織にメンバーを招待する
- メンバー は割り当てられた組織内で Devin とリポジトリにアクセスする
- リポジトリ権限 は Enterprise 管理者によって組織に付与される
組織構造の設計
推奨されるマッピングパターン
効果的なアプローチとしては、各 Devin の組織を GitHub/GitLab のチームに対応付ける方法があります。これは多くの場合、IdP (Identity Provider) のグループや論理的な業務アプリケーションと整合します。この対応付けにより、利用を体系的に拡大し、リポジトリへのアクセスを一元的に管理しやすくなります。マッピング例
意思決定フレームワーク
組織構造を計画する際は、次の要素を検討してください。チーム境界
チーム境界
質問: 現在、開発チームはどのように編成されていますか？ガイダンス: 既存のチーム構造を反映するように組織を作成してください。同じコードベースで定期的に共同作業するチームは、通常同じ組織に所属させるべきです。例: フロントエンドチームとバックエンドチームが同じプロダクトで密接に協働している場合は、フロントエンド/バックエンドを分けるのではなく、単一の「プロダクトチーム」組織にまとめることを検討してください。
リポジトリアクセスパターン
リポジトリアクセスパターン
質問: 各チームはどのリポジトリへのアクセスが必要ですか？ガイダンス: 同じリポジトリ群へのアクセスが必要なチームをまとめてください。すべての組織メンバーは、その組織のすべてのリポジトリにアクセスできることを忘れないでください。例: Web チームとモバイルチームの両方が共通のデザインシステムのリポジトリへのアクセスを必要とする場合、これらのチームは同じ組織に所属させることが考えられます。
コスト配分と予算管理
コスト配分と予算管理
質問: Devin の利用コストをどのように追跡し、配分したいですか？ガイダンス: 組織は ACU 利用状況を追跡するための自然なコストセンターとなります。組織を予算構造に合わせて設計してください。例: プロダクトラインごとに個別に予算を管理している場合は、それぞれのプロダクトの境界に対応する組織を作成してください。