AI導入から効果的なSDLC活用へ
発表: 2026年3月 · 著者: Jessica Baolin, Nathen Harvey · 原文: https://dora.dev/insights/balancing-ai-tensions/
核心命題
2025 DORA調査で90%の技術専門家が仕事でAIを使用し、80%以上が生産性が上がったと答えました。しかし2025年第3四半期に、Googleのソフトウェアエンジニアが「過去3か月間にAIツールが開発ワークフローに与えた影響」を問うサーベイ項目に残した1,110件の自由記述回答を定性分析した結果、AIのSDLC（ソフトウェア開発ライフサイクル）への影響は単純な線形改善ではなく一連のトレードオフとして現れました。この結果はGoogleという1つの組織のエンジニアの回答から導かれたものであるため、他の組織にそのまま一般化することはできません。
AIは増幅器です。高パフォーマンス組織の強みと脆弱な組織の機能不全を等しく拡大します。社内プラットフォーム・API・ワークフロー・テストが堅牢なら強力な協働者になり、ツールが分断されデータがサイロ化すれば技術的負債をより速く生成します。
AIが即座に価値を生む領域
- ボイラープレートの自動化 — 予測可能なパターンの手作業を排除
- 着手の摩擦低減 — 下書きを提供し「生成」から「編集」状態へ。白紙の前で固まるがアイデアを投げる場所ができた
- 認知的協働者 — ピアレビュー前に論理を外在化し仮定を検証する相手
- 知識ギャップの橋渡し — 馴染みのない言語・レガシーコードで即時チューター
- 情報の統合 — 断片化した文書・ログ・ソースを要約し数時間の調査を圧縮
これらのユースケースは主にコード生成(600+)、情報探索(150+)、コードレビュー(150+)、テスト(150+) に集中し、デバッグ・プロトタイピング・アイデア出し・文書作成・リファクタリング・学習が続きます。ただし研究チームは、先行するサーベイ項目のために回答者がコード生成について言及するようある程度誘導（priming）された可能性があると述べています。そのため、コード生成の言及数が最も多いという点は実際の利用比重より膨らんでいる可能性があり、研究チームはそれでも言及頻度は、エンジニアが各ユースケースをどれほど重要な接点とみなしているかを示すと解釈しています。すべてのユースケースで速度向上が報告されますが、同時に検証オーバーヘッド・ハルシネーションが共通して現れます。
隠れた税金: 3つのトレードオフ
1. 速度の押し引き — 検証税
節約した作成時間が監査・検証へ再投入されます。2025年DORAレポートによれば、30%の開発者がAI生成コードを「少し信頼している」または「全く信頼していない」 と回答しました。現在のAIツールは自らの不確実性を示せず、ハルシネーションも確信に満ちた口調で出力するため、エンジニアはすべての応答が誤っている可能性を前提に扱わねばなりません。作成者の速度利益はレビュアーの認知負荷増大へ転嫁されます。
「いくらか生産的だが代償がある。コードを書く時間は減るが、AIの世話とレビューに時間を多く使う。」
巨大なCL/PRをレビュアーが手動監査せねばならず、発見しにくいバグ・技術的負債・中身のない文書が流入しコードベースの品質を汚染する恐れがあります。DORAは、この現象が2025年の調査でマクロに観察された処理量と不安定さの同時増加と整合すると解釈しています。これは2つの結果を結び付けた説明であり、この研究が因果関係を直接検証したものではありません。
2. 専門性の逆説
AIが参入障壁を下げるのは強力な安全網ですが、深い専門性に必要な 「生産的な苦闘(productive struggle)」を迂回させます。表層的な学習・長期的なスキル低下につながりえます。AIがアーキテクチャの妥当性と無関係に初期仮定を検証してくれる場合、特に深刻です。
「経験のない領域で速く開発できるが、AIが正しいか確認する文脈がないため『盲人が盲人を導く』感覚になる。」
3. ワークフローギャップ
AIは初期の大量作業（プロトタイピング）を速くしますが、残り（本番統合）がその利益を相殺します。精度・エッジケース・社内システム統合が必要な最後の一区間は、手作業より長くかかることがあります。AIが主に内側のループ(inner loop) を狙ってきたためです。またツールの乱立(tool sprawl) がフローを壊します。
チーム・リーダーのための実践指針
- アウトプットではなく影響を測る。 受理されたコード行は採用指標になりえても、生産性指標にはできません。Googleは開発者生産性の指標として速度・容易さ・品質(Speed, Ease, Quality: SEQ) を使い、SPACE・H.E.A.R.Tフレームワークとバリューストリーム管理(Value Stream Management, VSM) も活用します。VSMはコードレビュー回転時間・デプロイ失敗からの復旧時間・再作業率・本番インシデントといった下流の指標でシステムのボトルネックを見つけます。
- コードレビュープロセスを適応させる。 AIフィードバックを作成段階の作成者へ届け、レビューエージェントで標準を自動強制し、小さなバッチを維持し、非同期レビューの必要性を見直す。
- ワークフロー・本番準備のギャップを計画する。 見積もりにプロトタイプ→本番の差を明示し、AIがアクセスできる社内データを接続し、ツールの乱立を減らす。
- 深い専門性を保護する。 ジュニアをシニアメンターと組ませてAI生成のアーキテクチャ決定をレビューし、複雑なシステムは手動コーディングを奨励する。
結論
AIはルールを変えますがエンジニアリングの規律の必要性を代替しません。
出典
DORA Balancing AI tensionsの要約。原文 © Google LLC、CC BY 4.0。