WEB問題集
AZ400-PRC#1
ある企業では、開発チームと運用チームが分離しており、四半期に一度しか本番リリースを行えていません。リリースのたびに大量の手戻りと障害が発生しています。経営層は「変更のリードタイム短縮」と「変更失敗率の低減」を最優先の改善目標として掲げました。あなたは DevOps 変革のロードマップを策定する立場です。最初に取り組むべきもっとも適切な施策はどれですか。
解説
【正解: A】の理由
DevOps 変革では、改善対象を定量的に把握することが起点になります。コミットから本番までの価値の流れ(バリューストリーム)を可視化し、各ステージのリードタイムと変更失敗率のベースラインを計測することで、ボトルネックに基づくデータ駆動の改善が可能になります。DORA の主要メトリクス(リードタイム・変更失敗率など)を測定する仕組みを先に整えることが、経営層の目標達成に直結します。
【他選択肢が違う理由】
- B: インフラ刷新は有効な場合もありますが、プロセスのボトルネックを把握せずに大規模移行を先行させると、リードタイム短縮や失敗率低減という目標に直結せず、リスクとコストだけが増大します。
- C: 個人別コミット数は生産性の指標として不適切で、サイロ化や協働の阻害を招きます。DevOps はチーム全体のフロー改善を重視し、個人の犯人探しは文化変革を後退させます。
- D: 計測やプロセス改善の裏付けなしにリリース頻度だけを宣言しても、手戻りと障害の根本原因は解消されず、変更失敗率がむしろ悪化します。まず現状を測定することが先決です。
【参考】
AZ400-PRC#2
Azure DevOps REST API を使用して、新しいユーザー ストーリーを作成します。次の HTTP 要求の空欄に入る最も適切な語句を選択してください。
POST https://dev.azure.com/{org}/{project}/_apis/wit/workitems/${{BLANK1}}?api-version=7.1
Content-Type: application/{{BLANK2}}
[
{
"op": "add",
"path": "/fields/System.Title",
"value": "ログイン画面の改善"
}
]| ステートメント | 選択 |
|---|---|
{{BLANK1}} に入る URL セグメント (作成する作業項目の種類) Work Items - Create API では URL の {type} に作業項目の種類 (例: $User Story) を指定します。$ 接頭辞は新規作成エンドポイントの規約です。 | |
{{BLANK2}} に入る Content-Type メディア型 作業項目の作成/更新は JSON Patch ドキュメントで行うため、Content-Type は application/json-patch+json を指定する必要があります。通常の application/json では受け付けられません。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| {{BLANK1}} に入る URL セグメント | $type で作業項目の種類を指定 ($User Story) |
| {{BLANK2}} に入る Content-Type メディア型 | json-patch+json |
【各判定の詳細】
- 「{{BLANK1}} に入る URL セグメント」→ $type で作業項目の種類を指定 ($User Story): Work Items - Create API では URL の {type} に作業項目の種類 (例: $User Story) を指定します。$ 接頭辞は新規作成エンドポイントの規約です。
- 「{{BLANK2}} に入る Content-Type メディア型」→ json-patch+json: 作業項目の作成/更新は JSON Patch ドキュメントで行うため、Content-Type は application/json-patch+json を指定する必要があります。通常の application/json では受け付けられません。
【参考】
AZ400-PRC#3
あるエンタープライズは、開発と運用が分断された「サイロ化」を解消し、DevOps 文化を醸成したいと考えています。次の要件を満たす施策として適切なものを 2つ 選択してください。
要件: (1) 開発と運用が共通の目標と指標に責任を持つ、(2) 障害から組織的に学習し再発を防ぐ。
2 つ選択してください
解説
【正解: A / B】の理由
機能横断チームを編成し SLO/SLI など共通の指標に共同責任を持たせること (A) は、開発と運用のサイロ化を解消し共通目標への当事者意識を生む DevOps 文化の中核です。ブレームレスなポストモーテムを行い是正策をバックログ化して追跡すること (B) は、非難ではなくシステムの改善に焦点を当て、障害から組織的に学習して再発を防ぐ実践です。両者が要件を満たします。
【他選択肢が違う理由】
- C: 運用を専任部門に集約し開発者を本番から完全に切り離すのは、責任の分断を固定化しサイロ化を強める従来型の運用であり、共通目標への共同責任という要件に反します。
- D: 個人の口頭承認とメールでの履歴管理は、追跡可能性と再現性を損ない、共通指標による統制にもなりません。
- E: 失敗の責任を個人に帰して評価へ反映する手法は非難の文化を生み、インシデントの隠蔽を招くためブレームレスな組織学習に逆行します。
【参考】
AZ400-PRC#4
Azure DevOps の継承プロセス (Inheritance Process) をカスタマイズして、既存プロジェクトに新しいフィールドを反映します。手順を正しい順序に並べ替えてください。
- 組織設定でシステム プロセス (Agile 等) をコピーして、新しい継承プロセスを作成する
- 新しいプロセスで作業項目の種類にカスタム フィールドやルールを追加する
- 対象プロジェクトの使用プロセスを新しいプロセスに変更する
- プロジェクトのボード/フォームでカスタマイズが反映されたことを検証する
解説
【正しい順序】
- ステップ 1: 継承プロセスを作成
- ステップ 2: フィールド/ルールを追加
- ステップ 3: プロジェクトのプロセスを切替
- ステップ 4: 反映を検証
【各ステップの理由】
- ステップ 1 継承プロセスを作成: システム プロセスは直接編集できないため、まずコピーして編集可能な継承プロセスを作成します。
- ステップ 2 フィールド/ルールを追加: 作成したプロセス上で WIT へカスタム フィールドや条件付きルールを追加し、定義を整えます。
- ステップ 3 プロジェクトのプロセスを切替: 対象プロジェクトの使用プロセスを新しいプロセスへ変更すると、その内容がプロジェクトへ適用されます。
- ステップ 4 反映を検証: 作業項目フォームやボードでカスタマイズが期待どおり反映されたことを確認します。
【誤った順序の問題点】
- プロセス作成前にプロジェクトのプロセスを切り替える: 切り替え先となる継承プロセスがまだ存在せず、操作自体が成立しません。
- フィールド追加前にプロジェクトへ適用: 空のプロセスを適用してもカスタマイズが無く、再適用の手戻りが発生します。
【参考】
AZ400-PRC#5
チームのフローと進捗を分析するための各指標を、それを可視化するのに最も適した Azure DevOps のチャートに対応付けてください。
項目（ドラッグしてください）
- スプリント バーンダウン
- 累積フロー図 (CFD)
- ベロシティ チャート
- サイクル タイム / リード タイム
スプリント内の残作業の推移を日次で表示する
各状態に滞留する作業量を時系列で積み上げ表示する
スプリントごとの完了量から処理能力を示す
作業が開始から完了までに要した経過時間を示す
解説
【正しいマッチング完全版】
※ バーンダウンは残作業、CFD は各状態の滞留、ベロシティは処理能力、サイクル/リード タイムは所要時間を可視化します。
- スプリント バーンダウン → スプリント内の残作業の推移を日次で表示する
- 累積フロー図 (CFD) → 各状態に滞留する作業量を時系列で積み上げ表示する
- ベロシティ チャート → スプリントごとの完了量から処理能力を示す
- サイクル タイム / リード タイム → 作業が開始から完了までに要した経過時間を示す
【正解マッチング】
| 項目 | カテゴリ |
|---|---|
| スプリント バーンダウン | スプリント内の残作業の推移を日次で表示する |
| 累積フロー図 | 各状態に滞留する作業量を時系列で積み上げ表示する |
| ベロシティ チャート | スプリントごとの完了量から処理能力を示す |
| サイクル タイム / リード タイム | 作業が開始から完了までに要した経過時間を示す |