こんにちは！ QAエンジニアとして2025年の夏に弥生に入社のテイと申します。
この記事は 弥生 Advent Calendar 2025 の23日目の記事です。
◆弥生に入っての3ヶ月。
弥生に入ってから、とにかく『知る』の連続でした。
1か月目、弥生で働く上のルールとプロダクトについて知り。
2か月目、今チームでやっているテストについて知り。
3か月目、不安感。
「…チームに何か還元できるようになるのかな…」
そう思った理由は大きく3つあります。
1.ドメイン知識（弥生で言うと会計知識ですね）が圧倒的に足りず、ユースケースの理解が追い付いてない。
2.（あるあるですが）仕様となるドキュメントが膨大だけどメンテされていなくて解読に時間がかかる
3.開発メンバーは熟練者で各自が高度なテスト観点を出している
一方、開発は当然ながら待ってはくれず、目の前には大型のリリース物が控えている。
このままではいけない。自分の不安を減らすため、自分の仕様理解を助けるためのツールが欲しい。
◆決めたゴールと方向性
ただ、仕様をイチから理解しきるには時間も知識も足りない。そこで、ゴールを決めました。
『短期間でのユースケースの理解は諦める。
今回のゴールは付け焼刃でも観点リストを作成して、中長期で理解するためのベースにする』
そうと決まれば観点リストに使える資料探しです。
観点リストの材料としてひらめいたのは「過去のテストケース」でした。
「今までテストケースを作るときには観点リストを使っていた、ならば逆算すれば抽出できる！」
そんな仮説からスタートしました。
同時に『AI使ったら時短かな…』そんな気持ちも持ちました。
とはいえ、AIをQA業務でがっつり頼ることは初めて。
翻訳や検証業務の一次レビューにAIを使ったことはありますが、ゼロから任せる経験はない。
でも、今を打開するには、の気持ちで試してみようと決めました。
◆試行錯誤と経過
当時付与されていたAIツールのライセンスは以下3種類。
・cursor（https://cursor.com/）
・Devin（https://devin.ai/）
・ChatGPT（https://chatgpt.com/）
サンプルデータを読み込ませた所、CSVの扱いが安定していたDevinを相棒にして、試行錯誤です。
⓪下準備（1時間）
今回はテストケース→観点リストの逆順で作成します。
構想を立て、対象プロダクトのBTSのCSVをダウンロードして準備完了。
ここから有効な手順を抽出してテキストマイニングの形で抽象化、と構想を固めました。
①CSVの中身の成形（4時間）
対象をユーザー操作に紐づく観点に絞るため、分類をDevinと相談しながら進めました。
まずホワイトボックスとブラックボックスの文言について整理。
例）ブラックボックス（残す）：ボタン/更新/並び替え/CSV/スナックバー/タイムアウト/排他…
ホワイトボックス（排除）：SQL/DB/ログ/内部API/移行/監視/コンソール…
ブラックボックスとホワイトボックスの境界はDevinと合わず、今になって思えば最初に判断基準のサンプルを渡しておけばスムーズだったかもしれません。
ただ、この時点で「あ、これ結構いけるかも」という手ごたえがありました。
②テキストマイニングして重みづけ（3営業日）
当初は名詞の重みづけを中心に進めましたが一般語を除外した結果、専門用語だらけになり、
同時に語同士のつながりが失われて粒度がそろわず、何がなんやらわからない、という事態に。
そこでDevinと相談しつつ方向転換。
・述語と目的語で条件抽出しなおし、なにがどうなる、の最低限動作パターンを確保する
・カテゴリを決めてグルーピングしなおす
…と、Devinと一緒に何度も試行錯誤を重ね、形になりました。
◆成果とやってみた感想
◎足掛け4営業日で土台の観点リストは達成
◎ドメイン知識が不足していても、理解を助けるための自分用の観点リストのカンペができた
○不安感が減った
○今後のAIを使うにあたっての試行錯誤の足がかりの粒度感がわかった
・観点をグルーピングしたり抽象化したりするのは得意
・一方、細かい粒度のテスト観点は苦手（一次成果物の補助として使うのがよさそう）
△結局メンテ工数が必要。
・最終調整はどうしても力業。
・再現性のあるプロンプトの確保が課題（Devinに聞いたけど有効な答えは返ってこず…）
・プロンプトの精度を上げること、出したい成果物を抽象化して言語化する能力が必要
◆まとめ
AIが当たり前に使われる時代とはいえ、「検証にゼロベースでAIを使っていいのか？」という迷い、
加えてプログラミング経験のなさから、Devinには少し苦手意識すらありました。
ただ、今回の試行錯誤でプログラミングがわからないからこそAIに、という思考に持っていけました。
なんでも自分で狭めず使ってみることが大事。
AIという味方に頼るところは任せる、自分で検証するところはする。
その線引きが今後のQAには求められていく力かな、とわかったこと、
『できないからAIに頼るのではなく、できるようになるためにAIを使う』
そのスタンスに変われたことを収穫に、これからも試行錯誤していこうと思います。
最後までお読みいただきありがとうございました！
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp
