「テストを自動化しないとプロダクトが成立しない」行政サービスのDXに取り組むGrafferが、高頻度のリリースを実現するわけ

マイナンバーカードの登場で、住民票や印鑑証明書などの申請手続きが便利になった。自治体も電子化、ペーパーレス化が進んでいる。

とはいえ行政サービスにおけるDXにはまだまだ課題が山積しているのが現状だ。

株式会社グラファーは、そうした現状を打破すべく、行政向けのSaaSを開発しているスタートアップベンチャー。スマホにマイナンバーカードをかざして本人確認、住民票の写しを申請できて、手数料はキャッシュレス決済が可能なシステム『Graffer スマート申請』を提供しており、全国の自治体が導入を進めている。

株式会社グラファー フロントエンジニア 吾郷 協 氏
(写真提供: 株式会社グラファー)

株式会社グラファーでプロダクト開発を手がけているフロントエンジニアの吾郷 協さんに、開発における課題や、テスト自動化について話を聞いた。

— 御社の事業について教えてください。

吾郷さん: 株式会社グラファーは、主に行政向けのSaaSを提供しているスタートアップです。行政手続きにおけるユーザーとの接点部分の「体験を良くする」ことを目標にSaaSを開発し、自治体などに導入いただいています。

そのほかに、法人証明書を取る際などに使えるサービスを企業向けにも提供しています。

— 弊社でもバックオフィスで活用していますが、本当に便利で驚いています。

吾郷さん: おかげさまで、多くの企業様からも好評いただいています。自治体では、新型コロナウイルスの感染拡大とともに、市民が窓口に訪れるだけでも感染リスクが高くなってしまうため、ペーパーレス化も加速しています。どうにか改善できないか、と弊社に相談いただく件数も増えている状況です。

— 吾郷さんはどのような業務を担当されているんですか？

吾郷さん: 私はフロントエンドのスペシャリストとして、技術的な部分全般を担当しています。E2Eてテストの管理や、ライブラリのアップデート、フロントエンド関係のCIの高速化やメンテナンス、そのほか共通ライブラリの構築などを主に担当しています。最近はセキュリティやアクセシビリティ、品質管理にも興味があります。

— Autify導入前は、どのような課題がありましたか？

吾郷さん: 製品に対してE2Eテストのプログラムコードを書いていても、メンテナンスコストが大きいのがネックでした。実行に時間が掛かるし、テスト環境を整備して維持管理するだけでも手間が掛かっていました。

開発側がコードを書き、環境を整備して、実行結果を確認するフローにしたのですが、それでは全体を網羅できないし、エンジニア以外はE2Eテストでエラーが出ても、どこがどのように悪いのかがわかりません。何か問題に気付いても、エンジニアでなければ、それを解決・確認するためのテストを書けないことも課題でした。

弊社の場合は主にBiz Dev（Business Development）の担当者がプロダクトを触ったり、自治体に導入を進めています。弊社のプロダクト自体の自由度が高いので、Biz Devにも一定の技術スキルが求められるんです。だからBiz Dev担当者も複雑な設定を理解して提案しなければなりません。

— その時点ではみなさん、手動でテストされていたんですか？

吾郷さん: エンジニアは自動テストも行っていて、簡単な修正であればサッと見るぐらいでした。Biz Devのメンバーは、リリース前のチェックシートに沿って正しく反映されてるかを手動でチェックするフローになっていました。

— 実際Autifyの導入は、どのように進めていったのですか？

吾郷さん: 元々エンジニアがTestCafeで作ったE2Eテストの基盤があったため、その部分は無理に移植せずに運用しています。エンジニア以外――Biz Devのメンバーに「こうすれば、このようにテストが実行できて、結果が出ます」と画面を見せながらAutifyの操作説明をしました。

AutifyはUIがパッと見て分かりやすいため、つまづくことはほぼなかったです。「ああ、なるほど」とすぐに理解してもらえたので、導入はラクに進めることができました。

実際に導入したらエンジニアからも「Autifyのほうがラク」という声もあり、使う範囲も広がりました。今ではエンジニアが書いて作ったテストと、Autifyのテストを半々くらいで走らせている状況です。

— 「こっちのほうがラク」と言っていただける状況は、まさしくAutifyが目指すところなので嬉しいです。どんなところを利点に感じていただいたのでしょう？

