デイリー日々

生活ライフ

プロダクト開発において、AIはゲームチェンジャーなのだろうか

序

プロダクト開発においては、もうAIエージェントを用いるのは当たり前になりましたね〜。私ももうコードは書いてません。

一般化に伴い「AIめっちゃすごいじゃん」みたいな論調は落ち着いてきた印象ですが、まだ各々の印象のばらつきは大きいように思います。

ということで、QAエンジニアとしての個人の感覚を書きます。お分かりの通り、タイトルは反語です。

「ゲームチェンジャー」

考え方を根本から変える、大変革をもたらす何か*1、と捉えています。インターネットとかスマホとか？そういうレベルですかね。

AIが変えたもの/変えなかったもの

開発プロセス全体

一般に開発プロセスは概ね以下の要素からなると思います*2。

  • 計画: 何を作るか、どのような仕様にするか
  • 設計: どのように実現するか
  • 実装・テスト: 実現と実現内容の検証
  • リリース: 顧客への提供
  • 運用: モニタリングとフィードバック

SDDだのハーネスエンジニアリングだの手法やツールは色々ありますが、大して変わってなくない？と思っています。プロダクト開発を丸々ひっくり返すほどのインパクトではなかったのでは。

実装

プロダクトコードを手で書くことはかなり減りました。そういう意味ではAIによる変化が大きい部分だと思います。

ただ、それでも「プログラミング言語で処理を記載し、設計内容を実現する」ということは変わっていません。設計内容を入力するとネイティブバイナリが出力される、というようなこともまだありません。

テスト

自動テスト

私が携わっているのがここら辺ですが、AIのパワーが発揮できる領域だなあ、と感じています。最近はmdファイルで書いたテスト仕様書をPlaywrightのテストスクリプトにしてもらったり、その道中ページのDOM構造を読み取ってもらってPageObjectModelクラスに反映してもらったり、大活躍です。

ただし、やはりここも人間の作業の肩代わりです。

マニュアルテスト

個人的にはこの部分をAIに代替してほしい、と思っていました。ClaudeとPlaywright Agentsあたりでいい感じにできないかな〜探索的テストできないかな〜、みたいな感じです。

試してはみましたが、あまりいいテストはできませんでした。まあそれもそうで、画面から読み取れる内容だけを用いてテストを作るからです。テストの目的がスッポリ抜け落ちていました。

運用

AIによるモニタリングを導入しているところも多いと思います。膨大なデータから正しく統計してくれるのはありがたいですね。まあここも作業を代替してくれているだけなわけですが。

ということで

ただの作業の代替をしてくれているだけで、それ以外は何も変えてくれていない、と思っています。ゲームチェンジャーとは言えないんじゃないかな？と。

その上で、どう扱うか

人間の代替として

ここは正直今までのSIerとSESの関係と変わっていないのではないでしょうか。「仕様を作って指示する→実装などの作業を行う」という構造は同じ*3ですから。

うまくやる方法も基本的に同じだと思います。「コミュニケーションを取り続け、ドキュメントを整備し続け、それを読み続け、同じ認識を持ち続けながら作業し続ける」だけです。流れが止まった場所から腐っていくのも同じです。

ツールとして

個人的には「Excelと同じようなもん」として扱っています。AI類を用いたプロダクトもExcelを用いた帳票も同じような性質を持っています。

  • 処理プロセスを変えるには至らない
    • (Excelも会計処理とかを変えたわけではないですからね)
  • 設計を誤るとすぐ崩壊する
  • 固まらないまま複数人で触るとすぐ崩壊する

あくまでツールだと考えれば、結局「ベストプラクティスに則る」が一番効くと思います。またAI類ならAI類自身によりよい使い方を尋ねるというのも効きますね。

総括

(今はまだ)AIはゲームチェンジャーではなく、作業を肩代わりしてくれるツール、くらいに捉えておけばよさそうです。エンジニアが丸々失職するには至らず。

大きく変わらなかったからこそ、今までの知見を見直して活かすしか道はないんだろうなあ、と思っています。

