1. 導入（設定の提示）
先日、別会社でチームリーダーをしている知人のエンジニアから相談を受けました。
『Azure DevOpsを使ってReposでソース管理を始めようとしたら、インフラ担当から開発メンバーは5人まで、管理者は1人という制限を言い渡された。これってAzureの仕様なの？それともうちの会社のケチなルール？』
という内容です。
2. 「5人制限」の正体は、Azure DevOpsのBasicプラン
結論から言うと、これは会社のケチなルールではなく、Azure DevOpsの標準的なライセンス仕様（Basicプラン）によるものです。
• 5人まで： Basicユーザーは5人まで無料。
• 6人目から： 月額料金（約$6〜/人）が発生。
知人のチームも、最初は『無料の範囲内でスモールスタートしたい』というインフラ側の意向があったようです。
こちらに詳しく書かられていました。
3. 「管理者は1人」という運用の背景
さらに彼を悩ませていたのが『管理者は1人』という制約。
これはシステム上の制限というより、ガバナンス（統制）の側面が強いとアドバイスしました。
• Organization Ownerは1人。
• マスターへのマージやデプロイ権限を絞ることで、事故を防ぐ運用。
• ただし、リーダーとしてコード管理をスムーズにしたいなら、権限（Project Administratorsなど）を適切に切り分けてもらう交渉が必要かもしれません。
4. 解決策として提示したアドバイス
相談に来た彼には、以下の3つのチェックポイントを伝えました。
1. Stakeholder（ステークホルダー）の活用: コードを見ないメンバー（進捗確認のみのPMなど）は、無料枠の5人にカウントされず無制限に招待できる。
2. Visual Studio サブスクリプションの確認: もし既にVSのライセンスを持っていれば、その人は5人の枠を使わずにBasic機能が使える。
3. 役割の明確化: 誰がマージ権限を持ち、誰がリリースを承認するか。人数を増やす前に、この『交通整理』をインフラチームと握っておくことが重要。
5. まとめ
クラウドサービスは便利ですが、こうした『人数の壁』が突然現れます。
実体験（相談）を通じて感じたのは、開発効率とライセンス費用のバランスを、リーダーがいかに把握しておくかという大切さでした。