組み込みが容易でスポット的な不具合解決に使いやすい　Ubieのエンジニアが語る、テストツールにmablを選んだ理由

Ubieのサービスと開発環境の紹介

増原賢秀氏（以下、増原）：Ubie株式会社の増原です。今はUbieのプロダクト開発とか事業開発をする「Ubie Discovery」という組織で、QAエンジニアとして働いています。

mabl（メイブル）のセミナーなのでmablの話をすると、mabl自体は前職から使っていて、トータルたぶん2年ぐらいは使っているのかな。私は、Ubieに入って今4ヶ月ぐらいですが、今日はその中でmablを導入した、ここ1ヶ月ぐらいのことをお話しできればと思っています。よろしくお願いします。

藤原大氏（以下、藤原）：お願いします。現在はUbieでQAエンジニアとして活躍されているんですよね。どのようなプロダクトを担当されているかを話せる範囲で教えてもらえますか？

増原：mablのところで言うと、今、弊社はプロダクトが2つあり、その1つに生活者向け「AI受診相談ユビー」というサービスがあります。そのQAを担当しています。

藤原：担当するアプリは、どのようなサービスになりますでしょうか？

増原：Googleで検索したら出てくるとは思いますが、生活者の方が「こういう症状あるよ」と言った時に、それに対していろいろ質問をしていって、それに答えていくと関連する病気や、その対処法を調べられるサービスです。

藤原：ありがとうございます。これも話せる範囲でいいんですけど、やはりサービスレベルは高いアプリになるんですかね。

増原：そうですね。広く生活者の方に使ってもらい、今ユーザーも増やしていきたいところなので、安定性も大事です。特にmablを導入したプロジェクトはわりと常に正しい挙動を求められることがあるので、そのあたりは日々がんばっています。

藤原：ありがとうございます。じゃあもうちょっと開発について教えてもらえると助かるんですが、開発の流れやフロー、パイプラインはどのようなところをどうされていて、どのあたりを自動化されているのでしょうか？

増原：リリースとかはもう毎営業日、何回も行われている感じです。かなり一般的だと思いますが、プルリクエストに対してユニットテストとかAPIテストが実行されていて、ビルドはGitHub Actionsを使っているのかな。クラウドインフラはGCPという感じです。

藤原：ありがとうございます。その中でどういったテストが存在しているのでしょうか？

増原：テストは業務委託の方がいるので、開発者がその方に頼みたいものをマニュアルテストで依頼したり、それに合わせてリグレッションテストをお願いしてやってもらってもいますし、先ほど言ったような開発者が書くユニットテスト・APIテストなどもあります。あとはmablの自動テストもあり、業務委託の方がメインで保守しているE2Eのテストもあったりします。

藤原：けっこういろいろなタイプのテストをやっている感じなんですね。

増原：そうですね。

mablのツールを使い始めた理由

藤原：ありがとうございます。だいたいの環境を教えてもらったので、まず1つ目の質問をしたいんですけれども、なぜmablのツールを使い始めたか教えてもらえますか？

増原：今のmablを入れたプロジェクトは、サービスレベルが求められる状況だったんですが、ちょっと不具合が頻発した時期があり、それをどうにかせねばというところでした。今言ったように毎営業日デプロイをしているような状況で、1個1個のプルリクを見ていっても、僕が担当しているプロジェクトに影響あるかどうかを判断していくのが難しかったんです。

そういう中で、リグレッションテストで壊れる前に検知はしたい。業務委託の方が使っているE2Eはとてもいいんですけど、それはちょっとコードレビューがけっこう大変で。

1つ大きいのは、自分自身、mablが使い慣れたツールだったことがけっこうあるかなと思っています。あとはやはり実際リリース前にクリティカルな不具合に気づかなきゃいけないので、そのデプロイやフローに組み込まなければいけませんが、そういうところの組み込みが容易という理由もあったかと思います。

藤原：ありがとうございます。いろいろなテストがある中で、不具合が頻発したときにスポット的に解決する策として、こういったツールを入れるかたちで取り組まれたということですね。

増原：そうですね。根本的なところを潰す作業をやるべきなのですが、それも手間がかかるので。

現状、デプロイごとにサービスが壊れているか壊れていないかを効率的にわかる手段がなかったので。「まずリグレッションテストを入れますか」というところで、いろいろありました。

藤原：壊れているか壊れていないかの確認なんですね。ありがとうございます。

mablのテスト自動化における立ち上げ時のポイント

藤原：さらにちょっと質問を続けていきたいと思います。ずばりmablのテスト自動化における立ち上げ時のポイントをうかがいたいです。今回のケースにおいて、どのあたりが立ち上げ時のポイントになりましたか？

