はじめに
NewsPicksでQAエンジニアをしています、西薗（@yurizono）です。家事・子育てに日々忙しく、最近は外部登壇をサボっていました。せめてブログくらいは書こうと思います。師走ですね！
データ取得、データ加工
AI、私はClaudeを使っていますが、これによってコーディングはとても楽になりました。楽になった、というか、これまでであれば面倒くさくて着手もできなかったようなタスクでも取り組めているという実感があり、生産性は何倍とかいう尺度では測れないレベルで向上しています。
もう一つ、ほぼ同じなのですが簡単になったなと思うことがあります。それが、『（どこかに格納された）データを取得すること』『データを加工すること』です。
やりたいこと
自動テストの改善を数ヶ月やってきて、ちょっとずつ安定してきたように感じる。しかし推移が定量的にわかるデータがない。そこで成功率の推移をグラフにして、明日の会議で紹介したい。
面倒臭さ
さて、データはどこにあるでしょう。例えばNotion上にあります。Excelファイルのこともありそうです。Oktaログインした先の、社内システムでアクセスできるページにあることもあるでしょう。またシステムに関連するデータは、AWSのS3なんかに入っていることが多そうです。今回の「自動テストの結果」はS3に入っていました。
その、使いたいデータはどんな形をしているでしょうか。HTMLかもしれません。表形式（TSVやCSV）になっていれば運が良いですね。プログラマのみなさまであればJSONにも馴染みが深いでしょう。Excelファイルの中のシートの一部が表になっているパターンもありそうです。「自動テストの結果」はJSONのようです。
このあたりの取得と形式の問題を解決したら、あとは欲しいフォーマットになるように加工をするだけです。なんらかのプログラミング言語を知っていれば難しくありません。なのですが、この取得と加工の入り口のところが、実にいろんなパターンがあって面倒臭いんですよね。さて、AWSから大量のファイルを取ってきたいので aws コマンドのリファレンスを探しましょうか……。
ところで、やりたかったことはなんでしたっけ。データを取ってきて、それを加工して、グラフなりにして明日の会議に持っていきたいんですよね。別に新しいAPIを使ってみたいわけでも、CloudFrontについての知見を深めたいわけでもありません。こういった日々の小さなタスクの積み重ねがスキル向上に繋がっていくわけで、それは否定しませんが、面倒な時もありますし、私が何かを理解するのを悠長に待ってくれないケースだってあるでしょう。このデータは明日使いたいし、もう夕方だし、子供をお風呂に入れないといけません。
データがあれば、それを活用するのは簡単
そんな、従来であれば私レベルのプログラマにとって少し骨の折れる作業であっても、AIの助けがあればあっという間です。前提として抑えておくべき知識・スキルセットはこのあたりでしょうか。
- やりたいことの全体像が説明できる（自動テストの実行履歴を手元に持ってきて、SuccessおよびFailの数を時系列でグラフにする）
- データの格納場所が明らかである（自動テストの実行結果はawsの開発環境にあるなんとかって名前のS3 Bucketにあって、ハッシュ値っぽい名前のディレクトリに入っている。本体は多分JSONファイル）
- データの取得方法について当たりがついている（細かいオプションは知らないけど
aws s3コマンドを使えば多分いけるだろう） - 作業のアウトプットが具体化できている（グラフは自分で作るから、CSVファイルになっていれば良い。カラムは実行した時間、成功したテストの数、失敗したテストの数かな）
- 作業中に発生する、ちょっとした技術的トラブルを自力で解決できる程度のスキル・知識があること（例えば私はプログラマとして新卒4年目くらいまで過ごし、以降はQAエンジニアをしています。基盤周りの知識不足を日々痛感していますが、コーディングはまぁプログラマとしては可もなく不可もなくレベルです、多分）
あとはやりたいことやデータの格納場所、取得方法、アウトプットイメージを構造化してAIに伝えることができれば、タスク実施は難しくないはずです。実際のところ、スクリプトの実行も含めて30分ほどでグラフは完成しました。初版のスクリプトは、ダウンロードしてきたファイルがなぜか読めずにエラーを吐きましたが、すぐに理由に思い当たりましたので、AIに「gzip解凍する処理を入れて」という指示を出してことなきを得ました。
前提は変わるのか
現時点では私の場合、NotionにあればNotionAPIだなとか、ExcelファイルならPowerShellでいこうとか、そういった技術的な前提をAIに伝えた上で実装方針を相談しつつ、コードを作成する、という流れで進めています。しかしそのあたりはよしなにやってくれる程度にはAIも進化してきており、特別な理由がなければ技術選定から全てお任せしても良いでしょう。
またAIの進化に伴って、上記の前提もどんどん変わっていくことと思います。例えば、ちょっとした技術的トラブルの解決は全てAIがやってくれる日も近そうです。そうなるといよいよ技術的詳細については知識がなくとも、こういったタスクはこなせるようになりそうですね。
ただ結果の正確性をどう判断するのか、という問題は残ります。プログラマであれば生成されたコードのレビューをすれば良いわけですが、それができない人はどうするのか。フォルダの数とレコード数が合っているかを数えるとか、サンプリングでjsonファイル内の値とcsvの値が合っていることをチェックする、というあたりが思いつきましたが、それらも手段の詳細がある程度わかっていないと採れない方法です。
私が例えば数学の難問をAIに解かせたとして、その解法がスマートなのかとか、そもそも答えはそれでいいのかを判断する手段は「誰か詳しそうな人に聞く」くらいしか思いつきません。
そう考えると、プロとして自分の責任で成果物を作るという前提で考えると、最低でもこのレベルの知識はないとAI活用は難しいよね、というラインはあると思いますし、そのラインが「全くの素人」にまで降りてくるにはそこそこ時間がかかりそうだと感じます。
QAエンジニアとしての優位性
ところで私の本職はQAエンジニアです。先ほどの数学の難問の例は極端であるにせよ、私の仕事は「すでに持っている知識の範囲」だけで行うものではありません。ドメイン知識は多くの場合、都度仕入れるものですし、設計も都度渡されて読み込むものです。つまり、前提知識がない中で、与えられた成果物が仕様や設計に沿っていることを確認するための武器を持っています。
そう考えてみると、我々QAエンジニアこそAIをガンガン使っていくべきであり、使っていけるポテンシャルがあると言えませんか？
とはいえこの言説は少し「手段」に寄り過ぎている面はあります。もっと大前提のところ、「必要なのはグラフなのか」「そのグラフで何を説明したいのか」「その説明は何を目的にしているのか」「そのプロジェクトが達成したいことは何か」といったところをいま本職として取り扱っている人たちこそ、AIがエンジニアを食い尽くした後に残るのだろうと思います。ただしその人たちにも、AIが出してきた成果物の妥当性を確認するスキルが求められることは間違いありませんから、「元々QAエンジニアだった未来の私たち」が生きていく余地はあるはずです。
さいごに
ChatGPTの登場から業界が大きく変わろうとしていますが、その変化に比べると、私個人の働き方は極めて緩やかにしか変わっていません。こうやって人は流れに取り残されていくのだろうと感じます。それでも、少しでもエンジニア寿命を伸ばすべく、AI時代についていきましょう。とりあえず、データ取得と加工をエンジニアに依頼するのではなく、自分でやってみるところから始めてみませんか。