AIに頼むと、昨日まで手が止まっていた機能が動き始める。ところが、チームのリリース日は変わらない。レビューの順番を待ち、既存機能を確かめ、別サービスの担当者と調整しているうちに、実装で浮いた時間が見えなくなる。この違和感は、AIの使い方だけの問題ではありません。コードを書く工程と、変更を利用者へ安全に届ける工程は、そもそも測っている範囲が違います。
結論から言えば、コード生成を速くしても、開発全体が同じ比率で速くなるとは限りません。ただし、それを「人間の確認が必要だから仕方ない」で終えると、改善できる待ち時間まで残ります。本記事では、DORAの指標を手がかりに、変更範囲、テスト、配布、復旧を一つの流れとして考えます。実装後の仕事を具体化すると、次に学ぶ技術も、転職先に確認したい開発体制も見えてきます。
議論すべきは、コードの量より変更の流れ
2026年3月のDORAの記事は、Googleのエンジニアによる自由記述回答の分析から、コード生成で節約した時間が確認や検証へ振り向けられる状況を紹介しています。全企業で同じ結果になる実験ではありませんが、実装の速さだけでは説明できない負担を考える材料です。DORAの分析
一方、Google Cloudによる2025年DORA報告の解説では、AI導入とソフトウェア提供量の増加に正の関連が見られる一方、不安定性の増加との関連も報告されています。「AIなら必ず速い」「AIは必ず開発を遅くする」のどちらも、この結果からは言えません。関連は因果関係の証明でもありません。2025年DORA報告の公式解説
Coding TimeとLead Timeは、起点と終点が違う
Coding Timeには共通の測定規格があるとは限りません。ここでは、実装作業に着手してから、レビューへ出せる差分ができるまでの実作業時間を指します。調査や待機を含めるなら、別の定義として記録する必要があります。
DORAのChange lead timeは、バージョン管理にコミットされた変更が、本番へデプロイされるまでの経過時間です。要望の受付からの時間でも、コードを書いている時間だけでもありません。レビュー待ちがコミット後に生じれば含まれますが、コミット前なら含まれません。本番へ配布した後も機能フラグで公開を待つ場合、利用者への機能公開までの時間は別に追う必要があります。DORAの現行指標
したがって、最初にするのは「AIで何時間浮いたか」の集計だけではなく、実装、レビュー待ち、修正、テスト、配布待ちのどこで変更が止まるかの確認です。同時進行する工程もあるため、担当者の作業時間を単純に足しても、利用者が待つ時間にはなりません。
変更が広がると、レビューとテストの意味が変わる
たとえば、会員情報の項目名を変える場面を考えます。画面だけの修正に見えても、APIの応答、データベース、外部への通知、過去データの読み取りに影響が及ぶかもしれません。AIがまとめて直せても、別チームのサービスが旧項目を使っていれば、単独ではリリースできません。変更行数より、またぐ契約と責任の境界が問題になります。
このとき、生成したコードの単体テストが通るだけでは不十分です。既存の会員更新が壊れないかを回帰テストで確かめ、APIの提供側と利用側の約束を契約テストで検証します。認可をまたぐなら、別の利用者の情報を更新できないかも確認します。これは想定例に対するテスト設計であり、すべての変更に全種類のテストを課すという意味ではありません。
DORAのテスト自動化の解説も、完成後に検査をまとめる方式ではなく、開発中に継続してフィードバックを得ることを重視しています。AIにテストを書かせる際も、実装と同じ誤解を正解として固定していないか、仕様や既存の利用例から期待値を独立して確認します。DORAのテスト自動化
レビュー待ちが長いなら、レビュー担当者の努力だけを増やすより、一つの目的に絞った差分へ分け、影響範囲と確認結果を添える方が着手しやすくなります。ただし、密結合なシステムでは差分を小さく切るだけで独立配布できるとは限りません。互換性の維持や責任分界の見直しまで必要です。
Deployの成功と、安心して戻せることは別
配布コマンドが正常終了しても、利用者の処理が成功したとは限りません。GoogleのSRE Workbookでは、一部へ変更を適用し、評価して展開を進めるカナリア方式を説明しています。本番の新旧バージョンについて、エラーや応答時間などを比較し、継続か停止かを判断する仕組みです。Canarying Releases
ここで先に決めるべきなのは、「異常を見つけたら誰かが考える」ではなく、何を監視し、どの状態で展開を止め、誰が復旧を判断するかです。観測できない変更では、配布の自動化だけを進めても成否の判断が残ります。
さらに、アプリを旧版へ戻せても、データまで元に戻るとは限りません。新しい形式で保存したデータを旧版が読めない場合、ロールバック自体が障害を生みます。AWSの解説では、まず新旧両形式を読める状態を用意し、その後で書き込み形式を切り替える段階的な方法を示しています。ロールバックの安全性
同じ考え方を実務へ広げると、送信済みメールや外部で成立した決済も、コードを戻すだけでは取り消せません。再実行して二重処理しない設計や、取消・補償処理の手順を別途用意する必要があります。「Gitで戻せる」と「サービスを復旧できる」の差は、変更履歴と復旧を理解する意味にもつながります。
実装後に詰まりやすい場所の診断
| 工程 | 何を確認するか | 詰まりが見えたら |
|---|---|---|
| Review | 差分の目的、担当者、待ち時間が明確か | 差分を絞り、影響範囲と検証結果を添える |
| Test | 既存機能と認可境界を検証できるか | 仕様から期待値を確認し、回帰テストを足す |
| Deploy | 配布単位、承認、環境差分が分かるか | 段階公開と停止条件を決める |
| Observe | エラー、応答、利用者影響を追えるか | 継続・停止の判断指標を事前に置く |
| Recovery | 旧版、データ、外部処理を戻せるか | 戻せない処理の補償手順も用意する |
実装後の仕事を、次の専門性につなげる
こうした工程を整える仕事は、SRE、DevOps、Platform Engineeringと接続します。SREなら利用者の体験に基づく信頼性の目標と障害対応、Platformならテスト・配布・監視をチームが使いやすい共通基盤にする仕事です。DevOpsの観点では、開発と運用で責任を投げ合わず、変更の流れを一緒に改善します。
AIがコードを出すほど、影響範囲を説明し、テストの抜けを見つけ、戻せる配布を設計する能力が役立つ場面は考えられます。ただし、これらの資料は日本の求人需要や年収の上昇を直接示していません。職種名だけで市場価値を判断せず、ITエンジニアの将来性と必要なスキルを自分の経験と照らし合わせるのが出発点です。
学習と求人選びは、変更を本番へ届ける一周から
学習するなら、小さなAPIの変更を題材に、差分レビュー、回帰テスト、CI、テスト環境への配布、監視、旧版への復旧まで一周させてみてください。次にデータ形式の変更を加え、旧版が新しいデータを読めるかも試します。必要なのはツール名を増やすことより、「どの失敗を、どの段階で検出できるか」を説明できる状態です。
職場では、直近の変更を一つ取り上げ、作業していた時間と待っていた時間を分けて振り返れます。長かった工程のうち、確認対象が曖昧だったのか、担当者が不在だったのか、テスト環境を作れなかったのかを探り、一つずつ改善します。
求人票や面接でも、「AI導入済み」に加え、レビューの責任者、テストの保守担当、配布の単位、障害時の復旧権限を確認したいところです。SRE採用でも、改善に時間を使えるのか、障害対応だけを引き受けるのかで経験は変わります。AIエンジニアの年収と求人の見方と併せて、担当範囲と評価条件を読み解いてください。
まとめ：速く書けた先の、詰まりを見つける
AIの効果はコードを書き終えた瞬間だけでは判断できません。変更を理解できる大きさにし、早く検証し、状態を観測して復旧できるようにする。その流れのどこを改善したかを説明できることが、実装の速さをチームの成果へつなぐ力になります。
一次情報・出典
- DORA：ソフトウェア提供の現行5指標（2026年1月5日更新）
- DORA：AI活用と開発工程の緊張関係（2026年3月10日）
- Google Cloud：2025年DORA報告（2025年9月23日）
- DORA：テスト自動化（2025年7月17日更新）
- Google SRE Workbook：Canarying Releases（2018年刊、現行公開章）
- AWS：Ensuring rollback safety during deployments（転送先は2026年6月22日更新表示。旧Builder’s Libraryからの移設記事）
- DORA研究一覧（年次報告の掲載状況を確認）
開発工程のどこまで経験できる環境かを考えながら相談先を探す方は、SES転職で使うエージェントの比較と選び方を参考にしてください。
