コード行数を測ることは無意味か？AI時代に振り返る「開発指標の向き合い方」【九州大学・亀井教授】

ソフトウェア開発がAIによって変わったいま、その成果を測る「開発指標」は、どう変わればいいのでしょうか。

コード行数やコミット数、PR数。こうした従来の指標は、AIがコードを書き、実装のスピードが上がった今、開発がうまく進んでいるかを以前ほど映さなくなっているのではないでしょうか。

そんな問いを、ソフトウェアメトリクスを研究する九州大学の亀井靖高教授にぶつけてみたところ、返ってきたのはこんな答えでした。

「コード行数やPR数のような指標も、無意味になるわけではありません。ただ、その意味は変わります」 「“先進的”な指標なら優れている、というわけでもないんです」

AI時代に開発指標とどう向き合えばいいのか。変わるところ、変わらない本質を取材しました。

「認知的負債」という、AI時代の新しい“負債”

――“AI時代の新たな開発指標”として、どんなものが考えられますか？

亀井：重要性は上がっているのに、まだ指標がないのが「認知的負債」だと思っています。これから研究してみたい領域ですね。

ソフトウェアのデータだけでうまく測れるかというと、たぶん難しい。脳波とか血糖値とか心拍とか、そういうバイオメトリクスもいるんじゃないかなと思っています。

指輪型のデバイスなどを使って計測すれば、AI側で「この人は今、理解するのが苦しい状態になっているな」と把握できるようになり、「いったんここだけ理解して」「このサマリーだけ読んでおけばOKだよ」というようなアプローチが選べるようになるかもしれません。

――AIの出力を理解するつらさや疲労感は、よく聞くところ。それを開発指標にすると、何がうれしいのでしょうか？

亀井：「技術的負債」という言葉は従来のソフトウェア開発にもありましたが、AI時代はここに「認知的負債」と「意図的負債」が加わって、3つを組み合わせた「トリプルデット（Triple Debt）」が問題になる ¹ 。2026年のICSEのワークショップでも、こういった考え方が紹介されていました。

queue.acm.org

AIの出力に対して人間の理解が追いつかなくなり、よく分からないまま「オッケー、オッケー」と進めてしまう。これが認知的負債です。

ソフトウェア開発では「このメソッドはこういう理由でこうした方がいいから、こうする」という意図がコードと一緒に残るものですが、認知的負債を抱えたまま開発を進めると、そのような設計の方針が残らなくなります。

つまり、コードはあるけれども「なぜそうしたか」が分からない。これが意図的負債です。この状態のままさらに開発を進めてしまうと、技術的負債だらけのソフトウェアが完成し、もはや人間には手が付けられなくなる、というわけです。

――その「理解が追いついていない状態」を早めに捉えられれば、手遅れになる前に立て直せる。そこに、それを指標にする意味があるわけですね。

亀井：そうなんです。実際、これを提唱した、マーガレット=アン・ストーリー先生²の話によると、AIを使った学生の開発プロジェクトを行ったところ、最初は爆速でコードが書かれていき、すごい勢いでプロトタイプが出てきた、と。しかし、数か月後にはコードが直せず、プロジェクトが停滞する事例が続出したそうです。

さすがにプロの開発現場でそこまで悪化してしまった事例はまだ聞いたことがないのですが、AI時代の開発指標を考えると、「開発者のウェルビーイング」のような人間的な側面も重要なテーマになってくると思います。

私自身、研究論文や研究費の申請書をAIと一緒に書くことがあるのですが、1日2時間くらいならまだしも、締切前にほぼ徹夜で10時間くらいAIとやり続けていると「もう何を言っているのかな」という感じで……。日々AIを使うエンジニアは、特に負荷が大きいはずなので、ケアする方法を模索したほうがいいのではないか、と。

――先進的な開発指標のアイデアですね。では逆に、古典的なものについてはどうお考えですか。わざと意地悪な聞き方をしますが、例えばAIが出てくる前からしばしば「測っても無駄」と批判されてきたLOC（コード行数）はいかがでしょうか。

亀井：いや、コード行数も別に悪い指標ではない、というか……。そもそも、指標それ自体に善悪があるものではないと思っています。

大事なのは、指標を通じて「何が見たいか」と「それをどう使うか」です。

「絶対的に良い指標」は存在しない

――改めて、なぜLOCを「無駄」と切り捨てないのでしょうか。

亀井：そもそも指標は、開発の実態から1つの側面だけを切り出して測定するもので、複数の情報を組み合わせないと機能しないんです。コード行数だけ見ても「開発がどれくらい進んでいるか」は分からないのは確かですが、それは他の指標にも言えることです。

極論、この世のすべての指標を使えれば一番正確に測定できます。でも計測には手間がかかるから、実際には「何が見たいか」を考えて、いくつかに絞ります。

そしてその「何が見たいか」は、チームの目標や状況によって変わりますよね。だから、一般論として「この指標が良い」という普遍的な正解はない。

例えば、変化の早いスタートアップの開発では、見る指標が半年や1年といったスパンで「これは実態を表していないな」「今度はこっちが見たい」と変わっていくと思います。それは自然なことなんです。

――とはいえ、Four KeysやDORAのように、近年、広く使われるようになり定番化しつつある指標もありますよね。ああいったものはどう見ていますか。

亀井：Four Keysが見ているのは、DevOpsでいう「システムやサービスを止めずにつくり続ける」という目標に近いと思います。CIを取り入れていて、コードを書けばマージされて動き、そのままリリースされる。そういう開発環境なら、その指標は測定すべきですし、一般的には導入したほうがいいと思います。

