こんにちは、大平です。
最近、「生成AIを入れたら、エンジニアが今までやっていなかったことを勝手にやり始めた」という話を聞くようになりました。
計画にない仕事へ手を出していると聞けば、経営側が不安になるのは当然です。ただ、僕はこの変化を一律に止めるべきではないと考えています。
エンジニアが急に余計な仕事を思いついたわけではありません。
AIによって、テストや技術的負債の返済、小さな施策の検証など、価値はあるが工数を理由に諦めていた仕事へ手が届く ようになったのです。
経営が判断すべきなのは、その仕事が計画に入っていたかどうかだけではありません。事業やプロダクトにどのような価値を生むのか、どこまで現場へ任せるのかを決める必要があります。
「頼んでいない仕事」の正体は、工数不足で諦めていた仕事
これまでの開発現場では、価値がないからやらない仕事と、価値はあるが工数が足りないためにできない仕事が、同じ「未着手」の箱へ入れられていました。
機能開発を優先するために自動テストを後回しにする。小さな不具合や使いにくさを把握していても、緊急性が低いため見送る。技術的負債があるとわかっていても、まとまった改修期間を確保できない。どれも珍しい判断ではありません。
生成AIが変えたのは、この工数の前提です。調査、実装、テスト作成といった作業の一部が速くなり、今まで予算や納期の都合で落としていた仕事を拾えるようになりました。
外からは「頼んでいないことを始めた」ように見えても、実際には 以前から存在していた改善機会が表に出てきた だけかもしれません。
テストと技術的負債の返済が、日常の開発へ戻ってきた
わかりやすい例が、自動テストです。
僕が直近で関わった現場では、フロントエンドのテストをゼロから立ち上げ、約1,500件まで増やしました。AIを使わず、日々の機能開発と並行して同じ量を整備するのは、現実的には難しかったはずです。
技術的負債も同じです。以前は、負債が大きくなってから改修プロジェクトを立ち上げるしかありませんでした。しかし、AIに調査や修正案の作成、テストによる検証を任せられる環境があれば、普段の開発の中で小さく返せます。
これはエンジニアの自己満足ではありません。不具合の予防、変更時の確認コストの削減、将来の開発速度の維持につながります。
AI導入で生まれた余力を品質へ再投資できるかどうかは、中長期の事業スピードを左右します。
コード品質と事業スピードの関係は、次の記事でも詳しく説明しています。
AI駆動開発では、コード品質が事業競争力になる
AI駆動開発で競争力を出すには、ツール選定よりも既存コードベースの品質・設計・自動テストが重要です。コード品質が事業スピードに直結する理由と、経営層が90日で着手すべき基盤整備を整理します。
2026年6月18日捨てていた施策を、実際に試して判断できるようになった
AIによって戻ってくるのは、品質改善の機会だけではありません。事業施策を検証する機会も増えます。
これまでは施策A、B、Cの案があっても、実装できるのは一つだけでした。そのため、会議の中で比較し、最も有望に見える案以外を捨てる必要がありました。
しかし、実装と検証のコストを小さくできるなら、完成版を三つ作らなくても、最小限の試作品や限定的なリリースによって複数案を確かめられます。作る前の議論だけでは見抜けなかった顧客の反応を、実データで比較できます。
もちろん、施策を増やせば自動的に売上が伸びるわけではありません。何を確かめるのか、成功をどの数字で判断するのかは、実装前に決める必要があります。
それでも 工数を理由に捨てていた可能性を、顧客へ届けて確かめられる ことには大きな価値があります。AI導入の投資対効果は、既存業務の時間短縮だけでなく、増やせた検証機会でも評価すべきです。
現場の自発性と、優先順位を無視した開発は分けて考える
ここまでの話は、エンジニアが自由に本番環境を変更してよいという意味ではありません。
AIによって実装コストが下がっても、変更による事業リスクはゼロになりません。顧客データ、決済、認証、権限、法令対応に関わる変更は、従来どおり慎重な判断が必要です。レビューやテスト、リリース承認も省けません。
経営側が区別すべきなのは、次の二つです。
- 既存のレビューやリリース手順を守りながら、改善の候補を増やす自発的な動き
- 優先順位や権限の境界を無視し、検証なしで本番へ変更を加える動き
前者まで止めてしまえば、AIを導入しても、指示された仕事を少し速く終わらせるだけです。一方、後者を放置すれば、現場ごとに判断が分かれ、事故や作りすぎを招きます。
必要なのは自発性の禁止ではなく、現場が安全に動ける境界の明文化です。
AI導入効果を、納期短縮だけで測ってはいけない
AI導入の効果として最も見えやすいのは、「予定していた機能が何日早く完成したか」です。しかし、それだけでは現場で起きている変化の一部しか捉えられません。
少なくとも、次の四つに分けて見る必要があります。
| 評価する領域 | 確認する変化 |
|---|---|
| 納期 | 計画していた機能を届けるまでの時間が短くなったか |
| 品質 | 自動テストや検証範囲が増え、不具合を早く見つけられるようになったか |
| 保守性 | 小さな負債を日常的に返し、変更しやすい状態を維持できているか |
| 事業検証 | 試せる施策の数が増え、顧客データによる判断ができたか |
数字を増やすこと自体を目的にしてはいけません。テスト件数が増えても重要な不具合を検知できなければ意味がなく、施策数が増えても検証結果を次の判断へ使えなければ作りっぱなしになります。
見るべきなのは AIによって増えたアウトプットが、品質や意思決定の改善につながったか という点です。
AI導入後の生産性をどこで測るかは、次の記事で整理しています。
AI導入で生産性が上がらない会社は、どこで詰まっているのか
AIコーディング支援を入れたのに組織のリリース速度が変わらないとき、原因は実装ではなく、その下流のレビュー・仕様決定・承認・デプロイにあることが多くあります。DORAの現行5指標を結果指標、工程ごとの待ち時間を診断指標として切り分け、どの区間で何時間止まっているかを測る方法、症状から詰まりを特定する対応表、よくある五つの誤診断、そして打ち手を選ぶ順序をまとめました。
2026年7月28日生まれた余力をどこへ投資するか、経営と現場で合意する
AIによって生まれた余力の使い道を、すべて経営会議で決める必要はありません。一方で、現場へ丸投げするのも適切ではありません。
経営と事業責任者は、今期に優先する事業課題と、避けるべきリスクを示します。たとえば、新規顧客の獲得を優先するのか、解約率を下げるのか、品質事故を減らすのかを決めます。
開発責任者は、その課題に対して、テスト基盤、負債返済、機能改善のどこへ投資すべきかを判断します。個々のエンジニアは、決められた境界の中で改善案を出し、小さく検証します。
この分担があれば、現場の自発性を残したまま、事業と無関係な作り込みを防げます。
AI導入で本当に変わるのは、同じ計画を短時間で消化できることだけではありません。これまで諦めていた仕事や検証機会を、開発の選択肢へ戻せることです。
その選択肢を何へ使うかまで決めて、初めてAI導入が経営の成果になります。
まとめ
- 未着手だった仕事を見直す：AI導入後に始まった改善は、以前から価値を認識しながら工数不足で諦めていた仕事かもしれません
- 自発性と無統制を分ける：レビューやリリース手順を守る改善は歓迎し、権限や優先順位を無視した変更は止めます
- 評価軸を増やす：納期だけでなく、品質、保守性、事業検証の変化も確認します
- 余力の使い道を合意する：経営が事業課題とリスクを示し、開発責任者と現場が具体的な投資先を決めます
エンジニアが「頼んでいない仕事」を始めたときは、止める前に、その仕事がどの機会損失を埋めようとしているのかを確認してください。そこに、AI導入によって初めて実行可能になった改善が隠れている可能性があります。