株式会社ecbeing（以下、「ecbeing」）は、2000年ごろからECサイトの構築を事業の主軸として、EC構築パッケージを提供する「EC専門」企業だ。
20年前と比較するとEC自体も進化していく中で、サイトの構築だけではなく、データ分析・マーケティングなど、ECを中心とした周辺のサービスについてもサポート、ソリューションを展開している。
WEBソリューション開発統括部が中心となり、Autifyの全社展開を進めている。そのご担当者である、執行役員の阿部 新一郎氏（以下、「阿部さん」）、部長代理の鈴木 盛士氏（以下、「鈴木さん」）、アーキテクトの高石 幸司氏（以下、「高石さん」）の3名にその導入の経緯と効果、今後の展望について伺った。
— まずはじめに、Autify導入前、どのような体制、仕組みでテストを行なっていたかお聞かせください。
阿部さん: 長年、「人が実装していく」というのが続いていました。これは長年の課題でもありました。
我々の事業はいわば受託開発。個別のプロジェクトが同時に何本も動きます。一時的に個別のプロジェクト単位で、テスト自動化のためのツールを導入することはあったものの、サービスのプログラム側は進化していくのに、テスト側は追従できず、最初は「いいね」となっても、結局長続きせず、やはり人手に戻るということを繰り返していました。
我々は、我々に発注をしていただく顧客（企業）がいる前提でプロジェクトが始まります。テストにかかる工数もすべて開発コストに反映されてしまう。
ECという特性もあり、最初は小さいサイト、プロジェクトであっても、徐々に大きいプロジェクトになっていきます。そのプロジェクトの成長に比例して、テストの工数、リグレッションテストの工数も増加します。最初は1人で済んでいたテストも2人、3人、4人…と徐々に人的コストが増していきます。このテストの人的コストの増加はつまり、顧客へのコストの増加を意味します。これをなんとか圧縮したいと考えていました。
また、そこに人手が取られるとなると、アプリケーションの開発の人手が足りなくなる。まさに悪循環でした。
— 確かに、テスト工数は機能が増えれば増えるほど、増していきますよね。ちなみに、テスト自動化ツールとはどのようなものを試されていたのですか？
阿部さん: Seleniumを使ったり、有償のツールを使ったりして自動化を進めていました。正直ツールのキャッチアップにも限界を抱えていました。
— そのような折にAutifyを知っていただいたということですね。
阿部さん: 2019年3月ごろにForbes JAPANの記事を見て、Autifyの存在を知ったのが最初の出会いです。
2019年の夏頃に、CEOの近澤さんと話すことができ、2019年10月頃に導入に至ったという流れです。
— まだ、「クローズドβ」として提供させていただいていた頃からお話をさせていただいていましたよね。大変ありがたいです。
— これまでもテスト自動化ツールは試されていて、どのような点に魅力を感じていただけたのでしょうか？
鈴木さん: とことん導入の敷居が低かった点が非常によかったです。WEBのサービスで、ブラウザ上でポチポチとしていけば、使うことができる。シナリオを作成するのも、20-30分のレクチャー、動画を見れば、すぐに開始することができます。以前試してきたツールではこうはいきません。
以前試したツールとしてSeleniumがあります。Seleniumの場合、作られたコードを読まないといけない、コーディングができないメンバーはそもそも使えない。
コーディングができないテスターの方もいますが、彼ら彼女らはその時点で参加できないことになります。
Autifyであれば、スクリーンショットもあり、誰でも、ビジュアルですぐに理解できます。導入のしやすさを身をもって実感しています。
— まさしく、我々が解決したい、「エンジニアの方じゃないと触れない」という課題の部分にお役に立てたという点が非常に嬉しく感じます。 — 導入時に何か特別に工夫したことなどはありますか？
鈴木さん: 今回の体制としては、高石さんが主導して、実際のアプリケーションを対象にして「とりあえず動かしてみよう」という形で進めました。この「とりあえずやってみよう」という流れで進められたことは、メリットが大きかったと感じています。具体的な進め方については何か特別なことをしたというものはありませんでした。とにかく動かして、試して、試行錯誤を続けました。
この試行錯誤を続けられること、続けたいと思えたことが大きいです。繰り返しになりますが、導入の敷居の低さがこれを支えている と感じています。 このおかげで、展開するプロジェクトを徐々に拡大していくことができています。
— 運用に入ってからの工夫などはありますか？
高石さん: さまざまなプロジェクトで使っているので、シナリオの命名ルールなどは明確に定義しています。並行して、AutifyのAPIを使って開発環境での自動デプロイの仕組みを組んでいます。手動で実行するということをさらに減らすための取り組みです。 近い将来的には本番環境向けにも流していこう、と考えています。
— CI/CDを実現しているということですね。
高石さん: はい。実は、Autify導入時に、Azure DevOpsを導入しはじめていて、古めのプロジェクトで、手動でやっている部分を自動でやっていこうという取り組みです。そこにAutifyも組み込むことで、できるだけコストを下げていこうというチャレンジです。
阿部さん: タイミング、組み合わせがとてもよかったです。テスト以外にも、リリースする際の人的コスト、トラブルはありました。それを改善したいという話から、DevOpsの話題が出て、さらにAutifyの試験導入が並行して走ったことで、「なら一緒にやっちゃえ」という流れで進みました。これはとてもよかったと感じています。
— 実際にAutifyはどのような方が触って、運用していらっしゃるのですか？
鈴木さん: テスターの方にテストシナリオを作っていってもらっています。動作確認作業として手作業で行なっていたものをそのままAutifyに登録してもらう、という流れをとっています。
Autifyを使うとしても、どうテストをするか、テストを設計する、といったことはもちろん考える必要があります。これを全員に求めると一気にテストの敷居が上がってしまいます。そうならないように、関わる全員が進めやすい環境づくりに注力しています。
例えば、ecbeingではデザインの適用作業があり、そのデザイン確認のテストも行なっています。これに対しては「Autifyのキャプチャベースで確認できるよ」、とか、回帰テストの場合はこう使いましょう、といった具体的なケースを我々で作って、各プロジェクトの担当者に展開するという流れにしています。 パターンごと、フェーズごとで利用用途を示すことで、デプロイしたときのプログラマによる手作業の動作確認も効率化できますし、テスター側で行うテストもできるようになります。
— コストはどのように見ていますか？
鈴木さん: Autifyの利用料金を各プロジェクトにも負担してもらっています。元々は我々のチームの予算としていましたが、今は、使わないとプロジェクトとしてはもったいないことになるような仕組みにしようとしている。 若干強制的なところもありますが（笑）、各チームの課題は我々が吸い上げて解決して、標準化していく。そして、徐々に各プロジェクトが自立していくように進めていきます。
鈴木さん: 回帰試験、デグレードに対しての意識が高まると思っています。これまでも、もちろん概念はあったものの、手動テストだと「時間がない」、「面倒だ」というイメージが植えつけられてしまっていて、進まないことが多い。ここが自動化できることで、回帰試験に対してのイメージがポジティブになり、その結果「回帰試験は重要だ」という意識づけができること自体が大きいと感じています。
高石さん: 直近でやっていた案件の例では、テストにかかる工数が減りました。デグレのテスト、標準的なものはAutifyでまわして、テスターの方には難しい複雑なもの、特殊ケースを任せるようにしました。
— テスターの方に手動でのテストを任せたテストケースとは具体的にどのようなものですか？
高石さん: 例えば。注文後の特別キャンセル対応など、電話対応が間に入るようなケースなど、を見てもらいました。
結果として網羅性が非常に広がっています。
— 我々としても人がやらなくちゃいけないところは人、そうではないところはAutifyでやっていただきたいと考えています。 — それ以外にもメリットはありましたか？
高石さん: Autify導入前に、Seleniumでいくつかテストケースを作ってはいましたが、メンテナンスのコストが非常に高い状況でした。作ったテストシナリオは他には流用できず、その場限りになって、結局やめてしまうといったことが繰り返されていました。
Autifyはこういったテストの流用が非常にやりやすいです。例えば、とあるバージョンで使ったテストケースは他のバージョンでも使える、なんてことがありました。いくつかこのケースが見えはじめたので、積極的にプロジェクトAで作ったシナリオを複製して、プロジェクトBやCにも展開するという運用をはじめました。
鈴木さん: 使い始めるまでは、AutifyのメンテナンスAI、あれがどこまでできるんだろうって気になっていました。ecbeingのパッケージは、デザインがあたっていない状態で、各プロジェクトでそれぞれのデザインをあてていく、というのが流れです。 デザインがあたっていないものと、あたっている状態とで、Autifyの同じテストシナリオを実行して、変更をうまく追従してくれました。適用が広がる！と感じましたね。 正直、巷で「AI」という言葉が広がりすぎていて、なんでもAIと言われている節があったので実は懐疑的なところもあったのです（笑）。が、この結果を見て、AutifyのAIは信頼できること確信しました。
— 実感いただいているのはとても嬉しいです！このAI部分は日々進化していますので、もっとお役に立てていただけると思います。 このAI部分は特に、運用時のテストシナリオのメンテナンス工数の削減に直結するものと私たちは考えているのですが、ecbeingさんではどうでしたか？
鈴木さん: ちょうど、どういう工程でどのようなテストをしたか、それによるテスト工数の削減と品質が上がったこと、というのを社内で共有できるように進めています。 可能性の1つとして考えているのが継続的な監視です。
ECサイトには重要機能があります。具体的な例でいうと、お店のPOSレジで会員証を掲示するとそれが連動してポイントが付与される、など。その機能が継続的に動いているかの確認は、現状はできていません。もちろんサーバー類のサービス監視は実施していますが、機能というところまで落として動いているか、JavaScriptで制御している部分が動いているか、というチェックを今後やっていきたいと考えています。
— サイトの監視はできても、機能の監視って難しいポイントですよね。
鈴木さん: リリース直後のタイミングだったらまだ気づけるので良い方です。しかし、我々が提供しているようなECサイトはユーザー側でコンテンツを追加します。我々では、そのタイミングや内容はわからず、もちろん制御できません。こういったユーザー側で行う変更についてもちゃんと確認して、サービスの機能としての稼働を確認していくことで、全体の品質レベルをあげていくという考えです。
ecbeingの顧客、小売業さんがメインになりますが、彼らの満足度をいかにあげていくか、という点で重点的にやっていきたいと思っています。これによってecbeingも筋肉質な組織になっていくとも考えています。
鈴木さん: 先ほども少し話しましたが、ecbeingもソリューション、つまり個別開発をゴリゴリやっているチームと、SaaSのようなサービスを提供したり、プロダクトを作っているチームと、サイトの運用・分析を行っているチームなど、多種多様なサービスを展開しています。 現在は、ソリューション部門が率先してAutifyを進めていますが、全社的に自動テストというものをプロジェクトとして展開して、会社全体にメリットのある仕組みづくりをしていきます。
鈴木さん: 部門や案件がわかれていると、それぞれやり方が違うところがあります。同じパッケージを導入していても属人的であったり、考え方が違ったり… 。 こういうケースでは、利用の仕方の具体例を示してあげる、やり方を指定して半ば強制的に使わせる力強さも、ときには必要だと思っています。
通常業務がある中で「新しいツールがあるよ」という感じで紹介するというのは、簡単ですが、それだとその場で終わってしまって、継続して使ってはもらえません。たまに出てくる興味をもった、使いたいと言ってくれるチーム、現場に見せていくこと、使ったことのモニタリングやレポートを行うことで、継続性も上がっていくと思っています。
阿部さん: 内部であっても抵抗勢力はやはりあります。社内で声かけをして使ってみよう、とやったときにも、実際に紹介してみても、テストの自動化にそもそも魅力を感じていない、「なくてもまわせるから大丈夫」という現状維持の考え方は、根深い。 「AIのツールを使っても、何がいいのかわからない」なんてことも言われていました。実際、このようなことを言ってきた該当の部門はまだ使うに至っていません。 現状踏襲ではなくすには、先を具体的に想像してもらうのが必要で、その想像力をサポートするための事例と実績。 効率が出そうなプロジェクトほど、テストだけでなくドキュメントの管理方法も含めて、今のやり方がこびりついてしまっています。そういうところこそやってもらいたい、やってもらう価値があります。
今は新しいプロジェクトから徐々に実績を積み上げて、文化自体も良い方向にアップデートしていきたいと考えています。 良い方向というのは、より、必要な仕事に専念できること、仕事の効率化に尽きると思っています。生産性の向上に向き合っていくことで必ず効果は出てきます。 このような社会状況の中、骨太で筋肉質な組織にしていくためにも、意思は強く持って、進めていきたいと考えています。
.jpg)
.jpg)