あとは、人間がAIに引きずられないことが大事なんでしょうね。ツールに合わせた工程改善も必要ではあるものの、仕様その他で人間が手綱を引いておく必要があると考えています。

*1:https://eow.alc.co.jp/search?q=game+changer

*2:ここではアジャイルだのウォーターフォールだの議論したいわけではないので、雑に書いています。なんかこういうの見て突っかかってる人たまに居ますよね

*3:私もかつてSESの会社に在籍して仕事していたので、結構強くこう思っています。上が下に強く当たるのも一緒ですね

QAエンジニアの変遷と個人的体感

QAエンジニアと名乗るようになって6年弱経つんですが、それまでのQA活動方法論とかを改めて調べ直していると、「変遷すごいじゃあん…」と思っています。その上、多分要求水準も上がっている印象です。ちょっと私の経験と体感をふりかえってみました。

基本的にいろんな人が言ってることの焼き直しです。個人ブログなんで書きたいこと書きます。

QA = テスト、というのもたぶん間違いではなかった

ネイティブアプリが当然だった

十数年前くらいまでは、今ほどクラウドのSaaSなどは発達しておらず、アプリケーションはデバイスにインストールして使うものという印象だったと思います。したがって、その頃までは「品質保証 = 受け入れテストによる仕様満足確認」と言ってもよかったと思います。納品(販売)されるソフトウェアが正しく動作し、かつアップデートも頻繁でない(高々月イチ程度ですかね)なので、「成果物に瑕疵がない」ことをソフトウェアテストで担保できればOKなはずです。

私の前職(当時は開発エンジニアでしたが)での納品物とテストもそのようなものでした。「仕様がfixしており正しい」という前提に立てば、ウォーターフォール開発やその中の最後の工程でテストするというのも違和感はないです。

曖昧な仕様

現実問題、 完璧な仕様というのは存在しません 。「ボタンに表示されている文字列が崩れていない」ということは明示的に仕様に書かれていないこともありますし、そもそも「崩れていない」の定義も曖昧です。そもそも「宇宙人が何らかのテクノロジーを用いてレコードを書き換えても動作する」みたいな荒唐無稽(に見える)ことは仕様にはしませんが、どこまで仕様として考慮するか？という線引きはありません。したがって、全てを網羅した仕様を作成するのは不可能で、「『仕様がfixしており正しい』という前提」自体やはり難しいものだったなと個人的には感じています。

QA = テスト、ではなくなってきた

クラウド上のWebアプリケーション・SaaSの隆盛

ここ十年くらいで、価値提供する手段としてWebアプリケーション・SaaSはかなりの勢いで浸透した印象です。Web技術の上で動くという統一したアプローチで多種多様なサービスが提供される、というのは開発側からしても大きいインパクトがあるものでした。

特に、PoCとしてのプロトタイピングとその頻回リリースは、インストールしないアプリだからこそできるものです。「とりあえず作って出して反応を見る」ことを優先するなら、仕様をカッチカチに作り込むことは無駄です。

アジャイル開発の一般化

成果物の形式が変われば開発形式も適したものに変わります。サービスを提供し続けた上で、フィードバックをもとに仕様・実装を更新し続けることは、以前の開発手法では対応できません。

アジャイル開発が一般的になったのは、体感的にここ5年くらいだと思います。ましてやそれが各社に浸透して、というと、当たり前のものになったのはここ数年かもしれません。それだけプロセスを変えるというのは、いろいろとパワーを使うものなのでしょう。工場だったら機械総入れ替えぐらいでしょうからね。

QA活動の対象の変化

以前はアプリケーションのバイナリを提供すれば終わり(というより何もできない)という状況でしたが、現在は サービスの総体を品質保証し続けないといけない 状態になっています。

さらに言えば、動作するアプリケーションに加え、その周辺もQA活動の対象です。仕様自体のテストとか、CI/CDパイプラインとか、モニタリングとフィードバックとか。全体を俯瞰しての開発プロセスとか。もはや二次元の図には落とし込めないですね。

そして、"テスト"という語が指すこと自体も変化しつつあるように思います。ISTQB Glossaryによれば

