Azure DevOps はプロジェクトを推進するための便利なサービスです。
色々と柔軟に使えるようにできていますがそれ故、複雑に感じる部分もあるかと思います。
考え方によっては機能が重複しているような部分があるのも事実です。
今回は、Organization,Project,Team,Areaの区分をどう考えると良いのか書いてみたいと思います。
ここに記載されていることがベストプラクティスだとは言いません。
とはいえ、"叩かれ台" があった方が良いかと思いましたので書いてみます。
セキュリティ、マイクロソフトアカウントとAzure AD については基本的に触れません。
Organization(組織)
Organizationは、Azure DevOpsを利用する上で必ず扱う単位です。
使い始めると、何も考えなくても１つのOrganizationが付与され、そこにプロジェクトがぶら下がります。
自分自身も、Organizationに参加しています。
Organizationはプロジェクト束ねる単位
ある程度の規模の会社になってくると、会社の中には複数の部門やプロジェクトが存在すると思います。（開発１部、開発２部）
また、作業者は複数のプロジェクトをまたいでいることもあると思います。
（今はBプロジェクトだけど先月まではAプロジェクトにいて、Aプロジェクトは運用フェーズだけど何かあったら問い合わせ対応はしないといけない）
マネジメント層であれば、ほぼ確実に複数プロジェクトの状況は把握しなければなりません。
このような状況をうまく束ねるための単位として、"Organization"が存在します。
Azure DevOpsは初めに、この組織の単位でアクセス可否判断をします。
おすすめは会社で１つのOrganization
Organizationをどの単位で扱うかは、会社の規模にも依存します。
理想的なのは、会社で１つのOrganizationです。これをAzure ADとからめてユーザーをグルーピングして扱うと、管理が楽になります。（"使えない状態にする"の管理が非常に大切です）
Organizationをどう扱うかを考える際に指針となりそうなポイントを列挙します。
- 支払いをプロジェクト単位で扱うのか、会社として扱うのか
- 利用者(社員やパートナーさん)が異動するプロジェクトの範囲
- 品質保証担当者やマネージャーの確認範囲
利用者にとっても管理者にとっても、できるだけ１つにまとめて扱った方が便利です。
利用料の支払いについても、Azure DevOpsはOrganization単位でユーザー数やコンピューティング数をカウントしていますので、まとめた方がお買い得です。
無料範囲と複数組織をまたがる有償ユーザー数を天秤にかけて、将来的にどちらが良いかをご検討ください。
おすすめは "可能な限り１つのOrganizationにまとめる" です。
Project
Project(プロジェクト)は、Organizationの次に意識する単位です。
Azure DevOpsはOrganizationの次にProject単位でアクセス可否判断をします。
１つのOrganizationには複数のProjectをぶら下げることができます。
またProject１つで（後述のTeamとAreaを使うことによって）複数のプロダクトやサービスを管理することは可能です。
Projectはプロダクトやサービスをまとめる単位
Projectは一般的な、いわゆる"プロジェクト"と同義です。
お客様に何らかの価値を提供して対価をいただくプロダクトやサービスの単位です。
おすすめはプロダクトやサービス単位の分割から始める
会社の中には開発、品質保証、運用で部門やチームが分割していることもあるかと思います。
そのチーム単位で管理したい内容が異なることもあるかと思います。
しかしながら、このような会社の中のルールに縛られることなく、プロダクトやサービスの単位で分割し、その個々のプロジェクトに対して必要な方が必要なタイミングで参加するという方式をおすすめします。
Projectをどう扱うかを考える際に指針となりそうなポイントを列挙します。
- 提供するプロダクトやサービスの単位になっているか
- イテレーションのタイミングが合致するか
- リポジトリの分割点として妥当か
まずはお客様に価値を提供する単位で分割します。
次に、１つのサービスであっても中身は複数のサービスに分割されていることがあります。この場合、リリースタイミングを意識してください。リリースタイミングはほぼイコールでイテレーション(開発期間)と関連があります。イテレーションのタイミングが異なるチームが同じプロジェクトで作業をすると、開発状況が良いのか悪いのかをジャッジしずらい状況になります。（きちんと管理すれば問題なくジャッジできる状況は作れますが、最初は混乱する可能性があります。）
最後に、主にソースコードを格納するリポジトリを意識します。リポジトリの分割は、CI/CD(継続的インテグレーション/継続的デリバリー)を検討する上で重要です。
おすすめは "プロダクトやサービス単位の分割から始める" です。
Team
Team(チーム)は、Projectの次に意識する単位です。
Projectはプロジェクトやサービス単位で作ることをおすすめしました。
１つのプロダクトやサービスを企画・開発・運営していく際、すべてを１つにまとめると視認性が下がる場合があります。
そこで登場するのが"Team"です。
細かい設定の話題を抜きにしますが、Teamを使うことで各Teamが "自分たちが成すべきことに集中しつつ、まわりがやっていることも確認できる" 状況を作り出すことができます。
Team は集中すべきことを共有する人たちのための単位
TeamはAzure DevOps上で人を束ねる最小単位です。
"お客様に最高のサービスを提供するために、今１つだけやるべき作業は？" と問われたときに同じ作業を想像するグループ（チーム）です。
Teamという単位には
- 人(Member)
- 作業領域(Area)
- 活動期間(Iteration)
などが紐付きます。
おすすめはプロジェクトで１つ or 価値の出し方別に分ける
Teamで実現できることは、タスクの視認性向上です。自分がどこかのチームに所属し、そのチームが集中していることを認識するための区分です。
自分たちの手のひらに乗る大きさであれば、チームは１つ（デフォルト）で十分です。また、 "自分のチームじゃないから関係ない" という認識をさせないという意味においてもOne Teamであることがベストです。
しかしながら、他人のことが気になって集中できないのは問題なのも事実です。
Teamをどう扱うかを考える際に指針となりそうなポイントを列挙します。
- 価値観を共有できるか
- イテレーションのタイミングが合致するか
- マネジメントの質が上がるか
まず大切なことは価値観の共有です。 "自分たちが集中すべきことが何か？" を共感できる単位を意識してください。
たとえば、
- Web・モバイル・バッチ・品質・インフラ・サービスのような機能や役割に応じた区分
- 開発チームを４つに分けて３チームは開発、１チームはリファクタリングをローテーションで実施
というような分け方です。
プロジェクト内ですべてのリリースタイミングが同じであるとは限りません。たとえば顧客向け機能と社内向け管理機能ではリリースタイミングがまったく異なるというようなことはあると思います。
このような場合に、無理にタイミングをあわせるのではなく各々が最大のインパクトを出すことができるタイミングで稼働できるようチームを分割します。
最終的に、プロジェクトを成功に導くためにはプロダクトオーナーやプロジェクトオーナー、その他関わりのあるマネジメント層が現状を正しく判断できる必要があります。この判断を素早く正確に実現するためにもTeamを利用します。詳細は記載しませんが、チーム単位でベロシティや予実をチェックすることで "プロジェクトの今" を簡単に把握できるようになります。
おすすめは "プロジェクトで１つ or 価値の出し方別に分ける" です。
Area
Area(エリア)は作業領域を認識するための区分です。
さきほどのTeamを機能や役割で分割した時の、そのTeamが担当する作業領域に対して付与する名前だと、まずはご理解ください。
まとめ
今回は、Organization,Project,Team,Areaについて記載しました。
使い方によって、どういう区分の仕方もできますし、結果的に同じことが実現できる機能が重複していることも事実です。
"どういう指針を以って構成したのか" をある程度説明できるようにしていただくことをおすすめします。
そうしないと、同じ会社で新たにAzure DevOpsを使おうと思った人が、そのOrganizationに参加して良いのか悪いのかよくわからず、最終的に野良Organizationや野良プロジェクトが生まれます。