QA専任ゼロから始めた品質組織づくり。イオンのQAチームの今とAIが変えるこれから

QA（品質保証）と聞くと、どんなイメージを持つでしょうか。開発の最後にテストをする人たち、納期に追われてしわ寄せを受けるポジション、そんな印象を持っている方もいるかもしれません。

イオンスマートテクノロジー（AST）には、ほんの数年前までQA専任の社員はいませんでした。テストは外部ベンダー任せで、全体の品質を見渡す人がいない状態。そこから組織を立ち上げ、現在はDeveloper Enablementディビジョンの下にQAの専門チームが複数のプロダクトの品質を支えています。iAEON開発ディビジョンではQAメンバーもスクラムチームの一員として動いており、AIを活用したテスト自動化も進むなど、QAのあり方そのものが変わりつつあります。

ゼロからこの体制をつくってきた二人に、これまでの道のりと、これからのQAについて聞きました。（聞き手・書き手：古屋江美子）

【目次】

QA専任ゼロからのスタート

──お二人はほぼ同じ時期にASTに加わったんですよね。白江さんは外部ベンダーのテスト管理者、当時中村さんはフロントエンド開発ディビジョン（現在のiAEON開発ディビジョン）のマネージャーとポジションは違いますが、状況はどうでしたか。

白江私は2023年の8月に、外部ベンダーのテスト管理者としてジョインしました。iAEONのリグレッションテストや、プラットフォームであるASPBのバックエンド側のテスト管理を担当していたんですが、当時は社内にQA専任の社員がいなかったんですよね。テストは外部ベンダーに任せていて、全体の品質を見る人がいませんでした。

当時の開発現場を振り返ると、一応ウォーターフォールで回してはいるんですが、仕様書やルールがきっちり整備されておらず、インフラのアーキテクチャを正確に把握している人もいなかった気がします。テストで拾えるはずのバグを取りこぼすこともあって、今とはだいぶ違いましたね。

中村私は同年の4月に、iAEONのフロントエンド開発ディビジョン（現在のiAEON開発ディビジョン）のマネージャーとして入社しましたが、似たような状況でしたね。内製化の方針はあったものの、当時はメンバーが少なく、開発ベンダー依存が多く、要件や仕様も部分的にしか把握できておらず、内製と呼べる状況ではなかったですね。

──そこからどう体制をつくっていったんですか。

白江CTO室（現在のDeveloper Enablementディビジョン）にQAチームという箱自体はあったんです。ベンダーとの契約が切れるたびに知見がゼロに戻ってしまうのを止めたいという山﨑CTOの思いもあり、社内にノウハウを貯めていくための組織としてつくられました。ただ、箱はあってもQAを専門的にできる人がいなかったので、予算や契約まわり以外はベンダーの立場だった私がほぼ担っていました。

その後、2024年の5月に正社員になりました。外部ベンダー時代は問題点が見えても、なかなか踏み込めませんでしたが、社員になってようやく手を入れられるようになりました。

──中村さんはどう着手していったんですか。

中村5人しかいなかったチームから採用を重ねて、3チーム体制にしていきました。QAメンバーもスクラムチームの中に入れています。テストだけ外に出していると、プロダクトのことを一番よく知っているのが外のテスターになってしまうんですよね。本来はチームメンバーが詳しくなるべきなので、要件の段階からチーム内で品質を見られるようにしたかったんです。

最初のうちはビジネスや経営側もスクラムに馴染みがなく、「内製になったんだからすぐ対応してもらえるだろう」と期待が先行していましたね。スクラムの考え方を説明し、開発のリズムを理解してもらうのに1年くらいはかかりました。

──お二人は見ている領域が違いますが、当初から連携していたんですか。

白江中村さんとは当初からいろいろ相談させてもらっていました。ただ、CTO室のQAチームは横断で見る立場とはいえ、当時動けるのが私だけでしたから優先度をつけるしかなくて。中村さんのディビジョンはスクラムがしっかり回り始めていたので、私は他の部分から改善を進めました。安心してプロダクトを出せる品質を目指すという方向は一致していたので、お互いのノウハウを共有しながら、それぞれのやり方で体制をつくっていった感じですね。

