〜手厚いサポートと拡張性。MagicPodは“作り手次第”でどこまでも育てられる〜
こんにちは！PRESIDENT CARDチームでQAを担当している、yukaです。
2025年12月11日（木）に行われた、株式会社MagicPod様開催の「ノーコードE2Eテスト自動化体験ワークショップ」に参加してきました！🚀
イベントページはこちら magicpod-product-seminars.connpass.com
本記事では、ワークショップでの体験や学び（MagicPodの使いどころ・向き合い方） などをまとめています。
自動テストを実運用中のエンジニアさんはもちろんのこと、まさにいまMagicPod導入検討中の方にも参考になれば嬉しいです！
筆者の前提
- QA歴5年目
- 自動テストツール使用経験あり（Autify / mabl）
- MagicPodは初心者（前任者からケースを引き継いだ状態で、これからどう活用していくかを模索しているフェーズ）
「MagicPod、ちゃんと育てられる？」を確かめたかった
触り始めてすぐに、こんな不安がありました。
- ケースが増えるほど壊れやすくならない？
- ロケータ設計、これで合ってる？
- メンテナンスコストが跳ね上がらない？
自動テストは便利ですが、
「育てられないと負債になる」未来も想像しやすい領域です。
だからこそ、開発者や実運用者が
どんな前提で設計し、何を割り切って運用しているのか を知りたくて、参加しました。
MagicPod社に到着！
ドキドキしながらオフィスに到着。
エレベーターに乗ろうかとドギマギしていたら、社員の方に「イベント参加の方ですか？」
と声をかけていただき、ホッと安心✨
さっそく綺麗で広々とした席にご案内いただきました！
当日は入門コースと実践コースに分かれていて、私は実践コースに申し込みました。
実践コースの参加者は、私1名のみ。
なんと開発者の方とマンツーマンで2時間みっちり質問させていただけるという
贅沢すぎる時間でした！🙌
（入門コースは導入検討中の方向けのようです。気になる方はぜひconnpassのページをチェックしてみてください！）
ワークショップで得た４つの学び
ここからは、特に印象に残った学びを4つにまとめます。
どれも「MagicPodの使い方」というより、自動テストの設計や運用の考え方を見直すきっかけになった内容ですので、最後までお付き合いいただけると嬉しいです！
学び①：自動テストが不安定なとき、まず見直したいのはテスト設計
【Before（悩み）】
自動テストが落ちると、つい
「ツールが不安定なのかも」「ノーコードは限界があるのかも」
と思いがちでした。
【Insight（気づき）】
開発者の方と一緒に確認すると、不安定さの原因はだいたい 設計の曖昧さ にありました。
具体的には、
- 画面の描画完了を待たずに次へ進む
- 前提条件（必要な状態やデータ）がケースに書かれていない
- 「とりあえず動く」書き方になっている などです。
つまり、テストの意図がツールに伝わっていないことが原因になっているケースが多かったんだと理解しました。
【After（これから）】
落ちたときに「ツールのせいかも」と思う前に、
“意図が伝わる設計になっているか？”を見直していく。
ここを丁寧に作れると、MagicPodは十分“育つ”ツールになりそうです。
学び②：ロケータは“力技”より“変化を前提にした設計”が効く
【Before（悩み）】
最新年月の表示など、毎月変わるUIがあるとロケータが不安定になりやすく
「毎月メンテが必要では？」というのが懸念でした。
【Insight（気づき）】
ここは 変数などで“今月”のような動的要素を表現する考え方が有効でした。
「変化するものを固定しようとしない」というお話が、腑に落ちました。
【After（これから）】
「取れるロケータ」ではなく、
“運用し続けられる指定か？”という観点で設計していくのが大切だと感じました。
変化する値を吸収できる作りにしておくと、メンテの辛さがぐっと減りそうです。
学び③：安定しているテストは、だいたい“読みやすい”
【Before（悩み）】
自分以外が作成したケースに対して、前提や意図がパッと見では読み取れず、
「これって何を保証してるんだっけ？」となりがちでした。
（自分で作成したケースについても時間経過とともに記憶が薄れ、
同じ悩みに直面することがありました）
【Insight（気づき）】
そこで話に出たのが、ケースを整理する基本パターンである AAA / Given-When-Then でした。
考え方自体は知っていたものの、「とりあえず動く」を優先してしまい、ケースに落とし込めていなかったと気づきました。
コメントステップをさらに有効活用し、「前提 → 操作 → 結果」を整理して書くだけで
- 意図が明確になる
- メンテしやすくなる
- 結果として壊れにくくなる
という好循環が生まれるとのこと。
【After（これから）】
読みやすさを意識して整えることが、結果的に安定性につながると実感しました。
「動くか」より「人が理解できるか？」を大切にしながら、ケースを育てていこうと思います。
学び④：「実行時間」と「制限事項」は、現実的に設計で折り合える
【Before（悩み）】
自動化を進めるほど、
- 実行時間が長くなる
クラウド実行に制約がある
といった運用面が心配でした。
【Insight（気づき）】
MagicPod側の回答は、かなり現実的なものでした。
- ケース単体での短縮は限界がある
- 並列実行が一番効く
- できないことがあっても、設計や代替策で寄せられる
「全部を自動化しなくていい」という考え方も含め、無理のない運用ができそうだと感じました。
【After（これから）】
全部を自動テストで抱えようとせず、
目的を守りつつ手段を選ぶ発想が大切だと実感しました。
実行時間や制約も含めて、現実的に回る設計を目指していきたいです。
今回の学びまとめ
- 自動テストが不安定なときは、ツールより先に テスト設計を見直す のが大切
- ロケータは「固定する」より、変化を前提に吸収できる設計が効く
- 読みやすいテストはメンテしやすく、結果として壊れにくい
- 実行時間や制限事項も含めて、現実的に回る設計を選ぶのがポイント
PRESIDENT CARDで目指したい、これからの品質活動
上記の学びを通して、MagicPodは「QAが定期実行するためのツール」ではなく、
設計と運用次第で品質活動そのものを進化させられるツールだと感じました。
「このテストは何を守るのか」
「どんな変更に耐えるのか」
を言語化しながら、プロダクトと一緒にテストも育てていきたいです！
おわりに
今回のワークショップでの学びから、
自動テストは「回すこと」がゴールではなく、品質で前進を支えるための手段だということを再認識しました。
MagicPodは、その挑戦を支える 土台・拡張性・サポート を兼ね備えていると感じます🚀
PRESIDENT CARDチームのQAとして、この環境を活かしながら、一段上の品質活動を模索していきます！✨
最後まで読んでいただき、有難うございました！
We Are Hiring !!
UPSIDERでは現在積極採用をしています。 ぜひお気軽にご応募ください。
UPSIDER Engineering Deckはこちら📣
