開発組織の立て直しで欠かせなかった自動テストツールの導入。リグレッションが減り、品質意識が向上した。

株式会社あしたのチーム

ブラウザテスト

ユーザーインタビュー第18回は、MagicPod代表伊藤とともに株式会社あしたのチーム様にお話を伺いました。
具体的な活用事例や選定の決め手など、いろいろとお話しいただきました。


株式会社あしたのチーム

創業以来10年以上、人事評価制度の専門家として人事領域のDXをサポートするHRTech企業です。人事制度の構築から運用支援、クラウドシステムを活用した業務効率化までをワンストップで提供しています。


POINT

  • E2Eテストが全くない状況で品質に課題があった
  • 実行回数に制限が無いMagicPodを選定
  • デグレ検知で巻き戻しが減少し、品質意識が向上
  • 導入から半年で十分すぎる成果が出ている

左から ・堀之内 将人さん 執行役員 VPoE プロダクト部長 ・梶田 英邦さん プロダクト部マネージャー ・安住 聡史さん プロダクト部、QAエンジニア ・藤原 立暉さん プロダクト部、QAエンジニア

左から
・堀之内 将人さん 執行役員 VPoE プロダクト部長
・梶田 英邦さん(オンライン参加) プロダクト部マネージャー
・安住 聡史さん プロダクト部、QAエンジニア
・藤原 立暉さん プロダクト部、QAエンジニア
・伊藤 望 MagicPod CEO


堀之内さん(以下、堀之内)︰執行役員VPoEプロダクト部長として開発の責任者をしています。開発体制の構築や開発手法の改善はもちろん、改修案件をCSやセールスと調整したり、採用やパートナー探しをしたりするのが主な仕事です。入社当時は開発組織の立て直しが必要な状況で、テストもほとんど行われていませんでした。そこで安住さんに来ていただき、QAの仕組みづくりを進めてきました。

安住さん(以下、安住)︰あしたのチームには2022年頃にジョインしました。QAチームの立ち上げ支援から始めて、「あしたのクラウド®」のメンテナンスを担当しています。具体的にはシナリオのリストアップとその優先順位付け、MagicPodへの実装と保守です。

QAチームにはメンバーが6人いて、手動テストと自動テストで3人ずつのチームに分かれています。私は自動テストチームのマネージャー的なポジションでタスクの整理と方針の決定を行っています。これまでもいろいろな会社で様々な自動テストツールを使って導入から運用まで経験してきまして、MagicPodも別の会社で導入経験がありました。

藤原さん(以下、藤原)︰私はQAエンジニアとして仕事をするのは今回が初めてで、シナリオ作成やMagicPodの実装をメインでやらせていただいています。もともと開発エンジニアとして働いてきたのですが、テストコードを書いたエンジニアがいなくなると保守が回らなくなるプロジェクトに関わった経験から、QAエンジニアに興味を持っていました。そんな時に安住さんからこの仕事を紹介していただき、参画しています。

堀之内:藤原さんともう一人のメンバーも、実は安住さんにご紹介いただきました。

伊藤(MagicPod代表):安住さんはご経験もそうですが、開発経験があるQAエンジニアを呼ぶことができるのもすごいですね。

堀之内:そうなんですよ。我々にはテストの知見が無かったので経験者に来ていただく必要がありました。でもQAエンジニアを見つけるのは難しく、自動テストの実装までできる方はそうそういません。たまたまご紹介いただいたのが安住さんで、是が非でもお願いしたいと話して入っていただきました。必要な人材がいないとなれば探して来てくれるので、本当に助かっています。

梶田さん(以下、梶田)︰私は現在、新規開発プロジェクトのバックエンドエンジニアをしており、「あしたのクラウド®」もSRE的な立場でインフラを見ています。MagicPodを直接触っているわけではないのですが、ステージング環境にデプロイするタイミングでMagicPodを走らせるようにしたり、Slackに通知を出したり、QAチームとはQAの進め方やプロセスにどう組み込むかという話をしています。


MagicPodを導入した経緯


伊藤:堀之内さんは開発組織の立て直しが必要なタイミングで入社されたとおっしゃっていましたが、当時どのような状況だったのでしょうか?

堀之内:ユニットテストは少しはありましたが、E2Eテストが全くない状況でした。エンジニアが一念発起したのか、やろうとした痕跡はありました。ただ、自分だけでは手に負えないと判断して諦めたようです。

