テスト自動化が組織の品質文化を育てる！Hacobuが「ノーコード≠ノーデザイン」で築いたプロダクトQAの運用基盤とは

株式会社Hacobu

モバイルアプリテスト ブラウザテスト

株式会社Hacobu様に、MagicPod選定の決め手や導入時から現在までの活用状況について、MagicPod代表の伊藤がお話を伺いました。

株式会社Hacobu

クラウド物流管理ソリューション「MOVO（ムーボ）」シリーズと、物流DXコンサルティング「Hacobu Strategy（ハコブ・ストラテジー）」、システムインテグレーション・AI導入支援「Hacobu Solution Studio（ハコブ・ソリューションスタジオ）」を展開。トラック予約受付サービス「MOVO Berth」、動態管理サービス「MOVO Fleet」、配車受発注・管理サービス「MOVO Vista」、AI発注・輸送最適化サービス「MOVO PSI」などのクラウドサービス、ドライバーの働き方を変えるスマホアプリ「MOVO Driver」の提供に加え、物流DXパートナーとして企業間物流の最適化を支援しています。

POINT

  • テストの属人化脱却と、リグレッションテストの整備が導入前の課題に
  • 保守性と共有ステップを評価。構造的に作成できるMagicPodを選定
  • 長期運用を見据え、データ駆動テストを前提とした設計を初期から採用
  • MagicPod MCP×Cursor連携で、テストケースの自動レビュー基盤を構築
  • 朝の一括実行をリリース判定基準に組み込み、組織全体の品質意識が向上
左から ・川瀬 鉄矢さん　テクノロジー本部 プロダクト開発統括部 Vista部 ・伊藤 望　MagicPod CEO

左から
・川瀬 鉄矢さん　テクノロジー本部 プロダクト開発統括部 Vista部
・伊藤 望　MagicPod CEO

川瀬：Hacobuには2023年の8月に入社しました。私は配車受発注・管理サービス「MOVO Vista」のQAを担当しています。弊社には組織を横断する品質保証部門がなく、各プロダクトチームに専任のQAが入ってプロダクトごとに最適なテスト戦略を考えて進めていく“プロダクトQA”の体制を構築しています。

この体制ですと、新たな施策を始める際の合意形成がチームメンバー内で完結するため、QAの意思決定がそのままチーム全体のテスト戦略・品質向上に直結します。納得感を持って進めやすく、フットワークの軽さが大きなメリットだと感じています。QAエンジニアは正社員で9名いまして、個々に動いていますので2週間に1回ほど共有会を実施しています。また、興味関心の近いメンバーが少人数で集まって取り組む"ギルド"のような活動も活発です。

私はもともと開発エンジニアとしてキャリアをスタートし、SES企業で他社のシステム開発を14年ほど担当していました。その中で、キャリア後半にはチームやプロジェクト全体を見る立場になることが増え、小規模案件であればシナリオテストや結合テストを担当する機会が多くなっていきました。

その後、別の事業会社で事業企画やSIerとの折衝業務を担当することになり、当時その会社が進めていたアプリ開発の担当として参画しました。そこで「きちんと動くシステムを作る」という作り手側の品質だけでなく、「どうすればお客さまに満足してご利用いただけるか」というユーザー視点の品質に向き合う面白さを実感し、第三者検証会社で経験を積んだ後、Hacobuに入社しました。

MagicPod選定の理由・経緯

川瀬：プロダクトQAはHacobuの強みである一方、個人の感覚に依存してしまうという面もあります。私が入社した当時、アジャイル開発によるスピードを優先していたフェーズだったこともあり、リグレッションテストはマニュアルテストでカバーできる範囲で対応するという認識で整備されていませんでした。「どのテストを実施すべきか」の判断が実施者の裁量に依存しており、「どこに原因があるか分からないがデグレが起きている」という事象が発生しうる状況だったと言えます。

伊藤：自動テストの導入や、具体的なツールの選定は川瀬さんが推進されたのでしょうか？

川瀬：私が入社する前から検討されていました。経営層も含めて気にかけていたようで、MagicPod導入の際は弊社の代表も好意的な反応をしていました。私が入社した後は、レコーディングタイプのツールかMagicPodかという2択で検討を進めました。その中で、MagicPodは作成フローが容易であること、メンテナンス性も高いことを評価しました。個人的には共有ステップが用意されている点も良いと思いました。