吾郷さん: ブラウザを操作しながらテストが作成できる点は、視覚的に分かりやすいです。それから、テストが安定しているところですね。今までプログラムコードを書いて作ったE2Eテストは、随時手を入れなければ「問題がないのに、落ちる」ということがありました。

Autifyではそれがなく、実行すればそのまま放っておける。落ちたら何か問題が起きているということなので、すぐに対応しています。その信頼性の高さが、エンジニアからの評価が高かった点です。

— 導入はスムーズだったとのことですが、運用も含めて、なにか工夫されたことはありますか？

吾郷さん: Autifyのユーザー権限に縛りをつくらず、誰でも追加できるようにしました。Autifyを使うための手続きを省いたことは、とっつきやすさにつながり、社内でも導入が進んだ要因だと考えています。

僕自身もはじめはAutifyを使っていないので、詳しいことはわからない状態でした。あえてルールはつくらずに、とにかく他のメンバーにも使ってもらうことを優先しました。

— ちなみにAutifyの導入時に、他のサービスも比較検討をしましたか？

吾郷さん: もともと「エンジニア以外のメンバーが使う」ことを想定していました。そのため、エンジニアでなくても使えそうなサービスをいくつかピックアップして比較をしました。

— 最終的にAutifyを選んでいただいた、決め手はなんですか？

吾郷さん: 1番の決め手になったのは、弊社のサービスで実際にテストをしてみて一番正常に動作するサービスだった点です。特に何かを工夫しなくても「普通に使える」ことが、採用の決め手になっています。

たとえば、hoverでスライドダウンメニューを出す動作で、他のサービスでは、hoverに対応していなくて、右クリックから「hoverイベントを発火する」ボタンを押さないと動かない。Autifyはそのようなこともなく、普通に使えました。

他のサービスはUIが分かりにくくて、エンジニアが使おうとしても、どう使っていいのか分からないものも結構あったんです。Autify以外の選択肢はあまりないな……と感じました。

— 「当たり前に動く」を実現するために細かいエンジニアリングを重ねてきたので、それが評価されたのは本当に嬉しいです。

— どのくらいの頻度でデプロイしていますか？

吾郷さん: 弊社は20前後のサービスがあります。頻度が高いサービスですと、1日に5～6回。会社全体だと、1日に10回くらいはリリースしています。

— 行政向けのサービスで、そんなに高頻度にデプロイできるのはすごいです。

吾郷さん: 開発者として手を動かしているので、行政サービスを作ってる感覚よりも「普通のSaaSを作っている」感覚です。行政だから夜間しかリリースできないという縛りは特にありません。

元々はサービスの数も、エンジニアの人数も少なかったので、リリース頻度は今ほど高くありませんでした。サービス数とエンジニアの人数が増えるにつれて、自然とリリースの回数も増えました。 E2Eテストもかなり初期から基盤を作ったので、現在はこのスピードで回せていると思います。

— Autify導入後は、どのような変化がありましたか？

吾郷さん: エンジニアも、それ以外のメンバーも取り得る手段のひとつとして、Autifyが加わったことは大きいと思っています。特に見た目に関してはAutifyのほうが簡単にチェックできるから、「Autifyに入れて、あとは放っておく」ということができるようになり、コストが大幅に削減されました。

— 導入後のメンテナンスはいかがですか？

吾郷さん: Autifyの、アップデートによる差異を自動検出してテストシナリオを自動修復する機能「メンテナンスAI」のおかげで、現在メンテナンスはほぼ自動で完了しています。稀に「UIが変わりました」という通知が来ますが、それを見ながら「OK」を押していくだけ。ほぼメンテナンスフリーの状態で動いている状態です。

— TestCafeのほうのメンテナンスコストはいかがですか？

吾郷さん: TestCafeは、どうしても一定数のエラーが出る。もちろん、待ち時間をどんどん追加していけば安定するのは分かってはいますが、待ち時間が増える分コストは減りません。例えばテストを追加していって、1回につき100msec待つ状況だったとしても、テストが100個になれば、それだけで10秒待たされてしまう。

しかもテストを実際に調査して、「本当に100msec要るのか／要らないのか」というのを判断した上でじゃないと秒数を削れないのでテストを実行する環境のパフォーマンスを上げても改善できない。かなり注意深くその時間「待ち」を調整していたこともあり、メンテナンスコストが掛かっていました。

— スタートアップでE2Eテストを自動化されてる企業はまだ少ないと思います。テスト自動化に、初期から投資された理由を教えてください。

