連載「Technology Company Internals」では、テックカンパニーの内側で働くエンジニアに、技術に精通したエキスパートが対面で話を聞き、テックカンパニーとは何か？を探るだけでなく、テックカンパニーを目指す企業の指針となることを目指します。
マネーフォワードのCTOとVPoEに話を聞く
白石: 本日はよろしくお願いします。自己紹介からお願いできますでしょうか？
中出: 中出 匠哉と申します。マネーフォワードのCTOとして企業経営に関わり、経営にテクノロジー視点を導入していくのが主な役割です。他には技術面での方向性の決定や、エンジニアの人事制度の立案などもやっていますね。あとはサービスがどんどん大規模化していく中でも、技術的負債に優先順位を付けて、体制を作って解消していくのも私の仕事です。
渋谷: 渋谷 亮と申します。VPoEを担当しています。マネーフォワードには複数の事業領域があり、それぞれにVPoEがいるという特殊な体制になっています。私はその中で、Money Forward Business CompanyのVPoEを担当しています。
白石: 御社のエンジニア組織はかなり大きそうですね。差し支えない範囲で構わないのですが、どれくらいの規模感なんでしょうか？
中出: そうですね、エンジニアとデザイナーを合わせて、ざっくり300-400人ってところじゃないかと思います。
白石: 渋谷さんが担当されている範囲というのは、そのうちどれくらいなんでしょうか？
渋谷: 私が所属しているのはB2B領域で、社内でも一番大きな事業体になっています。全従業員数のうち6割ほどがここ（B2B領域）に所属していますね。
白石: だいぶ大きな人数ですね。
渋谷: はい、そうしたチームの評価や採用、文化づくりなど、エンジニア組織に必要なことはだいたい担当範囲です。
技術的負債の実際
白石: 大きな事業体となると、先ほど中出さんがおっしゃってた技術的負債みたいなのも、かなりたくさん溜まってそうですね。
中出: はい、技術的負債を解消するという取り組みの中心になっているのは、マイクロサービス化ですね。Ruby on Railsで開発した巨大なSaaSを、Go言語でマイクロサービスに置き換えていくのが、メイントピックと言って差し支えないかと思います。
白石: モノリシックなサービスをマイクロサービス化するというのは、大きな決断も必要だったんじゃないかと思います。何が当初そこまで問題になっていたのでしょうか？
中出: 一つは開発効率上の問題ですね。モノリシックなサービスを、大人数のエンジニアで修正し続けることで、開発上の非効率が発生していました。
もう一つはレイテンシの問題です。例えば、たくさんのデータを持ったユーザーが帳票作成などを行うと、ひどいときには何十分も処理に時間を要してしまうようなことがありました。
白石: レイテンシの問題、とのことですが、RubyからGoにすることで速くなるというのは、言語の問題が大きかったということですか？
中出: というよりは、RailsでボトルネックになりがちなところをGoで置き換え、最適化したというのが本質です。大量のデータを読み込んで集計するような処理を、Go言語で開発したマイクロサービスに置き換えることで、先ほど申し上げた数十分かかるような処理が10分の1、場合によっては100分の1という処理時間で完了できるようになりました。
Go言語を選んだ決め手
白石: いろいろな選択肢がある中で、Go言語を選んだ決め手は何だったんでしょう？
中出: やはり開発チームが大きくなるにつれて、安全性を重視して静的型付けの言語に移行したかったというのがあります。選択肢としてはJavaやサーバーサイドKotlin、Goなどいろいろありましたが、Goに興味を持つエンジニアが社内にいたり、開発経験を持つエンジニアがいたというのが大きいですね。
白石: 実際大規模に使ってみて感じる、Go言語の良い点ってなんでしょうか？
中出: まず良い点としては、習得コストが低いところですね。高速で軽量なのもいい点です。マイクロサービスを扱うには、やはりDockerなどのコンテナ技術がほとんど前提になりますが、Goだと非常に小さなイメージサイズで実行できます。
白石: 逆に良くない点ってありますか？
中出: そうですね…いわゆるオブジェクト指向言語じゃないというところが、一長一短だなと感じるときはあります。あとジェネリクスがないなど、言語機能としてまだ不足しているなと感じる部分もあります。
渋谷: 実際のところ、Goは数ある選択肢の一つですし、他にも別の言語を採用する可能性はあります。5-10年経ったら、きっと違う言語で書き換えていくんだろうな、とも思いますし。Goは今「流行っている」というのも重要な点かなと思います。
中出: 流行りは大事ですね。人気のある言語を使っていると採用にもメリットがありますし。Goは、まだ経験者は多くないけどやりたい人は多い…という言語です。いろんな学生やエンジニアと接してきましたが、「やりたい技術」を先行指標として持ってもいいのかな、と思っています。そういう「やりたい技術」という指標で考えると、バックエンドの言語では、Goが今は一番だと感じますね。
白石: なるほど、企業として考えると、採用という面からもプログラミング言語は重要ですね。
渋谷: 企業としては、利用している技術を「ポートフォリオ」として考えてもいいんじゃないか、と思っています。技術を増やすと採用のターゲットも増えますし、ある技術が廃れたときの保険にもなります。ポートフォリオとして捉えると、今チームにエンジニアがどんどん増えつつあるので、もう一種類くらい言語を増やしてもいいのかな、と思います。
マイクロサービス化の実際
白石: では、先ほどから話題に上がっているマイクロサービスについて教えて下さい。具体的には、システムの全体像はどのようになっているのでしょうか？
中出: まず前提として先ほど申し上げたように、まずRuby on Railsでできた巨大なSaaSがありまして、それを今マイクロサービスに置き換えている最中です。現在のアーキテクチャとしては、ユーザーのリクエストがRailsに届き、それがGoでできたマイクロサービスを呼び出すという形になっています。将来的には、Railsを通さずに直接Goのマイクロサービスを呼び出す形に移行していくことを考えています。
白石: マイクロサービスは、Kubernetesなどで管理されているんですか？
中出: そうです。サービス間の通信にはgRPCを使っています。
白石: マイクロサービス化は、パーセンテージで言うと、どれくらいまで進んでいると思われますか？
中出: いや、全然です。言ってみればまだ入り口のドアを開けたくらいじゃないでしょうか。まだまだこれからです。
白石: モノリシックなサービスをマイクロサービス化していくにあたって、苦労している点はありますか？
中出: それは…山程あります（笑）Railsアプリの一部をGoで置き換える…という形で進めているわけなので、まずRailsのコードを読んで、Goで書き換えなくちゃいけない。そのためGoを書く能力だけじゃなく、Railsを理解する能力も必要になります。
白石: 理想的な進め方としては、テストケースを先に揃えてからマイクロサービスのAPIを書くことですよね。
中出: はい、なのでテストケースはだいぶ増えましたね。
渋谷: それに、先ほど言ってたような集計ロジックについては、データのdiffを取るという形でテストを行うこともできます。既存のコードと同じ動作を保証するためには、そういう形でのテストも行っています。
「マイクロサービスに伴う失敗談なら話が尽きないですよ（笑）」
白石: あと、マイクロサービスといえば、原則的にはデータベースをサービスごとに分けましょう、となるじゃないですか。そこも実際に実現しているのでしょうか？
中出: そこはほんとに苦労しているところです。既存コードの置き換えで進めているので、最初はDBをシェアするしかないんです。そうしておいて、あとはテーブルごとにアクセスを切り分けながら置き換えていく。
渋谷: 最初は「モノリシックなサービスをマイクロサービスに分解しよう」というつもりはなくて、複数のサービスがDBを一部共有してしまっているのを整理したかったんです。例えば会計や給与などの複数のサービスでユーザー情報を共有しているという状態から、認証に特化した基盤サービスを切り出すという感じです。そういう「基盤サービスの切り出し」を行っているうち、自然とマイクロサービス化が促進されていきました。
白石: なるほど、そういう経緯だったのですね。しかし、複数のサービスで共有しているDBを個別に分けるというのは本当に大変そうです。例えば、JOINの対象になっているテーブルを分けるとかも必要になってくるわけですよね？
渋谷: そうです。そういうものは、論理DBを通じてデータアクセスするようにし、裏側を少しずつ置き換えていくとか、地道な作業が必要です。あと、問題になるのはトランザクションですね。ネストトランザクションとか。
白石: ああ、それはしんどそう。2フェーズコミットとか必要なやつだ。ロールバックとかどうするんですか？
渋谷: しんどいです（笑）至るところにデータの整合性を担保する仕組みを作り込んだりはしていますが、本当につらい。
白石: しかも、御社ってお金を扱うサービスじゃないですか。ちっともカジュアルなサービスじゃない。お客様の会計情報っていう、重要極まりないデータを取り扱っているわけで、トランザクション周りをいい加減にするわけにいかないですよね。
中出: そうなんです。お客様の大切な情報をお預かりしているので、ミスは許されません。
渋谷: 正直、マイクロサービス化は、しないならしないに越したことはないと思います。トランザクションとかもそうですし、サービスを間違ったところで切ったときの悲惨さと言ったらもう…マイクロサービス、ちっとも銀の弾丸とかじゃないので（笑）
中出: そんなこんなで、技術的負債を解消するのも4年くらいやってます。会社ができてから8年しか経ってないのに（笑）正直、マイクロサービスに伴う失敗談なら話が尽きないですよ（笑）
スモールチームこそがプロダクティビティの源泉
白石: 8年中4年間、技術的負債を返しながらも、新しいサービスをどんどん生み出している。そのプロダクティビティはどうやって生み出しているのでしょう？
中出: そこは一貫して数名のスモールチームで開発しているから、じゃないかと思います。そうすることでチームごとに意思決定が行えます。それぞれのチームが、周りを気にせずに自分たちのプロダクトに集中できるようにするのは、私の役割ですね。
白石: でもチームが多くなると、今度はそれはそれで大変じゃないですか。チームのそれぞれにマネージャーが必要になりますよね。
中出: はい、マネージャーの確保は非常に重要です。なので私たちは、「このまま行くと数年後にはマネージャーが何人必要になる」など逆算して、マネージャーの採用や育成を行っていますね。
白石: スモールチームや採用のあたりとか、非常に興味深い話がたくさん有りそうです。ここらへんはまた別途お話を伺いたいところですね。では本日のインタビューはこれくらいにしたいと思うのですが、最後にエンジニア読者の方々に対してお伝えしたいこととかありますか？
中出: そうですね…マネーフォワードは事業も好調に成長しており、新しいサービスもどんどん生まれています。そんな中課題もどんどん生まれていくわけで、それらを解決していく日々は非常にエキサイティングです。自身を成長させるためにチャレンジを望んでいる人にとっては、面白い職場だと思います。
渋谷: 今回はバックエンドの話ばかりでしたけど、フロントエンドの話もしたいですね。言語や領域は関係なく、プロダクト開発の全てに関わりたいエンジニアにも活躍いただける環境になってきています。基盤系サービスが整った上で、ゼロイチのサービス開発もやっていきたいんですよね。そういうゼロイチを素早く実現できる環境づくりも、今後整えていきたいなと思っています。
Expert’s Voice
今回印象に残ったのは、とにかくマイクロサービス化の苦労話。「失敗談なら話して尽きない」というお話なので、そのうち飲みながらでも伺いたいと思った（笑）
それにしても、Ruby on RailsからGo言語への移行という話を伺うのは、トレタに引き続いて2社目。筆者はRailsもGoも疎いので知らなかったが、大きなトレンドになっているのだろうか？
そして「Tech Company Internals」としては、技術的負債を返しながらも新しいサービスをどんどん生み出す生産性の源泉をぜひとも深く探りたいと感じた。またそのうち必ずやお話を伺うことになると思う。