コンポーネントやシステム、および関連する作業成果物の品質を評価するための、ソフトウェア開発ライフサイクル内のプロセス。

です。定義自体は変わっていないのかもしれませんが、かつての「アプリケーションを動かしてみて評価すること」はごく一部でしかなく、 すべてがテスト対象で、継続してテストしていく必要がある と言えると思います。

遡ってみて思うこと

QAエンジニアのスコープ

"QAエンジニア"という職種に対する見方の違いは、「そのQAエンジニアが何を守ろうとしているのか？」という認識の違いに起因しているのでは？ということです。特に、シフトレフト・シフトライトとか、自動化・パイプライン品質とか、以前は認識されていなかった領域に対しても、QAエンジニアとしてアプローチする必要が出てきています。しかし、どういったアプローチであれ、 品質に関してコミットするエンジニアがQAエンジニア です。

領域が広がるにつれ、QAエンジニアだけではカバーしきれないようになってくるのは当然のことです。そのため、QAエンジニアが守備範囲を広げつつも、QAエンジニア以外も含む全員でQA活動をしていくというのはもはや避けられません。QAエンジニアはQA活動の手法を広めつつ、プロセスの交通整理をして、開発エンジニアなど他のメンバーにQA活動の一部範囲を移譲し、その上でQAエンジニアが注力すべき場所に集中する必要がありそうです。

「テストするだけのQAエンジニアは認識が古い」と見る動きもあります(感じます)が、そもそも求めている/求められていることをすり合わせないままなので、古いもへったくれもありません。テストを作り・行うのも大事なQA活動の一つです。方向が合うかどうか、です。

QAエンジニアのこれから

たぶん、「私の考える"品質"はコレです」「私はこうして品質にコミットしていきます/きました」ということを明確に語れないといけない、と感じています。ミスマッチを防ぐだけではなく、各々の姿勢を宣言してそれに向かっていくことが重要なのではないでしょうか。

「テスト自動化」したいのか、「自動テスト化」したいのか

おひさしぶりです。アウトプットしなくなるとアウトプットしなくなるな、と思ったので、再開です。

追記(公開翌々日)

以下の私のブログ記事、末村さん(Autify)の2020年の登壇資料の内容と一部近いことが判明しました。

speakerdeck.com

ぜひこちらの資料をお読みください。

はじめに

それなりにSETっぽいことをしてて、「テスト自動化してます！」みたいな記事を見にすることも増えました。でも、思うことがあるので、書きます。

時間がない方へ

  • 「テスト自動化」は手動テストを文字通り自動化することが主眼
  • 「自動テスト化」は自動化されたテストを用いつつ、テスト計画から自動化を考えること

おことわり

ここから先、「自動テスト」といった場合、自動化されたテストのことだけではなく自動で動かす仕組みなどの話も含まれるかもしれません。文脈で判断ください。あとE2Eテスト寄りです。整理されてないです。すみません！

それは「テスト自動化」なのか、「自動テスト化」なのか

「テスト自動化」、着手しやすいが難しい

「テスト自動化」はわかりやすいワードだと思います。テストを自動化すればテスト自動化です。ただ、テスト自動化は実は安定しづらい難しいものです。

個人的なイメージでは、電気自動車の自動運転で考えています。「テスト自動化」はロボットに人の代わりに運転させるようなもので、「自動テスト」は車自体が自律して運転するようなものだと思っています。

左ハンドルですかね

こう考えると、前者の方が細かく難しく複雑な制御が必要で、後者は数値的に制御できる&mockしやすい、というような感覚がわかると思います。

ということで、テスト自動化を行った時の不安定さは手動テストでは考える必要のなかった暗黙的な部分にあり、それを上手にいなさないといけないのが難しく辛いところです。

これすっごい疲弊します。「自分でやった方が早いいいいい」ってなります。

「自動テスト化」はプロセス自体の自動化を前提にする必要がある

車自体が自律して運転するためには、車自体のセンシングはもちろん、自動運転を周囲の環境・インフラが考慮する必要があります。

  • GPSによる測位
  • 交通情報のリアルタイム提供
  • 信号等へのビーコン埋め込み

