はじめに
ふざけた表題ですみません（笑）
私が元々バンドマンだったからでもありません。
3ヶ月ほどブログを書いていませんでした。シンプルに忙しかったというのもありますが、表題のようなことをずっと考えていたからでもあります。
先日、私が非常に愛読している秋山さんのとあるブログの記事を拝読し、非常に深い共感を覚えました。
QAという職種に対する洞察や捉え方に触れ、自分自身の経験や考えとも重なる部分が多く、改めてこの領域の奥深さを感じる機会となりました。秋山さんのブログは「QAとは何か？」と悩んだ時に必ず立ち返るブログです。他に井芹さんのブログやアシカさんのブログなどもよく参考にしています。
本記事では、秋山さんのご意見に刺激を受けながら、私なりの視点でQAエンジニアという存在について考察してみたいと思います。
これから話す内容の賛否は分かれると思いますし、私自身も深く考え込んだ末に「最近、多分そうなんだろうなと思った」という実感に近づいてきた段階に過ぎません。ですので、いろいろなご意見をいただけると嬉しいです。いただいたご意見を通じて、私自身も結論をより的確に言語化できるかもしれません。
※以下の文章中に3種類のアート表記があります。本文は基本的に「アート」で統一しつつ、概念の対比をするときは「Art」、特定の固有の書名や慣用表現に対しては「The Art」を使っております。ご承知おきください。
おそらくAIによってテクニックは淘汰され、アートだけが残るだろう
私がここで考えていることは、AIによってテクニックの側面は淘汰されつつある一方で、アートの側面は残るのではないか、ということです。テクノロジーの進化で質の高い「アートらしきもの」は作れるようになるでしょう。しかしそれは往々にしてアートの表現ではなく、アートの近似にとどまる可能性があります。
アートの本質は表現であり、「その人がどのような目的や意図を持ってそれを作ったのか」ということ自体に価値がある。テクノロジーがどう発展しても、世の中は人が働き、価値やモノや何かを生産し続ける。であれば、人が目的や意図を持って何かを生み出すこと自体はなくならない。そう考えると、QAが持っているアートの側面は本質的には消えないのではないか、と思うのです。
補足： アートの近似とは何か？
イギリスの統計学者George Boxは「All models are wrong, but some are useful（すべてのモデルは間違っている、しかし有用である）」と述べました。重要なのは、モデルは現実を完全には写し取れず、あくまで近似であるということです。
テストやQAにおける「手順書」「チェックリスト」「方法論」は、いずれも「現実（仕様・ユーザー行動・制約・リスク）」を扱いやすくするためのモデルです。天気予報が地球の気象を完全には再現できず、様々な要因が絡み合った結果外れてしまうように、ガンダムのプラモデルがガンダムではないように、現実を扱いやすく抽象化したものでしかありません。近似とは、そのような性質を持っています。
モデルである以上、必ず取りこぼしや歪みが生じます。だから、手順や方法論に「盲従」しても完全にはなりません。むしろ、モデルが近似であることを自覚し受け入れて、その適用範囲・前提・限界を明示しながら、状況に応じて更新・破棄・補完する 「判断（アート）」が不可欠です。
ここで私たちにとって特に重要なのは、ソフトウェアの世界ではこの「近似」の感覚が薄れがちだということです。モデル（設計）から作られたコードはコンピュータをその通りに動かすため、「モデル = 正解」というバイアスに陥りやすい。しかし開発者が行っているのは、不完全かもしれないモデルを、論理的に矛盾のないコードへ忠実に変換する活動です。コード自体は「1 + 1 = 2」のようにロジックとして正しくても、元のモデルが現実の要求とズレていれば、ユーザーにとっては不利益、つまり「バグ」として現れます。
一方で、私たちQAがやっていることは開発者とは違い、「モデルからテストというモデルへの変換」です。仕様や設計というモデルを、テストという別のモデルに変換する活動をしています。だからこそ「仕様書にこう書いてあるから」という理由だけで思考を止めることになってはいけない。ほかに検証すべき前提はないか、実際にプロダクトに触れて「仕様どおりだが使いにくい」「この仕様はユーザーのためになっていないのでは？」と、モデルそのものに疑問を投げかける視点が必要です。
つまり、QAエンジニアにおいて技法はアートであり、モデルの側面も持っている。そして、それは常に近似であるがゆえに 「熟練（アート）」 で補正する必要がある。AIがテクニックを強化しても、意図と判断が価値を生む限り、その役割は置き換わらないと考えているのです。
そのため、AIが作るテストケースというのは、ただでさえ近似であるアートのさらに近似にとどまり、QAが持っているアートの側面は本質的には消えないのではないか、と思うということでした。
『The Art of Software Testing』と「技法」の話
この話に関連して触れておきたいのが、マイヤーズの「The Art of Software Testing（邦題『ソフトウェア・テストの技法』）」です。原題ではArtとされているものが、邦題では「技法」と訳されています。私は、この文脈での「技法」はTechnique（手順や方法）というより、むしろArt（熟練のわざ・達人芸）に近いと捉えています。皆さんはどう思われますか？
技法をTechniqueとして厳密に捉えるなら、「マニュアル化による再現性と標準化（誰でも一定の成果）」が期待されると思いますし、そのためには誰が・いつ・どこで・何を・どう・どの基準で行うかを明文化する必要があります。
例えば「エラー推測」「探索的テスト」「チェックリストベースドテスト」といった経験ベースのテスト手法はTechniqueか？と問うと、私には違和感を感じました。基本的な手順はあるにせよ、手順をなぞれば誰しも同じ結果に到達できるわけではありません。そこには暗黙知や経験の蓄積、状況適応の妙が伴います。私は、現代のソフトウェアテスト……特に私がいる業界では、この「Art」の色がかなり濃いと感じています。だからこそ、テストに意図や目的を込めることが重視されるのではないでしょうか。
語感と翻訳： Art と Technique
Artは本来「技巧・技（わざ）」の意味をもつ語で、語源はラテン語のars（技・術）です。artisan（職人）、artifact（人工物）、artifice（巧妙さ）などに痕跡が残っています。近代以降は「美術・芸術」という意味が強くなりましたが、英語には今もthe art of 〜（〜のコツ / 妙）という慣用が残っています（the art of negotiation, the art of cooking など）。フランス語のart de 〜、ドイツ語のKunstでも「技・術」の含意が強く、19世紀以降の翻訳や書名にそのニュアンスが色濃く表れました。代表例として『孫子の兵法』は「The Art of War」と訳されますし、「The Art of Computer Programming」や「The Art of Electronics」といったように、技術書のタイトルにも使われます。
日本語の「技法」を直訳すればTechniquesが最も一般的です。しかし「熟練の妙」「コツ」「達人芸」のニュアンスを前面に出したい時、英語ではartが選ばれやすく、タイトルや見出しでも好まれます。この観点に立てば、探索的テストのような経験ベースのテスト技法に限定せず、同値分割や境界値分析のような体系立った技法も、広い意味で「アート（熟練のわざ）」に含めてよいのではないかと考えました。
実際のQA技術： 同値分割・境界値分析にも存在するアートの側面
以下のようなポイントがあると思います。
- 規則はあるが、適用には判断が要る
- どの仕様をもとに同値クラスを切るか、粒度をどこまで細かくするか、リスクやドメイン知識をどう織り込むかは自動的には決まりません。
- 境界値も「どこが本当の境界か」を見極めるには経験と読解力が必要です。
- 現実の複雑さへの適応が肝
- 複数パラメータの相互作用（組合せの爆発）にどう折り合いをつけるか、ペアワイズ等とどのように併用するか。
- 数値でないドメイン（状態遷移、日付・時刻、文字種、ロケール、権限）をどのようにマッピングするか。
- プロダクトの仕様の癖や既知の不具合の起こりやすいパターンをどのように反映するか。
- 必要最小限で効果的なテストセットに落とす設計
- 冗長を避けつつ見落としを作らないテストセットの選定、優先順位付け、探索的テストの停止基準の設定は「勘所」が必要です。
つまり、同値分割や境界値分析には「ルール」の側面がある一方で、それを現実の仕様・制約・リスクに合わせて切り出し、組み合わせ、最小実行セットに仕立てる部分が「アート」なのだと思います。The Art という語は、エラー推測のような経験ベースのテスト技法だけを指すのではなく、ソフトウェアテスト全体が「方法 + 熟練」の両輪で成り立っていることを示している、と捉えると納得できます。
意図や目的によってテストケースが変わる例
仕様が精緻でも、「ユーザーにとって起こってはいけないこと（リスク）」や「プロダクトの目的・意図」によって同値分割の切り方は変わります。つまり、正常 / 異常の境界は機械的に一意に定まらず、判断（アート）が介在します。ちょうどGPT5も出たところなので、試しにこれまでのアートの概念を教えた上で出力させてみました。AIはどこまでアートの近似が作れるのか？という視点も含めてテストケースを読んでみてください。
- 機能: ワンタイムパスコード（OTP）
- 仕様
- 6桁数値、5分有効、最大3回試行、3回失敗で30分ロック、時刻はサーバ基準、使い回し禁止
-
乗っ取り防止を目的に置いた場合
- 許容できないこと: 攻撃者の突破、再利用による不正
- 同値クラスの切り口例
- 入力の種類: 正しい / 誤り / 期限切れ / 再利用
- 文脈: 既知端末 / 新規端末、IP・国変化 大 / 小
- 連続性: 連続ミス / ミス間に成功 / 端末切替
- 代表的なパターン例
- 新規端末 + IP大変化で誤り×3 → ロック
- 成功直後に同一OTP再送 → 拒否（再利用防止）
- 期限切れOTP → 拒否、即時再発行で復帰可
-
正常なユーザーのロックアウトを最小化することを目的に置いた場合
- 許容できないこと: SMS遅延や時刻ずれでの締め出し
- 同値クラスの切り口例
- 配送遅延: 5分未満 / 超
- 時刻差: 端末時計ずれ ±2分 / ±10分
- 通信断: 成功後レスポンス喪失→再送
- 代表的なパターン例
- SMS遅延6分 → 期限切れ扱いだが再発行導線で救済
- 端末時計 + 2分で入力 → 許可（サーバ基準判定）
- 成功後の再送 → 重複処理なしで成功表示に誘導
- 仕様
もし、目的や意図で駆動してテスト設計を行いたい場合、下記のようなテンプレートでテスト分析やテスト設計をやっていくといいかもしれません。
- 目的（守りたい価値）:
- 許容できないこと（ユーザー視点のリスク）:
- 仕様の解釈 / 運用方針など:
- 観点（入力 / 出力 / 文脈 / タイミング / 状態）:
- これまでの例に忠実に従うならば「同値クラスの切り口」でもいいかもしれません。
- テストケース:
このように目的や意図を込めたテストケースレビューをするときは、下記を意識するといいと思いました。
- 業務の境界（守るべき価値）と技術の境界（データ型 / フォーマット）を分けて定義したか
- ユーザーにとって「起こってはいけないこと」を明文化し、同値クラスの切り口に反映したか
QAという職業の複雑さと可視化の難しさ
この前提で立ち止まると、QAエンジニアという職業はかなり複雑で難解な職業です。例えば、テストにおいてQAの生産性を可視化するのは難しく、「誰でも優秀なテストができるようになる標準」も存在しません。品質の可視化に苦労が伴うのも、そもそもQAの仕事自体がArtの側面を持っており、そのことが仕事を難しくしているからではないか、と感じています。
AIはQAエンジニアを奪うのか？
最近、「QAエンジニアもAIに仕事を奪われるのでは？」という話題を見る機会が増えました。私は上述の理由から、QAはAIに奪われにくい仕事だと考えています。
アートの本質は表現であり、作り手の目的や意図に価値が宿る。だから、テスト設計とは人が目的や意図を持って生み出す営みそのものはなくならない。だからこそ、QAが持つアートの側面は残り続けるのではないでしょうか。
関連して以前「QAのAである Assurance は不安を減らすという意味がある」という記事を書いたことがあります。
ここでも問いを立てたいのですが、AIは本当に、仲間の不安を減らせる存在になり得るでしょうか？最終判断は人が下すとして、品質そのものをAIが判断できるのか。アートの側面がある限り、品質を担う「あなたがどう考え、どのような根拠で判断するか」、ということがAIにはないQAエンジニアの価値ではないでしょうか。
俺たちってきっとアーティストなんだと思う
そう考えると、QAエンジニアはアーティストです。アーティストであるならば、AIという新しい道具を使って表現の幅を広げ、より良い世界を描き出すことは可能です。しかし、仕事そのものがなくなるとは思っていません。テストという営みもアートの側面を内包している限り、同様です。
最後に個人的な感覚ですが、QAエンジニアをアーティストと捉えるなら、「優秀なQAエンジニアは非常に少ない」という業界内の声にも妙に納得がいきます。
私自身20代前半はバンドマンでしたが、本当に優れた表現者は一握りだと痛感していました。QAエンジニアにおいても、技術だけじゃなく「感性」や「洞察力」が求められる場面が多いので、だからこそ光る人は限られているのかもしれません。
参考文献
- マイヤーズ：ソフトウェア・テストの技法
- ゆもつよさん：QAの訳って品質保証でいいのかな?
- 多モデル思考
- akiyamaさん：第109回：経験ベースのテスト技法
Discussion