中村そうでしたね。考え方が近くて、どこがゴールかはお互い言わなくてもわかっているところがありました。

ベテランが集まり、見えてきた組織のかたち

──現在のQA組織の体制を教えてください。

白江Developer Enablementディビジョン QAユニットは正社員5名とパートナー4名です。ASPB、ネットスーパー、会員基盤、ECなど、フロントエンド以外の領域をプロダクト横断で支援していて、テストベンダー各社とも連携しながら動いています。最近はQA歴数十年のベテランの西原さんや、プロセス改善が得意な紺野さんも加わってくれて、体制に厚みが出てきました。

中村iAEON開発ディビジョンはスクラムの4チーム体制で、QAメンバーはチーム横断で3名います。モバイルアプリはどうしても端末ごとの実機検証が必要なので、QAの専任を置いていますが、本来は開発に吸収してしまいたいんですよね。なので今はQAメンバーにも要件の確定から入ってもらっています。その時点でテストコードを書き始められるので早いんですよ。

自動化も進めてきました。なかでもMagicPodというノーコードの自動テストツールは初期に構築していたテストコードに置き換えたツールで、今はリグレッションテストの外部依頼はゼロにできています。QAまで組み込んでスクラムを回しているのは、今はフロントエンドだけですが、うまく機能していると思います。

──体制は整ってきたのですね。何か課題はありますか。

白江人手は全然足りていません。将来的には各プロダクトに専任QAをつけたいと思っています。AIを使えば人が足りるかというと、そういうわけでもないんですよね。手を入れるほど品質の奥深さが見えてくるので。人数を増やすだけでなく、チームとしての質も上げていきたいです。

あとはオフショア開発拠点との連携にも課題があります。バックエンド基盤はオフショアで開発しているんですが、ブラックボックス化しており機能、非機能の両方に起因する障害が起きても原因を追いにくかったんです。ここも外部ベンダーの立場では声を上げにくかったんですが、正社員になって改善を提案できるようになりました。CTOの山﨑さんも尽力してやり方の見直しを進めてくれています。

──開発チームとQAの関係性はどうですか。一般的にQAは最後にしわ寄せが来るポジションになりがちですが。

中村対立するという感覚がそもそもないんです。QAメンバーもスクラムチームの中にいて、要件の段階から一緒に動いているので、あとから別の人がチェックしに来るような構図にはなりません。右手と左手みたいな感覚ですね。

白江ウォーターフォールの現場だと、難しいこともありますね。かつてSIerにいた頃は、開発が遅れたらテスト期間が削られる大変な現場をたくさん見てきました。でもASTでは、中村さんのように品質の重要性を理解してくれている人が開発側にいて、上流から品質を作り込んでいくシフトレフトの考え方で一緒に動けますし、提案もちゃんと受け止めてもらえます。ありがたい環境ですね。

「いなくても回ってるよね」が理想のQA像

──開発とQAが一体で動ける関係が築かれつつあるということですが、あらためてQAとはどういう役割だと考えていますか。

白江理想は、「あの人たちいなくても回ってるよね」くらいの存在ですね。QAがきちんと機能していれば、バグは減るし、安定してリリースを続けられるはず。逆にQAが目立つのはどこかで問題が起きているサインでもあるので、あまり前に出ずに品質を支えていけるといいなと思っています。

中村私は、「QAは気づけないことに気づかせてくれる人たち」だと思っています。iAEONって買い物のときにレジで使う日常のアプリなので、本当に幅広い方が使うんですよね。開発側が「これは使われるぞ」と思って作っても、ユーザーにとっては複雑すぎることがある。でも作っている側はなかなかそこに気づけないんです。要件の段階でQAが「それ、使えなくないですか」と言ってくれると、早めに方向を正せます。

それから、QAは「仕様ホルダー」にもなれるんですよね。iAEONは機能が100以上ありますが、開発者が見ているのはそのうちの一部です。QAはプロダクト全体を横断して見ているので、要件も含めて一番詳しいのはQAだったりするんですよ。今年のミッションとして、QAメンバーにはその役割をしっかり担ってもらおうと考えています。