ちなみにMagicPodは前職の第三者検証にいた頃、業務委託先の会社さんがリグレッションテストの自動化を検討されていた際に知りました。別の担当が進めていたので私は触る程度だったのですが、最終的にその会社さんでも導入されていました。

伊藤：無制限でテストが実行できる点を評価いただく会社さんも多いのですが、そこはそれほど重要なポイントではなかったですか？

川瀬：当時はそこまで具体的にイメージできていなかったかと思います。ただ、今おっしゃっていただいて毎日気兼ねなく実行できる状態は確かに大きなメリットだと感じました。

伊藤：ありがとうございます！海外製のテストツールやSeleniumなども候補でしたか？

川瀬：以前の検討ではそうしたツールも候補に入っていました。ただ、海外製ツールに多いレコーディングタイプは個人の作り方に依存しやすく、品質にばらつきが出やすい懸念がありました。また、コーディングベースのツールはメンバーによってプログラミング経験にばらつきがあり、立ち上がりの学習コストが懸念されたため候補から外しました。最終的に、構造的に作成できてメンテナンス性も高いMagicPodを選定しています。

伊藤：プロダクトQAでチームが分かれていると導入推進が難しいのではないかと思うのですが、どのように工夫されていますか？

川瀬：当初は推進するメンバーがもう一人いまして、その方が最初にトラック予約受付サービス「MOVO Berth」で導入しました。そこでレビューの仕組みやレビュー観点、テスト作成時の規約などをひと通り整備しまして、他プロダクトに展開する際はその仕組みを成長させながら適用していくというアプローチを取っています。

テスト自動化は、ツールの導入そのものよりも「どのような構造で品質を担保するか」を設計することが重要だと考えています。よく「ノーコードだから設計は不要」と誤解されがちですが、私は「ノーコード≠ノーデザイン」だと思っています。

実際に取り組む中で、テストの構造やデータの扱い、ルール設計といった“アーキテクチャ”を十分に考えずに実装から入ってしまうと、後から修正が難しくなり、結果として「失敗したテストが放置され、自動化が廃れてしまう」といった形骸化を招くケースが多いと感じています。

一方で、ツールの使い方自体は実際に触りながらでもキャッチアップ可能です。だからこそ、私たちのチームでは実装を始める前にテスト構造やデータ設計、運用ルールなど、後から変更しづらくレバレッジが効きにくい部分について初期段階で整備しました。

MagicPod導入初期の基盤設計

伊藤：具体的にどのような整備をされたのでしょうか？

川瀬：開発の現場ではプログラムのコーディングルールや変数規約があり、最低限の品質を担保する仕組みが導入されている場合がほとんどです。私自身がエンジニアとして開発経験を持っていたこともあり、それと同様のアプローチをテスト自動化にも適用しようと考え、大きく4つのレイヤーに分けて整備を進めました。

最初は運用後のメンテナンス性と実装のしやすさを考慮し、構成の設計に取り組みました。MagicPodの各機能が従来のどのテスト構成概念に当てはまるのか役割が明確になり、チーム内で共通認識を持って実装を進められるようになったと考えています。

次に安全なデータ駆動テストが実装できるようガイドラインと命名規約を整備しました。変数の種類ごとに命名規則を分けており、例えば共有変数は大文字のスネークケース、テストケース内変数はキャメルケースといった形で統一しています。

3つ目が運用設計です。構成やガイドライン・規約を整備しただけでは運用されない可能性があるため、テストケースの実装フローやレビューフロー、テスト失敗時の調査から修正に至るまでのフローを明文化しました。

そして最後が「活用の手引き」の準備です。導入直後は手探りでテストケースの実装を進めていたため、実装時の気付きやアンチパターンを蓄積するページを用意し、良いやり方や避けるべきパターンをチーム内で共有できるようにしました。こうした整備によって、運用が形骸化せず、修正もしやすい状態の土台を作ることができたと思っています。

伊藤：素晴らしいですね。ツール導入の前段階でここまでしっかり整備されているケースは珍しいと思います。「ノーコード≠ノーデザイン」という考えが運用にしっかりと反映されていると感じました。

川瀬：ありがとうございます。ただ、こうした運用基盤をしっかり継続していくうえで初期段階におけるチームのモチベーション維持も重要でした。そこで役立ったのがMagicPodのアナリティクス機能です。特に運用の健全性を測定してくれる「ヘルススコア」を90点台で安定させることを当面の目標に設定しました。評価項目が段階的に分かれており項目ごとの重要度や優先順位も表示されるため、ゴールを短いスパンで区切りやすく、モチベーションの維持につながったと感じています。

