87%は速度の改善を感じた人の割合、72%は仕事の摩擦が同じか増えた人の割合。短縮率や因果関係とは区別します。
コードや仕様書の下案は早く出るようになった。それなのに、レビュー待ちの仕事が増え、次の担当者へ渡すまでに時間がかかる。AI導入後の開発チームで起こり得るこのずれを、Atlassianの新しい調査が示しています。
同社が2026年10月20日に公開した解説では、開発者の87%がAIによって仕事をより速く届けられると回答する一方、72%は日々の仕事の進めにくさが以前と同じか、増えたとしています。個人の作業速度と、チーム全体の流れは分けて見る必要があります。
この記事でわかること
- 調査の読み方：87%と72%は矛盾する数字ではなく、異なる側面への回答です。
- 詰まりやすい場所：情報探し、確認作業、要件の不明確さなど、作成の前後にある負担を見ます。
- 現場での確認方法：作成時間だけでなく、レビュー待ちと差し戻しを同じ仕事で追います。
「速くなった」と「仕事が進めにくい」は両立する
Atlassianの「State of Developer Experience Report 2026」は、公式の紹介ページによるとソフトウェア業務に関わる1,500人超への調査を基にしています。そこでは、開発者の80%が勤務時間を延ばさずに、より多くの仕事をこなせると回答したことも示されています。
ただし、これは「AIを使えば開発期間が87%短くなる」という意味ではありません。87%は速度の改善を感じた回答者の割合であり、短縮率ではありません。同様に、72%を「AIのせいで生産性が落ちた人の割合」と読むのも不正確です。「以前と同じ」と「増えた」を合わせた回答で、原因を切り分けた実験ではないためです。（出典：Atlassian公式解説）
一つの工程を速めると、次の工程へ仕事が集まる
たとえば、AIを使って実装案を早く用意できても、変更内容を理解して確認する人の時間が同じだけ増えるとは限りません。確認待ちが積み上がれば、作成者の手は空いても、利用者へ届くまでの期間は変わらないことがあります。
これは調査対象の特定企業で測定した事例ではなく、工程の違いを理解するための例です。重要なのは、「作り終えた」と「受け取った人が使える」を同じ完了にしないことです。開発だけでなく、AIで作った資料を上司や顧客が確認する仕事にも通じる視点です。
AIの出力が増えても、情報探しや確認は残る
公式解説では、開発者が感じる主な負担として、情報探し、会議、作業の切り替え、技術的負債、不明確な要件が挙げられています。技術的負債とは、過去の設計や実装の問題などが、後の変更や保守を難しくしている状態です。
レポートの紹介ページでは、開発者の49%がAI出力のレビューやプロンプト修正などに週4時間以上を使い、75%がAI生成物の品質・安全性を確かめる責任が増えたと回答しています。生成にかかる時間だけを減らしても、確認の仕事まで消えるわけではありません。（出典：公式レポート紹介）
作る人と、受け取る人の両方で確認する
| 仕事の場所 | 確かめたいこと | 改善を試す例 |
|---|---|---|
| 着手する前 | 必要な仕様や決定理由を探し直していないか | 今回使う仕様と決定記録の場所を依頼に添える |
| AIで作成する工程 | 下案完成までの時間だけを成果にしていないか | 確認に渡せる状態までを作成時間に含める |
| レビュー待ち | 誰が何を確認するか不明なまま積み上がっていないか | 確認担当と、判断してほしい点を明示する |
| 差し戻し・修正 | 同じ誤りや説明不足で往復していないか | 変更理由・テスト結果・未確認点を一緒に渡す |
この表は調査結果そのものではなく、調査を現場へ生かすための整理例です。すべての工程に新しい仕組みを入れるのではなく、まず現在止まっている場所を一つ選びます。
一件の仕事を、着手から受け渡し完了まで追う
改善を試すなら、「AIを使った回数」を増やす前に、普段の小さな変更作業を対象にして、どこで時間を使っているかを記録します。AIの効果を厳密に証明する実験ではなく、次に直す工程を見つけるための観察です。
- 完了の意味をそろえる。下案の作成ではなく、レビューを通過し、後続担当が受け取れる状態など、仕事に合う終点を決めます。
- 作業と待ち時間を分ける。作成、確認、修正に手を動かした時間と、返事やレビューを待った時間を別に残します。
- 差し戻しの理由を短く残す。要件の不足、出力の誤り、テスト不足など、次回に直せる理由へ整理します。
- 一つだけ変えて比較する。たとえばレビュー依頼に変更理由と確認結果を添え、受け手の質問や往復が減るかを見ます。
自社で尋ねるときも、設問と分母を分ける
調査を社内アンケートの参考にするなら、「下案を作る速さ」と「仕事の進めにくさ」を一つの満足度にまとめないことが大切です。速度は改善・不変・悪化、進めにくさは減少・不変・増加など、別の項目で聞きます。これは編集部の設問案で、Atlassianの原票を再現したものではありません。
たとえば回答者20人中、速度改善が15人、摩擦不変・増加が12人でも、その15人と12人がどの程度重なるかは個票を照合しないと分かりません。この架空例の75%と60%を差し引いて「純改善15%」とする計算は避けます。回答数、対象業務、比較した期間を併記し、欠損回答も分けます。
人がAI生成コードを確認する具体的な観点は、Anthropicの開発現場と人のレビューの解説へ。本記事は、調査の数値を読み違えず、自社で何を観測するかに焦点を置きます。
AIの利用量を、人の評価に直結させない
公式解説では、開発者の41%が、期待に応えようとして必要以上にAIを使うことがあると回答しています。また、組織のAI戦略が明確に共有され、実行されていると答えたのは開発者17%、リーダー23%でした。
この結果から、AI利用の多い人が必ず成果を出していないとは言えません。ただ、使った量を増やす目標と、仕事を円滑に終わらせる目標は別です。担当者ごとの使用回数より、確認待ちの滞留、差し戻しの理由、受け渡し後の不具合などを一緒に見たほうが、工程の問題を探しやすくなります。
導入施策を続けるか止めるかという組織全体の判断は、Gartner調査から考えるAI施策の継続・停止で扱っています。本記事では、開発者調査の回答割合と、自社での観察項目の違いに焦点を絞っています。
実務上の注意
紹介した割合は、Atlassianが公表した調査回答です。公開の紹介ページでは1,500人超という対象規模を確認できますが、調査国の内訳や実施期間などの詳細はここで示した公開解説だけでは確認できません。日本の開発者全体に同じ比率が当てはまると考えたり、AI利用と成果の因果関係を断定したりしないでください。
作業時間の記録は、個人を責めるためではなく工程の改善に使います。難易度や担当範囲の違う仕事を単純比較せず、コード量やAI使用回数だけで評価しないことも大切です。
まとめ
Atlassianの調査が示すのは、AIによる個人の速度向上と、日々の仕事の進めにくさが同時に存在することです。次に見るべきなのは、生成量ではなく着手前の情報探し、レビュー待ち、修正、引き継ぎ。回答割合を短縮率と混同せず、自社では速度と進めにくさを別々に尋ね、一件の仕事の待ち時間と照らし合わせましょう。
よくある質問
87%という数字は、開発速度が87%向上したという意味ですか？
いいえ。AIで仕事をより速く届けられると答えた開発者の割合です。短縮時間や速度の上昇率を表す数値ではありません。
AIを使うのを減らしたほうがよいのでしょうか？
この調査だけでは、減らすべきとは言えません。どの工程が改善し、どこに確認や待ち時間が残っているかを分けて見ます。利用回数そのものより、完了までの流れを確かめることが先です。
最初に一つだけ記録するなら、何がよいですか？
レビュー依頼を出してから返答を得るまでの待ち時間と、その間に必要になった追加質問が候補です。作成速度の改善が受け渡しにつながっているか、確認する手掛かりになります。
出典・参考情報
- Atlassian：AI is making developers faster. It’s also exposing what’s broken in software delivery（2026年10月20日）
- Atlassian：State of Developer Experience Report 2026 公開紹介ページ
公開ページは2026年10月26日に確認。調査の数値と、本文中の実務上の提案・架空例を分けて記載しています。
運営元について
AXメディアは、株式会社ジーズ AX事業部が運営しています。AX事業部では、AI研修・AIエージェント開発・ローカルLLM開発・補助金／助成金の活用支援を提供しています。