「自動テスト化」の難しさは、テスト計画やプロセス・テスト実行環境のインフラから練り直さないと上手くいかない、ということになります。自動テストが実行されるトリガーやパイプラインを用意するとか、結果を適切にフィードバックできる仕組みを事前に作っておくとか、です。

さらに、場合によってはプロダクト自体の構造を見直すことも必要になります。例えば、自動E2Eテストを行えるようにしようとしたら、画面の構造自体の見直しが必要になることはままあります。大リファクタをするのが怖いなら、当面はカスタムデータ属性を入れる*1など、メタデータ埋め込みなども必要になります。

幸い、ソフトウェアであれば、都市計画よりは実現しやすいです。

じゃあどうするべきなのか

最初から「自動テスト化」を目指すべきか

プロダクトの性質(特に新規開発かどうか)にもよりますが、何もわからないうちから「自動テスト化」するのはやめた方がいいです。たぶん。

「人の操作を模擬する」ということを軽視すると、後で困ることになります。ユニットテストでいう「mock刺しまくってテストしたらmockのテストにしかならなかった」ようなことが起こります。したがって、あくまで極力実際のフローを模擬するということが必要です。そのために、まずは「テスト自動化」して何となく掴むことも必要かなと思っています。

何からやったらいいのか

(特にレガシーな)プロダクトにとりあえず入れて実績出しやすいのは、やはりE2E的なテストの自動化だと思います。画面ぽちぽちするのは時間がかかりますからね。人力で5分くらいのテストが1分で自動で終われば、それは十分効果があるといえます。

こだわりがなければ、とりあえずTypeScriptでPlaywrightを触っておけばいいと思います。ただし最初からMCPとかAgentsとかを触るのではなく、生のPageとかLocatorとかを触って操作→テストすべきです。実際の画面で生じるFlakinessをイヤというほど浴びておくのが後々重要です。「ここは画面遷移してすぐでFlakyになりやすい部分だから、文言の表示を待つようにしておこう」とか、「このinputとbuttonはdivで囲えばlabelで選択しやすくなる」とか、「だからPage Object Patternができたんだな」とか、何なら「この操作はAPIのrequestで模擬できる」とか、そういったtipsのようなものを感覚的に掴めば、後で便利です。

最後に

テスト自動化・自動テストについては種々の文献や記事など出回っていますが、状況次第です。何にせよ苦労することになります。その上、自動テストが動くようになっても、それはそれで考えることが多くあります。「果たしてこのテストで十分なんだろうか」とか。

それでも、自動でテストが動いている開発環境がそれなりにできると、何とも言えない感慨深さがあります。

プロダクトが続く限りいつまでも保守・更新し続けることにはなりますが…いいですよ。自動テスト。オススメです。

*1:ベストプラクティスではありません。本来はW3C標準に則ったりARIA Roleを適切につけたりするのが望ましいです。

LLMとサグラダ・ファミリアとSaaSプロダクトとQAエンジニアと

※要約(長いので)
LLMが発達してQAエンジニアが追いやられていることに悩んでいましたが、プロダクトの前提を考えることで何となく方向性が見えました。というお話です。

いまだに「QAエンジニアってなんだろう」を考える日々です。

というのも、今年に入って以降のLLMとバイブコーディングの隆盛が想定以上に凄いからです。3月もここまでとは思っていなかったし、5月も凄すぎてよくわかんなかったし、今は…もう全てを理解することは諦めて、「そういうものなんだな」と思うに至っています。

ここまで進歩しなければここまで悩むこともなかっただろう、と思いますが、まあそういうことになってしまったならしょうがない。かといって考えないで仕事できるほど朗らかな人間でもない。

なぜ悩むか、って、QAエンジニアとしての自分の存在意義がわからなくなる/なくなるからです。
QAエンジニアの職務には「(テスト等を用いることで)プロダクトを正しく作れるようナビゲートする」性質があります。バイブコーディングが進めば、この領域に開発エンジニアが染み出して来ることは容易に想像できます。LLMがコーディングするなら、人間の業務はドメインエキスパートとしてLLMの成果物をレビューする方向にシフトするはずです。
最初こそテスト技術についてはQAエンジニアは一日の長がありますが、テストは大概が枯れた技術ですから、「QAエンジニアいらなくない？」と言われるのもすぐでしょう。
ましてや私はQA畑ではないので、ただの劣化エンジニアです。

