学習目標
変更しないことではなく、変更の理由・影響・結果を追跡できることを目指す。開発モデル、プロジェクト管理、構成管理、自動化を別の軸として整理する。
開発モデルと管理の違い
| 考え方 | 主に重視するもの | 誤解しやすい点 |
|---|---|---|
| ウォーターフォール型 | 工程ごとの成果と承認を順に整理 | 全ての変更を禁止する方式ではない |
| 反復型 | 作り、評価し、改善を繰り返す | 反復するだけで必ず価値が増えるわけではない |
| インクリメンタル型 | 利用可能な機能を段階的に増やす | 反復と対立する分類ではなく併用できる |
| アジャイル | 小さな単位で学習し、変化に対応 | 計画・文書・契約が不要という意味ではない |
アジャイルソフトウェア開発宣言は、対話や動く成果などを相対的に重く見る考え方であり、文書を作らないことを求めていない。
Scrumで混同しやすい対象
| 対象 | 役割・意味 |
|---|---|
| プロダクトオーナー | プロダクト価値とプロダクトバックログの効果的管理に責任を持つ |
| 開発者 | 利用可能なインクリメントを作り、実現の計画を適応させる |
| スクラムマスター | Scrumの確立を支援し、チームの有効性に責任を持つ |
| プロダクトバックログ | プロダクト改善に必要な作業を順序付けした一覧 |
| スプリントバックログ | スプリントゴール、選択した項目、実現の計画 |
| 完成の定義 | インクリメントに必要な品質条件についての共通理解 |
スプリントレビューは成果と今後の適応、レトロスペクティブは進め方の改善を主眼とする。完成の定義を満たさない作業を、単に期間が終わったから完成扱いしない。Scrum Guide 2020
自動化の範囲
| 用語 | この教材での意味 | 本番反映 |
|---|---|---|
| CI 継続的インテグレーション | 小さな変更を頻繁に統合し、自動ビルド・検査で問題を早期検出 | 必須ではない |
| 継続的デリバリー | リリース可能な状態を継続して保つ | 人の判断を残せる |
| 継続的デプロイ | 検査を通った変更を本番まで自動反映 | 自動 |
この区別は説明上の標準的な用法で、CDがどちらの略かは文脈で確認する。どの自動化でも、アクセス制御、依存物の管理、成果物の完全性、脆弱性への対応が必要。NIST SSDF 1.1
判断例
ソースのコミットAから成果物を作って検査した後、本番用として再ビルドすると依存物の差により別の成果物になる可能性がある。検査済み成果物を識別子やハッシュとともに保管し、同じものを環境間で昇格させれば追跡しやすい。環境固有の設定・秘密情報は別管理し、設定変更も履歴に残す。
構成管理と変更管理
構成管理は、何を管理対象とし、どの版が組み合わさっているか、基準となる状態は何かを管理する。変更管理は変更要求の理由、影響、承認、実施結果を扱う。版管理ツールがあるだけで、承認や影響分析まで自動的に整うわけではない。
間違えやすい点と確認
- 自動テストの成功は、未定義の業務要求を満たす証拠にはならない。
- ロールバック手順はプログラムだけでなくDB変更や外部への副作用も考える。
- 本番投入前に承認が必要なら継続的デリバリーではないか？ → 承認を残しても成立する。
- 振返りで改善する主な対象は？ → チームの進め方や品質・有効性。製品の成果の検査だけではない。
出典と適用上の注意
図と運用例は独自作成。Scrumの用語は2020版を基準とし、旧版を指定した過去問とは区別する。特定ツールの導入を出題予想の根拠にはしていない。