コペツキ氏によると、成果の差を生んでいるのは「どのAIベンダーを選んだか」ではないという。成果を出すチームは、AIを導入しただけではなく、AIを前提に開発の進め方そのものを見直していると同氏は説明する。

　AIが得意なのは、構文生成や定型コードの作成、決められたルールに沿った変換処理などだ。一方、システム全体の設計や判断、集中して考えること、人材育成といった仕事までAIに任せることはできない。

　コペツキ氏は、AIに向く仕事はAIに任せつつ、人間が担うべき設計判断や学習、集中の時間を守ることが重要だと説明する。

　そのための方法として、同氏は6つの取り組みを挙げる。

1．単純作業を自動化し、空いた時間を守る

　1つ目は、繰り返し発生し、ミスも起きやすい作業を自動化することだ。ソフトウェア開発では、CI/CD（継続的インテグレーション／継続的デリバリー）や自動テスト、Infrastructure as Codeなどを使って、以前から定型作業の自動化が進められてきた。

　AIを使えば、コードレビューの支援やセキュリティスキャン、テストコード生成など、さらに多くの作業を自動化できる。

　コペツキ氏は「繰り返しが多く、ミスが起きやすく、単調な作業を見つけて自動化することが重要だ」と述べる。

　ただし、自動化によって生まれた時間を、別の会議や打ち合わせで埋めてしまっては意味がない。コペツキ氏は、自動化の目的は単に業務量を減らすことではなく、より価値の高い業務に時間を使えるようにすることだと指摘する。

2．コードを書く前に設計する

　2つ目は、実装より先に設計を進めることだ。開発者がすぐコードを書き始めると、本人が意識しないままアーキテクチャ上の判断を積み重ねることになる恐れがあるからだ。

　そこでコペツキ氏は、簡単なフローチャートやスキーマ、Markdownでの手順整理など、実装前に短時間でも設計することを薦める。同氏は「5分の設計が、3時間のリファクタリングを防ぐ場合がある」と強調する。

　この段階ではAIを使うこともできる。例えば、複数の実装案をAIに生成させる、設計案の弱点を指摘してもらう、想定していないエッジケースを洗い出してもらうといった使い方だ。

　一方で、最終判断までAIに委ねるのは避けるべきだとコペツキ氏は指摘する。同氏によると、AIには設計を批判させてもよいが、「決定そのものを任せてはいけない」と説明する。AIが生成したコードが動作していても、なぜその設計になったのかをチームの誰も説明できなければ、レビューや保守で問題になるからだ。

3．開発者が集中できる時間を確保する

　3つ目は、開発者が1つの作業に没頭できる「フロー状態」を守ることだ。コペツキ氏は、GitHub Copilotをコーディング支援に使った開発者のうち、73％がフロー状態を維持しやすくなったと報告した研究結果（注2）を紹介する。

※注2：GitHubが2022年9月に公開したResearch：quantifying GitHub Copilot’s impact on developer productivity and happiness

　ただしコペツキ氏によると、そもそも一般的な開発者のフロー効率は15～25％程度にとどまるという。

　つまり、AIによって一つ一つのコーディング作業が速くなっても、会議やチャットの通知によって作業が頻繁に中断されれば、生産性向上の効果は限定的になる。

　そこでコペツキ氏は、集中作業用の時間をカレンダーで確保する、Slackなどの通知を停止する、チームリーダーが集中時間への割り込みを避ける、といった方法を薦める。AI導入効果を高めるには、「AIが1つの作業を何分短縮したか」だけでなく、開発者がその作業に集中できる環境まで含めて見直す必要がある。

4．認知負荷を減らす

　4つ目は、開発者が頻繁に頭を切り替えなくても済む環境を作ることだ。不具合を調べている最中に会議へ呼ばれ、その後チャットで別件の質問に答え、さらに障害対応に入る――。こうしたコンテキストスイッチが積み重なると、元の作業内容を頭の中で再構築する必要が生じる。