MagicPodの活用状況

川瀬：現在はMOVO BerthとMOVO Vistaに加え、スマホアプリも含めて3つをMagicPodで自動化しています。アカウントは開発者にも発行しているため、50人ほどになっています。チームによりますが私が参加しているプロダクトではリリース判定にも活用しており、定期リリース外のタイミングで開発者が独自にMagicPodを実行してリリース判定を行うこともあります。

スケジュール実行は朝の7時半から動かして45分ぐらいで終わり、実行結果だけを通知するSlackチャンネルに結果が届きます。基本的にはMagicPodの一括実行が失敗するとQAが調査に入りますが、関心を持っているメンバーは自発的にエラー原因の確認に動いてくれます。一時的な問題かどうかを切り分け、フロントエンド・バックエンド側の不具合であれば修正のうえ、再度リリース判定として実行しています。

実は以前、日次テストの結果を確認する前に本番リリースされてしまうことがあり、テストとリリースが結びついていないという課題がありました。そこで「朝のテストがすべて成功していること」を明確なリリース基準として設定しました。それ以外のタイミングでの実行に関しても自動ワークフローツールを利用していまして、Slackでコマンドを打つと勝手に一括実行が流れる仕組みになっています。

伊藤：開発エンジニアの方たちもMagicPodを見ていただいているようですが、導入してから良いフィードバックなどありましたか？

川瀬：テストで拾いきれなかった不具合がリリース前に検出できている点について評価してもらっているようです。リリース前にきちんと動作確認するという共通認識でチーム全体が動いているため、それが安心感につながっているのは目に見える効果として表れていると感じます。また、リリース判定に組み込んだことで開発エンジニアが「MagicPod実行した？」と気にかけてくれたり、朝のテストに間に合わせるために前日までにリリース内容を確定させる文化がチームに生まれたりと、組織全体の品質意識が高まったのも大きな収穫でした。

伊藤：開発チーム全体に良い文化が生まれているのは素晴らしいですね。そうした毎日の安定した運用を支えるうえで、テストケース自体の保守性も重要になってくるかと思います。共有ステップを作る際の粒度の基準や、保守性を高めるためのコツなどありますか？

川瀬：基本的にAPIの部分は必ず共有ステップとして、呼び出しから結果の取得、返却までを一連で実装する方針です。それ以外にも、頻繁に使用されるものやフロントエンド側の共通部品で使われているものについては、積極的に共通化する方針で進めています。

また、保守性を高めるもう一つの工夫としてAIを活用した自動レビューの仕組みがあります。具体的にはCursorとMagicPodのMCPを連携させています。Cursor側の設定にあらかじめ弊社のコーディングルールや変数の命名規約をすべて読み込ませておき、独自のカスタムコマンドを作成しました。

このコマンドを打ってテストケースの番号を指定すると、AIが規約を参照しながら自動でレビューし、修正すべきポイントをフィードバックしてくれます。実際の運用フローとしては、各メンバーが手元のローカル環境でこの自動レビューを実行し、出た結果をNotionに書き込みます。そして、その内容をもとに他メンバーへ最終確認のレビューを依頼し、問題がなければ本番の運用に乗せる、という流れになっています。

レビュー以外にもCursorからMCPサーバーを経由して、一括実行で失敗したテストだけを再実行する処理や、APIからデータを取得して実行時間の推移をグラフ化するといった検証も行っています。GUIでは少し手間がかかる集計や分析処理も自然言語のプロンプトを入力するだけで実行できるため、テスト自動化の運用の自由度が格段に上がったと感じています。

伊藤：AIを活用した自動レビューやMCPを通じた集計など、かなり高度な工夫をされている印象です。今後、そうした仕組みを社内の他のメンバーやチームへどのように展開させていこうとお考えですか？

川瀬：弊社の組織文化は個の自律やチーム最適を非常に重んじています。そのためトップダウンで管理するのではなく、どう現場の主体性を生かしながら広げていくかが今後の課題だと捉えています。ただ、弊社の良いところとして新しいツールを試したいと提案すれば会社として「やってみよう」と後押ししてくれ、チームの垣根を越えてSlackなどで活発に意見交換が行われる文化があります。そうした環境を生かしながら社内に浸透させていく必要があると考えています。

