Customer Stories

開発とカスタマーサクセスが一丸となって顧客のニーズに寄り添う。 『請求管理ロボ』テスト自動化の舞台裏

プロダクトマネージャー 田本 諒 氏、カスタマーサクセス 山下 隼平 氏、QAエンジニア 妹川 洋之介 氏
Company
株式会社ROBOT PAYMENT
https://www.pa-consul.co.jp/
Industry
IT・ソフトウェア
Their Services
請求管理ロボ
Autify’s Service
Autify NoCode Web
Size
100~199名
Purpase
リリースサイクル維持・短縮
Publish Date
November 26, 2020

現在、多くの企業が経理部門のIT化に取り組んでいる。その背景には世界的なFintechの進展だけではなく、新型コロナウイルスによるリモートワーク推進もあげられる。

そんな現在の潮流より20年も前から、決済・資金移動・請求・料金回収業務の自動化に邁進しているのが株式会社ROBOT PAYMENTだ。

ROBOT PAYMENTの請求書自動作成ツール『請求管理ロボ』は2014年にリリース。年々ニーズは高まり現在では、500社以上の企業が導入している。いまも根強く残る紙文化・ハンコ文化により、経理部門だけが出社を余儀なくされている現状を問い直す「日本の経理をもっと自由に」プロジェクトも動き出した。

ROBOT PAYMENTで『請求管理ロボ』を手がけるプロダクトマネージャー 田本 諒 氏(以下、「田本さん」)、カスタマーサクセス 山下 隼平 氏(以下、「山下さん」)、QAエンジニア 妹川 洋之介 氏(以下、「妹川さん」)の3名に、品質管理や開発の裏側、テスト自動化ツール「Autify」導入について話を聞いた。

(写真左から、株式会社ROBOT PAYMENT カスタマーサクセス 山下 隼平 氏、プロダクトマネージャー 田本 諒 氏、QAエンジニア 妹川 洋之介 氏)

—皆さんがご担当されている業務内容について教えてください。

田本さん: ROBOT PAYMENTで『請求管理ロボ』のPMを担当しています。大学2年生のときから当社でインターンをしていました。当時から要件定義と受け入れテスト、シナリオテストを作っていたので“テストの辛さ”は、インターン時代に経験しました。大学卒業後に新卒として入社、エンジニアを経験した後、2年前からPMをしています。

山下さん: 私は『請求管理ロボ』のカスタマーサクセスを担当していて、企業のオンボーディングや満足度を高めていくのが任務です。

妹川さん: 私は『請求管理ロボ』だけではなく、Salesforce上で提供しているアプリケーションや、決済サービスの分野も含めたQA(Quality Assurance=品質保証)エンジニアを担当しています。

—貴社のサービス、今すごく需要が高まっていますよね。紙の請求書を「送っても受け取る相手もいない」という状況でもありますし、電子化がどんどん進んでいる領域です。

田本さん: 2020年10月1日に電子帳簿保存法の改正があり、ペーパーレス化がますます進んでいくので、企業もバックオフィス系のシステムを整えようという動きがありますね。

品質向上のための改修に、工数ばかりが増えていくジレンマ

—Autifyを導入いただいていますが、以前はどのような課題があったのでしょうか?

田本さん: かつては品質に多くの課題がありました。不具合を改修すると別の不具合が発生することもあり、人が手動でテストするには限界がありました。

そこで3年前、Selenium IDEを導入することに。当時は全シナリオを書いてリリースした直後、本番環境で回しても不具合がないかを毎回手動で確認していきました。Seleniumを触ったことがある人はよく分かると思うんですけれど、Ajax(Asynchronous JavaScript and XML)で取れなくて落ちたりと、エラーが頻発するので直すのに時間がかかっていました。

IDEだと厳しいので、Seleniumをコードで書いていくことにしたのですが、環境によって動かなかったり、原因不明なエラーも出てきてしまい……。仕様変更に合わせてテストコードを都度修正しなければならず工数ばかり増えていく、という課題を抱えていました。

—コードを書くとき、実際どのくらいの工数をかけていたのですか?

