ブロックチェーン事業からピボットして、業務プロセスのデジタル化を推進するBtoB SaaS事業に乗り出した株式会社LayerX。
「すべての経済活動を、デジタル化する」をミッションに掲げ、バクラクシリーズとして請求書業務の自動化ツール『バクラク請求書 (旧: LayerX インボイス)』や稟議フローを効率化する『バクラク申請 (旧: LayerX ワークフロー)』などを提供し、急成長している。
いずれも経理に関わるプロダクトであるがゆえ、システムの不具合を避けなければならず、QAが重要になってくる。顧客のニーズに応えながら、開発サイクルの維持と品質保証の両立に挑む梶原 将翔さん、鈴木 政隆さんに話を聞いた。
梶原さん: LayerXのSaaS事業部で2つのプロダクト『バクラク請求書 (旧:LayerX インボイス)』と『バクラク申請 (旧: LayerX ワークフロー)』のQAとカスタマーサクセスのリードを兼務しております、梶原です。（*2021年10月 取材時点）
鈴木さん: 僕はアプリケーション開発のサーバーサイドのエンジニアとして8月にLayerXに入社しました。テストのほうが逼迫し始めたため、今はSET (Software Engineer in Test) の0.5人目としてテストを作っています。
梶原さん: LayerXには3つの事業があり、その中でもSaaS事業部は一番多くの人数で推進しています。SaaS事業部では、経理などのバックオフィス領域のDXを推進するプロダクトを2つ提供しています。『圧倒的に使いやすいプロダクトを届け、ワクワクする働き方を。』というビジョンを掲げ、サービス作りに励んでいます。
2021年1月にリリースした『バクラク請求書』は、請求書の受け取り業務を手入力ゼロでできるSaaSです。請求書の発行業務はすでにさまざまなプロダクトがありますが、受け取った請求書を自動で処理するサービスはまだ少ない。私自身も経理業務を行っていた時には「そこだけはどうしても手入力が残る」というのが課題でした。100社ぐらいインタビューしてニーズに応える領域を定め、開発されました。
また、稟議の社内フローを短時間で行える『バクラク申請』を2021年4月にリリースしました。お客様のご要望に素早く対応すべく開発しています。それに伴って、さまざまなQAの課題が出始めて、改善に取り組んできました。
― 『バクラク申請』リリース後にQAに力を入れ始めたんですね。
梶原さん: そうです。経理を扱うプロダクトは、請求書データや会計ソフトとも連携しますし、サービスの特性としては品質がものすごく重要な領域です。ですが、QAの専任がいなかったため、エンジニアやBiz、プロダクトマネージャーがテストの一覧表を作りながら手動でテストを行っていました。
リリースは2週間に1回のスプリントで、ステージング環境に出てから2日後にプロダクションリリースをしています。その2日間でテストを行い、バグを直して本番リリースという流れで行っています。
― CSをやりながらのQAはなかなか珍しいパターンだと思ったのですが、梶原さんはQAをちゃんとしなければ、というタイミングでQA担当にもなられた？
梶原さん: 人が全然足りなかったので、皆が仕事を選り好みせず「何でもやる」という状況でした。以前はブロックチェーンの事業部にいましたが『バクラク請求書』のリリースに合わせてこのプロダクトのチームに移りました。セールスもCSもやりましたし、QAも少しずつ引き取っていった。全員野球的なフェーズでしたね。カオスに飛び込んで整理していくのがわりと好きなので、巻き取りながら、少しずつQAの改善を目指しました。
― 鈴木さんも、最初はバックエンドのエンジニアとして入社されたけれども、QAにアサインされたと。
鈴木さん: そうですね。開発スピードを落とさないためにもテストは大事ですし、仕様を理解することにも役立つ。最初は期間限定だったんですけど、今では結構先までやっていく予定です。
梶原さん: 貴重な開発リソースをSET (Software Engineer in Test) の役割に変えたのは、3月に、1回のリリースでプロダクションのバグが3件起きたことがきっかけです。幸いクリティカルなものではなくお客様が使う前に気づけたのですが、「1回に3件も…」とチームの中で危機感を覚えました。スピードももちろん大事ですが、品質に対してきちんと取り組む必要があると考えるようになりました。数カ月間は、開発リソースの2割を品質に割くことにしてAutifyの導入についても検討を始めました。
― 品質への課題意識があった中で、3月のバグがターニングポイントになったんですね。
梶原さん: それから品質を確保するため、チェック項目も500〜600項目に育っていました。テストに本腰を入れて、しっかり、踏ん張りながらテストしていました。1つの画面でも、会計ソフトによってビューが異なり、連携するパラメーターも変わります。同じ機能でも会計ソフトによりQA項目が6個あったりします。
開発も速かったので、物量的に2日間のリリースサイクルを維持するのがかなりキツくなってきた。ビジネス上、スピードが我々の強みです。だから、2日間のリリースサイクルを維持したままできるQAを模索しなければならなくなりました。E2Eテストも担保していくと、この開発スピードだったら、あっという間にテスト項目が1000項目をこえるだろうと。もう少し効率化を追及しなければ、と思って動きました。
― ステージングに上げてからプロダクションまでのテスト期間を2日にキープした状態で、自動化することをまずは検討されたんですね。
梶原さん: はい。あとは単体テスト・APIテストを書く範囲も検討しました。顧客の業務フロー上、バグるとクリティカルな機能が追加されていきます。そもそも品質保証に対する取り組み自体をもう少し広げて担保しないといけないんじゃないか、という課題意識がありました。
― それまではアジリティを追求してきて、さらにクオリティも向上させるという意識に変わっていった？
梶原さん: そうです。他の企業もそうだと思うのですが、立ち上げ期で機能追加をどんどんしているタイミングに、ゴリゴリテストを書けるエンジニアリソースがあるかと言われると、潤沢なリソースはない。エンジニアがいれば機能開発を優先したい気持ちになるので、リソースがない中で、Bizの動きも含めて、どう自動化していけるか、どうE2Eテストを効率化していけるかを模索していきました。
― どのようにAutifyを選んだか、お聞かせいただけますか？
梶原さん: 自動テストに知見のあるエンジニアと相談しながら、7～8個のツールをザッと見ました。AutifyのようなE2Eテスト自動化ツールのほか、開発が必要なSeleniumなども含めて検討しました。
その中から、「エンジニアじゃなくても進められること」を必須要件に、検討対象の自動化ツール4つに絞り、いずれもトライアルで触ってみました。特に2つのツールは、2週間しっかりテスト利用をさせていただきました。非エンジニアでも使いやすいか、『バクラク請求書』で回していたQA項目をどれくらい自動化できそうかの2点に着目して比較しました。
もともと全て自動化は無理だと思っていました。例えば、画面上でHTMLとしてはチェックボックスで書かれているけど、デザイン上はスイッチのようになっているような、工夫している部分は自動でできるのか。CSVファイルをアップロードできるか。ユーザー登録した時のメール検証ができるか。ダウンロードされたかどうかのチェックができるか。そういった項目を挙げていき、20項目くらい検証しました。
― トライアル時に、かなり細いテストケースのリストを試されたことをご共有いただきましたね。
梶原さん: ツール選定にものすごく熱中した記憶があります（笑）。スタートアップなので、朝令暮改には慣れていますし、いろんなものを変えながら改善していくスタイルはあるのですが。今回のようなテストプラットフォームは、なかなか後戻りできない。一度どれかのツールでシナリオを作り始めたら、違うサービスにはエクスポート・インポートは難しいです。「心中できるかどうか」という視点から入ったので、かなり本気で調べていきました。
― 最終的に「Autifyとなら心中できる」と思っていただけたのはなぜでしょうか？
梶原さん: まず、求めているものが十分できることが検証できました。具体的には、当時700～800まで育っていたテスト項目のうち、半分弱自動化できればいいなと思っていたんです。もう半分については、明らかに人の目でちゃんと見ないといけない内容でした。
半分弱の「弱」の部分は、「サービスによっては自動化できるかもしれないけど、普通に難易度高そうだな」みたいなものとか、基本的かつコアな機能のテストは自動化しなくても、担保できる。約3割——250〜300項目くらいを自動化できそうなら十分かなと思っていました。Autifyの場合、頑張れば400項目——半分強いけるかもしれない、という確証が得られたんです。サービスの機能としては、十分でした。
あとはトライアル中にCSに問い合わせを1日何件も送りました。毎回すぐにレスをいただけて、1個1個着実に解消していくことができました。CSの対応で「安心できる」と思えたのは大きなポイントでした。また重要なのは、非エンジニアである僕がもっとも使いやすかった。学習コストが低いところが良いと思いました。
― 非エンジニアでも使えるかどうかを大事にしているのは、エンジニアのリソースが限られている中で、全員で取り組まなきゃいけないことが前提だったからですか？
梶原さん: そうです。気持ち的には、エンジニアと名乗れる人は新機能開発をどんどん推進してプロダクトを強くしてほしい。その代わりにQAが頑張って巻き取るので、リソースをうまく使いたいなという思いがありました。大変助かっています。
― 逆に、迷ったポイントはありましたか？
梶原さん: APIテストをどこまでできるのかなというのは、迷ったポイントでした。
E2Eテストを非エンジニアでもシュッと自動化していける点は、十分見させていただいた上で、例えばエンジニアがAutifyを使ったらどこまでできるか。E2Eテストの中に「リクエストを送った後のレスポンスを確かめたい」シナリオを途中で埋め込みたい場合、どう作ったらいいかは、工夫が必要そうだなと思いました。
― 実際にAutifyの導入を決めていただいて、具体的にどういう風に進めていったかというところがお聞きできればと思います。
梶原さん: QAをパンクさせないための効率化を、4〜6月に注力して取り組みました。Autifyはその中でも目玉の1つでした。Autifyに置き換えるシナリオが、そもそも正しいかどうか、解像度が高くなっているのか検証が絶対に必要だと思い、既存のQA項目の見直しをガッツリやりました。落としてきた項目を追加したり、逆に細かすぎるほど書いてあるものは「この項目は3つあるけど1つにまとめよう」という感じで粒度を整えました。
期待結果のスクショを撮ってQA表の中に貼ったり、テストでアップロードするファイルを用意することも大事です。ここには時間を使いましたが、結果的にQAを実施する時間が半分ほど短くなって、思った以上に良い効果が得られました。
仕様を分かっている人が分かってる前提でQAするには問題ないような状態だと、新たに加わったメンバーや、ヘルプのメンバーにお願いする時、迷いながらQAすることになる。良いか悪いかは分かりませんが、「何も考えずに作業としてQAを進められる」ように項目を整理していったら、ものすごく速くなりました。
― 倍のスピードはすごいですね。
梶原さん: びっくりしています。組織が急拡大して、新メンバーも入ってきているので、昔のQA表だったら対応できなかっただろうなと思います。「みんなでQAしよう」といって募集すると、新メンバーやインターンが手を挙げて一緒にやってくれるので、仕様把握にもなる。
― 素晴らしいです。
梶原さん: ある程度決まっている箇所や自動化できそうなところ、重要なところを優先度を付けて選んで、どんどんAutify化を進めていきました。Autifyで作るシナリオが適切かどうかも重視しています。シナリオを作る前に、きちんとQA項目を詰める。作ったシナリオも二人でレビューすることに時間を割いていきました。
― テストケース見直しとAutify化はどのようなタイムラインでやられたんですか？
梶原さん: 同時です。細かいスケジュールを引いている余裕もなく、がむしゃらに。目安としては、導入から3カ月後に300項目をAutify化する目標で進めました。途中から鈴木さんが救世主的に入ってくれて引き渡して、進めてくれました。
鈴木さん: もらった時は『バクラク申請』には手つかずでした。『バクラク申請』の承認経路が複雑なところのAutify化に取り掛かりました。あまりに項目が多すぎて、人間だと全部見きれないから、何個かのシナリオをリリースごとにローテーションでやっていました。それをAutify化することで、毎回全シナリオをテストできるようになった。作り方に慣れてきて直近だと272項目はAutify化できています。
梶原さん: 「経路」についてですが、テストを網羅しようと思うとほぼ無限にパターンがある機能なんですよ。
「そもそも、これ、もう人間がやるの無理じゃね？」という感じのものでして。こういう類のものは人間がやるのは難しいし、気持ち的にも「重い……」と感じるところをAutify化すればかなりラクになると思ったので取り組みました。
優先順位として「絶対に担保したい機能」、「Autifyでできそう」というところを最初は選んでいたんですけど、途中から「人がQAするのは気持ち的にツライやつ」を選んでいきました。2日間で700～800項目、しかも毎回増え続けるのをやりきるというのは気持ち的にはつらい。そこを自動化できて、本当に気持ちがラクになりました。
― そこまで自動化がうまくいった秘訣や、Autifyで活用した機能を教えてください。
鈴木さん: 僕がテストを作り始めた時に、メールの機能も活用しようということになりました。経路をテストする時に承認のメールが飛ぶのですが、その部分だけ人間がやらないといけない。「検証が残っている」というのはスッキリしないので全部自動化できたら嬉しい。
Autifyさんは開発が速いから、将来的にもこのメール機能も拡充されていって、使いやすくなるんじゃないかという期待を込めて導入しました。実際に人間が目視確認をする必要がなくなったので、かなり検証がラクになったと思っています。
― APIの部分もそうですか？
鈴木さん: 僕は元々エンジニアなので「JSステップ」を使います。JSステップが使えると、できることの幅が広がります。今、LayerXではちょっとしたAPIテストはAutifyで実行しています。E2Eテスト系はアサーションが重要ですが、そこにも限界がある。例えば、今作って登録したレコードが、リストの一番上に来るとは限らない。結局、「表の中にそれがあるか？」という確認方法をしていると、前のテストの結果が残っていて間違うこともあります。
以前「登録した時に、二重に登録されてしまう」というバグが見つかりました。自動テストの中のアサーションだと見つけにくいんです。あとは、検索系です。クエリの結果に、検索したものが表示されていることの確認はできますが「それ以外が表示されていない」ことの確認がE2Eテストだと難しい。人間がやればすぐ分かることを精密に作るのは難しいです。
一方APIテストでは、アップロードや非同期タスクなどが苦手です。今どうしているかと言うと、E2Eテストのシナリオの中に、適宜JSステップを使ってAPIテストを組み込んでいます。E2EテストとAPIテスト、それぞれ苦手な部分を補いながら、かなり精度が高いシナリオが作れていると思います。
― 最初はJSステップをあまり使わないとしていたのに、途中から変わったんですね。
鈴木さん: エンジニアの工数を使ってでもメンテナンスしたほうがいいんじゃないか、という意見も出ました。APIの必要性がわかって、新しいツールを導入するかどうかを検討しました。既存のAPIテストツールを使うより、Autifyで簡単にAPIテストができました。
梶原さん: シナリオの中に埋め込めるのがいいですよね。最初はAPIテストはAutifyではカバーしていないものだと思っていたので、PostmanとNewmanの組み合わせを考えていたんですけど。鈴木さんが「そう言えば、JS書けるんだったら普通に書いちゃえばいいんじゃない？」って発想されて。書いてみたら、普通にAPIテストできるやんと（笑）。
― テスト期間は2日でリリースサイクルをキープしたい、非エンジニアでもライトにできる、といった点を重視されていたと思います。導入後はどう変わったか教えていただけますか？
梶原さん: 「リリースサイクルを維持できている」というのが一番の成果です。「Autifyでテスターの人件費が削減」という目線より「2日間を維持できている」という方が大きい話ですね。テスト項目自体は、今『バクラク請求書 (インボイス)』のほうが実は1,000を超えていて、『バクラク申請 (ワークフロー)』のほうも600あります。
毎回網羅するわけではなくて、『バクラク請求書 (インボイス)』だと400〜500項目、『バクラク申請 (ワークフロー)』だと200〜300項目、その時の影響範囲や新機能に紐付くものを選んで実行しています。そうすると、600〜700項目テストする中の300近くが自動化されています。本当にポチっと回すだけ。もちろん実行結果を見てメンテすることもありますが、バグがないかが早めに分かるというのは大きいです。
実際、自動化されていなかったら、さすがに2日では無理な状態になっています。2日後リリースなので1日半経った段階でほとんどテスト項目を終えてバグを洗い出した状態でないとバグ修正の時間を考慮するとリリースできません。だから同時に自動でテストを走らせて、バグがないかを先にわかるのは大変ありがたいんですよね。
鈴木さん: 実際、早くバグを見つけられることはとても重要です。その分、修正に使える時間が長くなるので。結果的に安心してリリースできることに繋がっていると思います。
― 確かに、かなり早い段階でバグに気付けますもんね。
梶原さん: Autifyは慣れるとメンテナンスがとてもラクです。Selenium使ってコード書いていたら、1個1個検証しなければならず「こんなにメンテコスト掛かるんだったら、自動化意味なくない？」という感じになりますよね。
鈴木さん: 変更内容をAutifyが自動で追従してくれるからメンテしやすいですね。UIの変更を追従してくれてシナリオが通るんですが、Autifyが気付いてくれて「要確認のマーク」が出る。それを見ると「ちゃんと反映されている」という安心感があります。
― 今後の展望をお聞かせください。
鈴木さん: 今後も新しいプロダクトをリリースしていくと思います。社内では「爆速開発」と呼んでいますが、スピード感を持って開発していく上では、品質が高くないとメンテナンスやバグの対応に時間を取られて、結果的にスピードが落ちてしまう。速いサイクルでプロダクトを世に出して、それを安心して使ってもらうためには、自動テストを早い段階から導入して開発していくことを今後も続けていきたいと思います。
梶原さん: 現状はステージング環境で行う2日間のQA中にAutifyを使っています。今後はプロダクションで定期的にテストを実行したり、Dev環境でマージされたら自動的に該当シナリオを実行したりということにも取り組みたいと思っています。各環境で定期的にテストが行われればより安心して開発できるので、リリースサイクルも早くなると思います。
― もっと前からテストを始められれば、最後の2日は予備みたいな感じになるかもしれない。
梶原さん: ステージング環境は最後の確認ぐらいになると一番いいなと思っています。あとは最近ChromeだけではなくEdgeでもテストし始めています。カバレッジを広げていこうと思っています。
品質保証全体で行っていることはE2Eテストの自動化だけではありません。機能要件だけではなく、非機能要件もある。「品質」という言葉が関わりそうなところは、あらゆるものに対して自分たちで責任を持っていきたいと思っています。他のインフラのチームとも連携しながらやることもあります。
例えば脆弱性診断とか、ペネトレーションテストについてはQAチームが率先して取り組みたい。やりたいことは本当にたくさんあるので、そのためにもAutifyを使ったE2Eテストの自動化は重要になると思います。
― これから自動化に取り組む方々にメッセージをいただければと思います。
梶原さん: Autifyはプロダクトの成長を支えているものになっているので、今年一番入れて良かったツールです。本当に助かっています。ユーザー視点でお伝えできることもあると思うので、検討に悩んでいる方は僕のTwitterからいつでもお声掛けください。
鈴木さん: どんなプロダクトもできるだけ早い段階から自動テストに取り組むほうが結果的に開発スピードが上がりますし、エンジニアは安心して夜眠れると思います。できるだけ早く自動化することをお勧めします。
― 最後に、御社からお知らせがあればどうぞ。
梶原さん: ありがたいことに、プロダクトがB2B SaaSとしては、順調な立ち上がりをしています。組織を大きくしながら、今後も多くの企業にワクワクする働き方を提供していきたいと思っています。
そのワクワクする働き方を守るのがQAの役割だと思っています。今日のお話した取り組みや、今後の品質に関わるところにご興味がある方と、ぜひ一緒にお仕事させていただきたいと思います。絶賛人材募集中です！
（聞き手：オーティファイ株式会社、CEO・共同創業者 近澤良）
.jpg)
.jpg)