自分の存在価値がなくなる。
厳しい現実を突きつけられてしまったな、と思いました。

TVerで博士ちゃんの世界遺産サグラダ・ファミリアSPを観ました。

tver.jp

「最近テレビ面白くねえなあ」と思いながらダラダラとテレビやらサブスクしてるやつやらザッピングして、TVerで目に止まったのが芦田愛菜ちゃんがバルセロナに行った回で、そのまますっかり引き込まれて観ました。

終わりの方に、外尾悦郎氏へのインタビューがあります。日本人にしてサグラダ・ファミリアの主任彫刻家の方です。
これがまた…シビレるインタビューでした。なんかゴチャゴチャいうのも野暮です、TVerで見てください。

インタビューの中で、「サグラダ・ファミリアの"完成"についてどう思うか？」という問いに対しての外尾氏の回答に、個人的に示唆を受けたところがありました。
曰く、「"完成"ということについてもっと考えるべき。常にいいものが出るなら完成ではない。人間が作るものに完成はない。」とのことでした。端折りまくってるのでTVerで見てください。

話を聞きながら、「これSaaSプロダクトにも通ずるな」と思うわけです。我々は日々完成しないものを作っているのです。
そもそもこれまでは完成する/しないを考えることもなかったわけですが、完成することがないのは明らかです。

我々の取り扱うプロダクトは完成しない。ならそれを前提として自身の指針や行動を考えるのはどうだろう。と思ったわけです。

「完成しない」ということに立脚すると、プロダクト開発に出てくる主要なアクターの考えることはこんな感じでしょう。

  • ビジネスサイド・PdM: これから先どのように良くしていくか
  • 開発エンジニア(デザイナー・SRE等含む): 今どのように良くしていくか

じゃあQAエンジニアの考えるべきことは、「これから先」を「今」に正しくつなげることなんじゃないか？と思いました。
これから先こういうことをプロダクトに盛り込みたい、ならこれを明らかにしておかないといけないよね、こんなものを用意しておかないといけないよね、ということをPdMや開発エンジニアと協力して進めることが必要かな、と。

これは、シフトレフト・シフトライトをより推し進める、ということかもしれません。「今」実装するにあたって必要なテストは多分もうLLMと開発エンジニアが作りますから、そこにQAエンジニアは不要になるはずです。「これから先」必要になる対応に対して、先んじて分析して、先んじて品質・正当性を保証できる方法を用意して、「今」実装できるようにする、そんな動きだと思います。
テストエンジニア志向のQAエンジニアならテスト分析・計画・設計を先にやっておくこと、SETならテストの実行環境を含むパイプラインを整備しておくこと、あたりから始めることになるのでしょうか。どちらにせよ、開発エンジニアより先を見通していないといけないでしょうね。

プラス、より良いものにできる、ということに貪欲になる必要がありそうです。アジャイル開発の「こうなっていればアジャイル開発を体現できている」というものはなく、常に磨き続けるところに本質があるところに通ずると思います。チェックポイントとして「完成」というものがあったとしても、それは綻びの始まりかもしれない。

ということで、なんとなく目指すべき方向性が見えた？かも？というお話でした。

再三書いてますが、博士ちゃんの世界遺産サグラダ・ファミリアSP、TVerで見てください。
時間がなければ外尾悦郎氏へのインタビューだけでも。2:25あたりです。
私にはブッ刺さりまくりました。上に書いたこと以外も示唆に富む内容です。是非。

三十代半ば過ぎの気付き - 損していた話

いい歳になってきたんですが、いまだに「そうだったのかあ」と思うことがぽつらぽつらありまして。という記録をしていこうと思いました。

のっけから汚め？な話です。すみません…でも結構衝撃を受けたのです…

トイレットペーパーは使い方を知らないと損をする

