日本語テスト自動化でコストを下げ、品質を上げる──DeNAが「マンパワー依存」から脱却した戦略とは
株式会社ディー・エヌ・エー
株式会社ディー・エヌ・エー様に、MagicPod選定の決め手や導入時から現在までの活用状況について、MagicPod代表の伊藤がお話を伺いました。
株式会社ディー・エヌ・エー
インターネットとAIを駆使して、エンターテインメント領域と社会課題領域の両軸で事業展開しています。ゲームやライブコミュニティ、スポーツ・スマートシティ、ヘルスケア・メディカルなど様々なサービスを通じて、世の中にDelightを提供しています。
POINT
- サービス長期化で増え続けるリグレッションテストが経営課題
- マンパワーに頼る品質管理を自動化し、テスト工数を大幅削減
- 要件160項目でツール比較し、機能の網羅性でMagicPodを選択
- 手動1,300項目を8割自動化で工数削減とカバレッジ向上を実現
- あえてテストを失敗させ、差分チェックする独自の活用方法も
左から
・辻 智彦さん IT本部品質管理部QC第⼀グループ
・今村 和哉さん IT本部品質管理部QC第⼀グループ
・伊藤 望 MagicPod CEO
辻さん（以下、辻）：10年ほどディー・エヌ・エーの品質管理に携わってきました。最初は主にMobage（モバゲー）でリリースするコンテンツを担当していましたが、現在はプラットフォーム自体やMobage以外のサービスも担当し、横断的に検証技術やツールの導入をサポートしています。
私たちの所属するIT本部には、プロジェクトに関わりながらテストや品質保証を担うQCの他にエンジニアリングの観点でテストを支援するSWET（Software Engineer in Test）という組織もあります。SWETが主に単体テストなど開発の「前工程」を技術で支援するのに対し、私たちの所属する品質管理部はE2Eテストなど開発の「後工程」における品質を担うのがメインミッションになっています。
今村さん（以下、今村）：私も辻と同じ検証技術チームでメンバーの育成や技術サポート、テストインフラの整備を行っています。もともとゲームのテストをメインで担当していましたが、ここ1〜2年は配信系のアプリやサービスをメインに担当しています。
弊社ではプロジェクトごとに独立性や機密レベルが大きく違いますので、全社的なツールの利用状況を俯瞰して把握するのが難しい側面があります。そうした中でも私たち品質管理部がツールを定め、全社的な品質向上を目指して導入を推進していくことが重要なミッションの一つになっています。
MagicPod導入前の課題
伊藤（MagicPod代表）：テスト自動化ツールは社内でどのように利用されているのでしょうか？
辻：ディー・エヌ・エーはもともと品質自体にこだわりを持って取り組んできた会社です。ただ、かつてはそのアプローチが「マンパワー」に大きく依存していました。例えば「大規模なプロジェクトには大人数を投入して品質を担保する」といった手法が取られることもありましたが、それが必ずしも効率的だったとは言えません。そうした背景もあり、現在はより効率的なアプローチが求められています。
社内には100人以上のテスト関係者がいるのですが、そのスキルはさまざまです。外部ツールを使わず自社開発のツールで進めるプロジェクトもあればAppiumやSeleniumを使っているプロジェクトもあり、テスト自動化ツールの利用はプロジェクトによるという状況です。
伊藤： MagicPodを導入いただく前は、別のテスト自動化ツールも使われていたそうですね。
今村：当時、リリースサイクルの高速化に対応したり、より長くサービスを提供するためにプロジェクトの生産性を上げたりする必要がありました。一方で、サービスの運用が長くなるにつれてリグレッションテストのケース数と重要度は増すばかりで、自動化が課題になっていたのです。
辻：ツールを選定する上で、まずノーコードであることが私たちにとっての第1条件でした。先ほど申し上げた通り、100人以上のテスト関係者の中には、私を含めて必ずしもコードを読み書きできる者ばかりではありません。
その前提をクリアした上で、以前使っていたツールはテストの実行回数が増えたことによるコスト肥大化の課題と、少なくとも当時はMagicPodさんのほうがモバイルアプリの検証能力が高かったという状況があり、移行を検討することになりました。
MagicPod導入の決め手
伊藤：選定の際に、MagicPod以外のツールも検討されたのでしょうか？
辻：当時は新しいツールを広く検討するというより、既存のツールと比較してMagicPodがどうか、という観点で評価を進めていました。
その中でMagicPodの導入を決めた理由は主に3つあります。まず、コストパフォーマンスが優れていたこと。次に、私たちが必須とするWebとモバイルアプリの両方に対応していたこと。そして最大の決め手は機能要件に対する網羅性でした。
多要素認証を突破する機能など、私たちが設定した160項目ほどの機能要件リストに対してMagicPodが最も多くの項目をクリアしましたので、「MagicPodでやってみよう」と導入を決定する大きな決め手になりました。
伊藤：検討から実際の移行までの期間はどれくらいでしたか？
辻：検討自体は2〜3カ月、実際の移行作業には半年ほどかかったと思います。ただ、かなり早い段階で手応えを感じており、使い始めて3カ月後には「このまま移行しよう」という方針が固まっていた記憶があります。
トライアル用のアカウントを発行していただきましたので、早い段階から本格的な環境で機能の検証を進めることができました。そのため移行の判断と、実際の移行作業を並行して進めることができました。
伊藤：ツールの良し悪しを別にしても、切り替えに手間がかかる現場としては抵抗感もあったのではないでしょうか。
辻：もちろん現場からは「すでにツールが安定運用できているのに、なぜ変えるのか」という声がありました。しかし、移行にかかる労力を差し引いても、コストパフォーマンスと機能の網羅性のメリットが大きかったです。料金的にも「まず1年間試してみよう」と思えるレベルでしたので、あまり迷うことなく思い切った舵取りが可能でした。
伊藤：実際、切り替えはスムーズに進んだのでしょうか？
辻：大きな混乱はありませんでした。MagicPodのサポート体制やヘルプドキュメントが非常に分かりやすかったおかげで、導入でつまずくことがあっても、すぐに解決策を見つけることができました。アプリの準備や認証設定などが分かりやすかったのに加え、サポートメンバーの方と直接やり取りできるSlackチャンネルで迅速に回答いただけたのも助かりました。
もちろん新しいツールなので学び直さなければならない部分はありましたが、全体として特に大きな問題はなかったと感じています。現在は、ほぼ移行が完了しています。
今村：ツールが変わったことで現場から「以前はできなかったことができるようになった」という声も上がっています。テストシナリオをゼロから作り直す手間はありましたが、それを考慮しても移行の判断をしてよかったという印象です。
MagicPodの活用状況
辻：導入から約90アカウントを発行していますが、アクティブなメンバーだけでなくお試しで使っているメンバーも含みます。アカウントの発行数に制限がないところもMagicPodの良いところで、権限管理はしますが「とりあえず触ってみたい」といった需要に応えられています。
アクティブなところでは活発に活動しているプロジェクトが4つぐらいありまして、それぞれコアユーザーが2、3人いるイメージです。具体的にはゲームやライブコミュニティ、ヘルスケア関連のサービスで利用しています。ゲーム関連では、ゲーム本体というよりユーザー様により快適な体験を提供するための「専用ブラウザ」のようなツールの開発で活用しています。
一般的なゲームの場合はどのブラウザでプレイするかといった再生環境をユーザー様自身が選びますが、私たちが専用ツールを提供する以上、その再生環境自体の品質を保証しなくてはなりません。そのためツールのアップデートを重ねる中で、意図しない不具合が発生しないかを確認するリグレッションテストが非常に重要です。
伊藤：MagicPod導入前のリグレッションテストは手動で行っていたのでしょうか？
辻：仰るとおりで、そこに課題がありました。私たちのチームはスクラム体制で開発スピードが速いのですが、そのリグレッションテストはずっと手動で、本来は1300項目ほどあるテストを70項目ほどに絞って行うのがやっとでした。
それがMagicPodの導入でテスト項目の8割を自動化でき、担当者の工数削減はもちろん、テストカバレッジも格段に向上しました。時間に余裕が生まれたことでテスト環境を増やすといった、より品質を高める活動も可能になったのは大きな成果です。今も手動で残っているのは、タイミングの確認など、どうしても目視が必要になる200項目ほどです。
今村：関連する複数の確認項目を一つのシナリオにまとめるなどの効率化もできていると思います。他のプロジェクトでもそういった工夫はよく見られますね。
伊藤：ゲーム本体のテストに活用するのは難しいのでしょうか？
今村：ゲームはイベントやキャンペーンなどでUIや表示内容が頻繁に変わるため、その都度テストをメンテナンスしていくのが大変です。
辻：ゲーム本体のリグレッションテストに本格活用するのは正直まだ難しい面がありますが、「表示が正しく更新されているか」を確認する少し特殊な使い方はしています。
例えばゲーム内のお知らせやイベントバナーなど、毎週のように表示内容が変わる箇所の変更を手作業で確認する代わりとして、MagicPodを使っています。テストを意図的に失敗させて、その時点の画面を比較することで、「意図した表示に更新されているかを効率的に確認する」という使い方です。
ただ、その使い方だとヘルススコア（※）が低くなってしまうというのが難点です（笑）。MagicPodとしては本来の使い方ではないのかもしれませんが、手動より早く正確なので活用させてもらっています。
※MagicPodのテスト健全性を示す指標
社内でのMagicPod導入推進
伊藤：初めての方向けのオンボーディングはどのようにされていますか？
辻：品質管理部として提供しているものは特にないです。そもそも使いやすいので「使ってみればわかるだろう」という認識で、必要性を感じていません。ただ、導入を推進する立場としては活用できているか気になりますし、導入を検討しているプロジェクトへのプッシュは行っています。
伊藤：導入を推進していく上で、どのようなことが課題になるのでしょうか？
辻：新しいプロジェクトといっても別のプロジェクトでMagicPodに関わったことがあるメンバーがいることが多く、MagicPodの存在や使い方についてそもそもの話になることは多くありません。
それより課題になるのは、「テスト自動化に対するアレルギー」のような、文化的な抵抗感です。例えば「手動で確認したほうが早い」という思い込みや、「リグレッションテストよりも優先すべきタスクがある」といった考え方です。
ただ、会社全体の体質もここ数年で大きく変わってきました。サービスを長くユーザー様に届け続けるため、運営コストをいかに削減し、利益を生み出していくかが重要になります。かつてのようにマンパワーに頼るのではなく、よりリーンで筋肉質な組織運営を目指すようになっています。
その文脈で、品質を落とさずにコストを管理できる「テスト自動化」は、以前にも増して重要な位置づけになっています。数年前なら人海戦術で対応していた部分を、今はAIなども活用しながら自動化し、「人間はより重要な判断に集中する」という意識へと会社全体がシフトしてきていると感じます。
だからこそ私たちの推進活動としても、安定した品質をユーザー様に届け続ける上でリグレッションテストがいかに重要か、その大変な作業を自動化することの価値を伝え、理解を広げていくことが中心になります。
伊藤：チームに価値を伝えていく中で、辻さんなりに「こういう言い方をすると響きやすい」といった推進のコツのようなものはありますか？
辻：そうですね。少し大げさかもしれませんが、「AIのように新しい技術を吸収していかないと、これからの時代は生き残れない」という危機感を共有することを意識しています。テスト自動化のスキルは個人の市場価値にもつながります。「会社の費用で新しいツールを試せる良い機会なのだから、積極的に活用してみようよ」と背中を押しています。
もちろんツールを使うこと自体が目的になって本来の業務が進まなくなったり、セキュリティリスクを見落としたりしないよう、管理者としてバランスを取ることは常に心がけています。
最後に
辻：個人的には、大規模なチームよりも、むしろ小規模なチームや、多くのプロジェクトを抱えて大変な思いをされているチームにこそ、MagicPodのような自動化ツールを試していただきたいと強く思っています。
自動化によって、機械に任せられる作業と、人間が集中すべき創造的な作業との「メリハリ」がつけられるようになります。まずは「自分の時間を確保する」という身近な目的からでも構いません。自動化に真剣に向き合う姿勢を持つことが、チームの働き方を大きく変える重要な一歩になるのではないでしょうか。
今村：MagicPodは日本語で使えるノーコードツールとして、使いやすさとコストパフォーマンスに優れていると感じます。リグレッションテストを軽視せず定期的に実行したいけれど、人員が少ないプロジェクトや、小規模なプロジェクトをたくさん抱えているテストチームには、まさしく相性が良いと思います。
導入当初は大変なこともあるかもしれませんが、私たちの場合はエンタープライズプランの柔軟なサポート体制に何度も助けられました。ですから、もし悩んでいる方がいらっしゃれば、まずは一度相談してみることをお勧めします。
実際にツールを導入してみると、これまで当たり前だと思っていた手動テストのプロセスそのものを見直す良いきっかけにもなります。単に手作業を置き換えるだけでなく、そうしたプラスアルファの価値を実感していただくのが良いと思います。
撮影場所：WeWork 渋谷スクランブルスクエア
