LO
ソフトウェアテスター/QAエンジニア
利用者より先に、そのソフトがどう壊れるかを突き止める——そして、出してよいかどうかを言う人である。
これは職を失う確率ではない。その職の業務量のうちどれだけが自動化にさらされているかと、導入が実際にどこまで進んだかを一つの値に合わせたものであり——同じ一つのものさしで職業どうしを比べるためだけに使える。それ以外には使えない。
製品開発のチームで働く手動のテスターとテスト自動化のエンジニアに向けて書いている。安全が絡む認証試験(医療、自動車、航空)やゲームの検証は事情が異なる。
実際に何が変わりつつあるか#
分析の単位は肩書ではなく業務です。職が置き換えられるのではなく、その業務の構成が移ります。
これはあなたの仕事ですか。そう言えば、このページはあなたの持ち分に絞られます。
肩書とは、まとめ買いされた業務の束であり、同じ束を持つ人は二人といません。どこにも送られません——このブラウザの中に留まります。
手動の回帰テスト
自動化されつつある≈ 本サイトの推定リリースのたびに同じ流れをたどり、これまで動いていたものが壊れていないことを確かめる。
台本に沿った回帰テストは以前から自動化可能だった。変わったのは、平易な言葉の説明から実際の画面を操作でき、画面が変わったら自分の台本を直せるようになったことであり、それによって、チームを手動のテストに留めていた保守の負担が消えた。これはたいていの検証の職で最も大きな時間の塊であり、それが速く失われつつある。
これはたいていの検証の職で最も大きな時間の塊だと、はっきり言っておく。残りの業務のどれも、その一週間を埋めていた人たちを吸収できるほど大きくない。
テストケースと自動化を書く
自動化されつつある≈ 本サイトの推定要件をテストケースに変え、テストケースを、統合の流れのなかで走る台本に変える。
仕様から、あるいはコードそのものからテストを生成することは、コード生成の道具の最も効く使い方の一つであり、一つの開発期間をかけて用意していた網羅が、いまや午後のうちに現れる。ただし生成されたテストは、生成されたコードと同じ意味で浅い——コードが何をすべきかではなく、コードが何をしているかを確認してしまう。だからこそ次の業務のほうが重い。
生成されたテストは、コードが何をすべきかではなく、何をしているかを確認してしまう。欠陥ではなく網羅率で測っているチームは、この業務はもう解けたと結論する。それは測り方の問題であり、割を食うのはテスターである。
探索的・敵対的なテスト
いまも人が主導✓ 証拠に基づく誰も仕様に書かなかったことを試す——変な入力、競合状態、手順2より先に手順3をやる利用者。
生成されたテストは仕様かコードから導かれるので、その死角をそのまま受け継ぐ。誰も想像しなかった壊れ方を見つけるには、現実の利用者と現実の系がどう振る舞いを誤るかについての頭のなかの模型が要り、それはこの製品とこの領域での経験から築かれる。道具は探す範囲を広げる。どこを見るかという仮説のほうは今も人のものであり、そして高くつく不具合はそこにある。
どこを見るかという仮説は、いま消えつつある回帰テストの仕事をやってきたことで築かれる。この業務を守っているのは、もはやその流れが生み出さなくなった経験である。
出してよいかを決める
いまも人が主導✓ 証拠に基づく残っている不具合、危険、期日、事業を量り、可か否かを言う。
これは組織的な結果を伴う責任の判断であり、チームがそれを委ねたがる気配はまったくない。画面は状態を要約する。この版、この顧客層、この一週間がどの程度の危険を背負えるかという一声は、チームがその判断を信じている人が下す。
多くのチームでは、この一声はテスターではなく開発の管理職のものである。そうである限り、これが守っているのは他人の職である。
モデルを抱えた系をテストする
新しい業務≈ 本サイトの推定出力が一意に定まらないソフトウェアを評価する——評価用のデータ集合をつくり、振る舞いの劣化を捕まえ、有害な出力を試す。
新しい製品の多くは輪のなかにモデルを抱えており、固定の出力を突き合わせる形ではテストできない。評価の設計、敵対的な指示、振る舞いの回帰検出は新しい分野であり、やっている人は少ない。そして検証の構え——壊れていると思え、どう壊れているかを突き止めろ——はそのまま移る。
やっている人が少ないのは、いまの話である。この分野は若く、最終的にどれだけの大きさになるかは分からない。そして検証ではなくモデルをつくるチームの内側に収まってしまう可能性もある。
ここで効いてくる技術はどれか#
四つの別々の signal です。意識して足し合わせていません——二つの技術にさらされている職が、二倍さらされているわけではありません。
ここに至るまで#
この指数は動かない数字ではありません。これは、ChatGPT 以降の能力の検査点ごとに、それがどこにあったはずかです——再構成されたものであり、そう明記しています。
● この職業についての2件の検証済みの出来事を、それが起きた日付の上に置いてあります——印の近くの線は、確かめられる何かに固定されています。
台本どおりの回帰テストは2022年よりずっと前から自動化できたので、基準線は高い。曲がるのは2024年下半期と2025年上半期の対のところであり、それはまさにコンピュータの操作についてである——平易な言葉の記述から実際の画面を操作するエージェントが、チームに手作業を続けさせていた台本の保守の負担を取り除いた。
平らな線は、安全の予測ではありません。それは、自動化がこれまでどの業務に届いたかを言っています——ここで最も動かなかった職業は、制約が身体的か規制によるものであり、そしてそのどちらも変わりうります。
最近の変化#
米英欧の大企業の上級エンジニア200人による自己申告の調査であり、しかも報告書を出しているのは Lightrun、デバッグの道具を売っている会社である。つまり発見と製品が同じ方向を指している。そこで引かれている Amazon の障害(2026年3月2日と5日。承認を経ずに投入されたAI支援の変更が原因とされ、その後335の系にわたる90日間のコード安全の立て直しが行われた)は独立に報じられた出来事だが、割合のほうはそうではない。対象は企業向けソフトウェアのみである。
失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。
一社における、既存の単体テストの改善であり、ビルド/合格/網羅の各条件でふるいにかけている。生成されたケースの75%がビルドでき、57%が安定して通り、25%が網羅を増やした。会社自身が書いた論文であり、日常の開発の流れのなかでの利用ではなく、期間を区切った集中期間での設定である。
実際の場での小規模な試行。導入の条件が試されていることを教えてくれるのであって、それが成り立つことを教えてくれるのではない——だから一件の試行は単独では決して足りず、独立した二件で足りる。
これがあなたにとって何を意味するか#
手動のテスターとして入ることは、このサイトのなかで最も弱い入口である。そこが最も速く消えている業務だからである。代わりに、敵対的な構えと新しい分野から入ること——誰も仕様に書かなかったことを壊せるようになること、そしてモデルを抱えた系を評価できるようになること。そこには経験のある人がほとんどおらず、チームは人を採っている。コードが書けることは、いまやこの職のなかの専門ではなく前提である。
一週間の大半が回帰テストと台本の保守なら、この職はあなたの足元で統合されつつある。向こうが動かす前に、自分から動いたほうがよい。あなたの本当の資産は、この製品がどう壊れるかについての頭のなかの模型である。それを、探索的なテスト、出荷の判断、そしてあなたのチームがほぼ確実に足しつつあるモデル由来の機能の評価に変えること。それらは上級の位置であり、先に名乗り出た人から埋まっていく。
選べる道#
四つの方向。それぞれに現実の制約と、今週試せることが一つ付いています。いまのまま続けることも正当な選択です——ただし、選ばれたものでなければなりません。
テストを実行する側から、品質を引き受ける側へ
「十分にテストした」とは何かを決め、出荷の判断を握り、探索的な仕事を引き受ける人が要る。その役割は残る。実行する役割のほうは残らない。
テスターの「否」をチームが受け入れることが要り、それはすでに築いていなければならない信用に依る。
今週、既存のテストにも生成されたテストにも捕まらなかったであろう不具合を一つ見つけ、どうやってそれを思いついたかを書き残す。その文書が、あなたの職務記述書である。
モデルを抱えた系の評価に絞る
新しく、希少で、テスターがすでにやっていることのすぐ隣にある。モデル由来の機能を出すチームは、それが壊れていると前提する人を必要としている。
手持ちにないかもしれない統計の知識が要り、合否が一意に定まらないことへの耐性が要り、道具立てもまだ未熟である。
自分の製品のモデル由来の機能を一つ取り、失敗させる・妙な振る舞いをさせることを狙った入力を二十通り書く。走らせる。そして、ほかの不具合と同じやり方で報告する。
テスト開発、あるいはプラットフォームエンジニアリングへ
チーム全体がテストできるようにする仕組み、環境、道具立てをつくることは、安定した需要のある開発の仕事であり、何がどう壊れるかというテスターの知識を使う。
これはソフトウェア開発の職であり、そのように評価される。コードで試されると見ておくこと。
チームのテストの流れのなかで不安定な部分を一つ選び、きちんと直す。不具合を見つけるよりそちらが楽しかったなら、この道は本物である。
よくある問い#
手動でテストを実行することは、そのとおりであり、しかも速い。品質という営みのほうはそうではない——系がどう壊れるかを想像し、出してよいかを決め、そして次第に、振る舞いが一意に定まらないソフトウェアを評価する人が要る。その最後のやり方を知っている人は、まだほとんどいない。この職はテストを実行することから危険を引き受けることへ、固定の出力を突き合わせることから振る舞いを評価することへ移りつつある。その移動をやり切った人は、かつてのテスターより価値がある。やらなかった人は、自分の周りでこの職が統合されていくのを見ることになる。
信号は、今四半期、自分のチームで誰が回帰テスト一式を書いているかである。その一式が生成され、画面が変わったあと自分で直るようになったとき、たいていの検証の職を支えていた時間の塊は消えている——それが動いた具体的な能力であり、どの報告書より先に、自分たちのリポジトリのなかで目にすることになる。
手動の回帰テストとテストケースを書くことであり、自動化と印がついている二つである。手動の回帰テストだけでも、たいていの検証の職で最も大きな時間の塊である。探索的なテストと出荷の判断はそうではないが、そのどちらも、回帰テストが一週間を埋めていた人たちを吸収できるほど大きくない。
評価用のデータ集合、振る舞いの回帰検出、敵対的な指示——本物の、そして伸びている分野であり、検証の構えはそのまま移る。正直な留保は、最終的にどれだけの大きさになるかを誰も知らないほど若いこと、そして検証ではなくモデルをつくるチームの側に人が置かれる形に落ち着くかもしれないことである。
これを目指して学んでいますか
この専攻がここへ通じています。そのページでは、どの能力が持ち越せて、卒業生に何が欠けがちかを分解しています。
これについて書いたもの#
この文章は、このページが持っているのと同じ記録から論じており、その一節一節が、何の上に立っているかを名指ししています。
方法と出典#
- 評価日
- 2026-09-10
- 業務の判断の根拠
- 証拠に基づく2項 · 本サイトの推定3項 · 証拠が足りない0項
- 検証済みの出来事
- 2