WEB問題集
ある企業では、開発チームと運用チームが分離しており、四半期に一度しか本番リリースを行えていません。リリースのたびに大量の手戻りと障害が発生しています。経営層は「変更のリードタイム短縮」と「変更失敗率の低減」を最優先の改善目標として掲げました。あなたは DevOps 変革のロードマップを策定する立場です。最初に取り組むべきもっとも適切な施策はどれですか。
解説
【正解: D】の理由
四半期に一度の大規模リリースで手戻りと障害が多発している状況では、まず改善の対象を定量的に把握することが出発点になります。コミットから本番までの価値の流れ (バリュー ストリーム) 全体を可視化し、各ステージのリードタイムや変更失敗率のベースライン (基準値) を計測すれば、どこにボトルネックがあるかがデータで見えるようになります。経営層が掲げた「変更のリードタイム短縮」と「変更失敗率の低減」という DORA 系メトリクスの目標は、現状を測る仕組みを先に整えてこそ、事実に基づいて着実に改善を進められます。したがって、価値の流れの可視化と基準値の確立を最初に行うのが最も適切です。
【他選択肢が違う理由】
- A: 開発者の個人別コミット数を測って生産性の低い人を特定する手法は指標として不適切で、サイロ化や犯人探しを招き、チーム全体のフロー改善を重視する DevOps 文化を後退させます。
- B: プロセスのボトルネックを把握しないまま全マイクロサービスの Kubernetes 移行を先行させると、リードタイム短縮や失敗率の低減に直結せず、リスクとコストだけが増えます。
- C: 計測やプロセス改善の裏付けなくリリース頻度だけを宣言しても、手戻りや障害の根本原因は解消されず、変更失敗率はむしろ悪化しかねません。
【参考】
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 |
【ポイント】
Azure DevOps REST API で新しい作業項目を作成する Work Items - Create では、エンドポイントの URL 末尾に作成したい作業項目の種類を指定します。workitems/$ に続けて $User Story のように種類名を渡すため、{{BLANK1}} には $type で作業項目の種類を指定するセグメントが入ります。要求ボディは fields を op と path で表現する JSON Patch ドキュメント形式であり、この形式をサーバーに正しく解釈させるには Content-Type ヘッダーに application/json-patch+json を指定する必要があります。通常の application/json では JSON Patch として扱われず要求が失敗するため、{{BLANK2}} は json-patch+json が正解になります。
【参考】
あるエンタープライズは、開発と運用が分断された「サイロ化」を解消し、DevOps 文化を醸成したいと考えています。次の要件を満たす施策として適切なものを 2つ 選択してください。
要件: (1) 開発と運用が共通の目標と指標に責任を持つ、(2) 障害から組織的に学習し再発を防ぐ。
解説
【正解: A / B】の理由
開発と運用のサイロ化を解消するには、両者が同じ目標と指標に共同で責任を負い、障害から組織として学ぶ文化を根づかせることが重要です。開発・運用・QA を含む機能横断チームを編成し、サービスの SLO/SLI など共通の指標に対して共同で責任を負わせることは、部門間の責任の分断を解消し、共通目標への当事者意識を生む DevOps 文化の中核です (B)。また本番障害に対して非難を伴わない(ブレームレス)ポストモーテムを実施し、得られた是正策をバックログ化して追跡することは、個人への非難ではなくシステムの改善に焦点を当て、障害から組織的に学習して再発を防ぐ実践です (A)。この2つが、共通の目標・指標への共同責任と障害からの組織学習という要件を直接満たします。
【他選択肢が違う理由】
- C: 運用を専任部門に集約し開発者を本番から完全に切り離す方式は、責任の分断を固定化してサイロ化を強める従来型の運用であり、共同責任という要件に反します。
- D: デプロイ承認を個人の口頭承認に一本化し変更履歴を各自のメールで管理する方式は、追跡可能性と再現性を損ない、共通指標による統制にもなりません。
- E: 失敗したデプロイの担当者を個人評価に反映する手法は非難の文化を生み、インシデントの隠蔽を招くため、ブレームレスな組織学習に逆行します。
【参考】
- プロジェクトのボード/フォームでカスタマイズが反映されたことを検証する
- 新しいプロセスで作業項目の種類にカスタム フィールドやルールを追加する
- 対象プロジェクトの使用プロセスを新しいプロセスに変更する
- 組織設定でシステム プロセス (Agile 等) をコピーして、新しい継承プロセスを作成する
解説
【正しい順序】
- 組織設定でシステム プロセス (Agile 等) をコピーして、新しい継承プロセスを作成する
- 新しいプロセスで作業項目の種類にカスタム フィールドやルールを追加する
- 対象プロジェクトの使用プロセスを新しいプロセスに変更する
- プロジェクトのボード/フォームでカスタマイズが反映されたことを検証する
【ポイント】
- ステップ 1 継承プロセスを作成: システム プロセスは直接編集できないため、まずコピーして編集可能な継承プロセスを作成します。
- ステップ 2 フィールド/ルールを追加: 作成したプロセス上で WIT へカスタム フィールドや条件付きルールを追加し、定義を整えます。
- ステップ 3 プロジェクトのプロセスを切替: 対象プロジェクトの使用プロセスを新しいプロセスへ変更すると、その内容がプロジェクトへ適用されます。
- ステップ 4 反映を検証: 作業項目フォームやボードでカスタマイズが期待どおり反映されたことを確認します。
【誤った順序の問題点】
- プロセス作成前にプロジェクトのプロセスを切り替える: 切り替え先となる継承プロセスがまだ存在せず、操作自体が成立しません。
- フィールド追加前にプロジェクトへ適用: 空のプロセスを適用してもカスタマイズが無く、再適用の手戻りが発生します。
【参考】
- 累積フロー図 (CFD)
- スプリント バーンダウン
- ベロシティ チャート
- サイクル タイム / リード タイム
解説
【正解マッチング】
| 項目 | 説明 |
|---|---|
| スプリント バーンダウン | スプリント内の残作業の推移を日次で表示する |
| 累積フロー図 (CFD) | 各状態に滞留する作業量を時系列で積み上げ表示する |
| ベロシティ チャート | スプリントごとの完了量から処理能力を示す |
| サイクル タイム / リード タイム | 作業が開始から完了までに要した経過時間を示す |
【ポイント】
これらのチャートはアジャイル開発の進捗と流れを異なる観点で可視化します。スプリント バーンダウンは、スプリント内に残っている作業量の推移を日次で示し、期限までに完了できそうかを追跡します。累積フロー図 (CFD) は、各ワークフロー状態にある作業量を時系列で積み上げて表示し、どの状態に作業が滞留してボトルネックになっているかを把握できます。ベロシティ チャートは、スプリントごとに完了した作業量を集計してチームの処理能力を示し、将来の計画やキャパシティ見積もりに使います。サイクル タイムやリード タイムは、作業が開始から完了、あるいは受付から完了までに要した経過時間を示し、フローの速さと予測可能性を評価します。残作業・滞留・処理能力・所要時間という着目点の違いを理解して選ぶことが重要です。