属人的だったE2Eテストを解消し、組織で品質向上へ。開発とQAが一体になったMagicPod運用とは

株式会社Skillnote

ブラウザテスト

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


株式会社Skillnote

Skillnoteは製造現場のスキルマネジメントシステム「Skillnote」を提供しているSaaSスタートアップ企業です。「Skillnote」は、製造現場で従来より紙・Excel・ハンコ等で管理されてきたスキルマップ(力量管理表)を、クラウド上で運用するプロダクトです。製造現場のスキルデータを見える化することで、スキルデータを活用した計画的な人材育成・人材配置を実現し、”技能承継”、”多能工育成”、”即戦力化”といった製造業企業様の人材管理に関する課題の解決に貢献しています。



POINT

  • Selenideで自動テストを進めていたものの属人化とメンテナンス負担が課題に
  • MagicPodの導入でスキルに依存せず組織全体で管理・運用できる体制を構築
  • 自動修復機能やお問い合わせ機能がテストの効率化と心理的負担の軽減に貢献
  • テストの安定化に向けテスト用idの付与などフロントエンドとの連携を強化
  • テストケース管理の徹底と手動・自動テストの役割分担の明確化が今後の課題

左から ・村田 友香さん フロントエンドテックリード ・高澤 奈緒美さん エンジニアリングマネージャー ・伊藤 望 MagicPod CEO

左から
・村田 友香さん フロントエンドテックリード
・高澤 奈緒美さん エンジニアリングマネージャー
・伊藤 望 MagicPod CEO


高澤さん(以下、高澤):Skillnoteには2020年に入社しました。現在、2つあるスクラムチームのうちの1つのエンジニアリングマネージャーをしており、新しいサービスの要件定義や仕様決定、設計、実装などを担当しています。Skillnoteに入社するまでは、プロジェクトマネジメントなどもやっておりました。

村田さん(以下、村田):私は2022年に入社して、高澤と同じスクラムチームのエンジニアとしてフロントエンドのテックリードをしています。Skillnoteに入社するまでは、フロントエンドエンジニアや開発チームリーダーとして経験を積んできました。
現在、Skillnoteの開発組織はスクラムチーム2つとVPoE室の3チームに分かれており、20人います。半年ほど前から1スプリント2週間のスクラム開発をしていますが、リリースサイクルは2カ月に1回になってきています。

高澤:以前は開発者が各々で品質を担保し、リリースまで進める形をとっていましたが、組織として品質を担保していくため3年ほど前にQAエンジニアが入社し、組織化していきました。一時期は、インフラエンジニアも加わり、QAとSRE(サイト信頼性エンジニアリング)を兼ね揃えたチームになっていました。しかし、その後、スクラム開発に移行したタイミングで、QAの機能は各スクラムチームに吸収される形となりました。

伊藤(MagicPod代表):各スクラムチームに、開発者によるテストだけでなくQAエンジニアのようにプログラムを書かないメンバーもいて、手動・自動の両方でテストを行っているということでしょうか?

高澤:おっしゃるとおりです。「開発者がより本質的なテストをできるようになる」というところに重きを置いて自動化を進めています。「QAはこのメンバー」という形より、「QAはチーム全体で担う」という形に変化させつつあります。



MagicPod導入の経緯

高澤:自動化の取り組みは、3年ほど前にQAエンジニアがSelenide(※)を使って自動テストを構築してくれたのが始まりです。しかし、そのQAエンジニアの方に属人化してしまい、ご本人も非常に忙しいためメンテナンスが難しくなっていました。また、自動テストはその方のローカル環境でしか実行できず、CI/CDへの組み込みもできておらずリリースをキャッチアップすることも難しかったため、品質保証上の懸念もありました。

※Selenide:Selenium WebDriverをベースとしたオープンソースのUIテストフレームワーク

伊藤:テストの実行自体にも課題があったのですね。主にどの部分を自動化したのでしょうか?

高澤:E2Eの部分に自動テストを適用していました。ただ、自動テストは本来、日次実行やデプロイごとに実行など頻度高く行うべきものですが、当時は2カ月に1回のリリース前に1回実行するのが限界で、新規機能開発にテスト作成が追いつかず、既存機能にも適用されていない部分がありました。

当時、私はSelenideのコードレビューを少しする程度で、実際にテストコードを書くことはしていなかったのですが、1年ほど前に状況を改善するため「組織として自動テストを管理し、何らかのツールを使って自動化を進めていこう」という話が持ち上がりました。

