このユニットの結論
自動テストは、決めた確認を、変更のたびに同じように速く繰り返す仕組みです。自動配布は、確かめた版を、決まった手順で各環境へ届ける仕組みです。
どちらも作業を速く、ばらつきなくします。一方で、書かれていない確認はしないこと、誤りも同じ速さで届けることが限界です。何を自動にし、どこに人の確認と承認を残すかを決めて使います。
1. 何の話か
このユニットは、変更を確かめて届ける作業の自動化の話です。
大勢で開発すると、変更が毎日のように本流へ取り込まれます（09-01 同時に100人がコードを変更したらどうなるか）。そのたびに人が手で確かめ、手で各環境へ配っていては、間に合わず、手順もばらつきます。
この自動化の仕組みを、一般に CI/CD と呼びます。CI は「変更を取り込む前後に、そのたびに自動で組み立てて確かめること」、CD は「確かめた版を自動で各環境へ届けること」です。
2. なぜ必要か
確かめる作業と配る作業を手作業に頼ると、
- 確かめる内容が、人や日によってばらつく
- 忙しい時期に、確認が省かれる
- 配る手順を間違え、確かめたものと違う版を出す
- どの版を、いつ、どの環境に出したかが分からなくなる
ということが起きます。
3. このユニットで分かること
- 自動テストと自動配布の流れ
- 自動テストで言えること・言えないこと
- 自動配布で気をつけること
- 自動化で、AIに任せてよいことと人間が決めること
4. 流れ（一般的な例）
- 変更の取り込みを依頼する
- プログラムを自動で組み立て、自動テストを動かす。失敗したら、そこで止まり、担当に知らせる
- 人がレビューし、通れば本流に取り込む
- 取り込んだあとの本流でも、自動で組み立ててテストする
- テスト環境へ自動で届ける
- 人が確かめ、承認する
- 本番へ届ける（決められた手順と承認で）
どの段階まで自動で進め、どこで人が承認するかは、プロジェクトで決めます。環境の分け方は 09-03 開発・テスト・本番をなぜ分けるのか で学びました。
5. 自動テストで言えること・言えないこと
| 言えること | 言えないこと |
|---|---|
| 書いておいた確認について、前と同じ結果になる | 書いていない確認の結果 |
| 変更のたびに、同じ確認を漏れなく行った | 業務のルールや手順に合っているか（10-03 利用部門が確認するテスト） |
| 失敗した確認と、その時点の変更 | 画面の分かりやすさ、使いやすさ |
| 本番と同じ量・条件での動き（10-04 性能をどう確認するのか） | |
| 確認のプログラムそのものが正しいか |
自動テストは、人が決めた確認を代わりに繰り返すものです。何を確かめるかを決めるのは人で、その計画は TST-002 テスト計画・対象一覧 にまとめます。テストの段階の考え方は 10-02 小さい単位から全体へテストする で学びます。
6. 自動配布で気をつけること
- 誤りも速く届く：確かめる仕組みが弱いと、誤りが同じ速さで各環境に広がる
- 本番の前に人の承認を置く：本番へ届けるのは、承認を得てからにする
- 戻す手順を用意する：前の版に戻す手順を決め、試しておく
- 出した版の履歴を残す：どの版を、いつ、どの環境に、誰の承認で出したか
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- システムに SYS-09 開発・CI/CD基盤がある
- Vendor B / クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- 約120人規模のプロジェクト
- AIへ最終委任しないことに「本番移行承認」がある
- 成果物に DEV-003 自動テスト・自動配布構成がある
アステリア案件で、どの確認を自動テストにしたか、どの環境まで自動で届けたか、本番へ届ける前の承認を誰が行ったかは、正本に記載がありません。未確定 Vendor B と他のベンダーとの間で、自動化の作業をどう分担したかも記載がありません。未確定
7. THINK — 「ときどき失敗するテスト」
ある自動テストが、ときどき失敗します。チームでは「失敗したら、もう一度動かして、通れば取り込む」のが習慣になっています。
問題
この習慣を続けてよいでしょうか。
判断例を開く
判断
続けません。
確認すること:
- 失敗の原因は、確認のプログラムの作りか、システムの動きそのものか（処理の順番やタイミングで結果が変わる不具合かもしれない）
- 「もう一度動かせば通る」習慣のせいで、本物の失敗を見逃していないか
- 誰が、いつまでに原因を調べて直すか
- 直すまでの間、そのテストを一時的に外すなら、誰が認め、どう記録するか
失敗を無視する習慣は、自動テストへの信頼そのものを失わせます。
8. よくある失敗
- 仕様を変えたのに、自動テストの期待する結果を直していない
- 失敗を通すために、中身を確かめずにテストの期待する結果を書き換える
- ときどき失敗するテストを放置する
- 本番まで自動で届く設定で、人の承認がない
- 前の版に戻す手順を、一度も試していない
9. 成果物との接続
- DEV-003 自動テスト・自動配布構成：自動化の流れと、各段階で何を行うかをまとめる
- DEV-004 環境・リリース対応表：どの環境へ、どの手順と承認で届けるか
- TST-002 テスト計画・対象一覧：何を、どの段階で確かめるか
10. AI WORKFLOW — 不安定なテストを洗い出させる
AIは、自動テストの結果の記録を整理する下書きに役立ちます。
指示例:
「次の自動テストの結果の記録（テスト名・日時・成功か失敗か・その時点の変更）を読み、変更がないのに成功と失敗が入れ替わっているテストを挙げてください。原因の断定と、テストを外すかどうかの提案はしないでください。」
11. REVIEW — AIの整理を確認する
- AIが挙げたテストを、元の記録で確かめたか
- 「変更がない」という判断が、記録と合っているか
- AIの整理をもとに、テストを外すと決めていないか（外すかどうかは人が決める）
12. 人間が判断すること
- 何を自動テストにし、何を人の確認に残すか
- どの環境まで自動で届け、どこで人が承認するか
- 不安定なテストを一時的に外すか。その期限
- 本番へ届けてよいか
本番移行承認は、AIへ最終委任しない事項です（正本の方針）。稼働後の個々のリリースの承認をどう扱うかは、正本に記載がありません。未確定
13. 判断演習
次の確認を、「自動テストに任せやすい」と「人が確かめる」に分けてください。分けた理由も書いてください。
- 計算の結果が、変更の前と同じか
- 入力の誤りを、決めたとおりに知らせるか
- 新しい画面の文言が、利用者に分かりやすいか
- 変更後の画面の流れが、業務の手順に合っているか
- 本番へ届けてよいか
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
自動テストと自動配布は、決めた確認と手順を、速く、ばらつきなく繰り返す仕組みです。
書かれていない確認はしないこと、誤りも速く届くことを忘れず、人の確認と承認の位置を決めて使います。