"The Effects of Generative AI on High Skilled Work: Evidence from Three Field Experiments with Software Developers" と題された論文がその出典元である。日本語に訳せば、『生成AIが高度技能職に及ぼす影響: ソフトウェア開発者を対象とした3つのフィールド実験によるエビデンス』といったところか。“3つのフィールド実験” とは、マイクロソフト、アクセンチュア、フォーチュン100に名を連ねる匿名の電子機器製造企業での実験を指している。
本稿は、この論文を主軸としつつ、他の文献も参考に、GitHub Copilotを用いたソフトウェア開発への生成AI活用の効果について見ていく。追加で取り上げた主な文献は、"調査：GitHub Copilotが開発者の生産性と満足度に与える影響を数値化" と "調査：GitHub Copilotが開発者の生産性と満足度に与える影響を数値化" である。
結論としては、GitHub Copilotの活用は、プルリク数を増やすだけでなく、コードレビューを速め、開発者体験も高める効果が期待できることが明らかとなった。また、チーム内外での協働を高次へと導くのではないかと考えるに至った。
なお、参考文献で使われた生成AIツールはGitHub CopilotやGitHub Copilot Chatであるが、本稿ではそれらを区別しない。一括して「GitHub Copilot」や、単に「Copilot」と呼ぶこととする。特定の生成AIプロダクトの性能や効果を見極めたいわけではないからだ。
調査の概要
まず、文献 "The Effects of Generative AI on High Skilled Work: Evidence from Three Field Experiments with Software Developers" の概要を簡単に説明する。
実験は、GitHub Copilotにアクセス権を付与した開発者とそうでない開発者をランダムに分け、それぞれの開発生産性の違いを比較する形で実施された。参加したのは、マイクロソフト、アクセンチュア、フォーチュン100に名を連ねる匿名の電子機器製造企業に務める計4,867人のソフトウェア開発者だ。それぞれ調査の実施時期は異なるが、2022年から2024年にかけて行われた。
主要な指標は4つ。週ごとのプルリクエスト数とコミット数、ビルド数。そしてビルド成功率である。プルリクは、企業によってそのスコープは異なるものの、“開発者の作業単位” として扱わるものであり、指標として適切だろう。その他の指標については、解釈が難しいので、本稿ではあまり触れないことにした。
実験の結果は次のとおりであった。GitHub Copilot利用者の開発生産性が、ビルド成功率以外の3つの指標で増加が見られる。
- プルリク数: 26.08%増加
- コミット数: 13.55%増加
- ビルド数: 38.38%増加
- ビルド成功率: 5.53%減少
開発生産性への作用
GitHub Copilotによって、開発生産性がどのように影響を受けたのか、追加の2つの文献も参照しつつ、もう少し詳細化したい。プルリク数をはじめ、実験で用いられた4つの指標の変化は、“結果” に過ぎないからだ。開発者とCopilotとのペアプロにも似た協働作業が何らかの作用を及ぼし、結果として4つの指標、特に、プルリク数に影響したのだ。
開発生産性を考えるうえで最近のトレンドは “SPACEフレームワーク” だろう。このフレームワークは、開発生産性を考えるうえで、多面的な視点を与えてくれる。それは、“5つのディメンション” と “3つのレベル” によってもたらされる。
“ディメンション” とは、開発生産性の観点を5つに分類したものだ。ちなみに、“SPACE” という名は、これらの頭文字で構成されている。
- 満足度と幸福度 / Satisfaction and well-being:
開発者が自分の仕事にどれだけ充実感を持ち、幸福であり、健康的に働けているかを測る指標。働きやすさやモチベーションとも関係する - パフォーマンス / Performance:
作業の量ではなく、その結果として生まれる価値（アウトカム）を評価する指標。単なるタスクの完了やスピードではなく、ユーザーやビジネスに与える影響を重視する - 活動 / Activity:
コードの変更数やレビュー回数など、開発における具体的なアクションやアウトプットの量を測る指標。ただし、活動量が多いことが必ずしも成果につながるわけではない点に注意が必要 - コミュニケーションとコラボレーション / Communication and collaboration:
個人やチーム内、さらにはチーム間での情報共有や連携の質を測る指標。スムーズな意思疎通や協力体制が、開発の生産性や品質に大きく影響する - 効率とフロー / Efficiency and flow:
開発プロセスの滞留や手戻りを抑え、スムーズに作業を進められているかを測る指標。不要な待ち時間やコンテキストスイッチを減らし、一貫した流れを保つことが重要となる
“レベル” は、各ディメンションで計測する指標が扱うスコープを指す。個人、チーム、システムの3つに分類される。「個人レベルの指標」、「チームレベルの指標」は、その通りの意味であるが、「システムレベルの指標」は誤解を受けやすい。これは、ソフトウェアシステムのことではない。 「システムレベル」とは、「チームレベル」より広い範囲のフローを指す。チーム間やプロセス間での仕事の受け渡しを含む範囲だ。
SPACEフレームワークの詳細については、DORAのドキュメントが参考になる。また、本ブログでも一度取り上げた。
以降で、SPACEが定義する5つのディメンションそれぞれについて、開発生産性に対するGitHub Copilotの作用を考える。便宜上、その並びは、S→P→A→C→Eの順ではなく、A→E→P→S→Cとなっている。
活動（Activity）の観点
プルリク数が約26%増えたという計測値1は、個人レベルでの活動指標だ。言い換えればこれは、“個人のスループット” が高まったことを示す。
ここで注意が必要なのは、個人のスループットが高くなったからと言って、“個人の開発生産性” が高まったとは限らないという点だ。スループットを高める要因は2つ考えられ、それらを分けて考察したうえで結論を導くべきだろう。
まず、“作業単位が小さくなった” だけかもしれないこと。つまり、プルリク1回あたりのスコープが小さくなったということだ。そうであるなら、実装しなければならないコード量も減り、作業時間が短くなる。結果として、スループットが高まる。
これが要因でスループットが高まったのであれば、個人の開発生産性が高まったとは言い難い（もちろん、プルリクのスコープやサイズが大き過ぎることは問題ではあるが）。
論文内ではこの可能性を否定する明確なエビデンスは示されていないが、スループット改善効果の要因は、おそらくこれではないだろう。Copilotを導入したからといって、プロジェクトや企業内での “開発者の作業単位” に変化が起きる明確な理由がない。また、プルリクのスコープを小さくすることに対し、この実験において開発者にその動機もない。もちろん、これはあくまでも私の想像でしかない。
もう1つの要因として考えられるのは、“作業自体が速くなった” こと。つまり、開発者が作業を開始してから、プルリクを投げるまでの時間が短くなったということだ。
スループット向上の要因がこれであれば、個人の開発生産性が高まったと言えるのではないだろうか。作業自体が速くなりプルリク数が増えた要因は、おそらくこれである。そのエビデンスについては、他のディメンションでの指標の計測結果が示している。
効率とフロー（Efficiency and flow）の観点
GitHub Copilotの活用が、個人の作業時間を速くしたというエビデンスとして、別の文献で次の数値が示されていた2。これは、個人レベルでの効率とフローに関する計測結果と言える。
- GitHub Copilotを使用した開発者は、使用しなかった開発者より55%速くタスクを完了した
知覚的指標ではあるが、タスク完了を速くした要因として次の調査結果がある3。これは、GitHub Copilotの導入効果に対する開発者へのアンケートを集計したものだ。
- 「検索する時間が減る」に同意: 88%
- 「強く同意」だけでも70%以上
- 「繰り返しの作業が減る」に同意: 88%
- 「強く同意」だけでも60%以上
これらの効果によって、具体的にどれだけ作業時間が削減されたかは明らかではない。しかし、この小さな時間削減が積み重なって個人の作業時間を速くしたのだろう。
さらに、次の結果が示唆するように、開発者が作業中に “フロー状態が維持されやすい” ことも示されていた3。フロー状態に入れば、生産性やパフォーマンスが高まりやすいことが知られている。これも、個人の作業時間を速くした要因であろう。おそらく、検索する時間や繰り返しの作業が減ったことが、心理面に好影響を与えたのだと考えられる。
- 「イライラが減る」に同意: 88%
- 「集中力が増す」に同意: 88%
- 「コーディングを楽しめる」に同意: 88%
また、コードレビューが速くなったという調査結果もある3。
- コードレビュー完了までの時間が15%短くなった
これは、次に挙げるパフォーマン指標に見られる効果が影響したのではないだろうか。
パフォーマンス（Performance）の観点
GitHub Copilotの活用により、コード品質が高まるという。Copilotを利用した場合とそうでない場合で比較すると、前者の方がコードレビューの平均評価が高いという結果が得られたのだ3。それは、次の5つの指標すべてにおいてそうであった。コード品質の評価は、個人レベルでのパフォーマンスの指標に含まれる。
- Readable / 読みやすさ
- Reusable / 再利用性
- Consise / 簡潔である
- Maintainable / 保守できる
- Resilient / レジリエント
コード品質が高まった結果、先述のように「コードレビュー完了までの時間が15%速くなった」のだ。まさに、“品質が速さを生む” ことの証明である。品質の低いコードは、レビュアーにとってストレスであり、読んだり理解したりするだけで時間をとられる。そもそもそのようなコードは、そのままではレビューを通過できない。その結果、コードレビュー内での差し戻しや習性の回数が増え、時間がとられてしまうのだ。
満足度と幸福度（Satisfaction and well-being）の観点
満足度と生産性の間には相関関係があり、前者は後者の先行指標になるとも言われている。それなら、GitHub Copilotによって開発者の満足度が高まれば、開発生産性も高まっているはずだ。
この点については、次の結果を個人レベルの満足度と幸福度に関する計測結果として扱えるだろう2。
- 自分の仕事に充実感をより感じる: 60%
- より満足できる仕事に集中できる: 74%
これらは、開発者体験が高い状態を表している。
効率とフローの観点で述べた “フロー効率が維持されやすい” という環境は、開発者体験を高める因子となるだろう。
コミュニケーションとコラボレーション（Communication and collaboration）の観点
それでは、コミュニケーションとコラボレーションの観点ではどうだろうか。このディメンションは、人やチームの関係性を対象とするディメンションだ。つまり、チームレベル、システムレベルでの開発生産性指標がターゲットとなる。
ここまではいずれも “個人レベル” での開発生産性指標に好影響を与えていたに過ぎず、チームレベルやシステムレベルではなかった。GitHub Copilotが開発生産性に及ぼす影響は、個人レベルにのみとどまるものだろうか。
この点について私は、効率とフローの観点やパフォーマンスの観点で挙げた次の調査結果3に注目する。
- 検索する時間が減る
- 読みやすさが向上する
開発者の作業時間のうち、多くは、設計・実装方法について調べることや、既存コードを読むことに費やされている。コーディングしている時間はそれほど多くはないのだ。
しかし、特に在籍期間の短い開発者や経験の浅い開発者は、この「調べる」「読む」を1人で遂行できない場面も多い。そういった時に頼るのは、先輩やチームメンバーたちだろう。わからない点を周囲の人にたずね、ヒントをもらったり、解決策を教えてもらったりする。この時、コミュニケーションが発生する。
こういったコミュニケーションはあって然るべきものだが、相談相手の時間や集中力を奪いやすいという欠点も抱えている。フロー状態にある開発者に話しかければ、そこで集中力は途切れてしまう。相談された人は、親身になって相談者に接するうちに、自身のタスクを進める時間か削られていく。相談する側も、相談相手に手間を掛けてしまうという心理的ストレスを持ちやすい。
GitHub Copilotが “個人レベル” での開発生産性指標に好影響を与えているのなら、それは “単独での業務遂行能力” が高まっているということではないだろうか。調査結果を見てみると、在籍期間の短い開発者や経験の浅い開発者の方が、GitHub Copilotを活用しようとする様子がうかがえる1。
- 勤続期間が短い開発者やジュニア開発者の方が、GitHub Copilotの採用率が高い
- 勤続期間が短い開発者の方が、採用後に継続して利用し続ける傾向が高い
それぞれの開発者の “単独での業務遂行能力” が高まれば、誰かの時間や集中力を阻害することも少なくなる。そうしてチームや組織は、より高次の協働に時間が割けるようになる。これが、生成AIの活用によって変化しつつあるソフトウェア開発の新しい姿なのだろう。
関係性の図式
SPACEフレームワークを用いてGitHub Copilotの効果を俯瞰してみることで、その作業が見えてきた。まず、直接の効果として、検索する時間と繰り返しの作業が削減されることで、手間が減る。また、コード品質も良くなる。これらの結果として、個人レベルでは、プルリク数が増え、開発者体験が良くなり、コードレビューも速くなる。さらに、単独での業務遂行能力が高まることで、チーム内外での協働を高次へと導くのだ。
活用しなければ効果は得られない
どんなに便利な道具があっても、それを採用し、使いこなさなければ高い効果は得られないのだが、手を出そうとしない人もいる。マイクロソフト、アクセンチュア、匿名企業での実験における採用率を見ても、それは明らかだ。30%から40%の開発者は、GitHub Copilotのアクセス権を得ても、それを試してもいない1。
開発者を取り巻く環境はめまぐるしく進化を続けており、その変化を組織にどう組み込んでいくかが、開発生産性に大きく影響する。採用率を高めるための努力は、組織自体の課題であろう。
GitHub Copilotを採用しなかった理由は、単に忙しくて手がでなかっただけかもしれないが、おそらくそれはないだろう。GitHub Copilotへのアクセス権を得てから数か月もの間、手を出す時間がまったく無かったとも考えにくい。
新しいツールや技術を学ぶことに対して面倒に感じ、敬遠したのかもしれない。これは、GitHub Copilotや生成AIに限ったことではない。人間とは基本的に、変化を嫌うものである。変化に追従するには時間も気力も必要なのだ。今までのやり方でできるなら、新しいやり方を学ぶまでもない。そう感じてしまうのだろう。
このような新しいツールや技術に対する関心の差が、勤続期間や職位に現れた可能性はある。勤続期間が短い開発者やジュニア開発者は、比較的に若手である可能性が高い。そのような若手の方が、新しい技術を採用する傾向が高いことを示唆する先行研究もあるようだ。
マイクロソフト社内での調査結果にそのヒントがある。
調査結果のサマリは次のとおりだ1。在籍期間短や職位で分けて、実験内でのGitHub Copilotの活用状況を比較したものだ。サマリ内の “勤続期間が長い” とは、実験開始時（2022年9月時点）の勤続期間が中央値以上の開発者を指す。“シニア” とは、実験時（2023年3月時点）の職位が高い開発者を指す。
- 勤続期間が長い開発者やシニア開発者の方が、GitHub Copilotの採用率が低い
- 勤続期間が長い開発者の方が、採用後に継続して利用し続ける傾向が低い
- 勤続期間が長い開発者の方が、提案されたコードを受け入れる傾向が低い
※わずかであるが、シニア開発者も傾向が低い - 勤続期間が長い開発者やシニア開発者の方が、開発生産性の向上率が低い
※プルリク数の増え方などが低い
見ての通り、いずれもベテラン勢の方が結果が良くない。これを深堀りしてみる価値はあるだろう。
1から4の結果について、ぱっと考えられる理由を書き出してみたが、どうだろうか。
- 採用率が低い理由:
- 既存の知識と経験だけで対応できる環境であるため、採用すべき必要性を感じなかった
- 多くのことを独力で解決できるため、必要性を感じにくかった
- 採用後に継続して利用し続ける傾向が低い理由:
- 提案したコードを受け入れる傾向が低い理由:
- 提案されたコードの内容が、自身のコーディングスタイルや設計方針と合わないことが多かった
- 提案されたコードの質が期待に達しなかった
- 開発生産性の向上率が低い理由:
- 継続利用率や提案コードの受け入れ率が低いため（上記2と3）、生産性向上が限定的だった
- 多くのことを独力で解決できるため、GitHub Copilotに頼らずに仕事を進めることが多かった
これらの問題に対し、組織で取り組むなら、次のような対策が考えられるだろう。
- 組織としてGitHub Copilot導入の目的を共有し、皆が共通認識を持つ
- 目的が共有されていないと、各自が独自の基準でGitHub Copilotの有用性を判断してしまう
- GitHub Copilotを使いこなせるよう、説明会や勉強会などを設ける（eラーニング教材を用意するなど）
- 個人やチームのナレッジを、Tipsとして組織内で共有できる仕組みを作る（ナレッジベースやLT大会など）
- 適度なチャレンジを組織内に注入する（新技術の導入、異動など）
- 組織がコンフォートゾーンにとどまらず、ラーニングゾーンへ移行できるよう促す
最後に: AIとソフトウェアエンジニアリング
GitHub Copilotをはじめとする生成AIは、コードの自動生成を通じて開発生産性を高めてくれるが、新たな問題も生みだす。特に、提案されたコードを開発者が鵜呑みにしてそのまま採用する危険性は無視できない。
生成AIに提案されたコードを理解せずに本番環境で使うことは危険だ。本番トラブルが発生しても、素早く原因を特定し、解決することが難しくなる。いずれAIがすべてを解決できる時代が来るかもしれないが、今はまだそうではない。
開発スピードを優先しすぎると保守や運用にそのツケがまわる。これは生成AIの活用でも同じだ。理解せずにコードを導入すれば、組織はレガシーシステムを抱えるのと同じ課題に直面することになるだろう。ソフトウェアシステムがブラックボックスになりかねない。
ソフトウェアエンジニアリングとは、「時間で積分したプログラミング」だとも言われる4。開発のあとに続く保守・運用までがその範囲なのだ。開発だけにフォーカスしたコーディングは、ソフトウェアエンジニアリング業務を破綻させる。
それはまるで、AIを “活用している” と言うより、AIに “使われている” ようでもある。主従が逆、いや、"Copilot" だから “主副” が逆なのだ。自らのソフトウェアエンジニアとしての価値を毀損する行為にさえ感じる。
ソフトウェアエンジニアリングを取り巻く環境は、常に変化し、進化し続けている。今までもそうであったし、これからもそうあり続けるだろう。ここ数年で大きく進歩したAI技術は、それをさらに加速させている。本稿執筆中の2025年2月7日にも、ちょうど、GitHub Copilotが、VS Code向けにエージェントモードを導入し、Copilot Editsを一般提供すると発表したところだ。本当に速い。そして楽しい。
この大きなシフトをどう受け止め、どう乗りこなしていくのかが、私たちソフトウェアエンジニアやエンジニアリング組織に問われているのだろう。
参考文献
- Zheyuan (Kevin) Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz, "The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers", 2024↩↩↩↩↩
- 調査：GitHub Copilotが開発者の生産性と満足度に与える影響を数値化 - GitHubブログ↩↩
- 調査：GitHub Copilotがコード品質に与える影響を数値化 - GitHubブログ↩↩↩↩↩
- Titus Winters (著)、Tom Manshreck (著)、Hyrum Wright (編)、竹辺 靖昭 (監訳)、久富木 隆一 (訳), "Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス", 2021, オライリージャパン, 1章↩
