Microsoft AZ-400: アジャイル計画と作業管理 — 学習ガイド

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

こちらの一部です： Microsoft DevOps Engineer Expert AZ-400 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azure DevOpsにおけるアジャイル計画と作業管理は、明確なデータモデル、規律あるフローとイテレーションの実践、そしてチーム間の可視性を中心に展開されます。Azure Boardsは、作業項目タイプの堅牢な階層とチームごとの柔軟な構成を提供し、一方、GitHub Projectsは、IssueやPull Requestと緊密に統合された、自動化主導の最新の計画機能を提供します。効果的な導入は、厳格な定義（完了の定義、受け入れ基準）、一貫した見積もり（ストーリーポイントと相対的サイジング）、そして実用的なインサイト（クエリ、デリバリー計画、DORAを含むメトリクス）にかかっています。以下のセクションでは、これらの実践を大規模に設計、実装、運用する方法について詳述します。

Azure Boardsのデータモデル、プロセステンプレート、チーム構成

作業項目タイプと階層は、計画のバックボーンを形成します。デフォルトのAgileプロセスでは、ポートフォリオ階層はエピック > フィーチャー > ユーザーストーリーであり、タスクとバグは実行レベルの項目です。子リンクは分解（ユーザーストーリー → タスク）を捉え、バグはチームのポリシーに基づき、ユーザーストーリーと同じバックログレベルで管理されるか、独立してトリアージされます。リンクタイプは不可欠です。

親/子 (Parent/Child): 分解階層を捉え、進捗と作業量のロールアップを駆動します。
先行/後続 (Predecessor/Successor): 作業項目間のスケジューリングと依存関係を表現します。これらはデリバリー計画で依存関係線として表示されます。
関連/重複/ブロックされている (Related/Duplicate/Blocked by): 非階層的な関係や障害をモデル化します。
アーティファクトリンク: 作業項目をコード（コミット、ブランチ、PR）、ビルド、リリースに接続し、エンドツーエンドのトレーサビリティを可能にします。

Azure DevOpsのプロセステンプレートは、状態、フィールド、WITの命名を定義します。

Agile: 要求レベルの項目はユーザーストーリーです。動きの速いチームがしばしばこれを選択します。
Scrum: 要求レベルの項目はプロダクトバックログ項目 (PBI) です。スプリントとScrumアーティファクトが第一級のオブジェクトとして扱われ、バグはPBIのように振る舞うよう構成できます。
CMMI: 要求レベルの項目は要求 (Requirement) であり、変更要求 (Change Request)、リスク (Risk)、レビュー (Review) のためのWITが含まれます。リスクや正式なレビューを追跡する必要がある場合にこれを選択します。
カスタム (継承) プロセス: Azure DevOps Servicesでは、継承を介してシステムプロセスを拡張し、サービスの互換性を維持しながらカスタムWIT、状態、ルール、フィールドを追加します。カテゴリを使用して、カスタムWITを正しいバックログレベルに配置します。レポート作成を困難にするような過度なカスタマイズは避け、ストーリーポイントや残作業などのフィールドを標準化します。

チームは、以下を介して構成される軽量なパーティションです。

エリアパス: 所有範囲とバックログのフィルタリングをスコープします。チームは1つ以上のエリアパスを選択し（オプションで子エリアも含む）、「自分たちの」作業を定義します。
イテレーションパス: リリースケイデンスとスプリントを表します。チームは計画のためにデフォルトおよび現在のイテレーションを選択します。
チームのバックログとボード: 各チームは、表示するポートフォリオレベル（エピック、フィーチャー）、カードのスタイル、列のマッピングを、他のチームに影響を与えることなく選択します。
チームダッシュボード: ベロシティ、バーンダウン/バーンアップ、累積フローダイアグラム (CFD)、リード/サイクルタイムチャート、カスタム分析ビューのウィジェットを使用して、共有の可視性を確保します。

かんばんによるフローベースのデリバリーとガバナンス

