AIはあなたのコードを作成できる。あなたの思考を誰が検証しているのか？

テック業界で最も過小評価されている役割はデベロッパーではなく、アーキテクトのように、ユーザーのように、そして戦略家のように考えるテスターだ。

テック業界の人材採用には、奇妙なことが起きている。

企業はAIコーディングツールの導入に競争している。GitHub Copilot、Amazon Q、Cursor、Claude――リストは毎月増え続けている。エンジニアリングチームはこれまでで最も速く出荷している。コード生成はほぼコモディティ化しつつある。

それでも製品の品質は同じペースで改善されていない。

私たちは間違ったものを、より速く作っている。

The Old Bottleneck Is Gone

何十年にもわたり、ソフトウェア開発のボトルネックは実装だった。アイデアがあり、それを作るには開発者が必要で、開発者は高価で不足していた。だから企業は開発者の生産性を最適化した。アジャイル、DevOps、CI/CD――すべては脳から本番環境へコードをより早く送り出すことを目的として設計された。

AIはそのボトルネックをほぼ完全に取り除いた。

適切なAIツールを備えた1人の人が、数時間で全体のアプリケーションを構築できる。バックエンド、フロントエンド、データベーススキーマ、APIエンドポイント、デプロイ設定――すべて会話を通じて生成・レビュー・洗練される。コードを書き出す追加コストはほぼゼロに近づいている。

しかし誰も語っていないことがある。実装のボトルネックを取り除くと、真のボトルネックが露わになった。

真のボトルネックは常に判断だった。

The Bug That No Unit Test Catches

従来のQAは1つの質問をします：動作しますか？

ボタンをクリック。フォームは送信されますか？APIは200を返しますか？計算は正しい数値を生成しますか？これらは重要な問いです。難しい問いではありません。さらに、AIもこれらに答えることができるようになってきています――自動テスト生成はすでに登場しています。

難しい質問はこれまでいつも以下の通りでした：

• この機能はそもそも存在すべきか？
• このフローは開発者ではない人にとって意味が通じるか？
• 誰かが実際に私たちが設計した通りにこれを使うのか？
• これは現実の問題を解決するのか、それとも私たちが作り出した問題か？
• これが10人ではなく10,000人のユーザーに拡大したとき、どうなる？

誰も求めていない機能を捉えるユニットテストはない。技術的には正しくても感情的にフラストレーションを引き起こすユーザーフローを指摘する統合テストはない。エンドツーエンドのテストも、あなたの製品が昨日の問題を解決しているとは教えてくれない。

これらはアーキテクチャのバグ。体験上のバグ。戦略上のバグだ。

そしてそれらはソフトウェアにおける最も高価なバグだ。出荷して、マーケティングを行い、ユーザーが離脱するのを見た後にしか発見されないからだ。

The Tester We Actually Need

業界には15年前のままのテスター像がある。画面を次々とクリックし、ボタンの不整合を指摘するJiraのチケットを作成し、Seleniumのスクリプトを記述する人のイメージだ。重要な仕事だが、今は指標を動かす仕事ではない。

業界が実際に必要とするテスターは、次のような人だ。

彼らはアーキテクチャ的に考える。 「どのデータベースを使うべきか」という意味ではなく、「ユーザーの観点からこれらの部品がどう組み合わさって機能するか」という意味で。彼らはシステム全体を見渡す。機能が動くかを試す前に、なぜその機能が存在するのかを問う。彼らは構造的な問題を捉える――個々の部品は完璧に機能していても、全体の体験が壊れているような問題。

彼らは開発者ではなくユーザーのように考える。 開発者は正常系をテストする。完璧なデータ、論理的な手順、内部でのシステムの動作全体の文脈を用いてテストする。実際のユーザーはそんなことをしない。そのようなユーザーのように考えるテスターは、非論理的なこと、忍耐強くないこと、「説明を読んでいない」ことを試す。ソフトウェアを壊そうとしているからではなく、実際の使い方がそうだからだ。

彼らは市場を理解している。 これは最も稀で最も価値のある資質だ。競合環境を知り、ユーザーが実際に何にお金を払っているのかを理解し、機能を見て「技術的には優れているが商業的には関連性が低い」と言えるテスター――そんな人は、10人の開発者よりも多くのお金を節約する。

