はじめに
kikitoriでプロダクトマネージャーをしている兒玉です。
本記事では、プロダクトマネージャーである私が、MagicPodを活用してプロダクトの品質向上に取り組んだ（取り組んでいる）事例について紹介します。
QAエンジニアが不在で、少人数でプロダクトを開発・運営しているスタートアップやチームにとって為になれば幸いです。
開発チームとして直面していた品質課題
nimaruはPMF目前の状況で、ほぼ毎日リリースを行う体制を取っています。ありがたいことにお客様も日増しに増えており、BizとDevが日々高速に連携しながら開発・リリースを進めています。
最終的な品質担保については、基本的に実装者が責任を持つ形で進めていましたが、ある日PRの内容からは想像しきれない箇所で、お客様にとってクリティカルな機能が操作不能になる事象が発生することがありました。
ポストモーテムを実施する中で見えてきたのが、お客様の主要な操作を担保する仕組みが存在していないという課題でした。
そこでこのタイミングで、主要なE2Eテストを継続的に実施できる仕組みを構築する方針を取りました。
一方で、進行中のプロジェクト状況を踏まえると、新たに体制を構築したり、エンジニアのリソースを大きく割いたりするのは現実的ではありませんでした。
そこで、私自身が過去にエンジニアとしてE2Eテストツールの導入・運用を少し経験していたこともあり、今回はプロダクトマネージャーである私が主導して進める判断をしました。
なぜMagicPodを選んだのか
nimaruの主要機能として、集出荷機能があります。
この機能では、生産者はスマートフォンから「いつ・何を・どれだけ出荷するか」を事前に連絡し、職員はPC・タブレット・スマートフォンを使って、実際に集まった農産物を受け取り、出荷先ごとに仕分け（分荷）を行います。その後、最終的に出荷内容を確定し、市場や取引先へ出荷するための出荷連絡を行うことができます。
この操作フローは、プロダクトにおける最重要ユースケースの一つであり、この一連の操作をテストできることを必須条件としました。
加えて重視したのが、運用に手間がかからないことです。
ここで言う「手間がかからない」とは、非エンジニアでもテストケースの作成・メンテナンスを低工数で行えることを含みます。
この条件を満たす候補として、MagicPodとBrowserStackに絞り、両方の無料枠を利用して使用感を試しました。
BrowserStackは、画面操作を録画するだけでテストケースを作成できる点が非常に魅力的でした。一方で、生成されたテストケースの修正時に、裏側で生成されているコードを修正する必要が出てくる点に、長期的な運用面での懸念が生まれました。
その点、MagicPodでは同様の懸念がなく、テストケースの保守をコード修正に依存せず行えることが、選定の決め手となりました。
プレ導入期間の計測指標について
MagicPodは価格面で見るとBrowserStackよりも高額なため、いきなり本導入するのではなく、成果を計測しながら慎重に導入する方針を取りました。
具体的には、月契約で3か月間のプレ導入期間を設け、その後に年契約に切り替えるかの判断を行う形にしました。
そこで、プレ導入期間中は以下3点の基準で、毎月1回振り返りをしました。
保守工数（1か月あたりのメンテ時間）
- 非エンジニア主体でも無理なく回せるか
- 目標：5〜7時間以内
- 「負荷が高くて回せない」状態にならないか
安定稼働性
- UI変更がない限り安定して動き続けるか
- テスト落ちが頻発しないか
- テスト落ち時の対応工数が過度でないか
品質担保への実感
- コア機能の自動実行によって、致命的なデグレを検知できているか
プロダクトマネージャー主導で進めた導入・運用の進め方
まず、MagicPod導入の目的をチーム全体で共有しました。
このテストがテストピラミッドのどこに位置づけられるのか、主要ユースケースに絞って自動化する理由、そして「メンテナンスを増やさない」ことを特に重視しました。
過去にエンジニアとしてE2Eテスト導入を進めた際、QA知見が乏しい状態でユニットテスト寄りの内容をE2Eで自動化してしまい、失敗した経験があります。その反省から、今回はここを強く意識しました。
次に、先輩プロダクトマネージャーを巻き込みながら、nimaruにおける主要ユースケースをユーザーシナリオとして定義しました。
プレ導入期間では、特に優先度が高い3つのユーザーシナリオを自動化対象としました。
幸い、過去の大きな改修時に使用していた手動テスト用のユーザーシナリオが存在していたため、それをベースに進めることができ、選定と定義に大きな時間を割かずに済みました。
テストケースの作成は、まずは私一人で行うことにしました。 また、テスト結果はSlackへ通知し、毎時の自動実行形にしました。
開発との連携としては、1時間に1回dev環境でMagicPodを実行し、テストが通っていることを確認したうえでリリースを行ってもらう運用にしました。
実際に導入・運用してみてどうだったか
2025年12月に初回の振り返りを行いました。
主要な成果としては、運用体制の構築や初期セットアップ、Slack連携の整備に加え、優先度が最も高いテストケースを作成し、安定的に稼働させられた点が挙げられます。
また、保守工数は月6時間程度に収まり、自動補正機能も有効に働いたことでテスト落ちはほとんど発生しませんでした。 これらの結果から、MagicPodは本導入に向けて十分に手応えのある指標を示していると感じています。
プロダクトマネージャー視点での課題とその打開策
1. テストケース作成にかかるリソース確保
現状は私一人が立ち上げを担っており、意識的に時間を確保しなければ進まないのが正直なところです。一方で、共有ステップ機能を活用してテストケースの部品化を進めたことで、以降のテストケース作成は徐々に効率化できています。実際に、1ケースあたりの作成時間は確実に短くなってきており、運用として現実的な手応えを感じています。
2. MagicPodの運用が属人化
テストケースの作成や運用を一人で担っているため、このままでは継続性やスケールに限界があります。その打開策として、本導入を見据え、テストが落ちた際には、その変更によって影響を与えたエンジニア自身が修正対応できるよう、簡易的なマニュアル整備を進めています。将来的には、私がすべてを抱え込むのではなく、チーム全体で品質を支える体制に移行していきたいと考えています。
3. E2Eテストだけでは担保しきれない領域が存在すること
nimaruには各種帳票のPDFを出力する機能がありますが、PDFの中身などは自動テストの対象にしづらく、引き続き人の目による確認が必要です。こうした領域については、自動化にこだわりすぎず、自動化と人力を組み合わせたハイブリッドな体制を前提とすることが、現実的かつ健全な選択肢だと感じています。
今回の取り組みを通しての学びとみなさんへ伝えたいこと
今回の経験を踏まえ、これから同じような取り組みを行う方に伝えたいポイントは、主に次の3点です。
一つ目は、すべてを自動化しようとしないことです。
E2Eテストで担保すべきなのは、プロダクトにとって「絶対に落とせない操作」に限る、という割り切りが重要だと感じています。
二つ目は、「絶対に落とせない操作」から着手することです。
最初から広く網羅しようとすると、テストケースの作成・保守が重荷になりがちです。まずは影響範囲が大きく、失敗した際のインパクトが大きいユースケースに絞ることで、小さくても確実な価値を出すことができます。
三つ目は、ツール導入そのものをゴールにしないことです。
MagicPodは非常に便利なツールですが、導入すること自体が目的になってしまうと、運用が形骸化しやすくなります。小さく始め、価値を確認しながら徐々に広げていく、そのプロセスを、役職にとらわれず誰かがしっかり主導することが、品質向上をプロダクト改善につなげるうえで重要だと考えています。
まだ取り組みは途中ですが、同じような課題を抱えるチームの参考になれば幸いです。
最後に
kikitoriでは事業拡大に伴い、一緒に働く仲間を募集しています！
ご興味ありましたらぜひお気軽にエントリー・面談をお申し込みください。
お待ちしております！
