「テスト自動化立ち上げ支援プラン」で品質保証を内製化。プログラミング経験なし×1人でも工数50%削減と24時間監視体制を実現できた秘訣とは
株式会社4COLORS
株式会社4COLORS様に、MagicPod選定の決め手や導入時から現在までの活用状況について、MagicPod代表の伊藤がお話を伺いました。
株式会社4COLORS
4COLORSは、「伝わる価値をつくる」というブランドメッセージのもと、創業から20年にわたり、アバター動画制作の先駆けとして「伝える」という行為そのものに向き合ってきました。誰でも簡単に動画を作れるだけでなく、“伝える”という行為を通じて顧客の課題解決に貢献する動画制作サービス「PIP-Maker」を提供しています。
POINT
- 立ち上げ支援プランを通じて、プログラミング経験がなくても約3〜4か月で自走レベルに到達
- テスト工数を約50%削減（手動4時間→約2時間）しつつ、カバー範囲は拡大
- QAほぼ1名体制で、3分おき・24時間365日の動画視聴監視を実現
- 開発とQAの分担で、エンジニアが機能開発に専念できる体制を構築
- AI機能の活用で、UI変更時の一括修正とエラー原因の把握を効率化
左から
・木下 衣織さん 情報システムチーム
・藤原 稔夫さん 開発部 部長
・伊藤 望 MagicPod CEO
木下：前職ではテスターとして3年ほどテスト実行とテスト設計を担当していました。弊社には、旧システムから新システムへ移行する際、前任のQA担当者から業務を引き継ぐ形で2025年4月に入社しました。そのタイミングでちょうどMagicPodの導入が決まったため、通常のテスト業務に加えてテスト自動化も担当するようになったという経緯があります。
弊社の「PIP-Maker」は、PowerPointファイルをアップロードするだけで最短5分でアバターと音声付きの動画を作成できるサービスです。eラーニングや商品紹介、マニュアル作成など、これまで多大なコストがかかっていた動画制作が誰でも・素早く・安価に実現できるようになります。
私はその品質保証を担当しており、新機能の検証からOS・ブラウザのアップデートに伴う表示崩れの確認、動画再生の安定性チェックまで幅広く見ています。所属している情報システムチームは全体で3名ですが、その中でPIP-Makerの品質管理を担っているのは私1人です。そのため基本的には1人で検証全般をカバーしており、現在は毎日MagicPodで自動テストを回しています。
藤原：私は2019年に入社しまして、現在は開発部の部長として組織のマネジメントやPIP-MakerのPMを担当しています。開発部の在籍は5名ですが、プロジェクトベースでPIP-Makerの開発・製品に携わっているメンバー全体だと10名ほどになります。
元々はテストをすべて手動で行っていたため、品質管理の自動化を目指してMagicPodを導入しました。特に昨年、旧システムから新システムへの移行を進めていたのですが、それを機に、新機能などの検証は手動で行いつつ、日々の監視やリグレッションテストは自動化して実施する、という効率的なテスト体制へとシフトしました。
MagicPod選定の理由・経緯
伊藤：情報システムチームでQA組織が立ち上がる前は、どのように品質管理されていたのでしょうか？
藤原：当時は社内サポートのメンバーが毎朝手動で「サービスが停止していないか」を確認する、最低限の外形監視を行っている状態でした。社内でも「できるだけ自動化しよう」という流れ自体はあったのですが、やはり「工数をいかに削減しつつ、いかに品質を担保するか」が大きな課題でした。
特にPIP-Makerはスライドを動画に変換するという製品の性質上、UIのボタン操作だけでなく「動画が正しく描画されているか」「アバターやテキストの配置が崩れていないか」といった視覚的な確認項目が膨大にあります。これまでは手動で一つひとつ動画を再生して確認していましたが、OSやブラウザの組み合わせごとにチェックを行うのは限界に近く、ヒューマンエラーのリスクやリグレッションテストにかかる工数の増大が大きな課題となっていました。
本来であれば開発部としても自分たちでE2Eテストなどの仕組みを構築して回すべきだとは考えていたのですが、どうしてもそこまで工数を割けないという現実的な課題がありました。そうした状況を見かねて木下の前任者が自動化ツールを探して動き始めてくれたのが、2024年頃のことです。
伊藤：MagicPodを導入される前、実際にそうした確認漏れによる不具合が表面化してしまうケースはあったのでしょうか。
木下：前任の方から伺っている話ですが、実際にいくつかヒヤリとする場面があったようです。例えばリリース後に一部機能が想定通り動作しなくなっていた事象を、お客様が気づかれる前に社内で発見できた、というケースが過去に何度かあったと聞いています。手動での検証範囲には限界があり、確認しきれない部分が出てしまっていたことが背景にありました。
そうした経験から、「たまたま社内の人間が気づく」という状態ではなく、「毎日きちんと高い精度で監視をしたい」ということで自動化の検討が始まったと聞いています。
検討にあたっては国内外のノーコードツールやSeleniumなども比較検討していたようですが、その中でMagicPodを見つけて触ってみたところ、「これが一番良いのではないか」と導入に向けて動き出したそうです。ちょうど選定が終わったタイミングで私への引き継ぎが発生したため、私は正式導入前のトライアルの段階から担当として触り始めていました。
藤原：選定の決め手となったのは、「導入ハードルの低さ」と「コストパフォーマンス」でした。
開発エンジニアがテストコードを書く時間を確保できない中で、MagicPodはノーコードで直感的にテストを作成・実行できるため、学習コストをほとんどかけることなく即座に運用を開始できます。さらに、画面のボタン操作だけでなく、ユーザーの視聴行動を再現して「正しく視聴ログが溜まっていくか」を確認する、といった当社ならではの特殊なテストにも柔軟に対応できる点も魅力でした。
製品の特性上、ユーザーにとって最も影響が大きいのは「動画が視聴できなくなること」、次いで「動画が編集できなくなること」です。この2つが圧倒的に影響度の高い部分になりますので、「問題なく視聴できるか」「しっかり編集できるか」というコアな部分については、現在自動化して回しているような形です。
テスト自動化立ち上げ支援プランの活用
伊藤：MagicPodの導入にあたって「立ち上げ支援プラン」をご利用いただきましたが、いかがでしたでしょうか？
木下：当時は前任者からの引き継ぎの真っ最中で業務量が多く、一人で新たなツールを習得するのは負担が大きいと感じてサポートをお願いしました。事前にテストを作り始めてはいたものの、支援プランで実践的な応用ノウハウを細かく教えていただけたことで日々の自動テスト運用体制へスムーズに移行できました。
最初は「XMLとは何か」「XPathとは何か」といった基礎知識の座学からスタートしました。その後は自分で作成してうまく動かない部分をハンズオン形式で直接レクチャーしてもらったり、次回に向けて「この機能について詳しく知りたい」とリクエストして講義を組んでもらったりと、「分からないところの解消」と「新機能の習得」という2つの軸で時間を有効活用できました。
支援プランをお願いしていなければ仕様理解や動かないときの原因究明に膨大な時間がかかっていたと思います。仕組みを細かく説明していただいたおかげでテストが動くロジックを本質から理解でき、「これがこう動くなら、次はこう応用できるはず」と自分でアイデアを広げられるようになりました。簡単なテストなら自力でも作れますが、「自分のやりたい形」へ細かく作り込む段階では、このプランで得た深い理解が支えになりました。
伊藤：実際に「自信を持って一人でテストを回していける」と確信が持てたのはいつ頃でしたか？
木下：3〜4か月で合計約15時間の支援プランが終わり、その頃にはだいぶ応用方法も頭に入っていました。社内から「こういうテストをやってみたい」と言われた際に、「じゃあ、あの機能をああやって組み合わせれば作れるな」と、パッと具体的な方法が思いつくレベルに達していました。
最初は正直「15時間って長いな」と思っていましたが、理解が進むにつれて「じゃあこれはどうなんだろう」と聞きたいことがどんどん増えていきました。序盤で全体の基礎を理解し、中盤で日々の疑問を解消し、最後のほうでより高度で詳しく聞きたいことを解決する、という非常に綺麗なサイクルで進めることができたので、終わってみれば15時間はベストな長さでした。
伊藤：開発側からご覧になって、木下さんのスキルアップや「手離れ」の実感はいかがですか？
藤原：想定をはるかに超えるレベルで自走してくれています。「こんなこともできるのか」と驚かされるテストもいろいろと構築してくれていて、当初はそこまで高度な自動化フローまでは考えていなかったので「MagicPodを使えばここまでできるんだ」と驚きました。開発側の手から完全に離れ、クオリティの高い検証を任せられているので、支援プランをお願いして本当に正解だったと思います。
MagicPodの活用状況
木下：PIP-Makerを対象に、動画編集画面の操作から実際に生成された動画のプレビュー再生までを自動化しています。特定のスライドが動画化された際、アバターや図形が期待通りに配置・表示されているかも自動でチェックする形です。本番環境では周辺機能を含めた基本操作テストを毎日実行して不具合の早期検知に努めており、開発環境でも週次で広範囲な定期テストを実行しています。現在、テストケースの数は全部で32個運用しています。
具体的な実行タイミングとしては、始業前の朝8時頃と終業前の1日2回、Chromeブラウザで全体の機能チェックを回しているほか、深夜の時間帯にはEdgeとFirefoxでも同じテストが走るよう設定しています。さらにこれらとは別に、動画が問題なく視聴できるかを3分おきに監視する1時間完結のテストを毎時間実行し、24時間ずっと監視し続ける体制を整えました。
伊藤：3分おきのテストは安定して動いていますか？
木下：最初は苦戦しましたが、工夫を重ねるうちに今では非常に安定して動くようになりました。動画視聴トラブルが発生した際もすぐに感知できますし、その通知は全社的に見られるチャンネルに流しているため必要なときはすぐに担当者へ連携できる状態になっています。
伊藤：素晴らしい運用体制ですね。現状、テスト全体の自動化としてはどのくらい進んでいるのでしょうか？
木下：毎日自動でチェックしたいコアな部分については、すでに100%に近い状態を実現できています。ただ、プロダクトの機能は常に新しく更新され続けますので、完全に100%で終わりということはありません。自分自身も入社して年月が経ち、製品への理解が深まるにつれて「こういうテストもあったほうがいいのではないか」というアイデアが次々と増えているため、全体的な進捗率としては現時点で7割くらいだと捉えています。
藤原：MagicPodの導入によって「ユーザーがちゃんと動画を見られる状態か」まで踏み込んで確認できるようになった意義は非常に大きいと感じています。現状はMagicPod側が安定していることもあり、木下にベースの監視を任せています。
伊藤：さまざまな時間帯や複数のブラウザで定期テストを徹底されているとのことですが、ブラウザアップデートによる影響を監視しているということでしょうか？
藤原：おっしゃるとおりです。特にChromeなどは突発的な仕様変更が多く、過去には仕様変更の影響で動画が見られなくなってしまったトラブルが起きています。開発環境も含めて定期的にテストを実行するようになったことで、ブラウザアップデート時の検知スピードが格段に上がりました。「視聴トラブルを未然に防げる」という心理的な安心感がチーム内に生まれたことはもちろん、開発中のデグレートを早期に発見できるようになったのも大きな成果です。
木下：また、品質面だけでなく工数削減の面でも大きな効果が出ています。弊社は毎週何かしらのリリースがあるのですが、以前はリグレッションテストを手動で行うと約4時間かかっていました。それが自動化によって、現在は約2時間で終わるようになっています。
さらに、MagicPodが動いている間に自分自身でより細かい箇所の手動テストを並行して実施できるようになりました。手動と自動を並行させることで、実質的な拘束時間を半分に圧縮しつつ、テストのカバー範囲を大幅に広げることができています。
伊藤：日常のテストと手動検証を非常にうまく並行されているのですね。そのほかにも、データパターンや変数を駆使したかなり高度なテスト運用も行っているとお聞きしました。具体的にはどのようなテストをされているのでしょうか。
木下：実はMagicPodを単なる画面のテストだけでなく、「視聴データの蓄積ツール」としても活用しています。
PIP-Makerは裏側で「誰が、いつ、どこまで動画を見たか」というデータを蓄積する仕様になっており、社内研修などで導入されているお客様は、そのデータをもとに「受講者がクイズで内容を理解できたか」を確認したり、未受講者に催促を行ったりします。
そのため社内では、大量のログを使って、お客様が管理画面から大規模な視聴レポートを出力する際のレポート機能の検証を行う必要があります。元々この検証は、必要な人数分のデータを手動で何度も動画を再生して用意せざるを得ず、大量のデータを準備することには限界がありました。そのため、事前に自動でログを蓄積させる仕組みは、導入の最初期からどうしても実現したかったことの一つでした。
そこで現在は、毎日MagicPodに自動で動画へアクセスさせ、データパターンと変数を細かく組み合わせてリアルな視聴ログを発生させています。例えば、ユーザーIDの末尾が2番か5番なら「動画を途中で離脱する」、動画内のクイズやアンケートに対しては、その時の視聴時間が偶数分なら「選択肢Aを選ぶ」、奇数分なら「選択肢Bを選ぶ」といった条件分岐を作っています。これにより、単一のテストケースでありながら、画一的ではない自然なばらつきを持った視聴データを、効率的に裏側へ収集できるようになりました。
この取り組みについては2025年の8月あたりから少しずつ試行錯誤を始め、データパターンと変数を自由自在に組み合わせて運用できるようになったのは秋頃だったと思います。やはり、立ち上げ支援プランのセッションの中で「データパターンのなかに変数を組み込む応用方法」などについて具体的に質問できたタイミングがあったからこそ、アイデアを形にすることができました。おかげで「こうすればもっと多彩なパターンが作れる」という深い学びにつながりました。
伊藤：AI機能も活用されていますか？
木下：はい、テストケースを修正するタイミングでMagicPod Autopilotを使用しています。先日、大きめのUI変更があったのですが、その際は最初の1箇所だけを自分で手動修正し、「これと同じ要素はすべて同じように書き換えて」とAutopilotに指示を出すことで一括修正を行いました。運用のノウハウがさらに蓄積されれば、もっと活用の幅が広がると期待しています。
最近は失敗分析のAI機能も重宝しています。予期せぬアラート画面などが原因でテストが失敗した際、エラーの技術的な原因をコードレベルまで一人で追い切るのは難しい場面もありますが、原因が曖昧なまま開発部に報告するわけにはいきません。しかし、失敗分析AIを使うと「これはこういう内容のアラートが表示されたための失敗です」と分かりやすく解説してくれるため、開発側への不具合報告が非常にスムーズになりました。修正作業だけでなく、報告業務の効率化という点でもAIの力を実感しています。
最後に
木下：現在は各機能ごとのリグレッションテストを中心に、さまざまなデータパターンでの検証を行っていますが、今後は最初のアカウント登録からの一連の流れを網羅した、お客様の実際の動きを想定した「ユーザーシナリオテスト」を作り込みたいと考えています。これまでは機能単体の検証に重点を置いていたので、今後はよりシナリオに重点を置いたテストを増やし、さらに品質を高めていきたいです。
エンジニア以外の担当者がテスト作成に着手する際、当初は意図した通りに動作しなかったり、原因が分からなかったりする場面も少なくないかと思います。ですが、MagicPodは非常に具体的かつ丁寧なサポート体制や、基礎から応用まで学べる立ち上げ支援プランが整っています。 「まずは自分たちで構築してみて、不明点があれば積極的に相談する」というスタンスで臨むことで、プログラミング経験がない方であっても安心してテスト自動化を推進できると思います。画面から気軽に、低い心理ハードルでサポートに相談できる操作性もおすすめしたいポイントですね。
藤原：開発部としては、やはりCI/CD回りでの連携強化を進めたいと考えています。現在は本番環境でのテスト運用が主になっているため、今後は検証環境などで先に自動テストを回し、開発主導でバグを検知できる仕組みをつくっていきたいです。
開発エンジニアがテストコードを書く時間が取れない企業にとって、このコストでこれだけのテスト範囲をカバーし、費用対効果を発揮してくれるMagicPodは非常に大きな存在です。「とりあえずこのリグレッションテストを回しておけば、ある程度の品質は担保できている」という確固たる安心感がチーム内に生まれることは、開発を加速させる上でも精神的にすごく大きなメリットになると実感しています。
株式会社4COLORS
- プロダクトサイト：https://www.pip-maker.com/
- コーポレートサイト：https://www.4colors.jp/