増原：先ほど言ったコードがリリースされていく中で影響範囲がわからないことと、サービスがどんどん変わっていくところでした。立ち上げ時で言うと、まずどこに導入するかを明確にして、リグレッションテストのやること・やらないことは決めて進めていったことかなと思いますね。

藤原：最初にやること・やらないことを決める。話せる範囲でぜんぜん構わないのですが、どういう決め方をされたんですか？　

増原：E2Eは担保できる範囲とできない場面があると思うので、そこをBizメンバーなどに説明しつつ。バグを見つけたいけれど、テストしたことの結果がわかるだけなので、「まぁそういうもんです」というところから始めたり。そういう中で自動テストを進めていくと……なんて言ったらいいんだろうな。

「このサービス、何ができないとダメなんです」ということを決めて、一番大事な部分から実装していったところですかね。

藤原：そのあたり興味深いですよね。こういうmablみたいなツールのデモをしていると、AIと言うとなんでもできると思われがちですが、結局うまいことテストを作らないと、壊れているかどうかも見つからない。このあたりの認識をはじめに合わせることがかなり重要なんだなと、僕も最近すごく思うようになりました。

増原：そうですね。AIテスティングツールを入れてすべてがよくなるかというと、そんなことはないです。先ほど言った「根本原因の対処はできないけど、まずはクリティカルなところがリリース前にぶっ壊れていないか確認することをやりましょう」という話ですね。

藤原：本当にシンプルなやり方ですね。増原さんは、「ここはもう絶対に壊さない」というところから始めることなんですよね。

増原：そうですね。

藤原：今回の場合は、ということですよね？

増原：はい。「こういう遷移がそもそもできません」という不具合があったりしたので。

藤原：なるほど。ありがとうございます。“今回は”かもしれませんが、その時にいつもどうやって認識を合わせているんですか？　どんな人とどういう話をしているんですか？

増原：僕が今やっているプロジェクトのスクラムに入っているので、そこで「今スプリント、まずこういうことをやっていきます」ということを、粛々とイシューに切って認識を合わせて、進めて引っ張っていただけです。

藤原：開発メンバーだけですか？

増原：いや、BizDevの方もいます。やはり一応社外のカウンタパートとやりとりしているのはBizDevの人に、「品質を高めるためにこういうことをやっていきますよ」と。でも、1個で「はい、すべて解決」というわけじゃなくて、E2Eテストを実装したことがある人ならわかると思いますが、シナリオを増やしていくのも大変なので、まず1個ずつ。いくつかシナリオを作らなければいけないうちの、「スプリントはまずこれからやっていきますよ」と言いながら進めていったり。

藤原：それを開発・BizDevを交えてやっていくかたちなんですね。

増原：そうですね。不具合があって困っていることは聞いているから、それをもとにQAエンジニアがベストのシナリオを実装したりしますね。だけど、あくまでそれは自分の過去の経験から、「こういうところが担保できていないとマズそう」という観点で進めているから、「ここはBizの人のレビューとかも必要だよ」と言いながら進める感じです。

藤原：なるほど。それは最初にそういう打ち合わせをしてすり合わせたり、あとは継続的になにか取り組んだり共有したりとかもされているんですか？

増原：しています。「いったんマイルストーンとして1個テストを作りましょう」というところから始めて、「それを増やしますね」とやっていって。E2Eテストは容易に壊れると思いますが、「今こういうところでメンテに時間を割いています」「だからシナリオの追加がちょっと遅れます」とか伝えます。

藤原：なるほど。タスクとかもイシュー化したりされているんですよね？

増原：全部が全部じゃないですけどね。タスク日数やデイリースタンドアップで「ここを進めていきますよ」と言ったりします。

藤原：それを伝え続けることで、増原さんは、やはり多少は効果というか成果は感じるんですか？　

増原：やはりBizの人に工数感というか。

藤原：工数かかりますもんね。

増原：スプリント、タスクにSPを振ったりすると思うんですよ。だから、だいたいどれぐらい時間がかかるかもわかるし、「今ここまで動いているよ」ということを見せれば「ここまでは担保できるんだ」とBizDevの人も理解できます。

藤原：おお、なるほど。本当スプリントの中でしっかりとポイントを積んで正攻法で進めている感じですね。

増原：そうですね。

藤原：きっと開発自体が、テストというものもしっかりとポイントを積んでやる感じなんですよね。

増原：今やっているプロジェクトは若干特殊なので、そういうBizDevの方のタスクが入っていたりするんですけど、それはそれで、あとはデータ分析やプロジェクト関連のタスクが、バックログとして入っている感じですね。

最初にどんなテストを作っているか？

藤原：ありがとうございます。ちょうど「周囲の自動化の価値の伝え方」もまとめて聞けたので、もう1個質問です。先ほどちょっとずつマイルストーンを組んで作っていく話をしていたと思うんですけれども、増原さんはどんなテストをはじめに作られていますか？

