CARTA HOLDINGSで働くエンジニアたちにCTOが「最近なにやってるの？」をざっくばらんに聞いていくシリーズです。今回はCARTA HOLDINGS CTOのすずけん(@suzu_v)が、fluctのエンジニアへ話を聞きました。
インタビュアー：鈴木健太 Twitter ID @suzu_v（写真左）
株式会社CARTA HOLDINGS 執行役員CTO / 株式会社fluct取締役CTO。社内では「すずけん」と呼ばれる。「みんなのGo言語」「データ分析基盤入門」共著者。ウェブ技術全般に明るい。ポッドキャスト「ajitofm」をやっています。
インタビュイー：中村翔 Twitter ID @konsent_nakka（写真右）
fluctの会計システム(backbone)やそれに関連するシステムを担当している20卒エンジニア。開発オペレーションチーム所属。社内ではなっかーと呼ばれる。
事業のお金の流れを支えるシステム
鈴木健太（以下、すずけん）： なっかーは会計システムを担当してどれくらいになるんだっけ？
中村翔(以下、なっかー)： 新卒2年目のタイミングから担当しています。ちょうど丸2年くらい経ちました。
すずけん： なるほど、ありがとう。今日はその会計システム、社内で通称「backbone」と呼んでいるシステムまわりのことを中心に聞かせてください。まずbackboneは、fluctでどんな役割を担っているシステムか紹介してもらえますか？
なっかー： 一言でいうと、fluctの広告配信システムや関連するツールの利用料金など、全体的なお金の流れを管理して、会計処理が円滑に進むようにするシステムです。
すずけん： この「会計システム」という言葉だけを聞くと、入金や送金処理もやっているシステムだと思う人もいるかもしれないけど、そうではないよね？
なっかー： はい。入金など実際にお金を扱うのは経理部門で行っています。backboneはその手前の、 メディアさんへの支払い金額が最終的にいくらになるのかを確定するために、広告主さんやDSPごとのレポートなどをさまざまな条件で集計して、いくら入ってきていくら出ていくのか管理 しています。
すずけん： うんうん。お金の流れとしてみると、fluctがいろいろなシステムや事業者を経由して広告を出してお金を稼いで、それをまたメディアさんに収益として分配する部分の仕組みを担っているのがbackboneということだよね。
なっかー： はい、そうです。
すずけん： backbone = 背骨という名前のとおり、fluctのまさに背骨であり大事な仕組みだよね。わかりました、ありがとう。
事業成長とリアーキテクティング
すずけん： もう少し歴史的な経緯も聞いてみたいんだけど、そもそもbackboneはなぜ開発されたのか、どういう背景があったのか、わかる範囲で教えてもらえるかな。
なっかー： まずbackboneの前身となるシステムが2010年くらいにできたと聞いています。fluctのなかで手作業でやっていた会計業務を自動化するための小さな仕組みとしてスタートしました。ですがそのあと、fluctの事業も大きくなり運用や業務プロセスがシステムと合わなくなってきて、5年ほど前に作り直した結果誕生したのがbackboneです。
すずけん： 事業の成長に伴って、扱うプロダクトや取引先も増えるなかで最初のニーズに合わなくなって現backboneの形に生まれ変わったということだよね。 そして、このbackboneをさらに良くしようという取り組みも始めているんだよね。それはどういうきっかけだったんだろう。
なっかー： 前身のシステムからbackboneに置き換えたとき、 根本的なところまでは手が回っていなかったんです。変わっていくプロダクトにあわせたドメインの整理や、リアーキテクティングまでできればよかったのですが、例えばコード管理をgithubに移すとかAWSにするとか暫定的なアプローチに留まりました。 なので、そのときの負債をどうにかしたい というのがひとつです。さらに、5年前に比べてより成長して 複雑化した事業の形に合うように会計フローを改修する 必要があるという、この2軸がきっかけになっています。
すずけん： なるほど、ありがとう。複雑性の話が出てきたんだけど、実際にどういう困ったことが起きるのか、これを読んでいる人にもわかりやすい例ってあるかな？
なっかー： そうですね。アーキテクチャとして変更を加えづらい形になっているので、会計業務をやっているオペレーションの方々からの「新しいDSPと接続するのでこういうレポートのパターンに対応できるようにしてください」というリクエストや、決まった会計フローからはみ出て暫定的に会計処理をしなければいけない場合など、細かい会計の要求に対応するのにとても時間がかかってしまうというのがあります。
すずけん： 今のbackboneの構造だと、その課題に対して仕組みとして改善するのが難しいということなのかな。
なっかー： はい。まず、コード自体の変更が難しいんですね。メディアごとに細かく「こういうルールでやりたいです」というのが増えて複雑化しているなかで、それぞれの処理がどこにつながっているのか構造として理解するのが難しい状態です。そのためbackboneの開発やオペレーションに新しく加わった人が、そもそものルールを把握するだけですごく大変な状態になっています。
すずけん： なるほど。この話には、コード自体の読みづらさと業務ドメイン自体の複雑さ、ふたつの側面があるのかなと思ったんだけど、後者は変えようがない気もしていて。今回はシステムとして変えうる前者の課題にフォーカスした改修ということで合っている？
なっかー： はい、 コードの読みづらさが一番直したい部分 です。といいつつ、後者の業務ドメインの話についても、実は既存のルールの全体像を把握している人ってほとんどいなくて、それを知る唯一の手段がコードを読むしかない状態なんです。そういう意味で、 現在の会計フローはそもそも最適なのか、全体像を把握して見直しする ということも今回のスコープにいれています。
すずけん： そうかそうか。そもそもどういう支払いルールを設計するかという部分も変える余地があって、それを変えることでより綺麗にしようということなんだね。つまり、コード自体のリファクタリングやリアーキテクティングをやりながら、会計フローの理解を個人的にも深めて、フロー自体をよりスマートなものに変えていくっていうステップを踏むイメージだよね。
なっかー： はい、そうです。
すずけん： ふむふむ。ちなみに素朴な質問なんだけど、backboneについては最初に想像していたのと比べてどのくらい複雑だった？2年間backboneを触ってきて、コードや会計フローの理解も深まった今の状態からすると、そのあたりの感覚的な部分ってどうだったんだろう。
なっかー： そうですねー。もともと1-2人で開発されていたシステムだと聞いていたので、そこまで複雑でもないだろうと軽い気持ちで入ってみたら、尋常じゃない条件分岐の数とものすごい謎のコードがたくさんあって・・・。それでオペレーションの方々に「これはどうなってるんですか？」と聞いても 誰も把握していない状況で。なので、想像を絶するくらいには複雑でした。
すずけん： もともと作っていたエンジニアの人しか知らないルールだったり、コードのなかに知識として埋め込まれていたということなんだね。やっていけばいくほど、「なんだこれは？」とか、「これはどういうルールなんだろう？」というのが見えてきた。そしてそのままいくと、次に開発として入る人も同じように難しさを感じるから、 より認知負荷を下げられるようにわかりやすく作り直したい ということだよね。
なっかー： そうです。
こういう人にきてほしい
すずけん： backbone自体をよりよくしていこうというなかで、どんな人にこのチームに来てほしいですか？
なっかー： 複数の職種の方たちと話しながら、自分からいろんな人を巻き込んで仕事ができる方に来てもらえるとうれしいですね。会計システムという性質上、開発メンバーだけでやるということではなく、普段backboneを使っているオペレーションの方々や経理のメンバー、法律の改正が絡むと法務の方など、いろんな人と関わって一緒に作っていく仕事だからです。
すずけん： そうだよね。いわゆるこの会計システムやbackboneの領域って、fluctのセールスチームやオペレーションチームも使うし、お金というものを媒介として経理、法務・・・と本当に関わる人が多いよね。なっかーとしては、いろんな人と関わるときに意識していることってある？
なっかー： システムを普段使う人たちにとにかく丁寧に説明することを大事にしています。 例えば「こっちでやっておきます」みたいな、開発とオペレーション側を分断して考えてしまうというのはやってしまいがちなことかなと思うのですが、 backboneのように関わる人が多く、逆に開発する人が少ないという場合、一人で全部やるのはそもそも不可能なんですよね。なので、できるだけ関わる人たちにシステムの裏側の深掘りした部分もわかりやすいように説明するのを意識しています。 そうするとオペレーション側からシステムのことを考えた形で提案をしてくれたり、「そういえば、裏側でこういう仕組みで動いているって言ってたけど、こういうこともできるの？」という新しい提案をしてくれたりするんです。CARTAのバリューにも「 全誠実でいよう。 」というのがありますが、こういう部分でも大事だなと思いますね。
すずけん： めちゃくちゃいい話だね。ありがとう。最後に、なっかーとしてやりがいを感じるところや学びだなと思うポイントってどんなところにありますか？
なっかー： 学びという点ではふたつあるかなと思います。ひとつは技術的な面で、フロントからバックエンド、インフラも含めて全部見られるという点で経験できる幅が広いところですね。もうひとつは、弊社のフルサイクルな働き方により、先ほどのとおり複数の職種の方たちと関わることも多く、エンジニアだけでは見えない新しい視点がもらえて刺激になるという点です。
すずけん： うんうん。最近だと法律の改正、例えばインボイス制度などが始まるなかで、なっかー的にはそれはやりがいになったりするのかな？
なっかー： そうですね。大変ではありますが 挑戦ポイントも多いですし、技術的に成長できるタイミングにも来ているのでおもしろいです。 特にインボイス制度は非常に複雑な制度になっているのでそれをどのようにシステムに落とし込むか、そもそもビジネス的な面も総合して考えた時にどういう対応をするのが一番良いのか、など力量が試されるなと感じています。それに影響されて法律の勉強を始めたり、会計の資格をとってみようかなとか、いろいろ刺激になっています。
すずけん： 以前なっかーと「backboneみたいな会計領域に近いところって、fluctに関わらずどんなプロダクトにも必要な要素だから、ここでやったことはどんな事業でも役に立つよね」とか「ほかの業務システムやビジネスだったら、この仕組みをどう作るかを考えることがソフトウェア設計に効いてくるよね」っていう話をしたよね。そういう文脈では、法律とか会計の知識ってソフトウェアのデザインにいいフィードバックを生んでくれるしね。
なっかー： そう思います。
すずけん： いいね、やっていこう。なっかー、今日はありがとうございました。一緒に挑戦してみたい方、ぜひお待ちしています！
PR
fluctではエンジニアを積極大募集中です。
https://hrmos.co/pages/cartaholdings/jobs/fl-e19hrmos.co
まずはカジュアルにお話してみませんか？
