テスト自動化で工数削減と意識改善を実現。ポーラ・オルビスの「いつかやろう」を断ち切るスモールスタート戦略とは

株式会社ポーラ・オルビスホールディングス

ブラウザテスト

株式会社ポーラ・オルビスホールディングス様に、MagicPod選定の決め手や導入時から現在までの活用状況について、MagicPod代表の伊藤がお話を伺いました。

株式会社ポーラ・オルビスホールディングス

ポーラ・オルビスグループは、ポーラを創業ブランドとし、2029年に創業100周年を迎える化粧品を中心としたビューティーブランドの企業グループです。エイジングケアや美白領域に強みを持つポーラと、スキンケアブランドのオルビスを基幹ブランドとして、多様化する「美」の価値観に応える個性的なブランドを展開しています。

POINT

形骸化したテストが「やる意味あるの？」という意識の悪循環を招いていた
料金の透明性と実行回数無制限がMagicPod選定の決め手に
スプリントあたり最大4時間かかっていた手動テスト工数をゼロに削減
スモールスタートの成功体験が意識を変え、テストは「作業」から「文化」へ

左から
・早川美穂さん　グループデジタルソリューションセンター ITプロダクト開発チームチームリーダー
・川田大蔵さん　グループデジタルソリューションセンター ITプロダクト開発チーム
・伊藤望　MagicPod CEO

早川さん（以下、早川）：私はITプロダクト開発チームのマネージャー兼プロダクトオーナーを担当しています。このチームはグループデジタルソリューションセンター（GDSC）に所属していまして、全体で100人ほどが在籍しています。以前はブランドごとに情報システム部門が存在していましたが、グループ全体のシナジーを最大化する目的で2022年4月にGDSCとして統合しました。

その中で我々が所属しているITプロダクト開発チームは、社員と業務委託のメンバーを合わせて10人ほどになっています。システム開発はもともと外部ベンダーに委託していましたが、市場の急速な変化に柔軟かつタイムリーに対応するため2023年1月に内製開発チームとして発足し、オルビスのシステムを内製化するところから着手しました。そのため現在もオルビス関連の比重が大きいのですが、特定のブランドに特化しているわけではなく、グループ全体を横断的に見るチームになっています。

川田さん（以下、川田）：同じくITプロダクト開発チームでスクラムマスターを担当している川田です。MagicPodの導入検討、選定から実際の導入までをリードしました。以前いた職場で自動テストがあることのメリットや、逆にないことによる大変さを強く実感していましたので、当社に入社した際、テストが手動で進められている状況を目の当たりにして、「これは何とかしたほうがいい」と考えて自動化の検討を始めました。

伊藤（MagicPod代表）：現在どのようなシステムを扱っているか、具体的に伺えますか？

川田：現在メインで扱っているのは社内向けのシステムで、特にオルビスの商品を管理するシステムに注力しています。このシステムはオルビスで長年にわたり機能追加されてきた大規模な基幹システムにあった機能の一部なのですが、市場の変化に合わせて迅速に機能改善を行うことが難しいという課題があったため、変更の要求が多い部分を我々が切り出して新規で開発しました。技術構成としてはバックエンドがPython、フロントエンドがReactになっています。

MagicPod導入前の課題

川田：私は内製開発チームが発足した後に入社したのですが、開発組織が立ち上がったばかりで、まだ体制が十分に整っていませんでした。
テストは当時Cypressを使っていましたが自動実行や定期実行がされておらず、メンテナンスも追いついていないため実質的に機能していない状態でした。そのため、動作確認は手動テストに依存していました。

特に大変だったのが、商品管理システムがオルビスの社員がPCで利用するケースと、店舗のBA（ビューティーアドバイザー）がiPadで利用するケースの2つがあり、通常のブラウザでのテストとChromeのモバイルエミュレーションを用いたiPad相当のテストを両方行う必要があった点です。

加えて、開発組織としての文化づくりを進めている段階でもありました。自動テストの必要性は認識していたものの、なかなか前に進まないという状況があり、これから機能が増えるにつれてテスト時間も増えることも明らかでしたので自動化ツールの導入を検討しました。

伊藤：テストを専門に行うQAチームなどはあるのでしょうか？