今までこうやって巻いてました。

ちゃんと図をこしらえました

で、気づきました。
この巻き方、シングルのトイレットペーパーだとガサガサの方が表にくるんです。

気づいたときは、もう愕然としましたね。今までだいぶ損をしていたぞ。と思いました。
私はお腹がゆるいほう(過敏性ﾅﾝﾀﾗｶﾝﾀﾗもち)なので、人よりだいぶ損をしています。

ちなみに、周囲に尋ねてみたところ、意外とみんなちゃんと巻いてない、ということがわかりました。両親ともｸｼｬｸｼｬｯとしてました。えっワシャ誰に倣って巻いてたんだ？

LT「QAエンジニアを諦めつつある」こぼれ話

先月また歳をとりまして…三十代半ばすぎ、めっちゃ具合悪いですね…
というわけで元気が出なくてまとめてなかったんですが、ふりかえりのために記事にしとこうと思いました。

イベントについて

QA engineer at a Startup vol.12に呼んでいただきまして。話してきました。発端はこの記事ですね。

blog.dashi-no-ajiwai.net

資料はこちらです。

speakerdeck.com

トーク内容(抄)

  • 「QA = テスト」ではない、みたいな議論は30年以上なされており結論は出ないので、"QAエンジニア"像は自分で決める
  • 品質は主観的で相対的、誰の視点で品質を捉えるか？ということを考えてみる
  • 限られたリソースで最大限コミットするために、好きなこと・やりたいことをやる
    • スキ😊パワー を活かす

よもやま

"QAエンジニア"という職種名と実情

そもそも職種名がアレですよね…*1とずーっと思ってるんですが、お話しした通り、もう30年はモメてるっぽい職種名ですからね…。

QAエンジニアという職種とそれに包含されるロールについては、QMファンネルと呼ばれる整理も有名かと思います。

www.slideshare.net

ただ、これも「(狭義の)テストをする」ことをベースとしたものなので、「(狭義の)テスト苦手！したくない！🥺」という私にとってはあまりしっくりこないものでありました。私が一番やりたいのは ソフトウェア自体(と付随してそのテスト)の可塑性を高めて変化に追随できるようにしつつ、堅牢性を評価できるようにする というようなものなのです。SETでもないです。

ということで、もういいや！QAエンジニアだけど(狭義の)テストしねえ！とヤケになって記事書いたのが今回のLTにつながりました。

あと、こういう痛快な会話もありました。本当にそうですね、って思ってます。まあ私はQAエンジニアという職種を隠れ蓑にしているので若干後ろめたいですが。

「テストをしない」ということ

いや、「テストをしない」というのは詭弁です。わかっています。わかっているのです…。
というのも、やはりQA界隈の"テスト"というものが広すぎるからです。なので、前の節ではあえて"(狭義の)"をつけていました。テスト、と言った場合、(特に動的テストの)テスト分析〜実施とその周辺が一般的だと思います。

ISTQB Glossaryによる"テスト"の定義がコチラです。

コンポーネントやシステム、および関連する作業成果物の品質を評価するための、ソフトウェア開発ライフサイクル内のプロセス。

「品質を評価するためのプロセス」がぜ〜んぶテストだ、と言っているわけです。なのでここのレベル感が各々違うので、ちょいちょい認識の齟齬が生まれるんですよね。
(かくいう私も「レビューもテスト」みたいな文言に触れた時は「えぇ〜」って感じでした。開発エンジニア上がりだとそう思いやすいのでは)

ということで、LTではまとめの方で話したのですが、上記定義のテストをマインドとして持っていれば、それはQAエンジニアなのではなかろうか、と思っています。

さいごに

時間を割いて聞いてくださった皆さま、そしてQaaS運営の皆さま、ありがとうございました！
特に誰かに刺さることも期待せず、「こういう道もあるのではなかろうか」という自己肯定のためのLTでしたが、結果話してよかったと思います。

QAエンジニアしていると、(狭義の)テストに関連する業務が主ではあるのですが、それ以外の道もありそうだと伝われば幸いです。