ブリーフを問うのは、ビルドだけではない。 最も価値のあるバグレポートは「このボタンは動かない」ですらない。むしろ「この全体のフローは、ユーザーがすでにXを知っていると仮定しているが、彼らはそうではない」というものだ。これはコードの問題ではない。思考の問題だ。そして、それは出荷前に検知される必要がある。遅れてからでは遅い。

Why This Matters Right Now

AIは意思決定を拡大する。良い決定も悪い決定も同様に。

AI以前は、間違ったものを作るのは高くついた。何か月もそれに費やすことになった。開発の遅さは自然なフィルターとして機能し、エンジニアリングのリソースが足りず作れないため、悪いアイデアはバックログで死ぬことが多かった。

そのフィルターは今やなくなっている。

AI支援開発により、悪いアイデアから出荷済みの製品まで日数で進むことができる。間違ったものを作るコストはほぼゼロに近づいた。しかし、作ってしまった間違ったもののコスト――間違った位置づけ、混乱したユーザー、技術的負債、機会コスト――は、常にそうであったのと全く同じだ。

これは、優れた判断のリターンが急上昇したことを意味する。すべての決定がより重要になる。なぜなら、すべての決定がより速く実装されるからだ。悪い決定をコードになる前に摘出する人が、チームで最も価値のある人になっている。

その人は別のデベロッパーではない。その人はテストケース以上の視点を持つテスターだ。

The Hiring Mistake Companies Keep Making

企業がAIツールを導入し、開発者の生産性が急上昇すると、直感としては強化することになる。開発者をさらに雇い、さらに速く出荷し、より多くの機能を作る。

これは正反対だ。

もし開発者が現在3倍生産的であっても、3倍のアウトプットを正しい方向へ向けることを保証する人が必要だ。考えをテストしている人が必要で、コードだけをテストしている人ではない。

アーキテクチャの判断、ユーザー体験のフロー、市場適合性を評価できる、鋭くて製品志向のテスター1人は、誤った方向へ速く作る5人の追加開発者以上のコストを節約する。

計算上は簡単だ。方向性のない速度は、ただの高価な放浪に過ぎない。

What This Role Actually Looks Like

これは理論的な役割ではない。産業全体のいたるところに存在しており、通常は異なる職名で呼ばれる――製品エンジニア、技術系製品マネージャー、QAアーキテクト、製品志向のスタッフエンジニア。しかし、それが意図的に採用されることは稀で、ほとんどの場合そのままの名前では呼ばれない――意思決定のテスター。

日常的には、この人は以下を行う：

• 開発前に機能仕様を見直し、「これは誰のためで、彼らはなぜ気にするのか？」と問う。
• 開発が始まる前に機能仕様を見直し、"これは誰のためで、彼らはなぜ気にするのか？"と問う。
• ユーザーフローを製品を見たことのない人の視点でエンドツーエンドでテストする
• 技術的な優劣ではなく、ユーザーへの影響という観点からアーキテクチャの選択に挑戦する
• 分析を見て「ユーザーは実際に何をしているのか？」と問う。『私たちは彼らに何をさせるためにこれを作ったのか？』ではなく。
• 「これは作るべきではない」と言う機会を「これはバグだ」に比べて多く言う
• エンジニアリングが作れるものと市場が実際に必要としているもののギャップを埋める

この役割の最も難しい点は、ノーと言うことを要求される点だ。技術的には興味深いが戦略的には意味のない機能に対して反対することを求められる。『これは完璧に機能しているが、それでも出荷すべきではない』とチームに伝える自信を要求される。

それには、コードを書くこととは異なる種類のスキルが必要だ。判断力が必要だ。

The Uncomfortable Truth

業界が聞きたくないことは次のとおりだ。AIは開発者を重要でなくしたわけではない。悪い決定をより危険にしたのだ。

AI以前は、間違ったものを作るのは高くついた。何か月もそれに費やすことになった。レビュー、ディスカッション、リソースの制約――これらすべてが、悪いアイデアが本番環境に到達するのを時折止めるスピードバンプとして機能していた。

AIはスピードバンプを取り除いた。

現在、悪い決定と出荷済みの製品の間に立ちはだかる唯一の障害は、「待て」と言える判断力を持つ人だ。誰よりも先に思考をテストする人だ、コードを誰もテストする前に。

私たちは20年近く、開発者のスピードを最適化してきた。そろそろ意思決定の質を最適化する時かもしれない。

作るためのツールは至る所にある。何を作るべきかを知るスキル――それが希少だ。

最高の製品は、最速のチームによって作られるわけではない。間違ったことにかける労力を最小限に抑えたチームによって作られる。