直接的なきっかけはVPoEの安藤からの提案でしたが、それ以前から現場では「このままでは、メンテナンスが立ち行かなくなる」という声が上がっていました。そのため安藤の提案と現場の声が合致した、という背景があります。

伊藤:リリース後に不具合が起きるといったクリティカルな問題は起きていたのでしょうか?

高澤:幸いそこまでの問題は起きていなかったのですが、メンバーも増えてプロダクトも新機能が増えている中で、「現在の属人化したE2Eの自動テストは限界かもしれない」という肌感覚は強く持っていました。「問題が起きる前に対処しよう」と動き出した形です。

伊藤:ちなみにSelenideのテスト環境をクラウド上に移行する形は検討されなかったのでしょうか?

高澤:検討はしましたが、QAエンジニアと相談する中でSelenide自体のメンテナンスの負担が大きいという結論に至りました。当時、QAエンジニアは他にも多くのタスクを抱えており、Selenideのメンテナンスに十分なリソースを割けない状況でした。

メンテナンスができるメンバーを増やそうと試みたこともありました。しかし、この取り組みに関わったエンジニアには時間的にも精神的にも大きな負担となり、現場には抵抗感がありました。また、プロダクトの成長に伴い、「Skillnote」のデザイン変更の頻度も上がっており、Selenideでの対応には限界がありました。そのため、頻繁なデザイン変更にも対応しやすい環境を整え、メンテナンスの負担を軽減し、属人化を解消する、ということを優先事項と考え、移行を決めました。



MagicPod導入の決め手

伊藤:ツールの選定や導入の推進など、どのように進められたのでしょうか。

高澤:プロジェクトが立ち上がり、主担当と私、村田さんがアサインされました。その3人で、まずは自動テストツールの候補を出し合い、各社にトライアルの申し込みをしました。

選定の基準は主に2つありまして、まずは「価格」です。Skillnoteはまだまだ成長過程の企業で、いくつかの有名なツールは料金面で折り合いがつきませんでした。その点、MagicPodは作成するテストケース数を限定した場合の料金が比較的安く、固定料金で実行回数が無制限というのが魅力でした。

もう一つの基準は「使いやすさ」です。コードを書かないQAエンジニアがいる状況も想定し、いろいろなスキルの方でも無理なくメンテナンスでき、自動テストを作っていくことができるというのを必須条件にしました。その点でもMagicPodは学習コストの低さが魅力でした。

伊藤:実際にMagicPodをトライアルしてみてお二人はどんな印象を持ちましたか?

高澤:マニュアルをさっと斜め読みして試しに触ってみたところ、直感的に「ここをクリックすれば、こう動くだろう」と予測しながら操作することで、テストステップがどんどん進んでいくことに驚きました。ほんの15分程度の学習で、ここまで操作できるとは思っていませんでした。

村田:私も同じように感じたことを覚えています。マニュアルをほとんど読まずに触ってみたところ、自然とテストケースのようなものが作成できました。失敗しても許されるという感じがあり、トライ&エラーしながら探索的に自分でいろいろ触れる点に、より興味を持ちました。


村田 友香さん フロントエンドテックリード

MagicPodの活用状況


高澤:MagicPodの導入を決めてからは、Selenideで作られていたリグレッションテストの移行を進めました。現在は毎営業日20時にステージング環境で定期実行し、意図しないデグレードの早期検知につなげています。「自動テストはリリース前に実行するだけ」という状態を解消できたのは、MagicPod導入の大きな成果です。

また、データベースのバージョンアップといった、システム全般に影響を及ぼす可能性がある作業後のテストにも活用しています。大きなアップデートを実施する際には「MagicPodがあるから、安心して実施できる」といった会話がメンバーから出るようになり、MagicPodが非常に頼りにされていることを実感しています。

村田:移行作業は広く協力してくれるメンバーを募り、コードを書くことが少ないQAエンジニアやインフラエンジニアにも参加してもらいました。その後も、定期的に開発チーム全体に呼びかけ、自動化されていなかったテストケースの拡充を進めています。その結果、属人的だった自動テストのメンテナンスが、特別なスキルがなくても、誰でも対応できるようになったこともMagicPod導入の成果だと考えています。

