オープニングと翻訳記事の紹介
皆さん、こんにちは。B-Testingのブロッコリーです。このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを約10分間で語っていくポッドキャスト番組です。
本日はですね、ちょっと緊急の収録になっています。というのもですね、先日、自分が書いているブログの方ですね。
ある翻訳記事を公開したところ、皆さんに反響をいただいたというものがあります。なので、今日はその記事について紹介および、自分なりの言葉で解説をしていきたいなと思います。
どういう話をするかというと、AIコーディングツールによって加速する高度生成に、品質保証活動はどう立ち向かうかということで、
開発がAIに任せていろいろ作っていったものに対して、品質保証活動、QAの活動ってどうするのっていうのを、
個人的にはすごい真新しい話ではないんですが、それをちゃんと言語化しているいい文章だなと思っているので、今回は紹介させていただきたいなと思っています。
ということで、今回もbtesting.fmスタートです。ということで、AIコーディングツールによって加速する高度生成に、品質保証活動はどう立ち向かうのという記事を紹介していきます。
これは現代は何かというと、QA in the Age of AI AcceleratedDevelopmentということで、現代をそのまま直訳すると、
AIで加速する開発の時代における品質保証みたいな、そういう訳になるかなと思うんですけれども、
中身を見ると、AIで加速する開発というよりも、本当にAIコーディングツールの部分、高度生成の部分について掲載されているので、ちょっと日本語訳は変えているというところです。
これを書いた人というのがJetBrainsのQA責任者であるリリアさんによる研究記事です。
もちろん許諾を得た上で翻訳をしています。
これって何かというと、このBeyond Qualityっていう、おそらく去年あたりにできた共同研究コミュニティの成果物になっています。
どっかの鋭利的なとかというわけではなくて、コミュニティ活動の成果物として出てきたものです。
それの英語の記事がすごい良かったので、自分のほうで日本語翻訳をしているということになります。
日本語文の全文はこの概要欄にURLを載せていますので、そちらを見ていただければと思いますし、英語の原文ももちろん公開されています。
自分が個人的にいいなと思ったところをどんどん紹介していきたいなと思っています。
コードを書くコストと引き換えに失われる知見
まず最初は、そもそもコードをAIコーディングツールによって書いてもらうっていうところで、どう変わっていったかっていう話で言うと、
コードを書くコストは安くなっていくんだけれども、代わりに2つの知見が損なわれ始めてますよと。
その2つっていうのは何かっていうと、まずは理解の負債ですね。
これは何言ってるかっていうと、コードがどう動くかに関する知見っていうのは失われていってますよねと。
もうAIに任せて書いてもらっているので、どう動くのかっていうのはもうAI任せになっていますよと。
そしてもう1つがですね、意図の負債ですね。どう動くのかではなくて、コードがそもそも何でこういうふうに作ったのかとか。
このコードを使うことでどういうビジネス課題を解決するかとか、これを考える上で他にも選択肢、とりあえず選択肢はあるはずだったけれども、
どうしてこっちの選択肢を選ばずにこっちを選んだのか、どういうトレードオフを強要したかっていうところ。
それを選んだ、そして作った、ずっとっていうのが見失われるよと。
意図の負債というのをこの記事では表現している。
これをこのAIコーディングツールを使うことによってどうなっているかっていうと、今までだと時間をかけて品質を向上させてきたんですね。
それは何かっていうと、コードを書いてテストをする上で、テストでバグを発見して、
それを開発者が学習をして、それが次のサイクルで同様のバグが減りますよと。
ここはこういうふうに気をつけなくちゃいけないなと思いながらコーディングをするのでバグが減るみたいなことがある。
こういうフィードバックループも弱体化するよっていうふうに表現していました。
これそもそもなんですけれども、今までっていうのはこのビジネスドメインですね。
ビジネスとしてのドメイン知識っていうのが実は無料で蓄積してきたよと。
これどうしてかっていうと、わざわざビジネスドメインを今から理解しよう。
そのためにはコストがこれぐらいかけてみたいな工数の見積もりとかしないわけですよね。
つまり明示的にこれだけ工数をかけてビジネスドメインを理解するっていうふうに活動することはあんまりなくて、
どちらかというと人間がプロセスに関与する。
例えばコーディングをしようとする。
その中でさっき言ったような意図、どうしてこれを作ろうとしたのかっていう意図を学習するっていうような
副産物としてビジネスドメインの理解が進んでいったっていうところがあります。
これがAIにとって代わってコード生成任せてしまうと、そこの副産物がなくなってしまうので、
ビジネスドメインが無料で蓄積していた部分が失われていくよっていうふうなことを書いてあります。
なので、このビジネスドメインを理解するための苦労っていうのが、
本来の排除すべきコストでは実はなくて、それをやることで理解を形成するプロセスそのものだったんですよと。
行動を書くにあたって、いろいろとビジネスドメインを理解するっていうのがどんどん形成されていくはずだったんだけれども、
そのプロセスがなくなってしまったよっていうところを危惧しています。
質的変化：コード量の増加ではなく理解度の低下
なので、以前は実装した本に人間がコードを一番理解していましたと。
ただし、それが今はエージェント、AIコーディングツールによってはAIにとって変わってしまったというところですね。
その上で厄介なのは、書いたエージェント自体には永続的な理解はないわけですよね。
その結果どうなっていたかっていうと、コードは存在します。
コードは存在しているんだけれども、実装者、作成者がかつては持っていたようなビジネスドメインの深い理解っていうのは持っていないわけですね。
だから誰も持っていない状態になりますよと。
この結果どうなるかっていうと、単純にAIコーディングツールによってコードが増えたっていう量的な変化だけではなくて、
そのコードの中身、1行あたりのコードの理解度が減ったっていうような質的な変化が起きてるっていうふうに
この記事では書いてあります。
修正コスト曲線の変化：手戻りの量から理解のギャップへ
それによってどう変わっていくか、コストがどう変わっていくかっていう話を次にしたいんですけれども、
AI以前には変更コスト曲線っていう考え方がありました。
これ何かっていうと、欠陥は早めに見つけたほうがいいよっていうふうに以前、
このbtesting.fmでお話したと思うんですけれども、
結果の修正コストは後工程になればなるほど、質感性的に増加しますよと。
何でかっていうと、発見が遅れるほど成果物が増えた状態で見つかるので、手元りが発生するよっていう話がありました。
これは以前、このbtesting.fmだと9回目のエピソードですかね。
そこで話した話として、使用誤りの修正コストっていう具体的な数値を持ってきました。
これ何かっていうと、要求仕様の段階で仮に1時間で直せるものがあったとしたら、
それがリリースした後の段階、要求仕様で見逃して、設計でも実装でもテストでも見逃して、
リリースした後の段階で、あれこれうまくいってないんだけどっていうのに修正が入った場合に、
同じ欠陥なんだけれども200倍、つまり所要時間として200時間かかるよっていうふうに言われていますっていう話をしました。
こういうふうに後工程になればなるほど手戻りがすごいコストになるよっていう話が以前の話でした。
このAIコーディングツールを使うことによって、そこでどうなったかっていうと、
後工程になって習慣性的に増加するっていうのは、実はあんまり変わってないです。
ただし、その中身がちょっと変わっていますよと。何かっていうと、まずAI以前の場合は、
コードを書くのは人間が手で行っていたので、ある程度コストがかかっていました。
それがAI時代によってエージェントが作成するので、コストが安くなりました。
その一方で、じゃあコードどういうふうに書いているかっていう、コードの中身の理解に関しては、
AI以前はコードを書きながら作成者が理解をしていたので、実質無料になってたんですね。
一方でAI時代はエージェントが作成しているので、結局誰もそこ深くコードの理解はできていないので、
それを理解するのはコストが結構かかってしまいますよと。
また、じゃあそれを実際にリリースした後とかで、もしくはテストの段階でバグが見つかって、
コードを書き直すっていったときを考えると、AI以前の頃、人間がやってたときは、
もちろんコードを書き直すときは、ある程度時間をかけて人間が手直しをしていたので、コストが高くなります。
なのでAI時代、今のAI時代においてはエージェントが再生成するので、そんなにコストがかからなくなりますと。
一方で、じゃあ書き直すところ自身は安くなったとはいえ、じゃあどこを書き直すべきなのかっていう、
場所を探すっていうところに関しては、AI以前、人間がやる場合は、ある程度作成者が理解している状況のコードを巡って、
じゃあここを直そうっていうふうに場所を見つけるので、少しのコストで進んでいました。
一方でAI時代の場合は、そもそもコードの理解っていうのを誰も深く理解していないので、
じゃあコードを書き直すっていった段階で、そもそもどこを直せばいいんだろうっていうのは、
もうほぼゼロの状態から理解をして書き直す場所を見定めるっていうふうになるので、非常にコストがかかりますと。
っていうふうにコストがかかる場所がちょっと変わっていったんですね。
なので、コストの要因がAI以前だと手戻りの量だったほうが、それがAI時代になると理解のシフトして、
その曲線、コスト、後工程になればなおほどコストが高くなるっていう、
その高くなる、コストが高くなる度合いがさらに急勾配、かなりコストが高くなるっていうふうに考えられて。
積極的（プロアクティブ）な品質保証と反応的な品質管理
で、そんな中でじゃあ品質補償活動ってどうしていくのかっていう話なんですけれども、
この基準の中ではそもそも品質補償活動を行うやり方っていうのを2つに分類しています。
まず1つの段は積極的な品質補償活動を行う企業についてです。
これは何かっていうと、前のめりに参画していろいろシフトレフトのテストみたいな言い方をしたりもしますが、
とにかく努力の比重っていうのが評価をする、できたものを評価するっていうよりも、
うまくちゃんと質の良いものを作り上げるっていう予防に重きを置くような企業を指しています。
なので、そもそもバグが起きないようにするとか、
ちゃんと設計をしっかり考える、品質の良い設計にするみたいに考えるところなので、
もうコードとかを書く前の予防の段階に重点的に投資しますよと。
その結果、早い段階、設計の段階、これは開発の機能設計の段階から入って、
そうすると、ここは複雑そうだからこの部分は重点的にテストを行おうよとかっていうのを考えて、
リスクの削減効果が最も高いところに狙いを定めて評価とかテストを行うっていう、
こういう企業をこの記事の中では積極的な品質補償活動を行う企業という表現をしていました。
一方でもう一つの企業が反応的な品質管理を行う企業です。
これは何かというと、品質を保証するのではなくて、開発が作り終わったコードを作った後に
事後的に管理するみたいな企業のことです。
そうするとそのテストの内容っていうのは、ここの部分はちゃんとテストしなきゃねっていうふうに、
事前に全員で合意したことを検証するのではなくて、事後的にテストをするので、
開発者がどういう意図で作ったんだろうっていうのを推測しながら、
じゃあここをテストしようっていうような、何を作ろうとしたのか、
意図を推測する作業になってしまうよっていうのを、
これを反応的な品質管理を行う企業として紹介していました。
人間とAIツールの調整コスト
その上で、品質補償活動がどう影響するかっていう話なんですけれども、
実際にいろいろなチーム、複数チームで開発をしていくっていうことを考えると、
そのコストの関数をこの記事の中だと、オーダーのNプラスyNの2乗という表現をしていました。
ここでいうNっていうのはチーム数のことです。
yはチーム間の調整係数になります。
なのでこの二次項の部分ですね、yNの2乗っていうところの部分っていうのが、
チームとチームをまたいで何か調整をしなくちゃいけないっていうのは、
その単一のチームで頑張ることよりもかなりコストがかかるよっていうのをここでは表現しています。
もちろんチーム数がいっぱい増えれば増えるほど、そこのコストはすごい大きくなります。
静か数的に増えていきます。
かつここが疑問になるんですけれども、
じゃあチーム数が増えていったときにチーム間の調整係数っていうのをできるだけ小さくしようっていう考えをするといいかなと思っています。
そうするとyが小さくなればなるほどNの2乗にかかる係数が小さくなるので、
オーダー全体としてもコストとしては低くなりますよと。
先ほど言った積極的な品質特保証活動を行う企業っていうのはこのyを小さく保つ努力がされているんですね。
決してゼロになるわけではないんだけれども、いかにチーム間の調整のコストを少なくするかっていう努力をしているわけですね。
例えばマイクロサービスにしてチーム間で依存関係の少ない状態にするのもあるでしょうし、
テストのことを考えると早めにテストのことを考えて、じゃあこの部分は単体レベルできちんとしましょうと。
どうしてもチーム間をまたぐこの部分だけは統合テスト、システムテスト、受け入れテストみたいなそういう後行程のところでテストをしましょうと。
全部をチーム全て作り終わった後につなげてテストするところにいっぱい時間をかけるんじゃなくて、できるだけ単体に寄せましょうよとか。
このゲストの中ではまだ紹介してないですが、例えばテストピラミッドの考え方を使ってユニットレベルのテストを多くしましょうみたいな、
そういうのもある意味このチーム間の調整係数っていうのをできるだけ小さくする努力になるわけですよね。
これが今チームとチームの間でそこのコストを掛け合わせるよみたいな言い方をしましたが、
これが特にコーディングツールにおける話で言うと、チームとチームではなくて人間とコーディングツールっていうそこの間っていうふうに考えられるわけですね。
つまり、例えば個人で開発しているような場合でもこのNのところには2が入るわけですね。
自分自身とコーディングツールっていうNイコール2になるわけですよね。っていうふうに考えられると。
そうするとそこの調整係数っていうのをちゃんと考えないと、どんどんどんどんエプシロンNの2乗っていうのが大きくなりますよね。
単にチームの数だけじゃなくてコーディングツールもそこのNに入ってくると、さらにコストが増えていくよっていう考え方があります。
だからこのエプシロンを小さく保つためには先ほど言った積極的な品質保証活動を行うっていうのが重要になってくるよっていうのをこの記事では紹介しています。
まとめと感想コーナー
ということで、自分がすごい共感するところいっぱいあったのでバーっといろいろしゃべってきましたが、やっぱり今日最初にも話した通り、
この記事、AIコーディングツールによって加速する行動生成に品質保証活動はどう立ち向かうかっていうこの記事自体はすごい真新しい話をしているわけではないんだけれども、
機械の不採とか、糸の不採とか、あとはオーダーのNプラスエプシロンNの2乗の話であったりとか、
あとは行動を書き直す場所を見定めるところにコストがかかるよみたいな話とかっていう、
我々がこのAIコーディングツールに触れて漠然とここちょっと結構コストかかるなと思っていたところを的確に言語化しているいい記事だなと思っています。
詳しくはブログの記事もしくは原文を読んでいただければと思います。
他にもいろいろ語っています。
ではここからは感想のコーナーですね。
今日は第22回目ですね、都道府県いくつテストするテスト設計の基本同時分割法徹底解説の感想をいただきました。
この感想はですね、Spotifyのコメントの方で多分初めていただいた感想になります。
リーさんですね、ありがとうございます。
Spotifyのコメントも全然空いていますので、ぜひ書き込んでいただけると嬉しいです。
リーさんの感想として、とても分かりやすかったですと。
慣れると頭にパッと浮かんだ値を使いがちだったので反省しましたと。
ありがとうございます。感想ありがとうございます。
そうですよね、結構やっぱり慣れると、とりあえずここ都道府県これを選んでみようかみたいに思っている。
暗黙的に思っているみたいなところがあると思うんですよね。
けどちゃんとどうしてそれを選んだのかっていう理由を考えると、
その人なりの言語化してなかったけれども、まさに意図ですよね。
その都道府県を選んだ意図っていうのが存在するはずなんですよね。
なのでそれをきちんと同時分割法を使って、同時パーケーションで考えましょうよというのが、
この同時分割法でお伝えしたかったことです。
ぜひこのエピソードをきっかけとしてリーさんをはじめ、
皆さんに同時分割法っていうのを改めて考え直してもらえると嬉しいなと思っています。
感想ありがとうございました。
エンディング
ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿本は番組概要欄にあります。
またエピソードの感想は、
ハッシュタグBテスティングでユクスのポストをお願いいたします。
あとは先ほどの感想コーナーでもいただいていたように、
Spotifyのほうのコメント欄も開けていますので、
そこにぜひ感想を書いてもらえると嬉しいなと思っています。
今日の話でいうとAIコーディングツール、
立ち向かう非相性活動をどう立ち向かうかっていう話しましたけれども、
うちではこういうふうにやってるよみたいな話を聞けると嬉しいなと思っています。
もしもこれからも聞きたいという方は、
お手持ちのPodcastアプリで番組のフォローもお願いします。
最新回が上がったときにすぐに気づけます。
基本的に私は毎週月曜日Podcastを上げているつもりなんですけれども、
それ以外にもこれ喋りたいなと思うときに木曜日に上げたいとか、
あと今日みたいに緊急でこのPodcastを収録したりとか、
そういうのをタイムリーに上げようとも思っていますので、
ぜひ番組のフォローもお願いしたいなと思います。
ということで今回はここまでです。
それではまた次回。バイバイ。
