QA不要論に、エビデンス文化のほうから返事をする

「QAって、もういらないんじゃないですか」と言われて、たぶん半分は同意できるんですよね。

AIがテストコードを書いて、AIがブラウザを動かして、AIがレポートを整形してくれる時代になりました。手で叩いていた工程は、確かに半分くらい持っていかれている気がします。「QAエンジニアという肩書き、5年後に残ってますか」と問われたら、正直に言って「半分残ってないかも」と思っています。

ただ、残り半分は、自分はどうしてもこっち側にいたいなと。

これは反論ではなく、返事です。QA不要論にうなずきながら、それでも譲れない一点を、エビデンス文化のほうから書いてみます。説明責任、というキーワードで。

古いエビデンス文化を、まず先に捨てる

スクショ500枚をExcelに貼って、ハンコ欄をつくって、メールで承認をもらう。あれはもう、要らない。

リリース判定会議のために、テスト結果のスクショを延々と貼り続けたExcel。ファイル名に「_最新」「_v3_最終_本当に最終」が並ぶシートを開いて、押印欄が空いている箇所を確認する作業に、何の価値があったのかと。

ああいう運用をいまやる気にはなりません。形式が肥大化して本質が見えなくなった典型で、AIに自動化してもらえるなら喜んで渡したい工程です。

ただ、ここで一つだけ立ち止まりたいんですよね。

あれをエビデンスと呼んでいたから、自分たちはAIに奪われる気がしてしまうんじゃないか、と。

スクショを貼る作業は、エビデンスの本質ではなくて、エビデンスの「形式」でしかなかった。形式は時代に合わなくなったら捨てればいい。捨てるのを躊躇する理由はないはずです。

問題は、形式を捨てたあとに、何が残るのか。残るものこそが、説明責任を支える本体だったんじゃないか、という話です。

エビデンスの本質は「説明責任の認証コード」だった

エビデンスって、何の証拠だったんだろう、と最近よく考えます。

「テストをやった証拠」と説明されることが多いけれど、たぶんそれだけではないんですよね。テストをやったかどうかなんて、AIに聞けばログから即答してくれる。そんなものを残すためだけにスクショ500枚は要りません。

エビデンスの本質は、もう一段深いところにあったと思っていて、それは 「その判断が正しいと第三者に説明するための認証コード」 だったんじゃないかと。

「リリースしていい」という判断には、必ず根拠がいります。①誰が ②何を根拠に ③どの基準で その判断をしたのか。この3つが再現可能な形で残っていれば、半年後に問われても答えられる。残っていなければ、答えられない。それだけの話なんですよね。

トレーサビリティも、同じ構造をしています。要件→テスト設計→テスト結果→バグチケットが双方向に辿れるという性質は、面倒な手続きじゃなくて「未来の自分への申し送り」だった。半年後の自分が「なぜこのテストを書いたのか」「なぜこの仕様でリリースしたのか」を辿れるかどうか、それを担保するための線でした。

ほんで、こう考えると見え方が変わってきます。

エビデンスは過去のためじゃなく、未来に問われたときのための認証コードだ。

形式（スクショ・ハンコ・Excel）は捨てていい。けれど認証コードとしての機能、つまり説明責任を果たす規律のほうは、5年後も10年後も必要なんじゃないかと。

AIは説明責任を負えない、という静かな事実

AIに「これでリリースしていいですか」と聞いて、AIが「はい」と答えたとして、それは説明責任を果たしたことになるのか。

たぶんならない。

AIはテストを書けます。テストを実行できます。結果を整形して、エビデンスらしき何かを出力することもできる。網羅性のあるテストケースだって、JSTQBの語彙や観点リストさえ渡せば一晩で量産してくれる。実行の速さ・いい感じのものと量産する力でいえば、もう人間が手で勝てる時代じゃないんですよね。

ただ、AIには引き受けられないものが一つあります。

それが 判断の責任 です。

リリース後に重大な障害が出て、お客様に説明する場面を想像してみるとわかりやすい。「なぜリリースを許可したのか」を問われたとき、責められる主体になれるのは人間だけです。AIに「お前のせいだ」と言ったところで、AIは責められない。組織のなかで責任を引き受けるという行為は、責められうる立場の人間にしかできない、はず。

