Azure Boards

解決する課題

ソフトウェア開発では「何を作るか」の計画と「実際の変更」が別ツールに分かれ、進捗や経緯が追えなくなりがちです。Azure Boards は、課題やタスクを作業項目として一元管理し、ボードやバックログで可視化したうえで、コミット・プルリクエスト・ビルドとひもづけて計画から実装・配信までを追跡できるようにします。

• 課題・要望・バグを1つの場所で起票・分類・優先順位付けしたい
• かんばんやスプリントでチームの進捗を見える化したい
• 計画した作業と実際のコード変更・デプロイを連結してトレースしたい
• 要件の階層（大きな目標から細かいタスクまで）を親子関係で構造化したい

主要概念と用語

• 作業項目（Work Item）: 計画や作業の最小単位。エピック・機能・ユーザーストーリー（またはプロダクトバックログ項目）・タスク・バグ・課題などの種類がある
• ボード（Board）: 作業項目をカードとして列（状態）に並べるかんばんビュー。ドラッグで状態を進められる
• バックログ（Backlog）: 作業項目を優先順位順に積んだ一覧。エピック→機能→ストーリーの階層を展開して見られる
• スプリント（Sprint）/ イテレーション: スクラムで一定期間に取り組む作業のまとまり。スプリントボードやタスクボードで進捗を追う
• プロセス（Process）: ワークフローや項目種類を決めるテンプレート。標準では基本（Basic）・アジャイル（Agile）・スクラム（Scrum）・CMMI から選ぶ
• エリアパス / イテレーションパス: 作業項目を組織構造（チーム・コンポーネント）や時間（スプリント）で分類する軸
• クエリ（Query）: 条件で作業項目を抽出する仕組み。フラット一覧や親子ツリーで結果を表示できる
• ダッシュボード / ウィジェット: バーンダウンやベロシティなどの指標をタイルで可視化する画面

仕様・制限・クォータ

• 4つの標準プロセス: 基本・アジャイル・スクラム・CMMI から選べる。チームのやり方に合わせて作業項目の種類やワークフロー（状態遷移）が変わる
• プロセスのカスタマイズ: 継承（Inheritance）モデルで、フィールド追加・状態追加・ルール設定などを画面から行える（旧オンプレ版の XML カスタマイズとは別系統）
• 階層構造: エピック→機能→ストーリー/バグ→タスクのように親子でひもづけ、上位の進捗を下位の積み上げで把握できる
• 作業項目の連結: コミットやプルリクエスト、ブランチ、ビルドと作業項目をリンクして相互参照できる
• クエリと通知: 条件クエリで作業項目を抽出し、変更時のフォロー通知やサービスフックで外部連携できる
• API/拡張: REST API と Marketplace 拡張で機能を補える
• 作業項目数やフィールド数などの上限値は時期やプランで変わり得るため、設計時は最新の公式ドキュメントで確認する

内部の仕組み

Azure Boards は Azure DevOps のプロジェクト配下で動く計画サービスで、すべての計画情報は作業項目として保存されます。各作業項目は種類ごとに決まったフィールドと状態遷移のワークフロー（例: 新規→進行中→完了）を持ち、これらは選んだプロセスによって定義されます。

作業項目はエリアパスとイテレーションパスで分類され、エリアパスはチームやコンポーネントへの割り当て、イテレーションパスはスプリントなどの期間への割り当てに使われます。チームのボードやバックログは、この2つのパスでフィルタした作業項目を表示しているにすぎず、同じ作業項目を複数のビュー（ボード・バックログ・クエリ）から異なる切り口で見ています。

計画と実装の連結はリンクで実現されます。コミットメッセージやプルリクエストに作業項目 ID を記すと、その作業項目と変更が相互参照され、どの要件がどのコードで実装され、どのビルドで配信されたかをたどれます。

設計パターン / ベストプラクティス

• 階層を意識した起票: 大きな目標はエピック、まとまった価値は機能、実装単位はストーリー/バグ、細分はタスク、と粒度をそろえて親子でひもづける
• 作業項目とコードの連結: コミットやプルリクエストに作業項目 ID を必ず記し、計画から変更・デプロイまでトレースできるようにする
• ブランチポリシーと連動: 保護ブランチに「リンクされた作業項目を必須」にして、変更の背景が常に残るようにする
• WIP 制限の活用: かんばんの列に仕掛り（WIP）上限を設定し、滞留やボトルネックを早期に発見する
• クエリとダッシュボードの整備: よく使う抽出条件をクエリ化し、バーンダウンやベロシティをダッシュボードに集約してチームで共有する
• エリア/イテレーションの設計: チーム構成とスプリントに合わせてパスを設計し、ビューの切り替えだけで多視点に見られるようにする

運用・監視

• 進捗の可視化: バーンダウン・バーンアップ・ベロシティ・累積フロー図（CFD）で、計画どおり進んでいるか・滞留がないかを把握する
• 滞留の検知: かんばんの列ごとの滞在時間や WIP 超過を確認し、特定状態での停滞を見つける
• クエリでの棚卸し: 期限切れ・担当未割り当て・長期未更新の作業項目をクエリで抽出し、定期的に整理する
• 通知連携: フォロー通知やサービスフックで、状態変更やコメントを Teams 等へ連携し見落としを防ぐ
• Analytics ビュー: 集計・傾向分析用の Analytics を使い、Power BI 等と連携してチーム横断の指標を可視化する

コスト

Azure Boards 単体の課金は、原則ユーザーのアクセスレベルに基づきます。ボードの閲覧やコメント中心の利用は無償の**関係者（Stakeholder）レベルで多くがまかなえ、フル機能の利用には基本（Basic）**以上のアクセスレベルが必要です。Boards 自体に並列ジョブやストレージのような従量課金は基本的になく、ストレージ課金は主に Pipelines や Artifacts 側で発生します。

セキュリティ

• 認証は Microsoft Entra ID と連携でき、条件付きアクセスや多要素認証を組織のポリシーで適用できる
• 権限は最小権限で。プロジェクト/チーム単位のグループとエリアパス単位のアクセス制御を使い分け、見せる範囲を絞る
• エリアパスごとの権限: 機密性の高いコンポーネントの作業項目は、対応するエリアパスの権限で閲覧・編集を制限できる
• PAT（個人用アクセストークン）の管理: API 連携で PAT を使う場合はスコープと有効期限を絞り、可能なら Entra ID 認証を優先する
• 監査ログ: 組織レベルの監査ストリームで、プロセス変更や権限変更といった操作の証跡を残せる

関連サービス・比較

ハンズオン / CLI例

# Azure CLI に DevOps 拡張を追加し、組織・プロジェクトの既定を設定
az extension add --name azure-devops
az devops configure --defaults \
  organization=https://dev.azure.com/myorg \
  project=demo-project

# ユーザーストーリーを作成する
az boards work-item create \
  --title "ログイン機能の実装" \
  --type "User Story"

# バグを作成して担当者と優先度を設定する
az boards work-item create \
  --title "ログイン時に500エラー" \
  --type "Bug" \
  --assigned-to user@example.com \
  --fields "Microsoft.VSTS.Common.Priority=1"

# 作成済みの作業項目を ID 指定で確認する
az boards work-item show --id 42 --output table

# 親子関係をリンクする（タスク42 を ストーリー10 の子にする）
az boards work-item relation add \
  --id 42 \
  --relation-type parent \
  --target-id 10