Azure Boardsのかんばんは、コミットメントから完了までの継続的なフローをモデル化します。ワークフローの状態にマッピングするために列を構成し、オプションで重要な状態を「実行中/完了」(Doing/Done) のサブ列に分割して、スループットの計算を改善し、隠れたキューを削減します。列ごと、スイムレーンごとに明確なWIP (仕掛り作業) 上限を設定し、運用上それを強制します。上限を超えた場合は、静かにバックログが増えるのではなく、改善のための対話のきっかけとなります。専用のスイムレーン（例：緊急 (Expedite)）を使用して、優先度の高い項目を視覚的に分離し、そのレーンに対してより厳しいWIPを設定します。

完了の定義 (DoD) は、品質と予測可能性を担保します。これをボードポリシー、特定のトランジションでの必須フィールドやチェックリスト、受け入れテストのリンクとして体系化します。例えば、「完了」(Done) に移動する前に、合格したテストケースへの「Tested By」リンクを要求し、「リリース済み」(Released) に移動する際にデプロイ検証ステップを記録します。

分析を使用してフローの健全性を管理します。

累積フローダイアグラムは、WIPの均衡を検証し、帯が拡大したときにボトルネックを検出します。
リードタイムは、作成から完了までの経過時間を測定します。サイクルタイムは、「アクティブ」(Active) に入ってから完了するまでの時間に焦点を当てます。サイクルタイムチャートウィジェットは、作業項目が「アクティブ」に移行した後の経過時間を報告し、ボトルネック分析と整合します。
スループットチャートは、期間ごとに完了した項目を追跡し、安定性と傾向を監視します。

イテレーション計画、バックログリファインメント、ベロシティベースの予測

スプリント計画は、優先順位をタイムボックス化されたコミットメントに変換するものです。スプリントバックログには、イテレーションに取り込まれたPBIまたはユーザーストーリーがリストされ、時間単位の残作業 (Remaining Work) を持つタスクに分解されます。スプリントキャパシティを使用して、メンバーの可用性をモデル化します。

アクティビティ（開発、テスト、UX）ごとの、個人単位の日/時間でのキャパシティ。
休日や休暇を反映するための、個人およびチームの休日。
タスクをアクティビティに関連付け、キャパシティと計画作業をレビューすることによる、アクティビティレベルの負荷分散。

ベロシティは、スプリントごとにデリバリーされたストーリーポイントを要約したものです。ベロシティチャートを使用して安定した帯域を確立し、「ポイントのインフレ」を避けます。プロダクトバックログで予測 (Forecasting) 機能を有効にすると、チームの過去の平均ベロシティ（最近の数スプリントに基づく）とイテレーションの長さに応じて、バックログをバーンダウンするために今後のイテレーションがいくつ必要になるかを予測できます。部分的に完了した作業を除外し、厳格な完了の定義 (DoD) を維持することで、予測の信頼性を保ちます。

バックログリファインメントは、明確さと相対的なサイジングを徹底します。

受け入れ基準 (Acceptance criteria): 作業項目の受け入れ基準フィールドに、明確でテスト可能なステートメントを記録します。あいまいさを減らし、テスト設計を加速するために、Given-When-Then形式を推奨します。
ストーリーポイント (Story points): 要求レベルで、相対的な複雑さと不確実性を見積もります。ポイントを時間に変換しないでください。タスクが残作業 (Remaining Work) を持ちます。
相対見積もり (プランニングポーカー): 共有のベースラインとシーケンス（フィボナッチまたは修正フィボナッチ）を使用して、迅速に収束させます。チームはMarketplaceの拡張機能を使用してAzure Boards内でプランニングポーカーを実行し、一貫したレポート作成のために見積もりをStory Points/Effortフィールドに書き込むことができます。

バグはトリアージし、要件のように扱う（ポイントで見積もり、バックログで計画する）か、スプリント内のタスクとして処理するかのいずれかにします。ベロシティの一貫性を保つために、チームごとに1つの方針を選択してください。

← パッケージ管理とアーティファクト管理 · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →