リグレッションテストの自動化で実行工数を50%削減!暗号資産取引サービスの品質と安全性を支えるQA改革とは

コインチェック株式会社

モバイルアプリテスト ブラウザテスト

MagicPod代表伊藤が、コインチェック株式会社でQAをリードする板山豪さんに、MagicPod選定の決め手や導入時から現在までの活用状況についてインタビューしました。


コインチェック株式会社

コインチェックはアプリダウンロード数6年連続「国内No.1」の暗号資産取引サービス「Coincheck」を運営しています。「新しい価値交換を、もっと身近に」をミッションに掲げ、最新のテクノロジーと高度なセキュリティを基盤として、ビットコインイーサリアムなどの暗号資産やブロックチェーンにより生まれる「新しい価値交換」を身近に感じられるように、より良いサービスの創出を目指しています。



POINT

  • 導入前は自動テストが属人化し、リグレッションテストの実行工数も課題に
  • MagicPod導入で誰もがテストを作成・管理・実行できる体制を構築
  • 定期的な死活監視で本番環境の不具合を早期に検知し、迅速に対応可能に
  • APIテストも自動化、テストピラミッドに基づく安定した体制を強化
  • フレームワークを活用し、QA組織の強化と継続的な品質向上を目指す

左から ・板山 豪さん アプリケーション基盤部 QAEグループ グループリーダー ・伊藤 望 MagicPod CEO

左から
・板山 豪さん アプリケーション基盤部 QAEグループ グループリーダー
・伊藤 望 MagicPod CEO


板山さん(以下、板山):コインチェックには2023年5月に入社し、現在はQA戦略の策定と実行、テストプロセス改善、MagicPodやQualityForwardなどのツール導入・運用、外部ベンダーとの折衝などを担当しています。

QAEグループは開発組織の中でアプリケーション基盤部という、ログイン周りや、使っているソフトウェアのバージョンアップの検証、インフラ周りを担当する部署に属しています。正社員が2名と業務委託が6名の計8名体制で、品質に特化したグループとして活動しています。

私はソーシャルゲームのデバッガーからキャリアをスタートしまして、前職はLINEヤフーコミュニケーションズ(旧LINE Fukuoka)でQA業務や、Seleniumを使ったテスト自動化を経験しました。MagicPodを用いた自動化も経験しており、それが今回のスムーズな導入につながりました。

伊藤(MagicPod代表):LINEヤフーコミュニケーションズさんは以前、ユーザーインタビューをさせていただいていますが当時、板山さんも在籍されていたのですね。コインチェックさんでもご利用いただきありがとうございます! 

先ほどQAEグループは品質に特化したグループというお話でしたが、どのような活動をされているのでしょうか?

板山:入社当初はチームによって「結合テスト」や「システムテスト」といった用語の解釈や認識にばらつきがある状態でしたので、テスト用語の定義や使用方法についても統一化を図り、ルールを明確化していく活動をしています。

テストプロセス自体の改善、開発プロセス全体への関与、品質文化の醸成など、QAEグループで改善していこうと日々、取り組んでいます。


MagicPod導入の経緯

板山:私がジョインする前のコインチェックはウォーターフォール型の開発プロセスを採用しており、各開発工程の後にテストフェーズを設けて、テストが完了したらリリースするという流れでした。当時はまだQAEグループがなく、第三者の検証会社がテスト設計と実施を担当していました。ただ、いくつか課題がありました。

一番の課題は、テストプロセスが整備されておらず、開発メンバー各々がテストの品質を担保していたことです。テストに対する意識は高かったものの、体系的に運用できる形にはなっていなかったのでテストのやり方やテスト結果の可視化にばらつきが生じ、我流のやり方になっていました。

また、モバイルリグレッションテストのテストケース数も1400件ほどあり、それを手動で実施していたため、実行に4人日/月ほどのリソースを割いていました。これはチームにとって大きな負担でした。以前導入されていた自動テストツールも、メンテナンスされず形骸化していました。

伊藤:何か問題があったのでしょうか?

板山:自動テストツールを導入したものの、専任で担当できる人をアサインできなかったため、計画的な運用が難しい状況でした。また、ツールの運用には特定のスキルが必要であり、チーム内でそのスキルを持つ人材が不足していたことも、運用が継続的に行えなかった要因の一つだと思います。そのうえ、そのツールには実行回数に上限があったことも、形骸化を招いた原因だと考えています。

他にも、品質保証活動がテスト工程(いわゆるQC)を中心に実施されていたので、テストプロセス自体の改善や開発プロセス全体への関与(シフトレフト)、品質文化の醸成といった、より広範なQA活動への注力が必要だと感じていました。これらの活動を強化するために、新たな自動テストツールの導入を検討することになりました。


MagicPod導入の決め手

板山:最初はSeleniumやAppiumを使ったスクラッチでの自動化も検討しましたが、当時はQAEグループに正社員が私しかおらず、自動化専任の担当者を置くことができませんでした。そのためGUIでテストケースを作成・管理できるテスト自動化ツールが望ましいと考えました。加えて、テスト実行回数が無制限でスモールスタートしやすい価格のツールを候補として探しました。

最終的にMagicPodを選んだ決め手は価格面です。いくつかの自動テストツールと比較しましたが、MagicPodは他のツールと比較して低価格でありながら、固定料金で実行回数が無制限だったことが魅力でした。また、GUIベースでテストケースを簡単に作成できることも決め手になりました。

私は前職でMagicPodの使用経験がありましたので、学習コストが低いことはわかっていました。実際にエンジニアだけでなく業務委託のQAメンバーもMagicPodを使っていますが、皆さん問題なく利用できています。

伊藤:どのようにオンボーディングをされていますか?

板山:MagicPodには導入用のスタートガイド(モバイル/ブラウザ)が用意されているので、まずはそれを見ながら、プロジェクトの立ち上げ、テストケースの作成、クラウド端末の起動、アプリのインストール、テストの実装と実行、という一連の流れを実際に体験してもらいます。そうすることで、1日あれば問題なく一通りの流れができるようになっています。

また、MagicPodの自動修正機能をはじめとする、保守コストを抑えるための機能が充実していることも魅力でした。前職で別の自動テストツールを使っていた経験からメンテナンスの重要性を痛感していましたので、MagicPodは安心して運用できると考えました。

伊藤:ありがとうございます!ちなみに、以前導入されていた自動テストツールをそのまま活用する、という選択肢は検討されなかったのでしょうか?

板山:コスト面を考慮した結果、その選択肢はありませんでした。以前のツールは形骸化したテストケースが残っているだけで、運用していたグループも組織変更でなくなっていました。改めて、まっさらな状態から最適なツールを選定し、その結果MagicPodに決定した、という経緯です。


MagicPodの活用状況


板山:現在は主に、これまで手動で行っていたモバイルリグレッションテストの自動化、サービスのフロントページの死活管理、月またぎのタイミングで生成される取引履歴など、定期的かつ夜間に発生する処理の確認に活用しています。

特にモバイルリグレッションテストは、約1400ケースのうち重要度が高く自動化しやすいものから優先的に、約700ケースをMagicPodで自動化しました。自動化されたテストケースの多くは、全体の主要な部分をカバーするものとなっています。

残りの700ケースについては、本人確認機能など自動化が難しい部分もあるため全てを自動化することは困難ですが、実装可能なものについては今後も積極的に自動化を進めていく予定です。

伊藤:フロントページの死活管理についてもMagicPodを活用されているとのことですが、具体的にどのようなことをされているのでしょうか?

板山:本番環境に対して1時間に1回、各ページにアクセスして画面に差分がないかを確認しています。リンク切れや非公開設定になってしまっているページがないかなど、問題の早期発見に役立っています。以前は手動で確認していましたので、自動化によって大幅に効率が上がりました。

モバイルリグレッションテストは、基本的に毎日夜間に実行しています。テスト結果は朝、業務開始後に確認する流れです。以前は私が確認していましたが、現在は自動化専任のメンバーが担当しています。問題が検出された場合、仕様変更でなければエンジニアに連絡して対応してもらう、という流れです。

テストのスケジュール管理は現状、MagicPod内蔵のスケジューラーで行っています。テスト実行時間の長さからスケジュールによる定期実行しかできていませんが、将来的には適切な粒度でテストケースを分割し、並列実行することでテスト時間の短縮を目指しています。ゆくゆくはCI/CDに組み込み、アプリのビルドごとに自動テストが実行されるようにしたいと考えています。

テスト結果はQAEグループだけでなく開発メンバーや関心のあるメンバーも確認できるよう、専用のSlackチャンネルに通知しています。現在、そのチャンネルには私を含めて36名が参加しています。

伊藤:開発エンジニアの方々の反応はいかがですか?

板山:「使ってみたい」という好意的な反応が多いです。最近、MagicPodのプランを切り替えてテストケース数が無制限になったタイミングで、開発チームからいくつかアカウント追加の要望がありました。ただ、開発チームも本業が多忙なため、MagicPodの活用は一部のチームにとどまっています。

MagicPod導入による効果として最も大きいのは、モバイルリグレッションテストの実行工数削減です。導入前は4人日/月かかっていたものが、2人日/月に半減しました。これは、MagicPodによる自動化だけでなく、不要なテストケースの削減やテスト内容の見直しを行った結果でもあります。

