「プログラマーの素質はなさそうだから、テストやって」。そう言われた瞬間は、悔しい。でも、十年後はわからない。
学生時代、プログラムが好きだったかもしれない。自分の得意な言語で、いろいろ作ってきた自負があるかもしれない。
この言語なら誰にも負けない。省略するツールもいくつも持っている。きっと、このツールを使えば、入社してからも楽に働ける。そんな夢物語を持っていないだろうか。
でも、配属されると現実はこうだ。
「今回の言語はこれね」。ちなみに前回は違う言語だった。
このシステムはAPI。このシステムは画面側。このお客さんはリプレースをケチっていて、いつの時代のバージョンなのかもよく分からない。そんな現場ばかりだ。
依頼される仕事も、最初から大きなシステムを任されるわけではない。
「ここの画像取り込みのところ作って」
「メインビジュアルの下にカルーセル作って」
「この一覧にページャー付けて」
そんな部品の作成が主な仕事になる。もちろん、それも大事な仕事だ。
でも、それを十年続けて、いざ独立しようとしたときに——プログラムしか書けない。SEはできない。指示された部品を作ることしかできない。そんな、なんとも残念な経歴になってしまうことがある。
しかも、簡単なプログラムはAIが書く。新しい言語やフレームワークが出てくれば、市場はまた若い人たちが持っていく。
では、テストエンジニアはどうか。
テストエンジニアは、言語に縛られにくい。
単体テスト。
結合テスト。
総合テスト。
対象のシステムが変わっても、見るべきものの本質は大きく変わらない。「何を確認するか」の引き出しは、テストパターン集のように体系化できる。言語やフレームワークが変わっても、そのパターン自体は使い回せる。
この機能は本当に必要な動きをしているのか。
他の機能を壊していないか。
仕様に書かれていない使い方をされたとき、耐えられるのか。
ユーザーが困る場所はどこか。
リリース後に火を噴くとしたら、どこか。
そこを疑える人は、強い。
「テストやって」と言われた日
むしろ、入社して早い段階で、「プログラマーの素質はなさそうだから、テストやって」と言われた人のほうが、将来役に立つかもしれない。
言われた瞬間は、悔しいと思う。自分は開発者として見られなかった。コードを書く側ではなく、確認する側に回された。そんなふうに感じるかもしれない。
でも、十年後は分からない。
言語は変わる。見るべきものは残る。
プログラムを書く仕事は、言語に縛られる。フレームワークに縛られる。案件に縛られる。新しい技術が出るたびに、また覚え直しになる。
一方で、テストは違う。画面が変わっても、言語が変わっても、業界が変わっても、見るべきものは残る。
これは本当に使えるのか。
ここでユーザーは迷わないか。
この修正で、別の場所を壊していないか。
仕様に書いていない操作をされたら、どうなるか。
そういう疑い方は、どの現場でも使える。
だから、テストに回されたことは、必ずしも負けではない。むしろ、コードだけを見る世界から、システム全体を見る世界に早く出されたのかもしれない。
何を疑うかは、まだ人間の仕事だ。
AIはコードを書く。
AIはテストケースも出す。
AIはそれっぽい答えも返す。
でも、何を疑うべきかを決めるのは、まだ人間の仕事だ。AIが生成したテスト項目書をそのまま信じると現場が止まる理由を書いた記事がある。→ AI生成テスト項目書の落とし穴
だから、これからの新人は、ただのプログラマーを目指さなくていい。目指すなら、検証できるエンジニアだ。