増原：今一番困っているところです（笑）。

藤原：それは、例えば1ケースから始めるんですか？　

増原：1ケースからです。

藤原：バリエーションとかも増やすんですか？　入力のこの種類はこれだけあるからみたいなのはもう無視して、1パスみたいな感じなんですか？

増原：いったんは考えないですね。

藤原：なるほど。じゃあ一番はじめに導入するときは、本当に大切なナンバーワンなシナリオ1本ということなんですよね。

増原：そうです。最低限、繰り返し実行できるようにはしますが、それらはいったん考えないですね。

藤原：なるほど。それを作ったあと、回しながら運用やメンテもしていくことになるじゃないですか。どのタイミングで次の一歩、次のテストに踏み出しているんですか？

増原：次のテストは場合によりますが、作って少しリファクタというか、共通化したり、mablだったらフローにしたりすると思うんですけど。そもそもある程度、部品化して、このままだとシナリオが増やせないというポイントがいくつかあります。これは完全に僕がmablを長く使っているからだと思うんですけど。

藤原：そうですね。

増原：ある程度作る。ある程度共通化する。そして、次のテストのシナリオを作るという感じかな。

藤原：なるほど。これも話せる範囲でいいんですけど、例えば期間のことで。1スプリント目で1件作ったとしたら、2スプリントで2件とか、それぐらいのスピードでやっているんですか？　それともやはり増えたりしますか？

増原：2スプリント目はもうちょっと増やしますね。

藤原：もうちょっと増えるんですね。結果的に、例えば10スプリントぐらい回った時、どれぐらいの数になっていることが理想なんですか？

増原：理想はわからないですね。

藤原：作りながら？

増原：作りながらじゃないかな。最低、今1スプリントは1週間でやっています。1スプリントで1個シナリオを作れていれば、1個は価値あるテストができているはずなので、それぐらいだと進んでいると思えるんじゃないですかね。

藤原：そうですよね。きっと数というよりは「1個ずつしっかりと積み上がっているか？」で作られていることですよね。

増原：僕もよくいくつも、2つ3つテストを実装するバックログを作っちゃうんですけど、でもそうすると割り込みの作業があった時に、その1個を丸めると達成できなくなっちゃう。なので、最近はなるべく細かめにしています。

藤原：おもしろいですね。ありがとうございます。そういうふうに本当に小さいところから作っていることが僕もなかなか経験がなかったので、とても興味深いです。何か作る上で気をつけているところ、先ほど部品化とかも話していましたけど、増原さんの中で、それ以外でポイントとなる部分は何かありますか？

増原：ポイントは、mablだとやはり部品化できるところを考えながら実装するとかですかね。フロー化できるとか。

藤原：可能な限り。

増原：すぐフロー化できるかはわからないんですけど、「これは使い回せるかも」と当たりをつけておくとか。

藤原：うんうん。作る時ですよね。

増原：最初はいろいろ確認したくなるんですけど、アサーションしすぎないとか。繰り返し実行したら「これやばい。めっちゃ落ちる」場面がアサーションにはあったりするので。mablは、かなり安定して動くテストツールだと思います。それでも落ちることはあるので、アサーションは最低限に。

困った時に足すぐらいです。困った時に困ったところのアサーションを追加する程度でいいのではないでしょうか。

藤原：そうですね。「フォームの入力が多い画面はどうしているの？」と僕もよく聞かれますが、そもそも見ていない場合がありますね。結局スクショを取って差分が出るので、はじめに1回見た時に壊れていなければ、ずっと壊れていないと判定するとか。あとは住所のところで、住所を選んだら自動で入ったりするのとかも、なんかバリエーション全部やるのもあれなので。

増原：バリエーションはやらないですね。

藤原：そうですよね。

増原：作らざるを得ないところ、そこのバリエーションを用意しないと、そこがバグった時に、ビジネス的にメチャクチャ価値が毀損するとか、そういうことではない限りは。メンテはけっこう力が取られますから（笑）。

藤原：あと、バリエーションになるかはわからないですけれど、他国籍のサイトとか作られている時とかは、けっこう1個作って使い回すのもぜんぜんありだとは思うんですけど、どう思います？

増原：僕はちょっとやったことないのでわからないな。

藤原：例えばですが、SaaS型だったらテナント型とかもあるじゃないですか。「同じ画面で同じソースコードだけど、ちょっと違うけど」みたいな。そんな時はけっこう使い分けてやられているお客さまも多いと思います。

増原：へえ。

藤原：1個作って10個カバーできる効率のいい使い方をされていますね。ありがとうございます。増原さんは、実践的で、もう磨き上げていますね。叩き上げのネタがおもしろいなと思いました。

（次回につづく）