AI時代の開発スピードに伴走するQA組織へ

伊藤：今後AIを活用して解決していきたい課題はどのようなところでしょうか？

川瀬：AIに対する習熟度もチームや個人によって理解度の差が生じます。AIの提案をテストにうまく落とし込むのに苦労するメンバーや、修正時に予期せぬ影響範囲を発生させてしまい試行錯誤しているメンバーもいます。また、ある修正がMagicPodのどのテストケースに影響を及ぼすかを事前に把握しきれず、リリース判定に使っているにもかかわらず影響が後追いで判明してしまうのも大きな課題です。この見えない影響範囲の検知を、AIで防ぎたいと思っています。

伊藤：変更に対する影響範囲の特定ですね。最近ですと、MagicPod MCPを活用してCursorなどのAIエディタにGitHubのプルリクエストURLを渡し、「この修正に影響がありそうなテストをリストアップして」と指示することで、テストを実行せずともある程度の洗い出しが可能です。

川瀬：それは便利ですね、確認してみます。弊社の開発環境はdevやstgに加え、開発単位のtopic環境も並走しており非常に複雑です。リソースに余裕があればトピック環境で網羅的に確認できますが、忙しいとどうしてもdev環境での確認のみで済ませてしまうケースが出てきます。

特に他人が作成したテストを引き継ぐ場合、その背景にある設計思想まで読み取るのは容易ではありません。その結果、全体の構造を考慮せず「エラーが出たステップだけを局所的に直す」といった対応になりがちで、それが運用の大きな課題だと感じています。

伊藤：なるほど、環境が複雑な分、テスト実行前の切り分けが重要になるわけですね。事前の検知によって無駄な実行を減らせるのは大きなメリットかと思います。また、エラー箇所の修正だけでなく背景まで踏まえて、より簡単に、かつ正しく直せるようなサポートも今後は重要になりそうですね。

川瀬：おっしゃる通りです。その「直すためのサポート」という点では、現在提供されているMagicPod Autopilotについて、共有ステップに対応していただけるとさらに強力になると感じています。現時点でもデータパターンを使用していれば関連する変数を適切に取得してくれることは確認できており、この点は活用できそうです。普段使わない計算ロジックなど、細かな使い方も任せやすい印象です。

伊藤：先ほど影響範囲の特定でCursorとMCPの話をしましたが、さらにもう一歩進んだ使い方もあります。運用フローとの兼ね合いもあるかと思いますが、AIエディタ上でコードをレビューし、その結果をMCP経由でそのままテストの修正に反映させるような使い方はされていますか？

川瀬：今のところ、そういった形では活用できていません。

伊藤：実は最近、MCPからAutopilotを呼び出せるようになり、エディタから「このレビュー結果をテストにも反映して」と指示するだけでテストの新規作成や修正を自動で行ってくれるようになりました。ただ、現時点の仕様ではテストのブランチではなくメインブランチに直接変更が反映されるため、実行履歴を見て問題がないか確認していただくひと手間が必要になります。

川瀬：新規作成のテストであれば、メインブランチへの直接反映でも全く問題ありません。それは非常に便利ですね、ぜひ試してみます。ありがとうございます。

最近はAIによるコード生成などで機能開発のスピードが劇的に向上しており、QAが旧来のマニュアルテストのままではリリース全体のボトルネックになるという危機感が社内にもあります。

伊藤：開発スピードがAIで加速していく中、QAがいかにそれに追いつくかは業界全体の大きなテーマですね。単にスピードを求めた使い捨てのテストではなく、変化に強く安定運用できるテストこそこれから求められてくるはずです。MagicPodもアップデートを続けていきます。

最後に

川瀬：導入当初のミーティングで、よくある失敗事例や運用のコツを事前に共有いただいたおかげで、最初から長期運用を見据えた構造を設計できました。この2年間の歩みを振り返ると、あの最初の土台作りがしっかりできていたことは本当に良かったと感じています。

リグレッションテストを自動化する意義自体は、いまや多くのエンジニアが理解していると思います。ただ、それを「個人の技術力に依存せず、誰が触っても一定の品質で実現できる」という点にこそ、真の価値があるのではないでしょうか。組織全体に自動化の文化を根付かせ、属人化を防ぐツールとして、MagicPodを採用して正解だったというのが私の率直な感想です。

株式会社Hacobu