※ 本内容は英語版からの翻訳です。元記事はこちら
ロサンゼルスに拠点を置く、家具のレンタル・買取ベンチャー企業、Fernish。今回のインタビューでは、Fernishでフロントエンド・テックリードとスタッフエンジニアを担当しているAJ・アルマガーさんにお話をうかがいました。
同社では、ワークフローにおけるエンドツーエンド回帰テストに大きな課題を抱えていたとのこと。また、小さなスタートアップであることもあり、エンジニアたちは仕事が山積みでした。
AutifyでE2Eテストを自動化したことで、すべてのテスト環境を検証できるようになり、テストを担当していたプロダクトマネージャーの負担も軽減されたなど、主な課題を解決できました。
AJさんは、AutifyがFernishに合った価格帯だったこと、弊社のソフトウェアテストツールを導入することで工数とコストを削減されたこと、安心感があることなどをお話しいただきました。では、インタビューをご覧ください。
– まず、Fernishの事業内容と担当業務について教えてください。
AJ: AJ・アルマガーです。Fernishでフロントエンド・テックリードとスタッフエンジニアを担当しています。
Fernishは、ロサンゼルスに拠点を置く家具レンタル会社です。最初は、カリフォルニアとシアトルで販売していました。その後、テキサス州オースティン、ダラス、フォートワースに事業を拡大し、最近ではニューヨークとワシントンDCに新たなマーケットをオープンしました。Fernishは約4年前に創業され、私は3年前からここで働いています。
– チーム構成はどのようになっていますか？
AJ: エンジニアは8～10人くらいいます。実は、QA担当者がいないんですよ。だからこそ、Autifyのような製品を見つける必要がありました。
– Autify導入前はどのような課題がありましたか？以前、どのような問題に直面していたのでしょうか？
AJ: コードに対するユニットテストと回帰テストは、効果的に実行できていました。ただ、E2Eテストを書くことに少し困っていたんです。それに、スタートアップですから、しなければならないことをスピーディーにこなさなければならない。したがって、E2Eテストソリューションがないことが課題でした。
もう少し詳しく説明すると、プロダクトマネージャーがリリースプロセスに参加しなければならなかったのです。プロダクトマネージャーがサイトのスモークテストを行い、すべてうまく行っていることを確認してからリリースにOKを出す。許可が出てようやくリリースできる、という感じでした。それが最大の課題だったんです。
ほかのメンバーもそうですが、プロダクトマネージャーはしなければならないことが山積みになっていきました。そこで、リリースプロセスのその部分を自動化することを目標にしたんです。そうすれば、コードとシステムの状態について安心感を持てるようになりますから。
– E2Eテストは、プロダクトマネージャーが実行していたということですか？
AJ: そうです。以前はプロジェクトマネージャーがテストしていました。E2Eテストツール、E2Eテストの自動化ツールを探すなかで、プロジェクトマネージャーが担当していたログインフローとチェックアウトフローの検証を任せられるかということに注目していました。
自社でE2Eテストを対応しようとしたところ、チェックアウトフローの最後のステップが最大のハードルになってしまいました。署名が必要でしたし、iFrameとのやり取りもあったので、かなり手こずっていたんです。Autifyを導入することで、とても楽になりました。
– 現在はどのようなアプリケーションがありますか？
AJ: まず、eコマースサイトがあり、そのサイトの検証にAutifyを使っています。検証するのは、主にエンドユーザーのエクスペリエンスです。また、オペレーションチームとカスタマーサービスチームが使っているバックエンドソフトもあります。たいていスタートアップはそうですが、バックエンドソフトの検証は怠っています。テストする必要はないんです。
3つ目に、Reactネイティブアプリがあります。私たちは「アセットマネジメント」アプリケーションと呼んでいます。このアプリケーションは、在庫のスキャン、ドライバーの配達や集荷、倉庫での作業などに使われています。
実は、このアプリについてAutifyに相談したんですよ。ただ、Androidで構築されているアプリで、その時点でAutifyはAndroidのE2Eテストに対応していなかったので、無理でした。確か、1年前だったと思います。ベータ版にサインアップしたと記憶しています。
– はい。最近、Androidの初期ベータ版をリリースしました。
– リリースサイクルはどうでしょうか？毎週、何回デプロイしていますか？
AJ: 平均すると、1日1回、または2日に1回デプロイしています。継続的インテグレーションが設定されています。きちんとしたパイプラインがありますが、自動デプロイされるのは開発環境だけです。そして、開発環境からステージング環境へ、さらにステージング環境から本番環境へ移行する際に、念のためいくつか追加のチェックを導入しました。最後の部分は少し手作業が入ってきますね。その週の担当者がやることになっています。
リリースプロセスの一環で、コードをステージング環境に上げて、Autifyのテストをトリガーします。AutifyからSlackに通知が届くと、すべてのテストが成功したか確認できます。
最後に、状況を知らせるために、全員に通知するSlackのワークフローがあります。そして、エンジニアディレクターかプロダクトディレクターがリリースのOKを出し、私がリリースを行うという流れです。
– 今は、ステージング環境でAutifyのテストを実行しているのですね。
AJ: はい。開発環境でのテストもAutifyで実行しています。それは毎朝行っています。Autifyのレコーディング機能には本当に感心させられました。私たちが最も気に入ったことの1つですね。個人的には、テスト結果画面が気に入っています。前回のスクリーンショットと今回のスクリーンショットが表示されますから、確認する際にテストが成功したか失敗したか簡単に見極めることができます。これはとても役立っていますよ！
Autifyは料金、機能、使いやすさがちょうどよかったんです。それが導入を進めるきっかけになりました。
– 以前はプロダクトマネージャーが検証していたと仰っていましたね。プロダクトマネージャーもAutifyを使っていらっしゃるのでしょうか？
AJ: 少しだけ使っています。プロジェクトマネージャーはとても忙しいので、それほどではありませんが。FernishでAutifyを使っているのは、主に私とその週の担当者です。私たちがテストの実行とモニタリングを行っています。テストが失敗した場合、テスト自体の信頼性が低いからなのか、リグレッションテストを行う必要があるのか判断します。ここ4ヶ月でAutifyが何度かリグレッションをキャッチしてくれたので、とても感謝しています。
– Autifyの導入が決まった後、どのように導入を進めていったのでしょうか？
AJ: リリースプロセスについては、プロダクトマネージャーやほかのメンバーにスモークテストを実行してもらうのではなく、自分たちでトリガーできるようになりました。その部分をAutifyで自動化できたのは、本当にありがたいです。
今のところ、テストが毎朝実行されるようにスケジュール設定するのは私が受け持っています。今後は、チームメンバーが自分でテストを設定できるように研修していく予定です。
– まずはどこから始めたのでしょうか？先ほど、ログインフローやチェックアウトなどのテストを作成されたとおっしゃいましたが。
AJ: 最初に行ったのは、お客さま向けのクリティカルパスの検証でした。そのテストでは、サイトにアクセスしてカタログを閲覧し、商品をカートに入れるなどを行います。デフォルトでは、家具をレンタルするようになっていますが、買い取ることも可能です。
厳密に言うと、レンタルしたいアイテムと購入したいアイテムをカートに追加することになります。カートをクリックすると、ログインワークフローを通してログインしなければならず、その次にチェックアウトワークフロー、契約書の署名というふうに進んでいきます（レシートに適切な情報がすべて表示されているか確認しなければなりません）。最後にダッシュボードに移動し、ダッシュボードに情報がすべて表示されているかチェックします。
クリティカルフローを通して収益をあげているのですから、そのフローがうまく動作するかテストするのは非常に大切です。Autifyを導入したとき、そこからテストを作成し始めました。
その後、ユニットテストで検証しにくい重要な部分のテストを追加していきました。例えば、プロモーション用のモーダルポップアップがうまく表示されるか、フォームが正常に送信されるかなどのテストを作成しました。
当社のサイトはウィッシュリスト機能があるので、そのテストも作りました。ウィッシュリストを利用するには会員登録が必要なので、お客さまのメールアドレスを収集するのにうってつけです。
そのようなテストのほかにも、商品詳細ページのためのテストも新たに作成し、サイトの重要な機能を検証できるようにしました。商品ページはECサイトでとても重要な部分なので。
– お客さまにとってのクリティカルパスが一番大切とおっしゃっていましたね。ECサイトにとって、それを検証できるのはAutifyの魅力の1つだと思います。マーケティングやビジネスサイドから「損失が出ないように、このコンバージョンパスフローを毎日テストしよう」「1分ごとに定期実行してほしい」という後押しはありましたか？
AJ: ビジネスサイドからそのようなリクエストはありませんでした。定期実行できると知らないのだと思います。そのままにしておきましょう（笑）
現在、本番環境でのテストは行っていません。というのも、Googleアナリティクスなど、データ分析のためにさまざまなツールを使っているからです。コンバージョンなどのフローを把握するために、Lookerで自社のダッシュボードを作ったのです。理論的には、Autifyを使って本番環境でテストをすることもできます。テストユーザーアカウントでログインして、それにフラグを立ててEコマースの本物のコンバージョン率がゆがまないようにする方法がありますね。
– Autifyで積極的に使っている機能や、今後役立ちそうな機能はありますか？
AJ:主に使っているのはシナリオとテストプランですね。その次に多用しているのは、テストをトリガーするAPIです。
– CLIをぜひ検討してみてください。ヘルプページで利用できますよ。さて、Autify導入後はどのような変化がありましたか？先ほど、プロダクトマネージャーが手動でE2Eテストを行っており、それがリリースのボトルネックになり始めていたとのことでしたが。
AJ: それが主な変化だと思います。Autifyのおかげで時間を大幅に短縮でき、夜もぐっすり眠れるようになりました。安心感がありますし、大した問題は発生していません。
– ぐっすり眠れるようになったのですね。Autifyによって重大なバグが発見されたことはありますか？
AJ: Autifyのおかげで、リグレッションバグがいくつか見つかりました。詳しいことは思い出せませんが、パイプライン全体でテストするのが困難なバグでした。現在、ほかのアプリケーションとやり取りしないNextJSのアプリケーションがあるんです。Railsのアプリケーションと切り離されているので、ユニットテストや回帰テストが難しいわけです。そのようなテストには主にAutifyを使っています。E2EテストにはAutifyだけが防御策なんです。
– Autifyを見つけた経緯は？
AJ: 以前はWalrus.aiを使っていたのですが、停止されてしまいました。そのため、代替ツールを探さなければならなかったのです。そんななか、Autifyからのメールが目に留まりました。
– フロントエンドをRailsから切り離すことにした理由をお聞きしてもよろしいですか？聞くまでもないことかもしれませんが…。
AJ: 以前は、Railsのcontrollerとして構築されたページがいくつかありました。MVCコントローラは、サーバーサイドのRailsページを操作します。そして、そのページに1つのReactアプリをインジェクトします。フロントエンドをすべて1つの統一されたコードにまとめたほうがやりやすいんです。
私にとって一番大切なのは、開発者が快適に使えること。フロントエンドを完全にコントロールできるようになったことで、エンジニアや私の作業がずいぶん楽になりました。数年前、フロントエンドとバックエンドがすべて1つのシステムに統合されていたのですが、変更しにくく、開発ライフサイクルが遅くなってしまったのです。
Fernishに来る前、私はいつもバックエンドエンジニアと作業していました。必要なAPIコントラクトを決めてから、それぞれ仕事をして、アプリケーションを統合する。それでうまく行っていました。並行して作業することもできましたが、1つのモノリスだったので段階的に作業しなければならず、スピードはかなり遅かったです。現在は、1人のエンジニアがAPIを作り、別のエンジニアがUIを作るというのが主流になってきています。そのほうがコードを組みやすいんです。
– 今後の展望についてお聞きしたいです。テストだけでなく、エンジニアリングリーダーとして、どのようなエンジニアチームをイメージしていますか？
AJ: NextJSをデカップリングし、NextJSでフレームワークを構築したことで、NextJSがやり取りするバックエンドが2つになりました。
あらゆる役割を果たすRailsアプリケーションがあるのです。さらに、一部のマーケティングコンテンツのためにButterCMSという使いやすいサービスを導入しました。
マーケティング部門から、サイトにブログを導入するよう依頼されました。カスタムブログを作るのではなく、便利なブログ機能とCMS機能があるButterCMSを活用することにしたのです。そして、NextJSがButterCMSとやり取りするようになりました。私たちはそれをコントロールしませんから、こちらとButterCMSとの接続をテストするために、Autifyが非常に重要になってきます。
近いうちに、トップページやランディングページなど、ページ全体をButterCMSで動かすようにする予定です。そうすれば、マーケティングチームがホームページやランディングページを変更したい場合、エンジニアリングにチケットを送らなくて済みますよね。自分たちでできるようになるわけです。その機能を提供することを楽しみにしています。
– フロントエンドがButterCMS APIとやり取りしてフロントエンドのコンテンツと結びつけているということですね。ブログ記事が中心ですか？それともほかのコンテンツを管理しているのでしょうか？
AJ: 今のところ、ButterCMSが管理しているコンテンツは主にブログ記事です。今後は、ホームページ全体をButterCMSで動かし、マーケティングが新たなランディングページを作れるようにする予定です。つまり、マーケティングが実施するキャンペーンごとに異なるバージョンのトップページを用意できるようにしよう、ということです。それらすべてをこのヘッドレスCMSで動かせるようになります。
– Reactについては、Eコマース用とWebサイト用のリポジトリが2つあるのですか？
AJ: いいえ、まだモノリスリポジトリですよ。しかし、そのリポジトリの中には、さまざまなアプリケーションが入っています。あるフォルダにはNextJSアプリケーション、別のフォルダにはRubyアプリケーション、また別のフォルダには当社のメインアプリケーションである「アセットマネジメント」Androidアプリが入っています。今でも1つのモノリスがありますが、すべてのアプリケーションがうまく共存できています。
– Autifyは貴社のサイトの検証にぴったりですね。弊社でも、ホームページの検証にAutifyを使っていますよ！マーケティングチームはこれから多くのランディングページを作成していくでしょうから、マーケティング担当者にもランディングページの検証に参加してもらうと良いかもしれませんね。
AJ: はい。マーケティングチームは、より柔軟にサイトとストアを管理できるようにして欲しいそうなので。ヘッドレスCMSのほうが、その希望を実現しやすいんです。こちら側でヘッドレスCMSを再構築する必要がないため、マーケティングが好きなようにコンポーネントやコンテンツを自由に表示できます。
– そのようなニーズがマーケティングからも出ているのですか？
AJ: 商品カタログのように重要なものは、これからもRailsバックエンドとやり取りすると思います。商品の在庫やお客さまの注文などを管理するのはRailsバックエンドなので。それらをコントロールする必要があるので、今のところ別のバックエンドに移行する予定はありません。フロントエンドはこれまで通り、ButterCMSとRailsのバックエンドとやり取りします。
– そうなんですね！ありがとうございました。聞きたいことは全部聞けたと思います。
AJ:どういたしまして。このインタビューを通して、ブログの本番環境をテストしようと思いましたよ。
– いいですね。役立つと思いますよ。ご質問、ご意見、ご要望はありますか？
AJ: 今のところありません。うまく行っていますよ。あるシナリオについて質問がありますが、インタビューとは関係ないのでサポートに問い合わせるつもりです。Autifyのサポートは本当に親切で、対応も丁寧なので、そちらに聞きます。
– そう言ってもらえて嬉しいです！サムは素晴らしいですよね。Autifyをほかの人に勧めたいですか？
AJ: もちろん！そうでなければ、このインタビューに応じるとは言いませんでしたよ。
– そうですか！Fernishの開発フローをAutifyがサポートできているとのことで、本当に良かったです。これからも貴社の開発プロセスにもっと貢献していきたいと心から思っています。ご意見やご要望などありましたらお気軽にお声掛けください。貴重なフィードバックを活かして、さまざまな機能を作ってまいります。AJさん、ありがとうございました！
.jpg)
.jpg)