田本さん: IDEだと、3人体制でひたすら書いて、機能を網羅するのに、1~2ヶ月かかっていました。エラーが出た部分を再実行するんですが、いざ再実行してみるとエラーにならないということがあるんです。エラーが再現できないというのは、その原因が掴めないので、本当に困るんです。あえてウェイトを入れたり、デバッグしたりして、それっぽいエラーを半強制的に再現してみたり。結果、時間だけとられて根本的な解決がされたのか、されていないままなのか曖昧なまま「まぁ、とりあえず問題なさそうだな」といったことも正直ありました。

顧客のニーズを理解しているカスタマーサクセスがシナリオ作成を主導

—そのような課題を解決するために、Autifyを検討したとのことですが、導入までのプロセスを教えてください。

田本さん: まずは関係部署に現状の課題を伝えることから始めました。品質を担保するために、Seleniumでどのくらいのメンテナンスコストがかっているかについて。AI解析で自動修正してくれるAutifyの利点を考えると、エンジニア1人がメンテを張り付きでやる必要がなくなり、その分を開発リソースに当てられる、といった説明をしました。

話し合いの末、いよいよ「Autifyで進めましょう」となったとき、主幹をどの部署にするのかを協議しました。これまではコードを書けるエンジニアが担当するしかありませんでしたが、AutifyだとGUIでできるため、必ずしもコードが書ける人が担当する必要がないからです。

当時、弊社には独立したQAチームがありませんでした。品質管理のフローをあらためて整えるにあたり、シナリオを書く担当はユーザーに一番近く、仕様に理解のあるカスタマーサクセスチーム (以下、「CS」)が適任なのではないかと提案しました。

それでも、成果物に責任を持つのは開発チームにあります。CSと開発チーム双方で協力しながら進めていく体制をとることになりました。

—コードが書けるバッグラウンドがあって、サービスの仕様についても社内で一番詳しいポジションでもある山下さんに、白羽の矢が立ったわけですね。

田本さん: そうですね。彼は「こういう使い方をするから、こういうケースでカバーしよう」というユーザーの業務に関する理解も深かったので今回の担当に最適だったと思います。

—確かに「どんなことに困っているか」「どのような使い方をしているのか」についてはお客さんをサポートするCSが一番理解していますよね。どこの部署が担当するかについては、CS以外の候補もあったのですか?

田本さん: サービス品質の担保という意味では「開発がやるべきじゃないか」という意見が他部署からはありました。開発側は「シナリオを考えるのは、ユーザーに近いところがいいんじゃないか」という意見です。どちらも忙しいので、ここで意見が割れたのは正直なところです(笑)。

そもそも、KPIを品質に向けるQA部隊があったほうが良いけれど、「今はないから、どうする?」と話し合った結果、PMの私とCSの山下で一緒に担当することになりました。

山下さん: コーディングやプログラミングなど、システム全般を学びたい気持ちがありました。
開発チームはどこが大変なのか。また、どうすればユーザーの要望をより早く開発チームに実装してもらえるか、といったところにも興味がありました。なので「やる?」って言われたら、「じゃあ、やります」という感じだったと思います。

—既存の業務があるなかで、リソース的に問題はなかったんですか?

山下さん: もちろん今までの業務が減るわけではなく、シナリオ作成とその運用が新たに追加された形にはなります。周りのメンバーに「こっちやるから、新規をお願い」とタスクを渡していきました。そこの調整は確かに難しかったですね。

でも、皆の協力が得られた理由は、やはり品質向上に繋がって、結果的に顧客満足に繋がるというところの理解がCSのメンバー間にあったからだと思います。不具合が減ることでCSの工数自体も減らせるというのも理由のひとつです。

妹川さん: 私は当時の議論のときにはおらず、そのあとにROBOT PAYMENTにジョインしたのですが、客観的に見ると、おそらく一番困っていたのがCSなんじゃないかなと思っていて。不具合が起きたとき、真っ先に問い合わせに対応しなければならないのがCSなので。

山下さん: 板挟みになる部署だから(苦笑)。できるだけ不具合を減らしたいというのが切実な願いです。

開発とCSが常時確認できる安心感

—導入後の運用で、なにか工夫したことはありましたか?

田本さん: シナリオ作成ではまず、機能をカテゴリごとに分類して、網羅的にカバーできるよう洗い出しました。それぞれ優先順位をつけて全体設計をしたあと、細かい部分を適宜直していくという形でスタートしました。