　コペツキ氏は、こうした割り込みが開発者の認知負荷を高めると指摘する。その対策として同氏は、オンコール担当をローテーションすることや、会議の参加者を必要最小限に絞ること、定型作業をテンプレート化することを挙げる。

　認知負荷の軽減にAIを使うという選択肢もある。例えば、AIエージェントを使ってコードとドキュメントを同期したり、「Claude Code」「Cursor」「GitHub Copilot」「IBM Bob」などのAIコーディング支援ツールを活用して、チームの規約に沿ったコード作成を支援したりする方法だ。

　コペツキ氏は「より多く考えることが目的ではなく、本当に考える必要がある仕事に思考力を使えるようにすることが重要だ」と説明する。

5．AIがあっても人材育成を止めない

　5つ目は、開発者が成長できる機会を確保することだ。コペツキ氏は、スキルアップを支援されていると感じる従業員は、そうでない従業員よりモチベーションが73％高いというコンサルティング企業PricewaterhouseCoopers（PwC）の調査結果（注3）を紹介する。

※注3：PwCが2025年11月に公開したPwC’s Global Workforce Hopes and Fears Survey 2025

　コペツキ氏は、「AIはメンタリングを置き換えるものではない」と説明する。つまり、AIはデバッグや調査を支援できるが、設計判断の理由や問題の切り分け方まで若手に教える「メンター」の役割を完全に代替するものではない。

　そこで、AIを使って基礎的なデバッグや定型的な調査にかかる時間を短縮する。そのようにすることで、人間のメンターは設計判断や問題の切り分け方など、より高度な内容の指導に時間を使えるようになる。

　AIを人材育成の代替手段にするのではなく、育成に伴う単純作業を減らすために使うという考え方だ。

6．AIだけでなく、開発ツール全体を見直す

　6つ目は、IDE（統合開発環境）やプログラミング言語、バージョン管理、AIコーディング支援ツールなど、日常的に開発で使う一連のツールから摩擦を減らすことだ。

　一つ一つのツールに使いにくさがある場合、その規模は小さくても、全開発者が毎日使い続ければ、時間的コストは積み重なる。AIコーディング支援ツールも、機能の多さだけで判断するのではなく、普段使うIDEと自然に連携できるか、既存の開発フローを邪魔しないかといった観点で評価する必要がある。

　同氏は、こうしたツール選定は単なる機能比較ではなく、「開発者体験」の問題だと位置付けている。

生産性を「コード生成量」だけで測らない

　こうした改善策を実施した後は、成果をどう計測するかが重要になる。コペツキ氏は、代表的な開発生産性の指標として「DORA」と「SPACE」を紹介する。

DORA

　DORA（DevOps Research and Assessment）は、サイクルタイムやデプロイ頻度、変更失敗率など、開発やデリバリーの状況を数値で計測するための仕組みだ。

SPACE

　Satisfaction（満足）、Performance（パフォーマンス）、Activity（活動）、Communication＆Collaboration（コミュニケーションと協力）、Efficiency＆Flow（効率とワークフロー）の頭文字を取ったキーワード。満足度やパフォーマンス、活動、コラボレーション、フローといった複数の観点から開発者の生産性を見る枠組みだ。

　ただし、指標そのものを開発者の目標にすると、新たな問題が起きる可能性がある。コペツキ氏は「指標は目標ではなく、ガイドとして扱うべきだ」と強調する。例えば、AIが生成したコードの量やコミット数を人事評価に使えば、開発者はユーザーに価値を届けることより、数字を増やす行動を優先する可能性がある。

　コペツキ氏が示した6つの方法からは、AI時代の開発生産性向上は単なるAIツール導入の問題ではなく、開発組織の仕事の進め方そのものをどう設計し直すかという問題だと分かる。AIが得意な仕事を任せる一方で、人が集中して考え、判断し、学ぶための時間をどう守るかが問われている。

本稿は、2026年7月20日にIBM Technologyが公開した6 Ways to Enhance Developer Productivity with AIを基に作成しました。