UbieでQAエンジニアをしている @tmasuhara です。
今日はプロダクトのオペレーションに使っているPlaywrightベースのツールにおける技術スタック移行について書きます。
ツールの概要
このツールは、YAML設定ファイルに基づいてPlaywrightテストを動的生成・実行する自動化ツールです。非エンジニアでもYAMLファイルを編集するだけで複雑なテストシナリオを作成できるのが特徴です。テスト対象のシステムについてはこの場では割愛させてください。
処理の流れ
- YAMLファイルでテストパラメータを定義
- テストケース生成スクリプトがテンプレート内のプレースホルダー（
[[変数名]]）を置換 - 生成されたテストスペックでPlaywrightが実行
- 結果をキャプチャしてGoogle Driveにアップロード
ブラウザ操作にはPlaywright、設定管理にはYAMLを使用しています。UI操作の抽象化にはページオブジェクトパターン（テストでよく使われる、画面操作をクラスにまとめる設計手法）を採用していますが、一部にとどまっています。
移行の背景と課題
技術スタックの分散によるメンテナンスリソース確保の困難
このツールには実装当初から重要な処理にPythonが使われていました。具体的には、全体のオーケストレーション、YAMLからテストケースを生成する処理、Google Driveへのファイルアップロード処理です。
Ubieのメイン技術であるGoとNode.jsから外れているため、メンテナンスリソースを増やしたいと思っていたもののPythonが技術的なブロッカーとなっていました。ちなみに私もPythonは詳しくないです。
環境構築とトラブルシューティングの複雑さ
Python + Node.jsの混在により、新しいメンバーの環境構築が煩雑になっていました。pipとnpmの両方を管理し、Python仮想環境とNode.jsのバージョン管理を並行して行う必要があります。さらに、利用者がWindowsで開発者（私）がmacという環境の違いが、トラブルシューティングを困難にしていました。
移行の進め方
CursorやClaude Codeを活用し、社内のもくもく会（各自集中して作業に取り組む会）をきっかけに段階的に移行を進めました。
まず最重要のテストケースの生成処理から着手し、PyYAMLをjs-yamlに、文字列置換をTypeScriptのreplaceAll()に、ファイル操作をNode.jsのfsモジュールに置き換えました。
Google Drive連携は簡素化し、APIを使った自動アップロードから「ブラウザでフォルダを開く」方式に変更しました。これにより認証周りの複雑さを一定解消できました。
移行時のポイント
Google Drive周りの挙動が既存と変わってしまうことを懸念して、移行が止まっていた時期がありました。しかし、オペレーションチームの方と直接会話することで、挙動が変わっても業務上問題ないことが判明し、一気に移行を進めることができました。
技術的な懸念があるときは、利用者と早めに相談するのが大事だと感じました。想定していた「変えたらマズそう」と思っていることが、実は運用上問題ないこともあるし、今の挙動・仕様が変えられないわけではないという学びを得ました。
おわりに
技術スタック移行により基盤が整い、今後はより多くのメンバーが改善や機能追加に参加しやすくなるはずです。実際の他のメンバーによる運用はこれからなので、成果についてはこれからかなと考えています。
今後は、このツールの事業における位置づけであったり、他のツールでできることも視野に入れて、投資対効果を見つつ運用や改善ができればなと思います。
Discussion