エンジニア全員がMagicPodでテストを実行。開発全体の理解を得ながら効率化と品質保証の両方を実現できた秘訣とは

KIYOラーニング株式会社

ブラウザテスト

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

KIYOラーニング株式会社

2008年10月より、スキマ時間を活用し資格取得を目指せる音声講座として「通勤講座（現：スタディング）」をスタートさせ、2010年には「KIYOラーニング株式会社」として法人化。
「学びを革新し、誰もが持っている無限の能力を引き出す」というミッションのもと、スマホで効率的に学べる学習システムを開発、動画コンテンツを充実させ、資格ラインナップの拡充、品質の向上を図ってきました。さらに、2017年には、法人向け社員教育クラウドサービス「AirCourse」（エアコース）も展開するなど社会人や企業教育を革新するプラットフォーマーとしてサービス展開を推進しています。

POINT

料金と実行回数が決め手になりMagicPodを選定
開発エンジニア全員の理解を得て移行を進めた
テストケースが短期間で20→100に増加した
改善計画の立案にヘルススコア機能を活用

左から
・伊藤望　MagicPod CEO
・坪根圭佑さん　リードQAエンジニア
・中井雅樹さん　シニアQAエンジニア

坪根さん（以下、坪根）︰私は2023年3月に1人目のQAエンジニアとしてKIYOラーニングに入社しました。開発組織は現在20人ほどいまして、その中で私と中井の2人がQAエンジニアとして所属しています。仕事としてはMagicPodのテストケース作成や一括実行の設定、弊社サービス「スタディング」「AirCourse」の手動テスト設計・実行などを担当しています。

テストに初めて関わったのは新卒で入社したワークスアプリケーションズで、伊藤さんの後輩にあたりますね。そこで内製ツールを使ってERPパッケージのテストを担当していました。

伊藤：もしかして「AUTOTEST」のことでしょうか？　そうであれば僕が作ったものですね！

坪根：そうだったんですね！　お陰でテストの面白さを知ることができ、もっと専門的に関わりたいと考えて第三者検証に転職しました。そこで会計と人事労務製品のテストなどを経験した後、現在に至ります。

中井さん（以下、中井）︰私も坪根と同じQAグループでQAエンジニアをしています。今年の2月に入社したばかりで、最初はMagicPodを使ってテストケースを作成していました。入社前はSIerで品質保証をしたり第三者検証で受託検証をしたり、手動テストをメインに携わってきました。自動テストに関わるのは今回が初めてです。

MagicPod導入の経緯

坪根：弊社では私が入社する前からテスト自動化ツールが導入されていました。私も入社した時点ではそれを使っていたのですが、契約していたプランが延長できずに実質的な値上げになるということで、ツールの移行を検討することになりました。

伊藤：ツール自体に課題があったわけではなく、値上げが課題になったということですね。

坪根：そうです。私自身も使い方を覚えたばかりでしたし、開発エンジニアも使い慣れているツールでしたので値上げがなければそのまま使い続けていたかもしれません。ただ、当時テストケースは20件ほどでしたが月に500回以上使用することもあり、そのツールでは実行回数の制限があり厳しいとも感じていました。いずれは見直しを検討していたと思います。

MagicPod導入の決め手

坪根：ツールの選定にあたっては、主に既存のツールとMagicPod、もう1つ別のノーコードツールの3つで比較しました。その中でMagicPodを選定したのは「料金が安いこと」と「実行回数が無制限であること」が決め手になりました。

他にも今後のエンジニア採用を考慮して「コーディング不要なツール」という条件を必須にしていたのと、上長からメンテナンス性を考えて日本で開発されているツールが望ましいと言われていました。

結果としてMagicPodに移行したことで月々の費用を10万円以上削減できましたし、実行回数を気にしないで毎日テスト実行できているのも助かっています。MagicPodでも「テストケース作成数」や「画像差分チェックステップ数」「並列テスト実行可能数」「並列テスト作成可能ユーザ数」などで追加料金はかかっていますが、それらを含めても他と比べて安価でした。

伊藤：以前のツールは開発エンジニアも使い慣れていたという話でしたが、移行する際に抵抗のようなものはなかったのでしょうか？

坪根：ツールに不満があったわけではありませんので「なんで変えるんだろう？」という雰囲気はあったと思います。ただ、「今までこれぐらいだった料金が、これだけ高くなります」という説明をしたところ「それなら仕方ない」とみんな納得してくれました。

また、移行を進めるにあたって「QAがやりたいこと」に見えてしまわないよう「会社として進めているプロジェクト」であると理解してもらう努力をしました。開発エンジニア全員に集まってもらう説明会もグループマネージャーに承認をもらって進めるなど、みんなの理解を得た上で移行できたと思います。

伊藤：中井さんは入社後に初めてMagicPodをご利用いただいたと言うことでしたが、最初の印象はいかがでしたか？

中井：私はコードを書くことができませんが、特に問題なく使えました。「直感的に利用できるツールだな」というのが率直な印象です。ステップなど「これがあったらいいな」というのがしっかり押さえられていたので、すぐ活用することができました。

MagicPodの活用状況

坪根：現在はMagicPodを使って「スタディング」と「AirCourse」のリグレッションテストを実行しています。弊社では開発担当者が各自の開発物に対してリリース前に必ずリグレッションテストを実行し、テストがすべて成功したことを確認するルールになっています。