高澤:一方で、既存機能については自動テストの拡充、新規機能については開発初期段階からの自動テスト導入を目指していましたが、いずれもまだ十分に実現できているとは言えません。これはMagicPodの問題というより、開発プロセス全体の問題だと考えています。現在、開発速度を落とさず、かつ、適切な範囲で自動テストを開発プロセスに組み込めるよう、方法を検討しているところです。

伊藤:現状どれくらいの方がMagicPodを利用されているのでしょうか。

高澤:開発メンバー20人全員がMagicPodのアカウントを持っており、全員が一度はツールを操作しています。ただし、日常的に運用を担当しているメンバーはそのうちの10人ほどです。これらのメンバーが中心となり、ローテーションで毎日テスト結果を確認し、必要に応じてメンテナンスを実施しています。具体的には、スクラム開発の2週間に合わせ、リーダー層と入社歴が浅いメンバーがペアを組み、2週間ごとに担当を交代する形です。

村田:弊社ではコミュニケーションツールとしてMicrosoft Teamsを使用していますので、テスト結果はTeamsに届いて全員が確認できるようにしています。ローテーションのメンバーで対応が難しい場合は、スクラムチーム内に確認したり、開発チーム全体に質問したりするなど、柔軟に対応しています。

伊藤:MagicPodがあったから検知できて問題を未然に防げたことはありましたか?

高澤:それがけっこうありまして、ここ1年で10回程度、開発者が認識していなかった問題をMagicPodで検知できています。

伊藤:実際に貢献できていて良かったです。現状、何か課題に感じていることはありますか?

高澤:まず、自動化されていないテストケースの拡充です。これまでは手の空いているメンバーに依頼する形で進めていましたが、組織変更やメンバーの入れ替えなどもあり、現在は作業が止まっています。そのため、改めて進め方を検討しているところです。

伊藤:テストケース全体を統括管理し、例えば「この画面のこのテストケースが不足している」といったテスト漏れを防ぐような仕組みはあるのでしょうか?

高澤:まさに課題となっているところです。以前は、手動テストと自動テスト、MagicPodで実施するテストなど、E2Eテスト全体を網羅したテストケースの一覧を作成し、管理していました。しかし、この管理の質に問題があり、例えば、ある画面のテストをMagicPodで自動化していると思い込んでいたところ実際には自動化されておらず、手動テストでも漏れてしまったことがありました。E2Eテストのケース管理を徹底する必要があると痛感し、どのテストを手動で実施し、どのテストをMagicPodに任せるかの基準を明確化し、テストケース管理の質を向上させる取り組みを進めています。

また、MagicPodを運用する中で「思ったよりE2Eテストの結果が不安定だ」と感じているメンバーがいることも事実です。この点については、安定性を高めるための対策も併せて検討していく必要があると考えています。

伊藤: E2Eテストはさまざまな要因で結果が変わってしまうため、どうしても単体テストや結合テストと比べて不安定になりがちです。そのため、要素特定に使うテスト用idを整備したり、変更頻度が高い部分を「共有ステップ」機能で共通化し、メンテナンス性を向上させたりすることで、テストの安定性を高めることができます。

ただ、それでも「テストコードや環境は変えていないのに、再実行したら通った」というケースは発生してしまいます。こういったケースを減らし、より安定したテストを実現できるよう今後もMagicPod自体の改善にも取り組んでいきます。

村田:テスト用idの設定は、現在まさに取り組んでいる最中です。MagicPodのアナリティクス機能を活用し、不安定なロケーターの数が減少していることを確認しながら、着実に進めています。


伊藤 望 MagicPod CEO

MagicPodのオススメ機能

伊藤:MagicPodの機能の中で、特に便利だと感じている機能や気に入っている機能はありますか?

高澤: まず、自動修復機能には非常に助けられています。 デザインの修正のためにdiv要素を追加するということがよくあるので、そのような場合に自動修復機能が有効になっていると、10個ほどのテストケースに影響がある場合でも簡単に対処できるため、大変助かっています。 実際に自動修復を適用する際には修正内容を確認して承認を行うのですが、その度に「これは本当に助かるな」と実感しています。最近もこの機能に助けられたところです。

次に、お問い合わせ機能が優れていると感じています。この機能は「Skillnote」でも参考にしたいと思うほど、使いやすいと感じています。 お問い合わせボタンを押すと、必要な情報が自動的に添付されるだけでなく、問い合わせ内容を記入するフォーマットもしっかりと用意されています。そのため、何を書けば良いのか迷うことなく、スムーズに問い合わせができる点が非常に気に入っています。実際、頻繁に利用させていただいています。