早川：QAチームはありませんので、開発チームの中で実装からテストまで行っています。

川田：前職の経験から、アジャイルに価値提供を行うためには自動テストが必要になることを身を持って知っていましたので、早川に「今やらないと将来、必ず開発スピードの足かせになります」という話をして自動化を進めることになりました。

川田大蔵さんグループデジタルソリューションセンター ITプロダクト開発チーム / 伊藤望 MagicPod CEO

MagicPod選定の理由・経緯

川田：自動化ツールをいろいろ調べていく中で、MagicPodを含む3つのツールを最終的な候補として挙げて検討を進めました。先ほどお話したとおり、テストコードはあっても動いておらず、メンテナンスにもコストをかけられていない状態が続いていましたので、運用のしやすさを優先してノーコードツールを検討しました。

伊藤：3つに絞る際は何を重視しましたか？

川田：私自身、ノーコードのテストツールは使ったことがなかったため、最初どういう観点で選定すればいいか迷いました。ある程度は使ってみて判断するしかないと思ってはいたものの、導入してから「やっぱりだめでした」となって乗り換えるのは大変ですから、ある程度の導入実績があれば機能的にもブラッシュアップされているだろうと考えて、業界でメジャーなツールであることを重視しました。

伊藤：確かにそこを重視されている会社さんは多いですね。3つに絞った中で、最終的にMagicPodを選んでいただいたわけですが、何を決め手にされたのでしょうか？

川田：MagicPodさんはQiitaやZennで導入事例を多く見かけましたし、MagicPodさん主催のセミナーやユーザーコミュニティがあることも安心感につながりました。そのうえで決め手になったのは「テスト実行回数に上限がないこと」と「月額費用が抑えられており、単月契約も可能でスモールスタートできること」です。

他のツールは金額が公開されておらず、問い合わせが必要というハードルがあったのですが、MagicPodはサイトに料金がわかりやすく明示されていたので、「これなら試せる」とすぐ判断できました。そこで最初にトライアルをお願いしました。

伊藤：トライアルの感触はいかがでしたか？

川田：いろいろ考えずに、だいたいの機能を直感的に使えたのが大きかったです。営業の方に少し質問した程度で動かせましたので、「私が使えるなら開発メンバーも使えるだろうな」と思いました。やりたいと思った時にどうすればいいか迷うことがあまりなく、「すごく使いやすい」と感じたことが印象に残っています。

伊藤：ありがとうございます！

MagicPodの活用状況

川田：現在は商品管理システムに対して、通常のブラウザテストとChromeのモバイルエミュレーションを用いたiPad相当のテストを2パターンで実施しています。具体的には最低限確認しておきたい正常系のテストを平日の午前9時から午後6時まで、1時間ごとに実行しています。結果はSlackに通知し、エラーが続く場合は開発チームで確認するような運用になっています。

今後は他のテストケースを含めた全体的な網羅テストを1日1回実行することを目指して、テストケースを準備中です。将来的にはさらに発展させて、CI/CDパイプラインと連携して、特に重要な正常系に絞ってデプロイ前に確認したいと考えています。

伊藤：導入によって何か数値的な効果や、工数削減につながった点はありますか？

川田：店舗でのiPad利用はシンプルな参照機能のみのため、MagicPodでテストを完結できるようになったお陰で導入前に1スプリント（2週間）あたり2〜4時間を費やしていた手動確認の工数がゼロになりました。全体としては、MagicPodでテストを作成・メンテナンスする工数が発生しているため時間削減効果は限定的ですが、毎時の実行による回帰テストで既存機能への影響検知が早くなったと感じています。

伊藤：現状、何人くらいで利用されているのでしょうか？

川田：ITプロダクト開発チームの全員が触れる状態にしています。MagicPodを使っていないプロダクトもあるため全員が毎日使うわけではありませんが、スクラムではタスクを取った人が必要に応じて修正するというルールになっていますので、全員アクティブに使っているといえます。

伊藤：どのような点がチームに合っていると感じますか？

川田：テスト実行回数とユーザー数に制限がない点は、非常に便利だと感じています。他にもノーコードで直感的にテストを作成できる点と、インターフェースがシンプルなところが良いですね。コマンドも豊富ですし、共有ステップを作成できて再利用性・保守性が高いのも助かっています。

