山下さんとの往復書簡、第四回目（そして私のパートの2回目）の記事となります。 前回が画鋲付き（！）とは気づかずに答えていました・・・。
今回の往復書簡は、当然ながら一つ前の記事を書いたのが自分ではないので、ひとりで書いているときと比べて注意ぶかく読んだうえで続きを書こう、という努力をしています。そうすると、繰り返し読むうちに考え方や文体の違いがだんだんと見えてきて、単純に直接会ってディスカッションしているときとはまた違った趣があります。
さて、話を本題に戻しまして。前回の山下さん記事の内容に対するコメントかつ感想かつ読者の方向けの補足、から入っていければと思います。
自動化は当たり前になったが、「どうテスト実行を自動化するのか」にとどまっているのでは
これは完全に同意です。ふと思い出して、過去の自分の発表資料を見返してみたのですが、同様の趣旨のことを言っていました。（※念のためお伝えしておきますがマウンティングではありません。「ここ4, 5年、引き続き、そのような傾向があるみたいです」といいたいのです。）
以前の、テスト自動化が今ほど当たり前でなかった頃には、小手先の自動操作ができれば技術力があるっぽく見えていた時期があったように思います。（そしてその時代に、小手先の自動操作ができることで先行者利益を得ていた自覚もあります。）
一方自動化が当たり前になってきた今では、小手先の自動操作だけでは価値を発揮しづらく、また市場価値的な意味でも特別な強みとは言い難い状態です。山下さんがおっしゃるような、テスト自動化に関するより大事なところがわかっていて、かつ組織の中で自動化を適切に取り入れ、推進できるレベルが求められています。そのレベルになってようやく「テスト自動化ができます」と言える、のが今なのではないでしょうか。ひとことで言えば「当たり前になった結果、ハードルが上がった」と言えるでしょう。しかしテスト・QA界隈を超えてソフトウェア開発の業界全体を見たときに、本当にその上がったハードルを皆が超えているのかと言われると、そうとは限らない。まさに「どうテスト実行を自動化するか」にとどまっていることがまだまだ多いように見えます。主観ですが。
ただし、これは必ずしも悪いことではないと考えています。合理的なテスト計画と設計に基づき～と書いてくださっていたようなレベルまで皆が成熟するには、小手先の「ちょっとできます」を通過することになるはず。手を動かす経験、たとえば「自動テストを作りすぎてメンテが辛い」などの経験があって初めて、本当の意味で理解して戦略を立てられるという面もあると思います。
まだまだ成熟しきっていないという指摘は正しい反面、当たり前のレベルが上がって、みんなが「小手先レベル」に来た。全体としては確実に進化はしていて、ほんとうに大事な部分の手前までは来た、という捉え方もありそうです。前は50点取れたらスゴイと言われていたけれども、今は80点を取らないとスゴくない。けどみんな70点を取れるようになっている。こんな感じでしょうか。
冷静な視点とその必要性
これも、自動化の成熟度の話とセットだと思っています。
小手先の自動化で「わかったつもり」状態にとどまっていると、山下さんのおっしゃっている「冷静な視点」で物事は見られないと思います。自分の知識や経験に対して、眼の前のひとつの物事があまりに大きいと、熱狂したり、必要以上に慌てたりしてしまいます。視界の８割をひとつのこと（今だとAIがあればテスト自動化できるぞ！など）が占めると冷静でいられません。広く知識と経験があれば視界も広いので、ひとつのものごとが占める割合が少なくなります。
つまり知識と経験があって、小手先でなく、より大事な点について考えられるくらい視界が広がっている人は、熱狂や過剰な期待に陥らずに済みますね。
すこし脱線すると、何かに「意図して熱狂」することも時と場合によっては大事だと思っています。視界のメタファでいえば、視界の広い・狭いを自分で意識的にコントロールできる人は、健全に熱狂できるということです。もちろんそれは広い側の視界を体得している人にしかできないことなので、どちらにせよ知識と経験をもって視界を広げておくことは大前提です。
と、こういったコメント兼私自身のスタンスや考え方を共有したうえで、また再度バトンを受け取りましょう。
生成AIが前提の開発において、自動テストアーキテクチャにはどのような変化があるか
まず目先の変化としては、アーキテクチャの構造は大きく変わらず、その構成要素がAIによって効率化される、あるいはAI向けに置き換わるといったことはありそうです。
gTAAでいえば、テスト実行レイヤーのテストレポート作業に対してAIを使ったり、テスト生成レイヤーでは以前は「手動設計」という部分がありましたがここがAIによる自動・半自動を含むなど、です。
さらに進んだ先でどのような変化があるのか、についても、この質問をいただいて考えてみたのですが・・・実はアーキテクチャの構造はそれほど大きく変わらないかもしれない」という考えに至りました。
理由としては、ISTQBのTAEシラバスが示すように、そもそもベースとして4つのレイヤー（生成・定義・実行・適合）からなるgTAA（汎用テスト自動化アーキテクチャ）があり、それを個別のプロジェクトや組織に合わせて具体化してTAA（テスト自動化アーキテクチャ）を設計する、というステップを踏むからです。ベースにあるgTAAの構造自体が持つ「汎用さ」が、生成AI時代の変化を吸収するため、構造としての変化はほぼ無いのではないか、というのが今のところの予想です。
ここで余談ですが、現状のTAEシラバス日本語訳の元になったバージョンよりも、さらに新しいISTQB側のTAEシラバスが出ています。この新シラバスに出てくるgTAAが、実はすごく簡素になっているんですよね・・・理解のしやすさの面では新バージョンのほうが勝っていると思います。簡素になっているぶん、さらに生成AIによる変化をある意味内包できるようになっているのではないかなと思います。
話を戻すと、gTAA→TAAは自動テストの生成・定義・実行・適応というざっくりとした構成を満たすようなアーキテクチャを作ろう、という考え方なので、生成AIが前提でもここの基本は変わらない、と思われます。
ただ、それだと答えとしては面白くないと思うので・・・少しひとひねりして、異なるテスト自動化アーキテクチャになるとしたらどのような場合か、を考えてみます。。
ここまでの、gTAA->TAAの話は、基本的に「スクリプトテスト」が前提の話です。ということは、スクリプトテストではないテストを自動化して実行するための自動テストアーキテクチャは、また違った形になる可能性がありますね。スクリプトテストではないテストは、例えば探索的テストがありますね。
探索的テスト自動化の論文見ていると、操作の過程の状態や画面表示に対して「バグかどうか」を判断する「Bug Detection Layer」のようなものが入ってきたりしそうです。スクリプトテストだと「期待通り動いたか否か」の判定を行いますが、探索的テストの場合は正解がわからない状態で、おかしいかどうかを判断してレポートする必要があるので、このようなテストオラクルを生成するようなレイヤーもまた、gTAA->TAAがあるとすれば、含まれるのではないでしょうか。
テストエンジニアはソフトウェアエンジニアリングの世界にどのような良い影響を与えうるか
壮大な問いなので、「はたして私が答える資格はあるのだろうか・・・」と思ってしまう面もありつつ。おそらく、ひとつ上の「自動テストアーキテクチャにどんな変化があるか」について考えているとき、私はQAエンジニアの、いわゆる「帽子を被って」答えていたように思います。無意識に。
そこであえて「テストエンジニアは」という聞き方をされている点については、なにか特別な意図があるように（勝手に）感じますね。山下さんが「テスター」にこだわりを持っているのも知っていますし。
そのような前提で、個人的な意見としては、優秀なテストエンジニアは開発プロジェクトにおけるスピードのコントロールができる存在なのではないか、と思っています。
生成AI以前であれば、開発サイクルは速いほうがいいと思われていたはずです。（しかしたら生成AI以降もそう思われているかもしれませんが。）しかし、私は「速ければいいというものでもない」と考えています。
車のレースを例に説明すると、（私も詳しくはないのですが）スピードが速いほうがよいからといって、アクセルを踏みっぱなしではレースには勝てません。速く走るためにはブレーキングも大事になってくるそうです。コーナーをいかに効果的に曲がるか。そのための適切なブレーキのタイミングがあります。
テストエンジニアはこの、ブレーキを用いた適切なスピードコントロールによってソフトウェア開発チームに貢献できると思っています。ブレーキを踏んだその瞬間は確かにスピードは落ちるのですが、その先のコーナーを上手に曲がることができれば、レース全体で見たときには速く走れている。そうした、先や全体を見通す役割として、テストエンジニアの存在意義があるのではないでしょうか。自動テストが当たり前になった、という話も関わってきていて、「スピードを殺さない」自動テストと、「適切にスピードを落とす」手動のテスト、のようなバランス取りが求められそうですね。
と、ここまでの抽象論ではもとの質問に半分くらいしか答えていません。上記の意見は「開発チームやプロジェクト」という目の前の現場に与える影響の話です。ここから、主語を「ソフトウェアエンジニアリングの世界」というマクロなスケールに変えて考えてみます。
スケールが変わっても、テストエンジニアが果たすべき役割は変わらないと私は思っています。それは、ソフトウェアエンジニアリングの世界における一方向への過剰な熱狂に対して、いい意味で水を差し、まさに「冷静な視点」を提供するということです。
たとえば、ロールや考え方が似通った開発者だけで構成されたコミュニティや業界のトレンドがあったとします。そこには強いまとまりや推進力が生まれるかもしれませんが、もし進む方向が間違っていた場合に、自浄作用による軌道修正が行われにくくなるリスクもあります。
だからこそ、異なる専門性や「批判的思考」を持つテストエンジニアという存在が不可欠になります。私たちが日々の開発現場で「ブレーキを踏み、中長期的に走り続けられるチーム」を泥臭く作り続けること。そして、その実践から得られたリアルな知見を発信していくこと。その積み重ねこそが、トレンドに傾きがちな、熱狂しがちなソフトウェアエンジニアリングの世界全体に対して、中長期的な持続可能性という形で良い影響を与えられるのではないでしょうか。具体的に「こうなる！」という未来の形がぱっと出てくるわけではありませんが、業界のバランスを保つ「バランサー」としての役割に、テストエンジニアの存在意義があるのではないかと考えています。
おわりに
山下さんがくれた問いに対するアンサーを考えてみたところ長くなってしまいました。回答になっていればよいのですが・・・
こうして文章を通じてやりとりするのは、直接会話するときのテンポとはまた違っていて、やっているほうとしては大変さと楽しさを同時に感じています。読者の皆さまにもそのあたり伝わっていたら嬉しいです。
