企業間取引に欠かせない、請求業務や入金管理は、事業の成長とともに負担も増えるのが常である。特に未入金時などに対応しなければならない督促業務は、精神的な負担も大きい。
企業間の決済業務の代行サービスを提供しているのが、マネーフォワードケッサイだ。
クラウド会計サービスを提供する株式会社マネーフォワードから、新たな事業として2017年に立ち上がったマネーフォワードケッサイ株式会社。取締役CTOの篠原 祐貴さんに、品質保証の課題やテスト自動化について話を聞いた。
マネーフォワードケッサイ株式会社 取締役CTO 篠原 祐貴 氏
(写真提供: マネーフォワードケッサイ株式会社)
― 御社の事業について教えてください。
篠原さん: マネーフォワードケッサイは、マネーフォワードが2017年に設立した新会社です。マネーフォワードはそれまで、法人向けの事業としては、バックオフィス向けのクラウドサービスにフォーカスしていました。そのため法人間の決済領域にコミットする事業として弊社が立ち上がりました。
弊社では、法人間の取引に発生する与信審査や、請求業務、請求書作成から発送などを円滑に行う、決済代行サービス『マネーフォワード ケッサイ』を提供しています。未入金の場合は、債務者に対して「入金を忘れていませんか？」と督促します。
与信審査は法人だけではなく、個人事業主にも対応しており、ほとんどの審査は自動化しています。最短数秒で結果をお戻しできる仕組みを構築しました。
― オペレーションを「システム的に解決する」ために、実際にソフトウェアを提供して自動化を？
篠原さん: はい。お客様が利用するマネーフォワード ケッサイとのセットポイントは、ウェブサービスで取引情報・請求情報を登録してもらうか、CSVをアップロードしてもらうか。もしくはAPI経由で登録してもらうか、というアクションだけになっています。
基本的にAPIを導入されている企業はシステム連携したいという要望もありましたので、審査に関しても結果をウェブフックで通知できるよう対応しています。
導入企業様は「エンジニアがいる／いない」「開発ができる／できない」などさまざまな事情があると思います。それらに合わせる形で、価値を提供しているような開発体制になっています。
― マネーフォワード ケッサイは課金モデルですか？
篠原さん: 基本的には委託いただいた金額に対して手数料をいただく「手数料型のビジネスモデル」になっています。
例えば100万円の債権に対して0.5％～3％の手数料を差し引いた金額を、支払い期日に入金する。
ですが「会社の事情が変わったので6月末まで待てない、早く入金して欲しい」という要望が生まれることもあると思うんですね。そういった要望に対して、手数料率にプラスαすることで、早期入金できる仕組みも提供しています。
このような企業間取引に関するお金の悩みに対して、マネーフォワード ケッサイが入ることで、不安やオペレーションコストを取り払い、より実質的な取引に専念できるような土台を作っていけるといいな、というのが弊社の考えになります。
― 同サービスができたタイミングで、篠原さんはCTOに就任されたのですか？
篠原さん: 僕は2016年12月にマネーフォワードに入社し、SRE（Site reliability engineering）として従事していました。
新卒の頃はヤフー株式会社でウェブアプリケーションを作っていましたが、その後ベンチャーに転職したことをきっかけに、すべてをフルスタックにやるようになりました。そしたらインフラ回りや生産性向上の仕組み、DevOps領域など、今だったらDXと呼ばれる領域に強い関心を持つようになったんです。
マネーフォワードに入社したタイミングには、AWSもまだ使われていない状態だったので、開発の生産性を高めるには、そもそもレガシーな開発、運用体制を変えなければと思いました。
入社して間もなくコアなミッションは受け持っていませんでしたが、マネーフォワードケッサイ（当時MF KESSAI株式会社）の創業メンバーと親しく、サービスの立ち上げの相談に乗ってるうちに、気付いたらマネーフォワードケッサイ専属になっていました。
― インフラ、DevOpsから品質保証に繋がってきた。
篠原さん: そうです。生産性の話で、フロントエンドという領域は、なかなかイテレーションに組み込むことが難しいと思うんですね。Cypress等を利用して、E2Eテストをコードで管理する会社もあると思いますが、コードが壊れてイテレーションのブロック要素になってしまうことも。
なので、E2Eには僕たちもあまり取り組めていなかったんです。デプロイ後に最低限、自分たちで動作確認していました。
もちろん新機能や変更点の動作確認は行いますが、よくある問題として「デグレしてないよね？」とか、gRPCをアップデートした際に「フロントに影響出ていないよね？」という確認まではできていなかったんです。「網羅的にできる体制を作らないと疲弊するな」という課題がありました。
篠原さん: 「参照できない」「状態が見えない」も課題ではありますが、まずマネーフォワード ケッサイとして一番起こしてはいけないものが、取引登録だと思います。
これまでは、ログやメトリクス、データベース監視などで、整合性の確認や動作検証はもちろんできていました。特にログやメトリクスのアラートって、ユーザー間のリアクション、アクションがない限り、発生しない問題だと思うんですね。
ユーザーが行動する前に何とかして行動しないといけないけれど、それを人でやると、忘れてしまうこともある。それによって生産性が下がることにも繋がるので、同じことを繰り返す作業は機械的にできる世界を作りたいと考えていました。
もう1点が、Kubernetesを使っていることもあって、インフラの作り変えイベントというのが定期的に発生する。その際に、作り直したものはバージョンが新しくなります。それが本当に全部正しく動いてるのかを、SREが全てを保証しきれない問題はあるかなと思っています。
その場合、僕たちは全アプリケーションの確認をエンジニアに依頼していました。アプリケーションサイドからすると、SREが進めたタスクに対する確認に、割り込み要素が入ってくる。そうすると自分たちで確認できないから、なかなかタスクを完了できないことが課題でした。
― ちなみに、どのくらいの頻度でリリースしてるんですか？
篠原さん: マイクロサービス的になってきてしまうので、ユーザーに対しての変更というリリースや、裏側でのリリースもあります。サイクルとしては、1日に数十回はリリースされています。全チーム合わせると、1つのKubernetesに対して20くらいは通常発生します。
デグレを避けるためのテストを1日数十回のリリースに対して、毎回実施できるかといえば当然できません。必然的に自動化せざるを得なくなります。
― Autifyを導入いただく前に、他のサービスも試しましたか？
篠原さん: 最初にCypressを使ってみたことはあります。でも「Cypress職人」が生まれてきてしまって、他のメンバーがメンテできなくなってしまう。
一応シミュレータやエミュレータはあるので、作れることは作れる。でもコード管理したり、新しいサービスを作った時の実行環境を構築したり、「やることが多いな」という印象で、なかなか根付かなかった。
僕たちの場合、小さな変更やUIの変更が頻繁に発生します。ですが、テストの変更が「壊れた。でもウェブサービス変更は進んでいってる」という状況があり、テストケースの変更が追いつかないままになってしまう。
「これは僕たちにはまだ早かったんじゃないか…」、「もう少し運用でカバーしようか」みたいな話になることがありました。
―メンテナンスが課題だったんですね。
篠原さん: そうですね。QAエンジニアを採用できる規模ではなかったので、自分たちで全部やっていました。テストコードを書いてUIのテストをする余裕がない、という状況もありました。
Cypressは、開発エンジニア全体で「みんなでやってみよう」という感じで書いたというよりは、誰かが担当者になって進めてみて、その中のレビューで「運用し続けるのは難しい」という感じでした。
2～3年前の僕たちの場合、チームが小さかったので動作確認をちゃんとして保証できた。その時は「もう少し頑張れるんじゃないか」と進めていました。当時はチーム全員が同じプロダクトを同時に開発していたので、確認し合うことができていたというのもあります。
当時はデグレすることもあまりなかったんです。でも実は、裏側でエラーが出ていたとユーザーからの問い合わせで気付くこともありました。
今はマネーフォワード ケッサイの事業が大きくなってきたことや、ユーザーに提供するサービスが複数になってきていることもあり、1つの変更が、違うチームのプロダクトにも影響してくる。だから必要性が高まって、Autifyやそれ以外も含めて検証を始めました。
— 他のサービスも検討されたと思いますが、Autifyを選んだ決め手は何ですか？
篠原さん: 1番の決め手は、オートヒーリング機能の強さです。僕たちのサービスは小さなUI変更が発生することが多いです。例えばユーザーから「ここは見づらい」というご意見があったとしたら、表示を変える。Autifyのオートヒーリングが強かったこともあって、トライアルで入れてみたところ、トライアル中のいろいろな変更に対してクリアしていた。だからそのまま導入することになりました。
これはブランディングの一環でもあるのですが、最終的には僕たちも「エンジニア以外でもテストを書ける世界」にしていこうと思っているんです。
誰でも書けないと、エンジニアに依頼しないと解決しない課題になってしまう。「これ保証したいよね、誰がやる？」という時に誰でもできる状態であれば「今、僕が空いてるんでやります」とか、誰でも品質を担保できるチームに向かったほうがいい。
E2Eテストをコード管理する場合、基本的には“エンジニアだけができる仕事”になってしまう。逆に人の手でテストするのであれば、誰でもできると思うんです。手順書を作るなり、チームの認識を合わせれば動作確認自体はPdMの僕がやっておくこともできるし、デザイナーが「ちょっとやるよ」などと、助け合えると思います。
Autifyのようにエミュレータがしっかりしている会社であれば、この「誰でも触れられる世界」を実現できるんだろうなと。Autifyは最終的に「誰もがテストが書ける世界を実現したい」というお話を聞きました。そういう世界の実現を僕たちも協力したい、一緒に見てみたいなというのもあって、Autifyを導入する流れになりました。
篠原さん: プロダクトチームだけではなく、SREでネットワークレイヤーやセキュリティレイヤーを変更する場合、少し間違えればユーザー事故に繋がってしまうこともあります。
その場合でもユーザーからの問い合わせがなければ気付かなかったり、ユーザーが使っていない夜中にリリースした場合、気付くのが朝だとツライじゃないですか。一応自分たちで動作確認はしても、抜け漏れというのを無くすのは難しい。
Kubernetesクラスタを入れ替えた後、Autifyでフルテストしたら問題がないことを保証できました。同じチームにいるからではなくて、隣のチームにいる人でも安心して変更できるというのは、導入後の心理的な安全性に繋がっていると思っています。
― Autifyを実際に導入いただいて、運用面で何か工夫していることはありますか？
篠原さん: どんなに使いやすいサービスだったとしても「導入したから、とりあえず使ってみて！」だと、「分からない、面倒くさい、ツライ」と思ってしまうんじゃないかと思います。だからまずはSREの課題解決ベースで、枠組みと土台を作りきった後に、徐々に各チームに操作方法を伝えながら、メンテナンスしてもらうようにしました。
マネーフォワード ケッサイのプロダクトに入れてみて、それを定期的に運用して、ある程度使い方を把握する。そしてE2Eテストに求める領域とそれ以外を分けて方針を固める。そこから徐々に関わってくれているメンバーにハンズオンをしていきました。
できることとできないことの把握、特に「できないこと」を把握をしておかないと、みんなが同じところでつまづいてしまうのは時間がもったいないと思います。
今日もSlackに誰かが書いていましたが、「触ってみたら簡単で使いやすかった」「イメージしていたよりラクだった」という声も共有しあって、みんなの理解やモチベーションを高めています。
— E2Eテストの領域と、それ以外をどのように分けていますか？
篠原さん: まず弊社の場合は「いきなり全てのテストを網羅することは諦めましょう」と最初に決めました。
マネーフォワードの各サービス間で連携しているところは定期的に実行しています。たとえば、新たに導入いただいた企業がAPIキーを発行するタイミングに、イベントが発火されますが、絶対に落としてはいけないコアな部分なのでしっかりテストしています。そういう、たまにしか起きないイベントは定期的に確認しておく。
「取引登録」の基本的なところはデイリーでチェックしています。そのほか不具合があるとユーザーが困るところを優先的に順々にテストを構築しています。 これはサービスの特性上ですが、取引登録をしたその日に請求書を送る状態をすぐには作れません。日にちをまたぐフローは自分たちでやることになりました。
取引登録してから請求書を送付して入金されるまで、フローによってステイタスが変わり続けますが、もしそれをEnd-to-Endでテストする場合、1カ月掛かってしまうことになるので、そこは自分たちで検証する領域だと、今は割り切っていますね。
「ウェブだけでできることにきちんと特化する」と決めてしまえば、悩まなくてもいい。まずはテストの作業を7割程度に減らすだけでも、毎日3割コストが浮くので、確実に生産性は上がります。
今後みんなが使い始めると「ここはどうしよう？」という話が出てくると思うので、都度検討しながら少しずつ工数を減らしていけるよう、自動化を進めたいです。今はまだスタートラインかなと思います。
― 各マイクロサービスは、リポジトリのcommit hookでマージされたタイミングにAutifyを回しているんですね。
篠原さん: 本来は社内環境でテストが通ってからマージする形が理想ですが、社内環境の課題もあり、デプロイ後に機械的に素早くチェックして早めに対応する、というところからスタートしています。
自動ロールバックまで実行できればいいのですが、まだそこまでの問題が起きたこともないので優先度は高くないと感じています。今後どうしていくかは、まだ見えていない課題です。
― 導入後はどのような変化がありましたか？
篠原さん: 最近モダンな会社が多いと思うのですが、少し前だとFirebase Authenticationや、今はGoogle Cloud Identity Platform。AWSだったらCognitoやAuth0。もしかしたらOktaとかが登場するかもしれない。
これらのアイデンティティ回りのサービスに対して、自社でIDパスワードの管理をせずにログインのための認証の仕組みを外部に任せる企業が増えてきていると思っています。そうなってくると、マイクロサービスの「デプロイしたら動作確認だけ」という運用では保証しきれないイベントが発生してくると思います。
導入SaaSで、特にログイン回りの話になるのですが、そもそも「ログインができない」という障害が起きてしまう。ログインがトリガーになってしまうと、ユーザーがアクションを起こさない限りアラートも上がらず、ユーザーがログインできなかったということになかなか気付けないまま、CSに問い合わせしていただくことになってしまう。
Autifyを導入して、定期的にテストを回す仕組みが整ったおかげで、「Firebase死んでたんだ」というのがわかるようになる。インシデントアラートなどはレポートで上がってくるけど、そこに上がらないレベルのエラーが内部で起きていることもわかる。「Firebaseで500は返っているけどインシデントに上がっていないよね」という問題がわかったり。
それらを社内で早めに検知した場合、導入企業様にCS経由で「現在障害が発生しています」ということをお伝えできますよね。早期検知するための仕組みとしても、大きな意味があると思っています。
― 責任範囲が分割するほど「E2Eじゃないと、どこで何が起きているか分からない」という問題は増えてきています。そこを担保できるのは大きいですね。
篠原さん: 僕が今話した内容くらいであれば、もしかしたらDatadogなどで監視して、確認することもできると思います。でも近い内容を別々に書くことによって、管理コストが増えてしまいます。なので、弊社としてはAutifyでログインやユーザーアクションを含む部分の監視を一元化できて助かっています。
― 最後に、今後の展望について何かあったらぜひお伺いしたいです。
篠原さん: DevOpsサイクルをいかに自動化し、効率化、そして高速化していくか。セキュリティ面のテストも、今後取り組んでいこうと思っています。
それはコードに潜む脆弱性を検知していくことも、もちろんですが、Dockerで生成したコンテナに脆弱性がないか、ファイルを誰かが変更したことで意図しないコードが空いていないか——それらを含めて、全ての生成物をデプロイをする前にテストして「安全」と思える状態を作る。
その上でデプロイできると、怖さや不安はなくなっていくと思うんです。機械がやってくれるんだから信頼できて、開発に集中できるようになります。開発することがより楽しくなって、より多くの価値を生み出していける好循環が生まれるのかなと思います。そのための投資だと思っています。
― テストを自動化することで、エンジニアがより本質的な開発に目を向けられる環境に整えていける。
篠原さん: アプリケーションのパフォーマンスもそのひとつだと思うんですね。改善してデプロイしたら、本番データベースに繋いだ瞬間、パフォーマンスが悪くなっていたら意味がない。出す前に気付けるようにしていきたいです。
SQLひとつでも、パフォーマンスをどう計測するか。今のデータだけではなくて、未来のデータ、例えば半年後は負荷が絶対に変わってくるはずなんです。そういった状況に対してどう取り組むのか。そういう課題が解決すれば、作ったものが将来まで保証できるようになる。負債にせず、開発サイクルが早く進むといいですよね。
― これからテスト自動化に取り組む方々へメッセージをお願いします
篠原さん: よく言われている言葉を使うなら「E2Eテストを導入したからといって、銀の弾丸はないよ」ということ。会社としての方針を決めておかないと、うまくワークしません。なので「自動化するぞ」を目標にせず、何を解決したいのかを掘り下げていくと、結果として「導入して良かった」と思える状態になると僕は感じています。
テスト自動化に何を任せれば幸せか、どう設計するのが自分たちにとってベストかを考えると、スムーズに進めていけると思います。
導入事例を見ると「あの会社がやってるならウチもそうしよう」と思いがちですが、事業内容が近しいものでも、プロダクトの構成や考え方が全然違うと思うんです。だからテストの作り方や考え方も違って当然です。その認識を誤ると、導入が困難になったり、むしろ生産性が下がるケースもあるかもしれません。自分たちのプロダクトにきちんと向き合えるかが、一番大事だと思っています。
― 最後に、なにかお知らせがあれば、どうぞ！
篠原さん: 決済のコア領域を開発するバックエンドエンジニアを募集しています。ロールをまたいで好きなように働けるポジションでもあります。
そしてSREも募集しています。弊社では「クラウドしていくぞ」と同時に、「やらなくていいなら捨てていこう」も大事にしています。運用コスト、生産性を判断ロジックにソフトエンジニアリングを改善していく仕事です。
近年、法人間決済の市場価値は高いです。債券を買い取っていくので、そもそも手持ちのキャッシュがあるかどうかで、踏み込めない会社も多いと思います。与信と資本金がないと、なかなか始められない事業でもあります。そういう意味では、競合になるスタートアップが少ない反面、課題解決に向かわないという問題にも繋がってるように思います。
マネーフォワード ケッサイは、法人間の決済というコアな領域で、企業の事業成長を助けていきます。その価値を一緒に作っていきたいと思ってもらえる方に出会えると嬉しいです。
（聞き手: オーティファイ株式会社、CEO & Co-Founder 近澤 良）
.jpg)
.jpg)