それから、クロスブラウザテストも非常に有効な機能だと感じています。「Skillnote」は推奨環境としてChromeとEdgeを定めています。今は事情がありEdgeのテストを一時的に停止しているのですが、以前はMagicPodで両方のブラウザのテストを実施していました。手動テストでは、推奨環境であるにも関わらずChromeとEdgeの両方を確認しきれていなかったのが実情です。以前のようにMagicPodでEdgeのテストも実施できるよう、近いうちに環境を再整備したいと考えています。

村田:私もお問い合わせ機能には助けられています。操作方法で不明な点が生じた際に、「すみません、ここが分かりません」と気軽に質問できる、といった形で活用しています。困ったときすぐに質問できるため、精神的な負担がかなり軽減されていると感じています。MagicPodの非常に良いところだと思います。

それから、個人的に気に入っているのは「要素が出るまで待機」の機能です。 最初、この機能を知らずに「何秒待つ」というコマンドを使用していました。しかし、それでは意図した通りに動作しないことも多く、本来は「特定の要素が表示されるまで待機する」という処理が必要だと感じていました。

高澤:わかります!私は「要素がアクティブになるまで待機」の機能も好きです。

村田:「Skillnote」では、要素を非アクティブな状態からアクティブな状態に変更する、という処理を頻繁に行っています。 「要素がアクティブになるまで待機」の機能を活用することで、その状態変化を正確に捉えてテスト実行できるため非常に便利だと感じています。 これらの待機系の機能は、本当によく使っています。

高澤:待機機能は私も村田さんが使っているのを見て初めて知りました。「こんな便利な機能があったのか」と驚き、さっそく自分の担当するテストケースにも取り入れています。先ほどお話ししたとおり、スクラム開発の2週間に合わせて担当をローテーションしていますので、そのタイミングで他のメンバーが修正したテストケースを見たり、書き方から学んだりしながら、MagicPodの活用を進めています。


高澤 奈緒美さん エンジニアリングマネージャー / 村田 友香さん フロントエンドテックリード

最後に

高澤:属人的だったE2Eの自動テストを組織の資産にすることができ、MagicPodを導入して本当に良かったと思っています。メンバーのスキルに依存しないようノーコードツールにフォーカスして検討していましたが、MagicPodは「とりあえず触ってみれば、なんとなく使える」という状態に、すぐに到達できました。その習得の容易さは、非常にありがたかったです。

ただ、実際に運用してみて、自動テストの品質を高めるためには基本的なエンジニアリングスキル、特に設計力やコーディング力が重要であると痛感しました。その点において、当初はもう少し時間やリソースをかけてもよかったと反省しています。具体的には、導入直後にエンジニアリソースをある程度割いて、自動テスト全体の設計や、チームの指針となるようなサンプルテストケースを事前にしっかりと作り込んでおくべきでした。そうすれば、チーム展開もよりスムーズだったと思います。

村田:私もMagicPodを導入してすごく良かったと思っています。私自身、導入推進メンバーだったこともあり、MagicPodの導入や運用を、より自分事として捉えられていると感じています。また、関わるメンバーにとっても、良い効果が出ていると思います。

一方で、MagicPodは簡単にテストケースが作成できるがゆえに、テストの目的や期待される結果を明確に定義せずに作成してしまうリスクもあると感じています。今後は「このテストは何を確認するためのものなのか」「期待する結果は何か」といった、各テストケースの目的やゴールをより丁寧に管理していく必要があると考えています。これは今後の課題としても、ぜひ取り組んでいきたいです。

また、テストの安定化にはフロントエンドエンジニアの協力が不可欠だと感じています。例えばテスト用idを適切に付与しないとテストが不安定になりますが、そこを気にかけてくれるフロントエンドのエンジニアが1人いるだけでテストの質が変わってきます。

高澤: Selenideを使っていた当時もテスト用idを入れたいという話はあったのですが、時間も人も割けないという属人的な判断になってしまい進みませんでした。今、テストが組織の資産になり、メンバー全員が向き合う形になったことで、ようやくテスト用idの整備を考えられるようになったと感じています。MagicPodの導入がその大きなきっかけになったと思います。

村田:これからMagicPodの導入を検討している方には、自動テストに対して、どれだけ組織の理解を得られるか、どれだけエンジニアリソースを投入できるか、という点を事前に確認しておくことをお勧めします。それにより、スムーズな導入やテストの安定化を実現できると思います。

株式会社Skillnote