リリースした翌日には、自動でテストが回るようスケジューリングしています。エラーが出たら確認して、必要に応じてシナリオを直すという運用になります。

—運用において、開発との連携はどのように行っているんですか?

妹川さん: もしもエラーが起きた時にはAutify上の画面で状況と手順が表示されるので、それをSlackで共有し、開発に対応してもらっています。一度、バッチ系のシステムが落ちてしまっていたときはAutifyが検知してフィードバックできました。
Slackと連携してあるので、リリース後に問題なく動けば「OK」の通知が来るように設定しています。パッと見で「ちゃんと動いている」ってわかるとホッとしますね。開発者もCSもきちんと動いていることを常に確認できていることに安心感があるんですよね。

エンジニア1人分の工数を機能開発に充てられるようになった

—導入していただいてしばらく経ちましたが、これまで抱えていた課題に対する変化は実感できていますか?

田本さん: 導入前は、その「ちゃんと動いているか」の確認作業を全て人が行っていました。1週間に1度のリリースで、毎回人が全てのケースを確認するのは現実的に厳しいですね。その工数が削減できたうえに、安全に運用できるようになりました。

以前にIDEを使用していた時は、ツラすぎて途中で止めてしまっていたので。メンテナンスが大変で結局動かさなくなってしまうというのは結構あるあるだと思います。

Autifyを導入してからは、テストが自動で回ってエラーをすぐに検知して、同時チェックできる“仕組み”を作れたというのが大きな成果です。安心して開発できる、ということが開発スピードの向上を後押ししていると感じています。

—メンテナンスの工数はどれくらい減りましたか?

田本さん: ちゃんとメンテナンスするとなると、1人月くらいの工数がかかるところを5人日程度に削減できました。全体で見ると、エンジニア1人分未満です。メンテナンスしなくてもよくて、作ってしまえば放っておいてもリリースが担保されるという形を作れたので、常に気にしていた状態から解放された実感はあります。しかも、それが安い。

—シナリオ作成に関してはどうですか?

山下さん: 画面処理だけでシナリオができるので、とても簡単です。CSのほうの業務があるので、工数をかけずにスムーズに使えている状態です。つまづくところがあっても、サポートしていただけるのが助かっています。シナリオを作ったらその場でテスト確認できる機能が新しくリリースされてありがたいなと思います。

—新機能もスピーディに追加していこうと思っています。今後、技術面で取り組みたいことがあれば教えてください。

田本さん: 開発中に起きた不具合に対して、再実行がラクになる体制を作ること。あとは、CI環境にも組み込みたいと思っています。デプロイする前のチェックにAutifyを活用して、より安心してリリースできる、という環境をさらに整えていきたいです。

ブラックボックス化をなくすため、まずはスモールスタートを

—最後に、これからテスト自動化に取り組む人へ、メッセージをお願いします。

田本さん: テスト自動化を自前でやろうとすると、数名のエンジニアしか分からないブラックボックスになりがちですよね。そもそもテスト自動化にも精通したエンジニア人材は希少ですし、そこはSaaSに置き換えて運用していくのがいいと考えています。部署をまたいで誰もが確認できて、シナリオも書けて、運用できる、皆がわかる状態を作れたら、引継ぎやコストがかかりすぎる問題もクリアになっていきます。

AutifyにはMicroプランというのがあります。自社のサービスでテスト自動化の費用対効果が証明できている企業はまだ少ないと思います。まずは小さいところから始めてみて、効果を感じられなかったら辞めるというのも含めて検証してみてはどうでしょうか。もし効果を実感できたら、範囲を徐々に広げていくような進め方が、これから自動化を進めるうえではポイントになると思います。

—御社では、メンバーも募集していると聞きました。

田本さん: 『請求管理ロボ』では、フロントエンジニア、バックエンドエンジニア、UI/UXデザイナー、スクラムマスター、QA担当者、QAエンジニア、SREなどなど、全方位で募集しています。テックブログもあるのでよかったら見てみてください。

—エンジニアだけではなく、CSも含めたチームで一丸となって品質を高めていく、という取り組みがとても勉強になりました。ありがとうございました。