安住:私が入った当初は大きく分けて3つの課題がありました。1つ目は堀之内さんが話した通り「E2Eテストが行えていない」ことで、どこにどのような影響が出るのかよくわからない状態でリリースし、デグレが頻繁に発生していました。2つ目は「プロダクトの品質」で、本番環境でも不具合が発生していましたし技術的負債も溜まっていました。3つ目は「自動テストの知見」で、重要性は認識されていましたが、どのようなツールを使って実装していけばいいのか理解しているメンバーがあまりいませんでした。

堀之内:クリティカルな問題は起きていなかったのですが、放置されたバグを運用でカバーしているような状況でした。改修要望の優先順位もわからず、誰がどの改修をいつまでに終わらせるか不明確で、エンジニアたちは「忙しい、忙しい」と話すものの、なぜ忙しいのかがよくわからない。そこでスクラム開発を導入しスプリントレビューやプロダクトバックログリファインメントのミーティングを設定して、事業責任者が「やる・やらない」を決め、優先順位をつけてリリースしていく形を作りました。

ただ、QAが無ければリリースしたタイミングで不具合が起きますので、QAチームの構築も急務でした。そこで安住さんに自動テストをお願いしたのですが、PRDやDesignDocなど仕様書に相当するものが全くない状態で大変だったと思います。

安住:仕様書などのドキュメントが無いのはどこの企業でもあるあるなので(笑)。課題のうち大部分は自動テストツールを導入することで解消できると考えていました。


MagicPod導入の決め手

伊藤:テストを始める際は手動から始めて困ったら自動化するパターンが多いですが、最初から自動化を考えていたのでしょうか?

堀之内:そうですね。QAを開発エンジニアが片手間で行うのはあり得ないと考えていましたし、「あしたのクラウド®」は規模が大きく、手動テストだけで進めるのは現実的ではないと考えていました。安住さんからも「自動化しましょう」と提案を頂きましたので、渡りに船でお願いしました。

伊藤:ツールの検討はどのようにされたのでしょうか?

安住:いくつか検討しましたが、日本語が使える2つのツールを比較検討しました。その上で実行回数の制限が無く安価で、メンテナンス性の高いMagicPodを選びました。堀之内さんからは「毎日テストを回したい」という要望がありましたので、実行回数で料金が変わらない点は決め手になりました。

堀之内:特にアジャイル開発はテストが重要で、反復的に行う必要があります。社内で「テストはいつやるの?」と聞かれることがあるのですが、「いつもやってます」と答えています(笑)。業界的にも自動テストの認知が低いと感じていて、「自動テストは誰が作ってるの?」「QAエンジニアです」「どうやって作るの?」「テスト項目書を作って実装しています」「へー!最近はそういうのがあるんだね!」といった会話をする機会が少なくありません。

伊藤:先ほど仕様書などのドキュメントが無かったというお話がありましたが、実装はどのように進めたのでしょうか?

安住:人の入れ替わりが激しいタイミングだったこともあり、誰に聞けばサービスの使い方が分かるのか不明でした。そこで最初に目をつけたのがCSの資料です。CSはお客さま向けに「この機能はこう使いますよ」というのを分かりやすく資料化していますので、それを参考にシナリオをリストアップして優先順位を決めていきました。

堀之内:リストアップに時間をかけた印象です。

安住:そうですね。「高・中・低」で優先度を決めて、60〜80くらいのシナリオ数になりました。そのうち「中」までの40シナリオを実装することになり、半年くらいで完了したと思います。

堀之内:お二人には「あしたのクラウド®」の正常系を終わらせていただいたので、次は新規事業プロダクトへの導入・実装をお願いしています。ただ、開発中のプロダクトですので要件や仕様が流動的なのもあり自動テストをどこまで作り込むかは少し迷っています。

伊藤:UIが変わる場合は検討が必要ですね。開発プロセスの一部として自動テストが浸透しているのは素晴らしいと思います。


MagicPodの活用状況

伊藤:現在、テストはどのように実行されていますか?

藤原:毎朝9時に定期実行しています。将来的にはデプロイするタイミングでも回せるようにしたいと話しています。

梶田:「あしたのクラウド®」ではユニットテストやリクエストスペック(統合テスト)をCircleCIから実行しています。新規事業プロダクトではmaster branchにプッシュされたタイミングと定期実行でGitHub ActionsからMagicPodを動かしています。

伊藤:自動テストがあることのメリットは出ていますか?

堀之内:リリース前にデグレの検知ができるようになったことで巻き戻しが減りました。テスト結果は開発メンバーも入っているSlackチャンネルに通知しています。以前は不具合が多すぎて「アラートが飛ぶチャンネルを見なくなる」という現象が起きていたのですが、MagicPodのチャンネルは普段来ないものが来るので「何かヤバい」と思うようになったようです。