白江そうやってQAが要件まで深く入っていくと、開発との線引きはどんどん薄くなっていきますよね。正しく早く動くものを作るのが開発で、ユーザーの手元で正しく動くことを見届けるのがQA。どちらもユーザーに良いプロダクトを届けたいという点では同じです。将来的にはワンチームとしてものづくりに向き合えたらいいなと思っています。

たとえば中村さんのiAEON開発ディビジョンのスクラムチームにQAメンバーを1人加えてもらって、スクラムの中で回しているQAのベストプラクティスを他のチームにも横展開していきたいんですよね。ただ、人手がまだ足りていなくて。だからこそ一緒にやれる仲間がほしいですね。

中村ぜひ。いつでもお待ちしています。

100万通りのテストをAIに任せ、人間は判断に集中する

──先ほどフロントエンドではMagicPodでテスト自動化を進めたという話がありましたが、AI活用の現状をもう少し聞かせてください。

白江MagicPodはiAEON開発ディビジョンで先行していたノウハウを共有してもらい、Developer Enablementディビジョン QAユニットでも同じツールに統一して他プロダクトに展開しています。2025年度の目標として自動テストの拡張を掲げていたのですが、1年でかなり進みましたね。リグレッションテストの外部依頼は不要になり、さらに展開先を広げている段階です。

それ以外にも、レビュー補助やテスト項目の自動生成、コード診断など、さまざまな場面でAIの活用を試しています。特定のツールに絞るのではなく、メンバーそれぞれが試したものを持ち寄って何がいいか考えるようにしていますね。人を減らすことが目的ではなく、精度を上げるためにどう使うかを考えています。

──今後さらに広がりそうですか。

白江はい。契約の見直しでオフショア開発拠点のソースコードを閲覧できる見通しも出てきました。そうなればコード自体をAIで診断して弱点を洗い出すこともできます。ウォーターフォールはプロセスがきっちり決まっている分、実はAIとの相性がよく、外部ベンダーに出す領域もAIで品質を底上げできると思っています。AIを活用する下地は整いつつあるので、テック企業としてしっかり取り組んでいきたいですね。

中村フロントエンド開発では、VS Code上のAIエージェントを使い始めています。日本語でテストの指示を出せば生成・実行・修正まで回してくれます。テストコードを人間が書く場面は確実に減っていますね。これまでテストは100万通りのケースがあっても、実際に回せる10%程度のサンプリングで全体の品質を担保していたわけですが、AIなら本当に100万通りを回せるかもしれないし、サンプリングの精度も上がるでしょう。繰り返しの検証はAIに任せて、人間はユーザビリティや使い勝手の判断に集中する流れになっていくと思います。

プログラムのコードには「人に優しいコード」「機械に優しいコード」ともう一つ「QAに優しいコード」があります。テストしやすい設計や書き方があって、AIに指示を出すときもそれを意識すれば、品質は上がっていくと思います。

品質も働き方も変える、これからのQAチーム

──QAチームではどんな人を求めていますか。

白江JSTQBのようなソフトウェアテストの基礎知識はあるとありがたいですが、それ以上に大事なのは、正解が決まっていない現場で一緒に型を作っていけることですね。出来上がったスキームがあるわけではないので、開発側とどう進めるかを一緒に考えられる人が来てくれるとうれしいです。

──最後に、入社を検討しているエンジニアに向けてメッセージをお願いします。

中村イオングループはとにかく規模が大きくて、どんなプロダクトもサービスもあります。品質を上げるフィールドとしての幅広さは間違いないですね。ソフトウェア開発では時間もスコープも予算も変わらず最後に品質が削られる「荒ぶる四天王」なんて言われる構図がありますが、もうそこに縛られる時代ではありません。AIを使いながら品質を上げて、働き方そのものを変えていける面白いフェーズだと思っています。

白江小売業の一気通貫のシステムが揃っていて、身近な生活に関わる品質を扱えるのはこの会社ならではですね。プロダクトの種類もテストの幅も広く、やれることはいくらでもあります。楽しみながら品質をよくしていける仲間と働きたいですね。

イオングループでは一緒に変革に挑んでくれる方を募集中です。どんなことをしているのか気になる方は、お気軽にご連絡ください。カジュアル面談も実施しておりますので、まずはざっくばらんにお話しましょう！