↓アイキャッチ用画像です、新潟行く機会があればラーメンを食べるといいですよ

*1:個人的にはSREも微妙だと思ってます。reliabilityを考えるのはインフラだけではないだろう、という感じです。

QAエンジニアを諦めつつある(今更JaSST'25 Tokyoの感想)

なんか、肩の荷がおりてきました。

一応"QAエンジニア"と5年ほど名乗っています。
特にQAエンジニアになるために必要な資格なんてないので、問題はないはずです。
(JSTQB FLすらも持ってないです)

なんですが、ずーっと負い目があったんですよね。「テストを作る」という経験が乏しいので。

元々C++のエンジニアをやっており、ダサいテストに辟易し、「テストは自動化できるものはした方がいい」と思ってコンバートしての現職です。
なので、「自動化する」ということにwillがあったものの、どういうテストを作るべきか？という部分は後付けでした。

それを5年ほど引きずってきました。

そして迎えたJaSST'25 Tokyo。たくさんのセッションとたくさんの人たち。
QA界隈に拭えない抵抗感があったんですが…割とどうでもいいのかもしれないと思いました。

みんなそれなりにテストの話はしていたんですが、それよりは「AI時代どうする」とか「組織課題どうする」とかそういう話が多くて、別にテストに閉ざした話だけではなく、「どうしていこっか」「こうしたらちょっとよかった」という感じでした。

あああ、凝り固まってたんだ、と思い知らされました。

QAエンジニアたるものテスト設計ができなければならない、テスト分析で疎にして漏らさずのモデリングができないといけない、テスト計画で適切にテストレベル設定ができていないといけない、テスト実装・実施して不具合分析できないといけない….
なんて勝手に思って勝手に負い目を感じていたんだな、と。

もちろんQAエンジニアとしてのコアコンピタンス？コアスキル？としてのテストの考え方は必要ですが、別に「絶対にバキバキにできないといけない」ものでもなく、それなりに理解できていればいい、のかもしれない。

なあ〜んて思ってのJaSST'25 Tokyo打ち上げ。同僚QAエンジニア2人に「テスト設計できないんよ」と吐露しまして。

「知ってる」
「うん、できないよね」
「やろうと思えばできるでしょ、やろうと思わないだけで」

痛快なコメントをくらいました。が、晴れやかでした。もうテスト設計とか、おれやんなくていいや！って感じです。正直やりたいと思わないし、得意じゃない、たぶん。

ということで、ワタシ、(今まで思ってた一般の)QAエンジニアになることを諦めることにしました。
(狭義の)ソフトウェアテストはしないけども、その代わり開発エンジニア・ビジネスメンバーが自動テストを読みやすい作りやすいとか、CI/CDパイプラインが元気に動いてリグレッションテストしながら自動でプロダクトがデプロイされるとか、プロダクトコード自体の品質がいいとか、品質改善につなげられるモニタリングするとか。

考えてみれば、元々エンジニア上がりだというのをあまりアドバンテージにしてこなかった(逆にQA畑でないことだけ考えていた)のかもしれないなあ、という感じです。労せず普通にソースコード読み書きできるQAエンジニアって多くないのに、それを捨ててテストエンジニアになる必要はなかった。

しかも、別にSET(Software Engineer in Test)でもないな、という感じです。テストだけをエンジニアリングするわけではなく、普通にプロダクトコードとかデプロイパイプラインとかにも携わっていきたいので。なので、「SET寄り」ではあるけどもSETではないな、という感じです。

じゃあなんて名乗るか？っていうと、結局QAエンジニアなんですよね。「品質良くしたい」というのは同じなので。QAエンジニアって元々ファジーで雲を掴むようなぼやけた職種なので、それを隠れ蓑にしようと思ってます。

ということで、肩書きはQAエンジニアのままだけど、内部的には大きな変化があったよ、というお話でした。今後ともご贔屓に！

同僚QAエンジニア2人には日々刺激をもらっていますが、特に今回は触媒として私に大きな気づきを与えてくれました。いつもありがとうね！

↓アイキャッチ用画像です、アナザースカイでパクソジュンが来てた青島！