安住:週次のミーティングで「今、これが落ちてこうしています」と共有するようにしたことで皆さん興味を持ち始め、自発的に見ていただけるようになりました。品質に対する意識が上がったと思います。

伊藤:それは素晴らしいですね。自動テストは誤検知がよくあるため、テストの作り方、実装の仕方が重要になります。どのように工夫されていますか?

藤原:週次で集まって、例えばUI要素の検証に関するルールを設定したり、画面の描画が終わってから次のステップに進むよう待機ルールを設定したりすることで精度を向上させてきました。ルールを明確にしてからは実装がスムーズに進んだと思います。

安住:共有ステップも有効に使っています。小さなパーツを組み合わせて1つのシナリオにすることでメンテナンスが楽になりますし、落ちにくくなります。落ちないようにそういったメンテナンスを重ねています。

伊藤:なるほど、すごく良いですね。


堀之内:以前の開発現場では、どういう仕様で開発するのか、どこをどのように改修するのか分からない状態でブラックボックス化していました。QAチームができて、テスト項目書を作り、QAと開発エンジニアで「これが正しい動き、これは正しくない動き」と改修内容の認識合わせができるようになったことで、仕様の抜け漏れや巻き戻しが改善しました。

安住さんには「こういうバグがありそうだ」というところもリストアップしていただき自動テストを実行しています。手動テストでは改修する範囲が分かるように案件ごとにテスト項目書を作っているのですが、想定外の副作用が起きた時は自動テストで検知するので安心感があります。

自動テストは新しい技術なので、知識と経験をしっかり持っている方は多くありません。安住さんや藤原さんなど実際に携わっている方から「こういうときはこうしたほうがいい」「テストはこう組み込んだほうがいい」「このタイミングで実行するのがいい」といったことを共有してもらえたことで開発現場にナレッジが溜まった点も助かっています。先日は安住さんにシナリオのリファクタリングもしていただきました。

安住:先ほど導入時にCSが用意した資料をもとにシナリオを作成したと話しましたが、それはゼロからイチを優先した不完全な内容でした。それをリファクタリングして、実際にユーザーが使う場面を想定したシナリオに作り直しました。70〜80くらいあったテストケースを30くらいまで減らせました。

最初から完璧を目指したい方もいると思いますが、進めているうちに「もっとこうしたほうがいい」と課題が出てくるものです。最初はスピード重視で作り、安定して動くようになったらリファクタリングしていくのが良いと思います。

堀之内:リファクタリングは安住さんの提案で、メンテナンス性も上がったのでやっていただいて良かったです。正直、導入から半年という期間を考えると、十分すぎるくらい成果が出ていると感じています。


最後に

安住:手動テストと自動テストを組み合わせることで、それぞれの強みが生きて非常に効率的なテストを行えるようになります。自動化をするか迷っている場合は、どんどん進めてみたほうがいいと思います。ただ、闇雲に自動テストを実装すればいいわけではありません。何を自動化するか、メンテナンスをどうしていくかをしっかり考えていく必要があります。

ツールとしては、導入のハードルが低く、コスト面や運用のしやすさでもMagicPodをお薦めします。トライアルで動かしてみて良さそうだと思えば続ければいいし、そうでなければ別のツールを検討するか、手動で頑張る選択肢もあります。

決まった手順を繰り返し行うテストはMagicPodに任せましょう。そして浮いたリソースで自動テストでは難しいUI/UXや例外的なパターン、新機能の機能テストなどクリエイティブなテストに集中することで、プロダクトの品質がより良くなると思います。

藤原:私もMagicPodをお薦めします。私が過去に参加したプロジェクトでは人のテスターがだんだん億劫に感じて雑になり、正確な検証ができないことが少なくありませんでした。そういった、人が苦手な分野は機械に任せて、人はユーザーの視点に立った例外的なテストを行うのが理想的だと思います。

梶田:MagicPodはAPIで外側からいろいろ叩けるところが良いです。単に自動テストができるだけでなく、デプロイやリリースのプロセスに組み込むことができるのも強みだと思います。

堀之内:自動テストは非常に重要だと考えていますが、社内のメンバーにその重要性を理解してもらえるようになるまで苦労しました。プロダクトを継続して改修するためには期待通りに動くことを保証し、動かなかった時に検知できるQAが必要なんだということを啓発活動して、最近ようやく理解してもらえるようになったと思います。ただ、これは社内に限った話ではなく、業界全体における理解度もまだまだだと思います。MagicPodさんには今後もリーディングカンパニーとして頑張っていただきたいです。

伊藤:頑張ります。あしたのチームさんの事例もより多くの方に知っていただき、自動化の重要性を広めていければと思います。今日はありがとうございました。

株式会社あしたのチーム