こんにちは、UbieでQAエンジニアをしているackeyです。
本記事では、弊社のQAエンジニア4名で始めた「生成AI活用もくもく会」の取り組みについて紹介します。
生成AIをもっと業務に取り入れたい方、チームでの生成AI活用を推進している方の参考になれば幸いです。
はじめに：なぜもくもく会をはじめたのか
Ubieでは「生成AIネイティブ企業」を目標に掲げており、職種を問わずあらゆる業務で生成AI活用を推進しています。
そのような背景もあり、QAエンジニア同士で、「生成AI時代のQAにおいて、近い将来どのような変化が起きうるか、そこで生まれる課題はなにか、自分自身はどう変わるべきか」といったテーマを話す機会が増えたので皆で集まってブレスト会を行いました。
ブレスト会で出た足元の課題として、以下のような意見がでました。
- 日々社内でベスプラが流通しているが追いきれておらず、生成AIを使い倒してる状態とはいえない
- AIを活用しようという発想に至れていないだけで効率化できるケースがもっとありそう
- シンプルに生成AIツールの素振りが足りていない(時間がとれていない)
そこで、「自分の思考の枠内だけでは気づけない活用方法も、複数人で取り組むことで新しい発見につながるのではないか。」「最初のつまづきをクリアできれば、各自の試行錯誤スピードが加速できるのでは」という思いから、もくもく会という形での取り組みを試してみることにしました。
もくもく会の設計
事前準備不要、かつ、実践的な学びの場となるよう、以下のようなシンプルな形式を考えました。
テーマ
参加者の誰か1人が持ち寄った「業務上の具体的な課題」をテーマとする。当日、具体的な課題が思いつかない場合は、最近の業務を振り返りながら生成AIの活用可能性を探る。
もくもくスタイル
参加者全員で、生成AIを活用しながら課題の解決に取り組む。
1人の課題に全員で取り組むことで、より深い議論と発見が生まれることを狙いとしました。
頻度
隔週開催
取り組み手順
1時間という限られた時間を以下のように区切って実施しました：
1. チェックイン（5分）
参加者の生成AI活用状況の共有と本日の進め方の確認
2. テーマの共有と理解（10分）
参加者の1人より、今日もくもく会で解決したい課題と背景を共有
3. 実践（15~20分）
meetで画面共有をし、参加者同士で意見を出しながら課題に取り組む
4. 振り返り（15分）
1人一言ずつ、今回のもくもく会で得た学びを共有
5. 次回のテーマ相談（5分）
実際の様子をレポート
実際に、@tmasuharaさん(以下massu)のチームが運用している「テスト自動化ツールのTypeScript移行」をテーマにもくもく会を行った様子をご紹介します。
テーマ概要
ツールの概要
- Playwrightベースで実装された管理画面の入稿確認自動化ツール
- YAMLファイルから設定を読み込み、toCサービス上の操作を自動実行
- 画面のスクリーンショットとWebM動画をGoogleドライブに保存
- ツールの利用者はWindows環境だが、開発環境はMac。両環境で動作する必要がある。
現状の課題
- Pythonで書かれた一部のコードを、会社の標準技術スタックであるTypeScriptに移行し、メンテナンス性を向上したい。
- オーナー変更で引き継いだコードのため、影響範囲を把握しきれていない。
画面共有で、ツールの仕様を教えてもらっている様子
実践の様子
Cursor※を使って探索的に作業を進めました。最初は「どこから手をつければいいのか」という基本的な疑問からスタート。
※AIコーディング支援ツール「Cusor」の詳細は以下を参照
「まずはやりたいこと伝えて懸念点を聞いてみよう」とCursorに依頼：
「結構変更範囲大きそうだね」
「一気に変えるのは大変そう」
「このうち一番影響範囲の少ないファイルはどれ？」と質問：
「なるほど、run.pyが一番影響範囲が少ないのか」
「他のファイルも書き換える必要はあるのかな？」
「いっきに全部動かなくなる可能性はない？」
などの疑問が噴出。
Cursorに疑問をぶつける：
「このPython Scriptを外部コマンドとして実行しているだけだから大丈夫なのか。」
「じゃあ実際に変換コードを生成しよう。」
CursorのChat機能を使って具体的なコード生成に着手
「コードの変更提案に対して、変更箇所ごとにacceptかrejectを選べるんだ！」
「そう、これやると実際にファイルに反映してくれるのよ、便利だよね。」
動作確認
変換終了後、実行コマンドを動かし確認をすると...
「おお！ちゃんとpassして正常終了してる！」
実践からの学び
「やっぱり一気に全ファイル変更すると、デバッグとかは面倒そうだよね」
「そうそう、問題箇所の特定とかが変更がでかすぎると大変だから」
「以前Cursor試したとき、雑にaccept繰り返してたらエラーになってどこでエラーが起きてるか全然分かんないってことがあったんで、こういうアプローチは確かにいいかも」
という具合に、実践を通じて具体的なアプローチの学びも見えてきました。
ただし、この時点でいくつかの課題も残っていました：
「TypeScriptの文法エラーがまだ残ってるな...」
「Mac環境では確認できたけど、Windows環境での確認は持ち帰りになりそう」
それでも、15分という短時間で具体的な成果が出せたことに、全員が手応えを感じました。
「意外と早かったね。30分経ってないよ」
「最初のCursorへの質問から挙動確認まで15分くらいだね」
「もっとかかる印象だったけど」
AIとの対話を通じて段階的にアプローチすることで、想像以上にスムーズに進められることが分かりました。今回のもくもく会では1ファイルのみの変更でしたが、「今後他のファイルも同じように変更できそう」という見通しも得られて一石二鳥だったようです。
参加者の振り返りコメント
実践を終えて、参加者それぞれから気づきを共有しました。
massu (=今回のテーマを持ち込んだ人)
生成AIによって、いつかやりたい系の改善にQAエンジニアが手を伸ばせる領域が広がったと感じた。デバッグとかテストとか変更どう進めていくかは経験が必要で、このあたりはCursor使いつつ慣れていきたい。1個ずつ変更していって変更影響範囲を小さくコントロールする進め方とか参考になった。
Yamachan
自分のプロダクトチームのE2Eテスト改善にも使っていきたい。今回のようなツールはプロダクションコードと疎結合だから無邪気に試しやすいから取り入れやすいね。もっと使いこなして面白いことがしたい
May
みんなで画面みながらCursorつかう様子を見てると、こんな使い方があるのかとツールのtipsがいっぱい発見できた。少しずつ自分でもつかってるけど、もっと効率的にできる部分がありそうと気づけてよかった。
ackey （=筆者）
普段あまり使ってなかったCursorのChat機能の理解が深まったのがよかった。作業効率あがるのはもちろんだけど、仕様の理解とかエンジニアリングの知識も学べるのが大きい。相手がAIだと時間問わず何回同じこと聞いても罪悪感ないから、質問しやすくて心理的安全性高くていいね。
おわりに
今回は「生成AI活用もくもく会」の取り組みの様子を紹介しました。
突発的に試してみた取り組みでしたが、各自の持ち場で活かせる学びが生まれて良かったなと感じます。
次回はYamachanのチームで運用している E2Eテスト改善をテーマに取り組む予定で今から楽しみです。
現在、Ubieではさらなる改善をすすめるため、QAエンジニアの採用を強化しています。
LLMを活用したQA活動のアップデートに興味のある方、ぜひ一緒に働きませんか?
下記募集かXのDM でご連絡いただけると嬉しいです。
カジュアル面談も大歓迎です。
Discussion