はじめに

はじめまして、1月から入社した札幌市在住、ACS事業部の大久保と申します。
以前はSIでプログラマーとして務めていましたが、クラウドネイティブの世界に触れてみたいと考えていた最中、Twitterで見つけたACS事業部が主催していたクラウドネイティブBootCampに応募してご縁があり、入社することができました。
インフラやクラウドは業務では初めてですが、日々新しいツールに驚きや刺激を受けています。
事業部では部内の進捗管理にAzure DevOpsのBoards（カンバン）を使用しています。
そのツールを使いこなすために、自身でAzure DevOpsを導入して試しているうちに、AreaPathやIterationPathという名前空間をチームに割り当てる機能を使用することで、よりアジャイルな組織構成、事業部で盛んに議論されているチームトポロジーの構築が簡単にできるのではないかと考えるに至りました。
このことを今回のブログのネタにしようと思います。

www.ap-com.co.jp

Azure DevOpsにおける２つのPath

AzureのProject上におけるPathは以下の二つになります。

AreaPath：プロジェクト内のチームを管理するためのパス。
IterationPath：割り当てられたチームのスプリントを管理するためのパス。

Azure DevOpsではプロジェクト内で業務やチーム名などで名前空間を作成し、チームを割り当て、ワークアイテムやスプリントをチームごとに管理することが可能です。
また、AreaPathを作成する際に組織のトポロジーを投影することで、組織を構成するチームやメンバーの関係性に即したボードやチケットの管理、コラボレーション、ワークフロー、そしてこれらと連動したDevOpsも実現します。
公式ページでは２つのAreaは以下のように説明されております。

エリアパスを使用すると、チーム、製品、または機能領域ごとに作業項目をグループ化できます。イテレーションパスを使用すると、スプリント、マイルストーン、またはその他のイベント固有または時間関連の期間に作業をグループ化できます。どちらのフィールドでも、パスの階層を定義できます。

また、以下のようにも書かれております。

製品、機能、またはビジネス領域に基づいてチームをサポートし、作業項目をグループ化するためのエリアパスを追加します。プロジェクトレベルでエリアパスを定義したら、チーム構成でチームに割り当てます。また、エリアパスの階層を作成して、最大 14 レベルの深さのサブエリアをサポートすることもできます。

learn.microsoft.com

参考画像

文字だけではイメージが伝わりづらいので２つのPathの設定画面でイメージをつけていただいた上で以降のトピックをご覧ください。

Project全体のAreaPath

チームに割り当てられたAreaPath

WorkItemにAreaPathが設定される様子

Project全体のIterationPath

AreaPathにチームを紐づけてSprintを作成する手順

以降の手順はadmin権限で全て行います。
今回の主題はAreaPathを紐付けてSprintを作成する流れをお見せすることなので、メトリクス等のトピックは取り上げません。

AreaPathを作る

まずはProject全体のArea管理画面を開きます。
ProjectSettings(画面左下)->ProjectConfigration(メニューバー) -> Areasタブ(右のタブ)

次にrootとなるAreaを選択してNewChildをクリックし名前を付けSaveAndCloseを押す。

※ネーミングは以下のリンクを参考に作業を分類するものを作成。少なくともチームごとに１つは追加。
(e.g frontEnd, backend, server_side, infra, management, marketing, club_activity,etc...)

直接エリアパスの定義と割り当ての項への直リンク learn.microsoft.com

AreaにはSecurity設定があり、Group, Team, Userに対して各種権限管理を設定することが可能となっております。

チームにAreaPathを割り当てる

次にこのAreaPathを割り当てるチームのメニューをメニュー画面を開きます。
ProjectSettings(画面左下)->Teams(メニューバーの上の方) -> チーム名をクリック

遷移先の画面のヘッダが選択したチームになるので、Iterations and Area Pathsを選択します。

新しいタブが開いてチームの設定画面が開きます。
この画面ではボードに表示するWorkItemTypeなど各種設定ができます。

Areaのタブを選択してArea管理画面に行くと、チーム作成時に作成したチーム名のAreaPathが設定されてる状態になります。

SelectAreaを選択するとプロジェクト全体のAreaPathが出てくるので、先ほど作成した"server_side_dev"を選択します。

作成したAreaに対してやはり権限管理等の操作が可能になります。

BoardsにAreaPathと同じ名前のボードができたのでクリックします。

すると何もないボードの画面に遷移するので、次のスプリント作成の紹介のために2つのUserStoryと幾つかのタスクを作ります。

スプリントを作成する

Project全体のIteration管理画面を開きます。
ProjectSettings(画面左下)->ProjectConfigration(メニューバー) -> Iterationsタブ(右のタブ)

AreaPathと同じ要領でrootからNewChildで新たなスプリントを追加しますが、最初のSprintはあくまでIterationのAreaとして作成するので日付は今回は入れません。

作成したスプリントに対して日付の設定した子を2つほど追加します。

すると以下のような、1週間スプリントが2つ作成されました。

作成したスプリントをチームに割り当てる

TeamConfigrationを開いてIterationsのタブを開きます。

Select Iterationsから先ほど作成した２つのSprintを選びます。

次にCurrentSprintをSprint1にsetします。

BacklogIterationは触らなくてよいです。これにてスプリントがserver_side_devチームに割り当てられました。

スプリントにWorkItemを割り当てる

次にBoardsのメニューからbacklogを開きますと以下のようにスプリントとWorkItemが画面に出てきます。 WorkItemをスプリントにドラッグアンドドロップします。するとスプリントのパネルの表示が変わります。この状態でBoardsメニューからSprintを開くとWorkItemが割り当てられてることが確認できます。

これでAreaPathに紐づいたSprintが完成しました。

チームトポロジーが頭をよぎる

さてここからが本題です。
ここまでのプロセスを振り返ると以下の流れの繰り返しです。

Adminがプロジェクト内にPathを切る

AdminがチームにPathを割り当てる

次に割り当てたPathのSecurity項目を見ると、チームに対してノード(AreaPath)や子ノードの編集権を付与することに気づきます。ノードの編集権とはアクセス制御、名前変更のことです。これを今のプロセスに追加してみます。

Adminがプロジェクト内にPathを切る

AdminがチームにPathを割り当てる

Adminがチームにノードの編集権を与える

この流れを見たときにチームトポロジーに書かれていた一節を思い出されました。

チームに権限を与え、チームを基本的な構成要素として扱うことで、チーム内の個人は単なる人の集まりとしてでなくチームとして密接に連携しながら進むようになる。

出典：チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計組織図の脱却の項より

この言葉に素直に従うと、次のステップは自ずと以下になると考えます。

チームはノードアクセス制御権を用いて自律的に他チームとのコラボレーションを開始する。
これによりチームは組織図からの脱却を計る。

※組織図からの脱却とは部門を跨いだコミュニケーションが親組織を経由して行われる組織、いわゆる縦割りからの脱却と考えてください。

やはりこれはチームトポロジーにしか見えませんね。
では実際の流れはどのようになっていくのだろうか？という妄想が膨らんでくるのですが、本記事は一旦ここまでといたします。
次の記事にてAzure DevOps x チームトポロジーのシナリオを描いてみますので、是非ともそちらの記事も読んでください。
最後までお読み頂きありがとうございました。

learn.microsoft.com