吾郷さん: 一般的に必要なプラクティスとして実践していました。弊社は経験を積んでいる開発者が多いので、E2Eだけでなくユニットテストも含めて「やっぱりテストは必要」「明らかに自動化したほうがいい」という共通認識を持っています。それに関してとくに異論を挟む人はいません。

そういうカルチャーができ上がった背景として、採用が大きいかなと思います。採用面接では「テストの経験があるか」、「これまでどんなテストをやってきたか」「どういう問題に直面して、どう対応したか」を質問しています。困難に直面し、乗り越えた経験のある人が多くいる会社だと思います。既存メンバーがそのカルチャーを根付かせてきました。

もちろんテストだけではなく、アーキテクチャの設計、多言語環境への対応などの経験があるか、どんな考えを持っているかも重要だと考えています。

— テストによる、コストと効果についてはどうお考えですか？

吾郷さん: テストすることが当たり前で、無いとプロダクトとして成立しなくなることは分かっていたので、その費用対効果を考えたことはないのが正直なところです。

例えば、今「クラウド環境を使うかどうか」について、使う場合と使わない場合で費用対効果を比較するかというと、おそらくみんなしない。それと同じように、そもそもテストしない選択肢すらないのです。

— そう考えられる企業カルチャーは素晴らしいと思います。御社のように「テストを当たり前として重視する文化の組織」はどうすれば作れると思いますか？

吾郷さん: 私が入社した時点ですでにそうなっていたのでゼロから作り上げる方法はわかりません。もし現状がそうではなくて、これから変えていきたいと思うのであれば、例えば「テストをしない結果を試す」で、痛い経験をする（苦笑）。

格言の1つで、「教育が高くつくというのなら、無知を試してみるがいい」という言葉がありますね。無知を一度試すと、教育のコストがいかに安いかがよく分かる。なので「テストの費用が高い」と思うのだったら、テスト無しでやってみるというのは、分かりやすく結果が示されることになるとは思います。

その上で重要なことが「自動化」であり、その一部が弊社の場合はAutifyです。自動化しないと回らないし、困ることは分かっているので、とにかく自動化は必須です。

— 今後どのように進化していきたいか、展望はありますか？

吾郷さん: AutifyとTestCafeの役割をどう切り分けるかについては、まだ迷ってるところではありますが、TestCafeをもっと安定させる必要はあると思っています。TestCafeで動いているテストを一度バラして、Autifyに再構築する場合、置き換えにもそれなりにコストがかかるので悩みます。

現在、スマホのネイティブアプリを使って電子署名をするフローがあります。その部分はまだテストが構築できていないので、Autifyに追加したいと思っています。Autify側で、Chromeのエクステンションを入れられるようになっていると、既存のテストフローと近い形でテストができるので嬉しいです。

Autifyは新しく組むにはすごく便利な環境ではあるんですが、既存のものを移行するとなると考えるところはあります。Autifyはクオリティが高く、とにかく「普通に動く」。それだけでもすごく価値が高いと思っています。

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

吾郷さん: もしこれからテスト自動化に取り組むのであれば、今あるコードをテスト可能な形にしていくことから始めるといいと思います。地味ですが、まずはコード分割や、機能の集約など。

弊社のプロダクトはシンプルなものが多いです。例えばアニメーションを多用したり、「クリックしたらフェードアウトして、また何かをフェードインしてくるみたいなものはないので、割とスムーズに導入できたと思っています。

テストが難しい環境で、無理矢理E2Eテストを作ることも可能です。ただ、それではE2Eだけが膨れ上がる。小さな問題を全てE2Eテストでカバーするのは非効率です。難しいコードであればあるほど高度なテスト技術が求められますが、テストしやすいコードのテストは、テスト技術はほとんど要らない。コードをテスタブルに整えていくといいと思います。

— 最後に、お知らせがあればぜひ。

吾郷さん: 株式会社グラファーでは、普段使っている行政サービスを自分たちの手で改善することに熱意のある方を募集しています。現在の品質がどのくらいで、どのレベルまで品質を高めるべきか、そのためにテストをどう構築するか。そこにチャレンジできる品質管理のスペシャリストをお待ちしています。ご興味をお持ちいただけた方はぜひ採用ページをご覧ください。

（聞き手: オーティファイ株式会社、CEO & Co-Founder 近澤 良）