伊藤：開発エンジニア全員がMagicPodのアカウントを持ち、各自でご利用いただいているということでしょうか？

坪根：おっしゃる通りです。QAグループで作った自動テストの一括実行設定を実行し、その結果を確認してもらっています。NGだった場合はもう1回実行して、それでもNGだった場合はQAグループに連絡してもらうフローになっています。ですから多くの開発エンジニアは「一括実行をして、結果を見るだけ」というのが通常の使い方です。

テスト結果はSlackに通知していまして、「スタディング」と「AirCourse」で別々にチャンネルを作ってそれぞれ通知しています。 NGの通知が来たときは、私も余力がある限り中身を見るようにしています。

伊藤：リリース頻度はどれくらいですか？

坪根：プロダクトによっても違いますが、軽微なバグフィックスは週に何回もリリースされています。大きい機能追加ですと何カ月も開発した上でリリースされますので、細かいものも入れれば週に複数回リリースされています。

伊藤：毎日決まったタイミングでリリースされるというより、小さい修正でもできたタイミングで各自どんどん出してMagicPodでテストを流すという感じなんですね。NGだった際は再度実行するというお話でしたが、全てのテストケースを再度実行しているということですか？

坪根：そうです。まだテストを作りながら運用していますので、週に3〜5回ぐらいは失敗していると思います。フレーキーなテストだから失敗するということが多く、再実行で何とかなっているものの安定性は今後の課題だと考えています。

また、開発エンジニアから直接指摘されているわけではないのですが、実行時間の長さは気にされていると思います。今はだいたい70ケースで25〜30分ぐらいかかっています。以前「10分くらいで終わってほしい」と言われたこともありましたので、なるべく時間がかからないよう並列実行回数を最大の10並列まで増やすなど工夫しています。

伊藤：移行前に作成していたテストケースは活用できましたか？

坪根：そうですね。前のツールで使っていた20ケースほども移行して、MagicPodを導入してから実際に動いているのは70ケースほどです。作成したテストケースの合計だと100ケースを超えるくらいです。テストケースを作成する際には何度もテストを実行しますので、実行回数に制限がないMagicPodでなければこれほど短期間に多くのテストケースを作るのは難しかったのではないかと思っています。

ツールを移行するきっかけこそ料金の問題でしたが、MagicPodに変えたことでテストケースを増やすことができましたし、手動テストで検出できなかったバグの流出を防げているのはすごく良かったです。現在は主要な機能を中心としたテストケースになっていますので、そこを拡充していきたいと考えています。MagicPodのお陰で効率化と品質保証の両方を実現できていると思います。

ヘルススコア機能は導入初期からの活用がオススメ

伊藤：開発エンジニア全員がMagicPodをご利用いただいているとのことでしたが、メンバーが増えた際のオンボーディングはどのように行っているのでしょうか？

坪根：弊社サービスの「AirCourse」にナレッジの共有機能がありまして、そちらにMagicPodの使い方ですとか、「こういう設定をしてますよ」といった記事を投稿しています。新しい方が入ってきた際はそれを使って説明しています。

伊藤：それは御社ならではで、すごく良いですね。先ほどMagicPodへの移行の際にグループマネージャーに承認を得て説明会を行った話もされていましたが、開発エンジニアが協力的なのは他にも理由があるのでしょうか？

坪根：MagicPodに移行するタイミングで、自動テストを拡充していこうというプロジェクトが始まったことも大きいと思います。実際、プロジェクトに開発の方をアサインしていただいてテストケースを作ってもらっています。具体的には、私と中井で「こういったテストケースが必要だよね」というのを洗い出して、そこに開発エンジニアをアサインして、Backlogで状況を確認しながら進めています。

そのプロジェクトが落ち着いたら、テストケースの改善も進めたいと考えていまして、MagicPodのヘルススコア機能がすごく役に立っています。週に1回程度、私と中井で確認しながら今後の改善計画を話し合っています。

最初から開発エンジニアをアサインできたこと自体はすごく良かったんですが、振り返ると一気にテストケース作成を進めてしまったのは急ぎ過ぎだったかなとも思っています。安定化していない状態でどんどんテストケースを追加したせいで、実行時間が長くなったり、メンテナンスに課題のある運用が続いたりしています。これから始める方は一度にたくさんのテストケースを作りすぎず、5〜10個くらいにしてヘルススコアを見ながらちょっとずつ直していく進め方のほうがいいと思います。

最後に

坪根：開発って何かをつくる仕事ですが、QAの面白いところは逆に壊してこそ喜んでもらえるというところだと思っています。お客さまに出す前に、どうやったら製品の意図する挙動を起こせるかを考えながらテストするのがQAの仕事で1番好きなところです。今回、MagicPodを使って自動テストの知識や経験を高めることができたのは自分にとってもすごくありがたかったです。

MagicPodは安価に自動テストを始められるのがメリットだと思いますので、初めて自動テストを導入する方にもお薦めです。実際に始める際は、QAだけで始めるのではなく、エンジニアを巻き込む形を検討してみるのがいいと思います。

中井：MagicPodは安価で使えて、実行回数も無制限というところが良いですね。毎日複数回テストを実行する会社にオススメです。ステップとかも分かりやすくて、気軽な気持ちで始められると思います。まずはスモールスタートで始めてみるといいんじゃないかと思います。