こんにちは、UbieでQAエンジニアをしている ackey です。
今年の10月からアプリチームのスクラムマスターとQAエンジニアを兼務していましたが、12月からアプリのテスト戦略&推進を進めるため、QAエンジニアに専念しています。
本記事では、LLMを活用した不具合分析とそれに基づくテスト戦略の立案プロセスについて紹介します。LLMを活用した新しいQAアプローチに興味のあるQAエンジニアやスタートアップでの迅速な意思決定プロセスに関心のある方々にとって参考になる記事となれば幸いです。
1. 背景
Ubieでは、React Native（with Expo）を採用したアプリ開発を行っています。この技術スタックを用いて、ユーザーに価値を素早く届けることを目指しています。
そんな中、今年の10月にアプリの新機能開発を担当するチームが誕生しました。このチームは元々Webアプリケーションの開発を担当しており、週に40-50件ものリリースを行うなど、非常にスピード感のある開発を行っていました。
チームの扱うテーマがアプリ開発に移行した後も、OTAアップデート等の仕組みも活用しながら迅速な開発を進めています。
しかしながら、既存のアプリコードでは、バックエンド側のテストは比較的実装されていましたが、React Nativeで構築されたフロントエンド部分にはほとんどテストが存在しない状態でした。
そのため、新機能の開発を進める中、リリース前のQA工程で多くの不具合が検知される状況が続き、素早いリリースを妨げる要因となっていました。
今後の開発速度を維持・加速させていくためにも、よりシフトレフトな品質保証活動を増やすことは必然でした。
2. LLMを活用した不具合分析
まずはじめに、LLMを活用して迅速に不具合分析を行い、現状を明らかにした上で、初手で取り組むべき活動の方向性を絞り込むことにしました。
この分析から始めたのは、「開発速度の維持・加速」という目的を見失わないように、データとして客観的事実から改善の検討を始めたかったからです。
また、最初にLLMを利用しようと考えた背景には、Ubieの生成AI活用環境があります。
自由に使いたい放題の「社内用生成AIWebシステム」のおかげで、セキュリティを確保しつつ、効率的にLLMを活用可能な状態でした。
(参考) 社内システムの詳細：
2.1 モデルの選択
今回の分析には、Anthropic社のClaudeを選択しました。ClaudeはGPT-4を超える性能を持つと言われています。
Claudeを選んだ理由は「精度の良さと十分な入力トークン数」という単純なものでした。
よくよく調べると、以下の特性が、不具合データの詳細な分析と分類に適していたようです。
- 高度な文脈理解能力と一貫性のある出力
- プログラミング知識とテクニカルな文脈の適切な理解
- カスタマイズ性の高さと効率的なデータ処理能力 (出力トークン数もある程度大きい)
2.2 プロンプトの作成
社内システムのプリセットストアに登録されている「ゴールシークプロンプト」を活用しました。「ゴールシークプロンプト」とは、プロンプト自体をAIに作ってもらう手法で、人間がテーマを与え、AIからの逆質問に回答することを繰り返しながら最終的にプロンプトを作る段階的なプロセスを提供するものです。
具体的には、以下のようなプロセスを経てプロンプトを作成しました：
- [私] 不具合分析のためのプロンプトを作成したい旨を伝える
- [AI] プロンプト案、改善のための提案、追加情報を得るための質問を返答
- [私] 「分析項目として含めてほしい要素」「現在の開発プロセスの課題」「ReactNativeのアーキテクチャ情報」などの詳細を提供
...以下完成まで繰り返し。
この方法により、不具合データの分析に特化した、高品質なプロンプトを効率的に作成することができました。また、このプロセスを通じて、分析の目的や期待される結果についても、自分の中で明確になっていったと感じました。これにより、後の分析作業がより焦点を絞ったものになったと思います。
最初の要望を伝える様子
2.3 データの準備と分析
Jiraからエクスポートした2ヶ月分の不具合情報をCSV形式に整理し、作成したプロンプトとともにLLMに入力しました。
2.4 結果の検証
分析結果が出た後、具体的な不具合事例数件について分類された工程の整合性を確認しました。また、AIに分類理由を質問することで、判断基準の妥当性を検証しました。そのやり取りの中で、一つの問題が複数のカテゴリに該当する可能性がある場合、より低レイヤーのカテゴリに分類するルールをLLMに伝え、結果の一貫性を確保しました。
2.5 不具合の分類
LLMは不具合を分類したうえで、「要因カテゴリ」「件数」「混入工程の推測」「改善方針案」の情報を整理してくれました。
実際の分析結果
この分類により、各カテゴリーの割合や特徴が明確になったと感じました。例えば、UI/UXの不整合が最も多く、全体の約32%を占めていることが分かりました。
3. 分析結果と効果
上記の結果を踏まえて追加の分析をAIに行ってもらった結果、フロントエンド部分にユニットテストとインテグレーションテストを導入することで、約58%の不具合が開発の早期段階で防げる可能性が示されました。
ここまでにかかった時間はなんと2時間半。分析結果の整理も含めると約3時間ほどで関係者への共有ができました。
slackでのシェア
開発メンバーの反応
4. 今後の改善方針とチームの変化
分析結果の共有後、具体的なテストの拡充戦略を考えるにあたり、社内のアプリ開発メンバーや社外のReactNative有識者との意見交換を行いました。検討の結果、ざっくりいうと「Testing Trophy」[1] の概念に則り、インテグレーションテストから拡充していく方針に決定しました。
また、決まったテスト戦略の詳細をAIに投入した結果、
「短期的(~1ヶ月)には新プロセスの学習コストによりリードタイムが10%ほど増加するが、中長期的には1リリースあたり15%ほどのリードタイム短縮が見込める」というそれっぽい試算をだしてくれました。
不確実性はありつつも、当初の目的の「開発速度を維持・加速させていくためのテスト戦略」に沿った形で初期の検討がすすめられたのではないかと思います。
具体的な取り組みや成果については、改善が進み次第、別途報告させてください。
チームの変化として驚いたのは、不具合分析結果を共有した翌々営業日に、「テスト書いてみたらかけたのでテスト実例とTips共有するよ」という投稿が社内のslackに上がったことです。
早すぎてビビった
Ubieメンバーの圧倒的行動力を目の当たりにし、分析に時間をかけず正解だったなと心底思いました。
5. LLMを使って良かったこと
以下、今回LLMを利用して良かったと感じたポイントです。
客観的な結果提示
最初にAIによる分析結果を共有することで、特定の立場や役割に関わらず、客観的なデータに基づいた議論を始められたことが大きなメリットでした。これにより、QAエンジニアを含むチーム全体が、フラットな立場から改善策を検討できるようになったと感じました。
適度な精度と迅速性のバランス
今回の利用用途では、精緻な分析結果よりも、ある程度の信頼性を持つ情報を基に迅速な意思決定ができることの方が、価値があると実感しました。スタートアップの環境下では、完璧を求めるよりも、適切なタイミングで行動を起こすことが重要であり、LLMの活用はこの点で大きな効果を発揮したと考えています。
迅速な意思決定を低コストで実現
人間が行うと1日以上かかる分析が短時間で完了し、迅速な意思決定につながったと実感しました。さらに、AIの実行コストと比較しても大幅に安価でした。エンジニア1人が1日かけて行う分析のコストを仮に3万円とすると、LLMを使用した場合のコストは1000円弱で済み、約30倍のコスト効率を実現できたと考えています。
新しいLLM活用余地の発見
品質保証におけるLLM活用事例はテストケースの自動生成など実務効率化用途のものが多い印象ですが、今回はテスト戦略の意思決定の根拠となる情報整理にLLMを活用できることがわかり個人的には新たな発見でした。今後もLLMと二人三脚でいろいろな業務を効率化していきたいと思います。
6. おわりに
本記事では、LLMを活用した不具合分析とそれに基づくテスト戦略の立案プロセスを紹介しました。約58%の不具合が実装段階で防げる可能性があるという具体的な数字は、「テストをかくこと」へのモチベーション向上につながり、実際のテスト実装にも素早くつながったと実感しています。
シフトレフトな活動のおかげで、リリース前QA工程での不具合が減る quick win
この経験は、LLMが単なる開発ツールではなく、組織の意思決定プロセスを加速させ、さらには組織文化の変革を促進する強力な味方になり得ると感じました。
今後も、こういったアプローチを積極的に取り入れ、開発プロセスの継続的な改善に取り組んでいきたいと考えています。
そして、この取り組みで初速が出せたのは、データに基づく意思決定を尊重し、新しいアイデアに対してオープンなUbieの文化があってこそだと感じています。技術と文化の両面から組織を進化させていくことの重要性を、改めて認識させられた貴重な経験となりました。
現在、Ubieではさらなる改善をすすめるため、QAエンジニアの採用を強化しています。アプリチームでは、インテグレーションテストの拡充を皮切りに、E2Eテストの最適化、不具合分析駆動での改善サイクルの確立、テストに限らないシフトレフト活動など、段階的にすすめていきたいと思っています。LLMを活用したQA活動のアップデートに興味のある方、ぜひ一緒に働きませんか?
下記募集かXのDM でご連絡いただけると嬉しいです。
-
React Testing Libraryの開発者であるKent C. Dodds氏が提唱している、どのテストを重視すべきであるかをトロフィーの形で表現した考え方のこと https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests ↩︎
Discussion