伊藤：ありがとうございます！　ちなみにAIエージェント「MagicPod Autopilot」は試していただけましたか？

川田：はい。いろいろ試しています。我々としても「生成AIを使って効率化していかなければ」という話は常々しており、今後もテスト生成やメンテナンス工数削減につながる機能追加を進めていただきたいです。弊社ではGitHub CopilotやDevinの利用を進めていますので、MagicPod MCPサーバー（CLI）が機能拡張され、開発からテストまでをワンストップで行えるようになることを期待しています。

伊藤：そこはぜひやっていきたいと考えています。

「やる意味ある？」から「テスト結果OKが当たり前」の文化へ

伊藤：日々の運用の他に、チームの文化や開発プロセスといった面で何か変化はありましたか？

川田：チームのマインドセットに良い影響があったと思います。私が入社した時は、みんなも「定期実行もメンテナンスもされず、動かそうとしても動かない」という状況を良くないと思っていました。一方で正しく動くようにするための工数がかなりかかるため、「いつかやろう」「そもそも、やる意味ある？」といったネガティブな雰囲気が出ていたように感じました。

そうなると自動テストを直すタスクの優先度がどんどん下がっていき、「自動テストがメンテナンスされない→テストが動かない→メリットが感じられない→メンテナンスのモチベーションが上がらない」という悪循環につながります。

しかし今後、プロダクトの機能が増えていく中で手動テストの時間も増え、開発スピードやアウトプットの低下が目に見えていましたので、どこかで悪循環を断ち切らないといけないと思いました。そこで取り組みやすいノーコードツールを利用することで、チームに自動テストの良さを実感してもらえるのではと考えたのです。

実際、少ないテストケースから徐々に範囲を広げてMagicPodで自動テストが動くようになると、徐々にメリットを感じて「エラーになってるから見ないとダメですね」という動きが出始めました。現在は「テスト結果がOKであることが当たり前、NGなら修正か改善をしなければ」という意識に変わったと感じています。

伊藤：その悪循環はMagicPodのような自動化ツールを入れることで断ち切れると思いますか？　それとも、まずはマインドセットを変えることから始めるべきでしょうか。

川田：そうですね。難しい質問ですが、やはり目に見える成果がないとマインドセットだけを変えるのは厳しいと思います。トップダウンで「やりなさい」と言うなら別ですが、こういったことは現場で手を動かしている人たちが効果を感じられないとなかなか前に進まず、変わらないのではないかと個人的には思っています。必ずチームに合ったやり方はあると思いますが、いずれにせよ、何か体感できるものが先かなという気はします。その一つの選択肢としてMagicPodは有効だと思います。

具体的な進め方としては、おそらく他社さんでもプロダクトの中に「ここは不具合が多いな」とか「ここは修正を入れる回数が多いな」といった箇所がきっとあるはずです。そういうところから始めると効果が出やすいのかなと思います。

最後に

川田：急速に変化する市場ニーズに対し、迅速かつ柔軟に対応しながら品質を保つためにはテストの効率化が必須だと考えています。すべてを自動化できるわけではありませんが、フロントエンドやE2EテストにおいてMagicPodは有力な選択肢になると思います。私たちも最初は1〜2ケースから始め、徐々に範囲を広げました。最初から完璧を目指さず、まずは小さく始めることが成功のポイントだと思います。

私たちの場合はMagicPodの導入によって、テストが「やらなければならない作業」から「品質を守るための重要なプロセス」という認識に変わったと感じています。小さく始めるという点でMagicPodは始めやすい料金体系になっていると思いますし、日本語のサポートやコミュニティも充実しており、困ったときに情報を得やすいことも安心できます。

私たちが感じていた課題は多くの会社に共通する「あるあるな話」だと思います。もちろんITに強い企業であればテストは当たり前かもしれませんが、リソース不足などで実践できていない会社さんはたくさんあるのではないでしょうか。機能が増えたり、サービスが長生きしたりすればするほど、テスト工数は雪だるま式に増えていきます。「できることは自動化して、本当に価値のあるところに時間を割く」ためにも、自動化は絶対にやるべきだと思います。