最近、開発の現場では 「まずAIに任せてみよう」という空気 がかなり強くなってきました。
- コードを書く。
- 既存のコードを調べる。
- テストを書く。
- レビューする。
- 障害の原因を調べる。
- ドキュメントを書く。
少し前まで人が時間をかけていた作業のかなりの部分を、AIが手伝えるようになっています。
これはかなり大きな変化です。
自分も、使えるところはどんどん使えばいいと思っています。
実際、数時間かかっていた作業が数十分で終わることもあるし、コードを読ませて影響範囲を調べたり、Test Codeを書かせたり、そのまま失敗原因を追わせることもできます。
ただ、最近少し引っかかることがあります。
AIでできることが増えた結果、「今までの前提も全部変わった」と考えすぎていないだろうか。
ということです。
もちろん、見直した方がいいものはたくさんあります。
AIほど大きな変化なら、今までのやり方を疑うのは自然です。
ただ、AIが便利になったことと、システムが持っている性質そのものが変わったことは、同じ話ではないと思っています。
作ること自体は、かなり楽になった
以前なら、要件を確認して、コードを調べて、実装して、テストして、失敗したら直す。
その一連の流れを、人がかなり手を動かして進めていました。
今は、この多くをAI Agentに任せられます。
しかも、一つの作業が終わるのを待たずに、複数のAgentへ別々の仕事を渡して並行して進めることもできます。
なので、
昔からこのやり方だから、これからも同じでいい
とは自分も思っていません。
変えられるところは、変えればいい。
でも、作りやすくなったことと、仕組みそのものが変わったことは別
AIがコードを書いてくれるようになっても、システムそのものが持っている性質まで変わるわけではありません。
Distributed Systemなら、AIが実装してもNetwork Failureはなくなりません。
Database周りのコードを書いてくれても、TransactionやConsistencyを考えなくてよくなるわけではない。
Securityの実装を手伝ってくれても、守るべき境界そのものがなくなるわけでもありません。
AIによって「作ること」はかなり楽になりました。
でも、その仕組みが持っている制約まで一緒になくなったわけではない。
この二つは、分けて考えた方がいいと思っています。
テストでは、この違いが分かりやすい
例えばE2E Testです。
AIによって、E2Eを書くのはかなり楽になりました。
「この画面でログインして、このボタンを押して、最後にこの表示を確認して」
と伝えれば、かなりの部分をAIが書けます。
テストが壊れたときも、修正を手伝ってくれる。
エラーの原因を調べることもできます。
ここは以前と比べて明らかに変わりました。
ただ、E2Eそのものはどうでしょうか。
E2Eでは、かなり多くのものを通って結果を確認します。
AIがTest Codeを書いてくれたとしても、
- Browserを起動する
- Networkを通る
- Backendが動く
- Databaseに接続する
- 外部Serviceに依存する
という構造は変わりません。
だから、
- 実行に時間がかかる
- 環境によって失敗することがある
- 失敗したときに原因を切り分けにくい
- 関係するものが多い分、壊れる場所も増える
という性質も残ります。
E2Eを書くコストは下がった。
でも、E2Eそのものの性質まで変わったわけではない。
ここは分けて考えた方がいいと思っています。
「AIが直してくれるから大丈夫」なのか
壊れてもAIが直してくれる。
Failureの原因もAIが調べてくれる。
だったら、今までよりE2Eを増やしても問題ないのでは。
そう考えるのも分かります。
実際、保守コストはかなり下がると思います。
ただ、自分はそれだけでテストの置き場所を決めるのは少し違うと思っています。
例えば、Integration Testで十分確認できる仕様を、E2Eで確認することもできます。
AIが書いて、壊れたら直して、失敗原因まで調べてくれる。
それでも毎回System全体を通して確認する必要があること自体は変わりません。
だったら最初から、
もっと速くて、安定していて、失敗した理由も分かりやすい場所で確認できないか
を考えた方がいい。
AIが便利になったからといって、「どこで確認するのが一番いいか」まで考えなくてよくなったわけではありません。
AIは、良い設計だけを速くするわけではない
これはテストだけの話ではありません。
AIは良い設計も速く実装できます。
でも、悪い設計も速く実装できます。
不要な仕組みも作れる。
似たようなTestを大量に作ることもできる。
必要以上に複雑なコードも作れる。
AIが速いほど、最初の判断が間違っていたときも速い。
少し皮肉ですが、そういう面もあります。
なので、
AIがあるから、設計をそこまで考えなくていい
というより、
AIが速くなったからこそ、最初の判断が前より重要になった
くらいに考えています。
「誰が書くか」と「どこで確認するか」は別
テストでは、
Unit / IntegrationはDeveloper
E2E / Test AutomationはQA
のように分けて考えられることがあります。
実装する人の役割としては、これでもいいと思います。
Unit TestをDeveloperが書くのは自然です。
Integration Testも、コードを理解しているDeveloperが書いた方がいい場合は多い。
ただ、
誰がテストを書くか
と、
どこでその仕様を保証するか
は別の話です。
例えば、あるRiskがあったとします。
最初から、
QAだからE2Eで確認しよう
と考えるのではなく、
と考えた方がいい。
Unitで十分ならUnitで確認する。
Integrationが適切ならIntegrationで確認する。
Service間の契約を見たいならContract Testを使う。
本当にSystem全体を通さないと確認できないならE2Eを使う。
そのRiskを、できるだけ速く、安定して、失敗した理由が分かりやすい場所で確認する。
自分はそこを先に考えたいです。
誰が書くかは、そのあとでもいい。
AI時代だからこそ、Test Strategyより先にRiskを見る
ここまで書くと、
つまりTest Pyramidを守ればいいということ？
と思われるかもしれません。
でも、そういう話ではありません。
Test Pyramid、Testing Trophy、Test Honeycomb。
あるいは、Systemの特性に合わせてContract TestやComponent Testを厚くする構成。
どれも、Systemの特性や組織の開発スタイルによって合う・合わないがあります。
Frontend中心ならComponent Testが多くなるかもしれない。
MicroservicesならContract Testが重要になるかもしれない。
Data Pipelineなら、また別の保証方法が必要になる。
Legacy Systemでは、最初から理想的なLayer構成を作れないこともあります。
なので、
Pyramidの形になっているから正しい
Trophyだから今っぽい
E2Eが多いから悪い
みたいに、図の形だけで判断したいわけではありません。
自分が見たいのはもっと単純です。
そのRiskを、どこで確認するのが一番合理的か。
大事なのは、最初に戦略の名前を決めて、そこにTestを当てはめることではないと思っています。
先にRiskを見る。
そのRiskを、できるだけ速く、安定して、失敗したときに原因が分かりやすい場所で保証する。
結果としてPyramidに近くなることもあるし、Testing Trophyに近くなることもある。
Systemによっては、どちらにもきれいに当てはまらないかもしれません。
それでいいと思っています。
AIが登場したからといって、図の名前を入れ替えるだけではあまり意味がないと思っています。
見たいのは、
それぞれのLayerを選ぶときの前提が、本当に変わったのか。
そこです。
ベストプラクティスは見直す。でも全部捨てる必要はない
新しい技術が登場したら、これまでの常識を疑う。
これは大事です。
AIほど大きな変化なら、なおさらです。
ただ、
これまでの常識を疑う
ことと、
過去の知見を一度全部捨てる
ことは違います。
Best Practiceには、そうなった理由があります。
昔の技術的な制約から生まれたものもある。
何度も運用で失敗した結果、そうなったものもある。
もちろん、その前提自体がなくなれば変えればいい。
ただ、その前に一度、
なぜ、このやり方がBest Practiceと呼ばれるようになったのか
を見る。
その上で、
AIによって、その理由は本当になくなったのか
を考える。
自分はそれくらいでいいと思っています。
AI時代ほど、変わっていないものも見る
AIについて話していると、
「何ができるようになったか」
にどうしても目が行きます。
Codingが速くなった。
Testも作りやすくなった。
Reviewも手伝ってくれる。
調査も速くなった。
使えるものは、使えばいいと思います。
ただ、できることが増えたことと、何をやるべきかが変わったことは同じではありません。
依存関係は残るし、障害も起きる。
Networkが遅れることもあれば、外部Serviceが落ちることもある。
Testには実行時間があるし、品質Riskそのものがなくなるわけでもありません。
AIが登場したからといって、それらまで一緒になくなったわけではありません。
おわりに
AIによって、Software Developmentの前提はかなり変わりました。
だから、これまでのやり方を見直すことには賛成です。
自分も、今まで人がやっていた作業をAIに任せることはかなり増えました。
ただ、
「AI時代だから全部見直そう」
という話になったときは、一度だけ考えるようにしています。
何が本当に変わったのか。
逆に、まだ何が残っているのか。
AIで今までできなかったことができるようになったなら、もちろんやり方は変えればいい。
でも、昔からある問題まで全部なくなったことにする必要はないと思っています。
AIは良い設計だけを速くしてくれるわけではありません。
正しい方向にも、間違った方向にも、前より速く進めるようにしてくれます。
だから、全部を白紙に戻すというより、
変わったところは変える。
まだ残っている制約は、そのまま見る。
今のところ、自分はそのくらいに考えています。