また、MagicPodによる定期的な死活監視によって本番環境での不具合を早期に検知できるようになったことも大きな成果です。以前、外部サービス側の設定ミスでCoincheckの一部ページが非公開になってしまったことがあったのですが、MagicPodが定期チェックですぐに検知してくれたため迅速に対処することができました。


専門知識と俯瞰力を高め、開発を支援するQA組織へ

板山:コインチェックのテストにおける特有の難しさは、暗号資産取引所における「板寄せ」(※注文をまとめて価格を決める方式)や「サーキットブレーカー」(※価格の急変動時に取引を一時停止する仕組み)といった仕組みのテストにあり、その処理には複雑な計算が伴います。そのため計算処理の正確性を多様なケースで確認する必要があり、専門知識がないとテストケースを網羅的に作成することが困難です。

また、テスト結果から得られるさまざまなデータを収集・分析し、テストの有効性や効率性を定量的に評価することも重要です。こうした活動を通じてテストプロセス全体を継続的に改善していくことが、QAEグループとして重要なミッションだと考えています。

伊藤:なるほど、テストの実施だけでなく結果分析、改善活動とQAEグループの役割は多岐にわたるのですね。具体的にはどのような取り組みをされているのでしょうか?

板山:当社に限った話ではありませんが、QAエンジニアの役割を考える上で「QMファンネル」という考え方があります。これはQAエンジニアのスキルを、テスト実行を担うTE(Test Engineer)、テスト自動化を担うSET/PE(Software Engineer in Test / Pipeline Engineer)、品質保証プロセス全体を担うQAの3つの専門性に分類したものです。現状、当社のQAEグループはメンバーの専門性がTEに偏っており、私がSETの領域を部分的に担当しつつ、QAコーチ以上の役割を担える人材が不足している状況です。

今後は各メンバーが自身の専門性を高めるとともに、他のメンバーの専門領域についても理解を深め、相互に協力しながら業務を遂行できる体制を目指したいと考えています。また、開発チームのメンバー自身がQAの役割を担えるようになること、もしくは、各開発チームに専任のQA担当者を配置できるような体制も理想的だと考えています。

伊藤:メンバーのスキルアップや開発チームとの連携強化の部分で、具体的に取り組まれていることはありますか?

板山:一つは、「Test.SFF」というフレームワークを活用し、各メンバーのテストスキルを可視化する取り組みを進めています。これは、テストスキルを評価・可視化するための枠組みで、このフレームワークを使うことでチーム全体、そして各メンバーの強みや弱み、伸ばすべきスキルを明確にすることができます。具体的には、自己評価と他者評価によって各メンバーのスキルを評価し、その結果をレーダーチャートなどで可視化します。可視化されたスキルマップは今後の人材育成や採用活動、チーム編成などに活用する予定です。

もう一つ力を入れているのが、APIテストの自動化です。E2Eテストだけでなく、APIレベルでのテストを自動化することもシステムの品質向上には不可欠だと考えています。現在、「Postman」というAPIプラットフォームをコマンドラインで実行できる「Newman」というツールを利用し、APIテスト自動化の技術検証を進めています。将来的には、このAPIテストをCI/CDに組み込み、開発の初期段階でAPIの不具合を検知できる仕組みを構築したいと考えています。

さらに、「TPI Next」というテストプロセス改善モデルを導入し、弊社のテストプロセスを客観的に評価し、改善していく取り組みも進めています。「TPI Next」は、テストプロセスの成熟度を評価し、改善のための指針を提供するものです。まずはこのモデルを活用して自社のテストプロセスを客観的に評価し、改善点を明確化します。具体的には、まずテスト計画、設計、テストデータ準備といった、テストの上流工程の改善に注力する予定です。もちろん、テスト自動化をさらに推進し、テスト全体の効率化を図ることも重要な課題だと認識しています。

伊藤:本当にさまざまな取り組みを推進されているんですね。

板山:はい。最終的な目標は、各メンバーがQAに関する高度な専門知識を持ち、開発プロセス全体を俯瞰できる力を身につけ、開発メンバーと協力しながら品質を作り込んでいける組織になることです。そしてQAEグループが、開発組織全体に対してテストや品質保証に関する知識やノウハウを提供し、開発を支援できるような存在になることを目指しています。


最後に

板山:テスト自動化の実現と定着には時間とリソースが必要です。しかし、適切なツールを導入することで、そのプロセスを大幅に効率化できます。MagicPodは、テスト自動化の最初の一歩を踏み出すのに最適なツールだと考えています。特にGUIベースで誰でも簡単にテストケースを作成できる点、そして実行回数が無制限である点はテスト自動化のハードルを下げ、多くの企業にとって導入しやすい要素だと考えています。MagicPodは単にテストを自動化するだけでなく、テストプロセス全体を見直し、改善していくための強力なツールとなるはずです。

コインチェック株式会社