だから「リリース判断の根拠を残す」という行為だけは、人間側に残り続けるんですよね。

ここでQA不要論の前提が、静かに割れます。

不要論はどこかで「AIが全部やってくれる」を想定しているけれど、実際には「AIが全部やる」と「AIが全部の責任を負う」は別物です。前者は技術の話、後者は社会と組織の話。後者は当面、人間側でしか解けません。

AIは速い。でも、責められない。

ただ、勘違いはしたくないんですよね。「だからQAエンジニアは安泰」という話には、ならない。説明責任を引き受けられる人は、別にQAじゃなくてもいいわけです。エンジニアでもPdMでも、誰でもいい。ただ、いまQAという職能にいる人は、この本質を継承するのに最も近い場所にいる、とは思っています。

だからQAは"転進"する

テストを手で叩いて品質を担保する仕事は、たぶん半分くらいAIに渡せます。残り半分のうち、自分が握っていたいのはここだ、という話を3つ書きます。

一つ目は、判断の根拠を設計すること。何をテストすれば「リリースしていい」と言えるのか、その認証コードを先に設計する仕事です。実装する前に、リリースを許可する条件を言語化する。AIにテスト生成を任せれば任せるほど、人間側に残ってくる仕事だなと思っています。

二つ目は、トレーサビリティを設計すること。要件⇄テスト⇄結果を結ぶ線を、AIが書いても切れないように張っておく仕事。AIはコードを書く、AIは結果を返す、けれど「この結果はどの要件のどの観点に紐づくのか」を保証する設計は、人間側でやらないと崩れる気がしています。AIの出力スピードが上がるほど、トレースの線は引きづらくなるんですよね。

三つ目は、責任を引き受けられる範囲を明示すること。「ここまでは見た／ここから先は見ていない」を言える、という能力です。曖昧に「全部見た」と言うほうが責任放棄に近くて、明確に範囲を切ったほうが、説明責任は果たせる。

旧来のQAが「実行者」だったとすると、これからのQAは「認証コードの設計者」になる、という整理がしっくりきます。実行はAIでいい。設計と説明は人間側に残す。これがいま、自分が考えている転進の方向性です。

（と書きながら、自分もまだ移行の途中なんですけどね。書きながら整理している節があります）

継承するのは、たぶん文化のほう

QAという職能の名前は、5年後に残っていないかもしれません。でも、説明責任を文書で残す文化は、絶対に残ってほしいなと。

ふり返ると、職能の名前ってけっこう変わってきているんですよね。テスター、テストエンジニア、QAエンジニア、品質エンジニア。Quality Assurance から Quality Assistance に読み替えようという話も最近はちらほら出てきます。名前は時代に合わせて変遷していくもので、たぶん今後も変わり続ける。

変えてはいけないのは、名前じゃなくて、説明責任を果たすために残す、という規律のほうだと思っています。

ここまで書いていて、ふと思ったんですけど、スクショ500枚を貼っていた人たちも、悪意でやっていたわけじゃないんですよね。あれは「未来の誰かに、なぜリリースしたのかを説明できるように」やっていた仕事で、規律としては正しかった、はず。形式が時代に合わなくなっただけ。

形式は捨てていい。規律は引き継ぐ。

それが、自分が考える転進の意味です。古い文化の悪い部分を全部捨ててから、本質だけを次の時代に持ち込む。そういう仕事なんだろうなと。

QA不要論が広がるのは、たぶん健全なことです。

不要論は、QAという職能を再定義する圧力で、自分はわりと歓迎しています。古い形のままで生き残ろうとするほうが、たぶん危ない。

その圧力に対して、自分は「認証コードの設計者」として残るつもりでいます。テストの実行はAIに渡して、説明責任を果たすための設計の側に立つ。形式は捨てて、規律を引き継ぐ。

同じような景色を見ている人がいたら、たぶん同志です。

誰かに問われたとき、ちゃんと答えられる側にいたい。それだけです。