ただ、これは「Four Keysが絶対的に良い指標である」という話ではなく、「止めずにつくり続けたい」という目標があるならば有効だろう、という話です。より本質的なのは「GQM+」³のような考え方だと思います。ゴールを定めて、サブゴールを分けて、何を知る必要があるかを決めて、だからこういう指標があるのだ、と逆算していく、という。

――「何が見たいか」と別の軸、「使い方」についてはどうでしょう。

亀井：指標を管理や評価に使うのは、指標のハックとつくり直しのいたちごっこになるリスクがありますね。

例えばLOCを見て「お前ら、ちゃんとつくってるか、サボってないか」と言う。他部門と比べて「A部門はコード行数が増えて立派、B部門はダメ」と言う。そういう使い方をすると、コード行数の水増しが起こります。

"When a measure becomes a target, it ceases to be a good measure"――いわゆる「グッドハートの法則」ですね。

測ること自体が目的になると、指標に対しての最適化が起こる。最初はうまくいくように見えても、長く使ううちに部分最適化が起きて、本当に見たかったものが忘れられてしまう。それで新しい指標に乗り換える、という悪循環が起こります。

――では、指標の良い使い方とは？

亀井：あくまで観察するためのものに留めないといけません。

指標を使うメリットは「現状把握がしやすい」「問題がどこにあるか見やすい」といった点にあり、「自分たちのチームの状態を把握するために使う」なら意味があります。

同じプロジェクトで同じ指標を計測し続けて、ポコッと異常値が出たら「どうしてだろう」と振り返る。管理ではなく、コミュニケーションのきっかけになるツールとして使うのがいいと思います。

「先進的」な指標は、実はもう使われている？

――近年提案されている開発指標には、どんなものがありますか。

亀井：例えば、2021年に発表された「SPACE」。LOCのような活動量だけでなく、コミュニケーションや満足度など5つの次元を、しかも個人・チーム・システム全体で見ましょう、というフレームワークです。

2023年には、もっと開発者個人の負荷に寄せた「DevEx」も出てきています⁴ 。こうした指標を統合的に組み合わせて使うことには、意味があると思います。

queue.acm.org queue.acm.org

ただ、これらの指標には「仕様がどれだけうまく解決されたか」のような、計測に手間のかかるメトリクスが多いのが欠点で、全部取り入れようとすると測定が大変だと思います。

また、指標として使ううえでは「正しく数値化できているのか」という問題も出てきます。例えば、「顧客満足度」はどうやって測るのか。クレームを分析してまとめるなどすれば何らかの数字を出すことはできるでしょう。でも、それが本当に満足度を表しているのか、というような疑問は残りますよね。

こういった新しい指標になるほど、「自動化のしやすさ」と「真に測りたいものとのズレ」、この2つの課題が大きくなるという傾向はあると思います。

こう考えてみると、コード行数には「自動化のしやすさ」という良いところがあるんです。コマンドを叩けば、明確な数字がすぐに出る、という。

――「日本の開発現場は遅れている」と言われがちですが、こうした開発指標は取り入れられているのでしょうか。

亀井：実を言うと、以前から類似する指標は使われているんですよ。

2005年から、IPA（情報処理推進機構）が「ソフトウェア開発データ白書」を出していました（2022年に終了）。

www.ipa.go.jp

ここにSCSK、NECソリューションズ、NTTデータ、沖電気工業、パナソニックといった会社で実際に使われている指標が書かれていて、数百種類あります。

人月、テストケース、バグ数、LOC、欠陥密度、レビュー指摘数、ファンクションポイント……といった定番から、顧客満足度のようなものまで載っています。

「海外で生まれた先進的な指標」に近いものは、実は意外と前から日本にもあるのです。そういう意味では、必ずしも「日本の開発現場は遅れている」とは言えないと思います。

AIが来ても、古典的な指標は“無意味”とは言い切れない

――AI時代にも有効そうな指標は、実はもう使われてきた。では対照的に、人月、テストケース、バグ数のような古典的な指標は、どうなると思いますか。

亀井：そういった古典的な開発指標もなくなるわけではないと思いますが、「その指標が何を表しているのか」という意味は変わると思います。しかも、その変わり方は指標ごとに違うので、十把一絡げには言えません。

AIによって大きな影響を受けやすいのはLOC、PR、コミット数あたりでしょうか。「いっぱいコミットできた」「PRが出た」からといって、ソフトウェアの価値が上がっているかは分からず、「変更量が増えている」くらいしか測れない指標になるかもしれません。また、「PRのマージにかかる時間」は今後、「人間がどれくらいボトルネックになっているか」を示す指標になるかもしれません。

それに対して、AIの影響を受けにくそうな指標としては「ビルドが失敗してこける時間やデプロイの手戻り率（リワークレート）」が考えられますが……これも「人間がきちんとチェックする」という前提で考えるのであれば、ですね。

――一般論として考えるのは難しそうですね。でも、開発組織の中にいて具体的な文脈を把握していれば、考えられそうな感じもします。

亀井：そうですね。つまるところ、指標を使ううえで大事なのは、最先端でも古典的なものでも、その開発現場において「何が測りたいか」だと思います。

自分たちの問題がどこにあるかを調べて、使う指標を決める。一定期間計測してみて、本当に見たいものが見えないと思ったら、指標を見直す。また、開発が進んでゴールや状況が変われば、測るべき指標も変わっていく。こういった点は、これからも変わらないのではないでしょうか。

取材・執筆：川島 昌樹
編集：川島 昌樹、田村 今人