AI駆動開発が進む中で、改めて「ユーザー目線」を持つためにバグバッシュをやってみた
はじめに
AIによる実装が当たり前になってくると、エンジニアが担う役割も少しずつ変わってきます。
私たちのチームでも、Claude Codeを中心にAIを活用した開発が進み、実装そのものだけでなく、要件を理解すること、何を作るべきか判断すること、ユーザーが実際にどう使うのかを考えることに、より意識を向けるようになっています。
その中で、改めて「実際のユーザーと同じようにサービスを触ってみる」取り組みとして、今回ラッコキーワードの開発チームでバグバッシュを実施しました。
結論から書くと、バグを見つけること以上に、「普段触らない機能をユーザーとして触る時間を作れたこと」が大きな収穫でした。
一方で、実際にやってみると「ユーザー目線で見るのか、開発者目線で見るのか」「どこまでを対象にするのか」など、バグバッシュにも設計が必要だということが分かりました。
この記事では、初めてバグバッシュを実施した流れと、やってみて分かったこと、次回試したい 「利用状況 × バグバッシュ」 について紹介します。
対象読者
- 開発チームでバグバッシュをやってみたい人
- エンジニアがユーザー目線を持つための取り組みを探している人
- AI駆動開発が進む中で、エンジニアの役割を広げていきたい人
背景・課題 🤔
ラッコ株式会社では、Claude Codeを中心にAIを活用した開発を進めています。
調査・設計・実装・テスト・レビューなど、これまで人間が時間をかけていた工程をAIに任せられる場面が増えてきました。
一方で、実装が速くなれば、それだけでユーザーへの価値提供が増えるわけではありません。
「何のために作るのか」「ユーザーは実際にどう使うのか」「作ったものが本当に使いやすいのか」まで、エンジニア自身が見る必要があるのではないか。
そんな話が社内でも出るようになりました。
普段の開発では、自分が担当しているIssueや変更箇所を中心にサービスを見ることが多くなります。
そこで今回は一度Issueから離れて、実際のユーザーと同じようにサービスを触りながら、バグや違和感を探してみることにしました。
やったこと 💡
機能ごとに担当を分けて1時間触る
今回対象にしたのは、弊社が運営するSEO・キーワード分析ツール「ラッコキーワード」です。
サービスの機能をいくつかのエリアに分け、それぞれ担当を決めて確認しました。
例えば、
- サジェストキーワード・関連キーワード
- 見出し抽出・共起語
- 検索順位チェック・一括調査
- AI記事生成・料金プラン・アカウント周り
といった分け方です。
全体の時間は1.5時間。
| 時間 | 内容 |
|---|---|
| 10分 | キックオフ・担当エリア確認 |
| 60分 | 各自でサービスを触って探索 |
| 20分 | 発見した内容の共有・整理・Issue起票 |
ルールはシンプルで、この時間では修正しない。「見つけること」に集中するとしました。
明確なバグだけでなく、
「ここ、ちょっと分かりづらいな」
「ユーザーはこの動きで迷わないかな？」
といったUX上の違和感もメモします。
最後に全員で共有し、重複しているものを整理したうえで、対応が必要なものをLinearにIssueとして起票しました。
結果：やってみて分かったこと 📊
普段触らない機能を見る時間が意外と重要だった
実施して特に良かったのは、普段あまり触らない機能について意見を出せたことでした。
開発中はどうしても、自分が担当している機能や変更箇所に意識が向きます。
バグバッシュでは担当エリアをまとめて触るため、普段のIssue単位の確認とは違った視点でサービスを見ることができました。
また、最後に全員で共有してみると、同じサービスを開発していても、人によって気になるポイントが違います。
バグを探すだけでなく、開発者が一度「サービスを作る側」から「サービスを使う側」に寄ってみる時間としても意味がありそうだと感じました。
1時間では全部見られなかった
一方で、最初に想定していたよりも時間が足りませんでした。
当初はWEBだけでなくAPI/MCPも対象にする想定でしたが、実際に始めてみるとWEBだけでもかなりの機能があります。
さらにラッコキーワードには複数の料金プランがあり、プランによって利用できる機能や制限も異なります。
全部を見る、という方針では1時間では足りない。
今回は対象をWEBに絞り、API/MCPは次回以降に回すことにしました。
「何を見るか」を先に決めた方がいい
もう一つ大きかったのが、見る観点の粒度を揃えた方が良いという気づきです。
例えば、
- ユーザー目線で使いづらさを見るのか
- 開発者目線で不具合を探すのか
- フロントエンドの挙動を見るのか
- バックエンドまで確認するのか
- プランごとの差分まで見るのか
これらを全部同時にやろうとすると、確認範囲が一気に広がります。
初回はあえて細かく決めずにやってみましたが、次回は**「今回は何を見るバグバッシュなのか」を最初に決める**だけでも、かなり進めやすくなりそうです。
次は「利用状況 × バグバッシュ」を試したい 🔍
今回のバグバッシュ自体は、かなり良い感触でした。
ただ、対象を絞るとしても、次に出てくるのは 「では、どの機能から見るのか？」 という問題です。
そこで次回試してみたいのが、実際のサービスの利用状況をもとにした優先順位付けです。
すべてを均等に確認するのではなく、
- よく利用されている機能を把握する
- 利用頻度の高い機能から優先してバグバッシュする
- 発見した問題を整理し、改善につなげる
という進め方です。
全機能を同じ密度で見るのではなく、実際によく使われているところから見る。
限られたQA時間をどこに使うかについても、ユーザーの利用実態を判断材料にできるのではないかと考えています。
今後はバグを探すだけではなく、「どこにQA・改善のリソースを使うと、ユーザーへの影響が大きいのか」まで考えられる形にしていきたいです。
まとめ 📝
初めてバグバッシュを実施してみて、次のようなことが分かりました。
- 👉 普段触らない機能を、ユーザーとして触る時間を作ること自体に価値がある。
- 👉 「全部見る」は難しい。 WEB / API / MCP、プランなど、対象範囲を事前に絞った方が良い。
- 👉 見る観点も決めておく。 ユーザー目線なのか、開発者目線なのかで探すものが変わる。
- 👉 修正せず「見つけること」に集中する。 その場で直し始めないことで、限られた時間を探索に使える。
- 👉 次回は利用状況も参考にする。 利用頻度の高い機能から優先して見ることで、ユーザーへの影響が大きいところに時間を使う。
おわりに ✨
AIを活用した開発が進む中で、エンジニアの仕事は単にコードを実装することだけではなく、要件を理解し、判断し、ユーザーがどう使うのかまで考えることへと広がっていると感じています。
今回のバグバッシュも、そのための取り組みの一つです。
やってみるまでは、「どれくらいバグが見つかるか」が一番の成果になると思っていました。
実際には、普段触らない機能を触って意見を出したり、「次はこういう観点で見た方がいい」とチームで話したりできたことの方が印象に残りました。
バグバッシュは、バグを探すイベントであると同時に、開発者がユーザー目線に戻る時間でもある。
次回は今回の振り返りを活かし、実際の利用状況も参考にしながら、よりユーザーの実態に沿った形を試してみたいと思います🙌
弊社では、AIを活用した開発だけでなく、こうした開発プロセスの改善にも一緒に取り組んでくれる仲間を募集しています。興味があればぜひのぞいてみてください。
Discussion