「AIが書いたコードに、テストはもう要らない」
こういう話が、ちょっと前にけっこう盛り上がってました。
今のAIは、ほぼ完璧なコードを書く。
だから細かいテストを書いても、AIが完璧にやるところを確かめてるだけで意味がない。
本当に問題になるのは、システム全体がちゃんと動くかどうか。
だから、細かいテストはやめて、E2Eの振る舞いを見ろ、と。
E2Eっていうのは、人間じゃなくてシステムが自動で、サービスを実際に動かして、ちゃんと動くか確かめるテストです。
筋は通ってるんですよ。
実際、細かいテストを大量に書いても、それ単体では全体が動く保証にならないので。
ただこれ、実際に運用に乗せると、話が変わるんですよ。
そもそもE2Eって、2種類あります
E2Eってひとまとめに語られてますけど、中身は2種類あるんですよ。
これを分けないと話が噛み合いません。
1つは、APIだけを動かすやつ。
データを送って、返ってきた中身が合ってるかを見るだけです。
画面は出てきません。
もう1つが、画面からバックエンドまで全部繋いで動かすやつ。
ブラウザでボタンを押すと、本物のバックエンドにリクエストが飛びます。
本物のデータが返ってきて、画面に出る。
で、この2つなんですけど。
テストが通らなかった時に、決定的な差が出るんですよ。
前者は、バックエンドだけ見ればいいです。
範囲が限定的なので、原因を特定するのも、直すのも楽なんですよ。
でも、後者はシステム全部が疑わしいです。
フロントエンドなのか、バックエンドなのか、データベースなのか。
どこに原因があるのか、ぱっと見では分かりません。
同じE2Eという名前ですけど、運用のだるさは全然違います。
APIのほうは、入れたらいいと思います
落ちても原因がすぐ分かるし、AIでもだいたい直せます。
正直、入れない理由があんまりない。
ただ、問題はもう片方なんですよ。
全部繋いだやつは、バックエンドを直すたびに崩れます
で、こっちなんですけど。
画面とバックエンドが繋がってるので、片方を直すと、もう片方のテストが落ちます。
裏側でデータの持ち方を変えると、APIが返す中身も変わります。
当然、画面に出るものも変わります。
そうなると、まずどのテストが引っかかるのかを探すところからです。
数百本の中から、です。
そこが分かったら、画面を見てるテストを1本ずつ直す。
テスト用に入れておくデータも、入れ直す。
バックエンドを1箇所いじっただけで、これです。
とんでもない修正量になります。
AIに書かせても、合ってるかの確認は自分でやるので。
正直、開発のスピードは落ちます。
で、落ちるたびにこう聞かれます
「これ、バグ? それともテストが古いだけ?」
これを調べるのは、人間です。
サービスが壊れたのか、テストが現実に追いついてないのか。
どっちなのかを、AIは判定できません。
今の仕様が正しいかを知ってるのは、作ってる人だけなので。
これ、さっきの「どのテストが引っかかるか探す」のところも同じなんですよ。
探すのはAIができます。
でも、出てきたものを見て「これは直す」「これはもう要らない」を決めるのは人間です。
AIが直せるのは、壊れたものです。
そのテストが今も正しいかどうかは、別の話なんですよ。
しかも、E2Eそのものを見るのがしんどいんですよ。
1本の中で、ログインして、画面を移動して、入力して、送信して、表示を確認する。
やることが多いんです。
これが数百本あります。
AIが書いてきたそれを、1本ずつ「この確認は今も要るのか」って見ていく。
正直、読むだけで日が暮れます。
しかもこれ、自分の時間だけじゃないんですよ。
バックエンドを直しただけなのに、レビューする人もE2Eのケースまで読むことになります。
毎回、チームの時間が持っていかれます。
で、ここが一番きついんですけど。
この見直し、1回でも抜かすと崩れます。
直し忘れたテストが、次の日から落ち続けるので。
落ちてるのが当たり前になると、誰も中身を見なくなります。
そうなったら、もう終わりです。
本物のバグで落ちても、「またあれでしょ」で流されるので。
手間をかけて育てたテストが、誰にも信用されなくなるんですよ。
そうならないためには、直し忘れが1本も出ないように回し続けるしかないです。
毎回、全部です。
これをちゃんと回せる体制がある現場なら、入れたらいいと思います。
ただ、そこまでやる価値があるかは、現場によります。
じゃあ厚くすべきなのか、しないほうがいいのか
ここ、答えが真っ二つに割れます。
一方は、止まったら、その時間ぶんお金が消えるサービス。
決済とか、予約とか、在庫とか。
こういうの、止まったらすごい損害ですよね。
下手したら、賠償しないといけないレベルです。
だから、バグが出たらさっさと直さないといけない。
なんなら、そもそもバグが出ないように仕組みで止めないといけない。
こういう現場では、画面からバックエンドまで繋いだE2Eがかなり効きます。
で、もう一方は、これから画面もAPIの仕様もガンガン変わって進化していくサービス。
成長段階のサービスですね。
ここに全部繋いだE2Eを入れたら、どうなると思いますか。
画面を作り変えるたびに、テストも作り変えることになります。
APIの仕様が変われば、そこでもまた探して、また直す。
機能を1個足すのに、毎回この作業がついてきます。
そのぶん、リリースが遅れます。
で、成長段階のサービスって、早く出してお客さんに使ってもらって、契約を取っていかないといけないんですよ。
そこが全部後ろにズレます。
完璧な品質を優先して、スピードを捨てて、タイミングを逃す。
気づいたら、他社に先を越されてる。
品質を守ったのに、サービスが利益を出せなくなるんです。
最悪、会社ごと潰れます。
こんな感じで、E2Eをどこまで入れるか。
そもそも入れる必要があるのかどうか。
それは、自分たちが作ってるサービスと、そのビジネスが今どのフェーズにいるかで変わってくるんですよ。
前者は、E2Eをやらなかったら損をする。
後者は、E2Eを入れたら損をする。
同じ技術の話なのに、答えが真逆になるんです。
同じことが、設計でも起きてます
これ、テストに限った話じゃないんですよ。
クリーンアーキテクチャで組んで、ドメイン駆動で設計して、テスト駆動でテストコードをガリガリ書く。
理想としては、めちゃくちゃいいと思います。
ただ、それができる会社・現場・体制って、どれだけあるんですかって話なんですよ。
理想を語る人は、たくさんいます。
でも、じゃあそれを自分の現場にどう乗せるか、まで話す人はあんまりいない。
評価される基準が、そもそも2つあります
そもそも今回の「E2Eさえあれば、AIでの開発はうまく回る」って意見。
どこから来たかというと、SNSです。
で、この手の技術的な理想論って、XやYouTubeだけじゃないんですよ。
QiitaやZennみたいな技術記事でも、よく出てきます。
で、ここで知っておいてほしいことがあって。
技術記事やSNSで評価されることと、現場で評価されることは、別なんですよ。
記事で評価されるのは、正しさです。
きれいな設計。正しいやり方。新しい技術。
現場で評価されるのは、結果です。
その判断で、サービスに何が起きたか。
正しさか、結果か。
ここが噛み合ってないと、正しいことを言ってるのに評価されません。
で、やっかいなのが。
正しさのほうは、毎日タイムラインに流れてきます。いいねの数まで見えます。
結果のほうは、どこにも書いてないんですよ。
だから、こうなります。
記事で読んだ「いい設計」「いいテスト」を、そのまま現場で求められてることだと思ってしまう。
で、こうなった人が次にやることって、だいたい決まってるんですよ。
デザインパターンを覚えた。
よし、これを使える場所を探そう。
クリーンアーキテクチャを学んだ。
よし、これを現場に当てはめよう。
で、これを現場に持っていくとどうなるか。
「いや、うちの今の状況見えてる?」
「そんなのより、もっとやることあるでしょ」
聞いてもらえないんですよ。
で、こう思います。
なんだこの現場、技術に関心がある人が一人もいない。
じゃあ転職するか、となって面接で同じ話をします。
でも、相手はしっくり来てなさそう。
結果、転職先が決まらない。
フリーランスなら、高単価もフルリモートの案件も通らない。
なんでだ、と。
技術記事も読んで、詳しい人の意見も取り入れて、必死でやってるのに。
これ、リアルで起きてる人めちゃくちゃいます。
「正しさ」だけを追いかけて、「現場の結果」を置いてきた人の行き先です。
で、何がまずかったかというと、順番なんですよ。
覚えたものを当てはめる場所を探してるので、現場が今困ってることとは関係なく始まります。
知識として知っておくのは、めちゃくちゃ大事です。
ただ、先に見るのは現場のほうなんですよ。
ネットで流れてきた話を、そのまま正解として持ち込まない。
これ本当にうちの現場に入れて大丈夫なのか。
そこを自分で考えて決める。
で、これ、キャリアの話とまったく同じです
転職したい時とか、案件を取りたい時に、エージェントと話しますよね。
そこでこんなこと、言われたことないですか。
「この言語は、経験3年ないと厳しいですよ」
これ、間違ったことを言ってるわけじゃないんですよ。
経験年数で人を選ぶ現場は、実際にあります。
そこをずっと見てきた人にとっては、本当の話なので。
ただ、現場が変われば常識も変わります。
そもそも採用基準が真逆なので。
SIerやSES、受託開発会社は、過去を見ます。
何年やってきたか。
何の言語を触ったか。
自分たちでサービスを作ってる会社、いわゆる自社開発は、未来を見ます。
入ってもらったら、何が良くなるか。
うちが今困ってることを、分かってくれるか。
過去か、未来か。
見てる方向が、そもそも逆なんですよ。
だから同じ「経験3年」でも、片方では足切りに使われて、片方では話題にすら出ない。
つまりそのエージェントは、嘘をついてるわけじゃなくて。
自分が見てきた現場の常識で、話してるだけなんですよ。
これ、SNSで流れてくる技術の話とまったく同じ形です。
どっちも、誰かの現場の正解なんですよ。
悪気があって言ってるわけじゃない。
ただ、あなたが行く現場を見てはいない。
答えより先に、確かめるものがあります
技術の話でも、キャリアの話でも、やることは同じです。
その答えは、どういう前提の上で正しいのか。
そして、自分の現場はその前提と同じなのか。
これ、難しいことじゃないです。
今いる現場が何で困っていて、そこに時間を使うと何が良くなるのか。
それだけ見ればいいので。
僕、テストが1本も入ってない現場にいたことがあるんですけど。
その時に提案したのは、「クリーンアーキテクチャでやりましょう」じゃないです。
毎回手でポチポチ確認してるのが時間かかってるから、そこだけ一つずつ書いていきませんか。
最低限から、でいいので。
これだけです。
きれいな設計の話は、1個もしてません。
その現場が今いちばん困ってることに乗ってたから、通っただけです。
こういうのを考えてる人が、現場で「この人に聞こう」って頼られるようになります。
新しい言語を覚えた人じゃなくて。
そして、ここがAIではなく、まだ人間に残ってる価値です。
前提が自分の現場に合ってるかどうかは、AIは判定してくれません。
というか、そこしか残らないと思ってます。
最後に
次に何かを勧められた時。
技術でも、キャリアでも。
いったん、こう聞いてみてください。
それ、どういう現場の話ですか、って。
たぶん、返ってくる答えのほとんどは、あなたの現場の話じゃないです。
ただ、ここまで読んで思いませんでしたか。
じゃあ自分の現場が今何で困ってるかなんて、どうやって分かるんだと。
僕も最初は分からなかったです。
技術のことしか見てなかったので。
ここ、実はやり方が決まってます。
見る場所と、順番があるんですよ。
センスもいらないし、新しい技術も1個も足さなくていいです。
そのへんは、メルマガのほうで書いてます。
コメント