こんにちは。Accounting Productsチームの渡部です。私は現在エンジニアとして仕事をしていますが、元々は経理の仕事をしていました。一見すると両者は全く異なる仕事に思われるかもしれませんが、現在はメルカリのAccounting Productsチームに所属し、どちらのバックグラウンドも活かす仕事をしています。この記事では、私のこれまでのキャリア変遷やメルカリAccounting Productsチームで働く醍醐味のほか、チームが抱える課題についても赤裸々に紹介します。

経理からエンジニアへジョブチェンジ、そしてメルカリへ

新卒で地元のガス会社へ入社

新卒で地元千葉県のガス会社に入社し、経理部で6年間働きました。経理部では決算や税務、有価証券報告書の作成など幅広い業務を経験しました。自分が作成した財務諸表が経営層の意思決定に関わるというインパクトの大きさから、やりがいを感じていました。

当時の経理部での仕事はアナログな側面が強く、紙の資料をベースとした押印業務や目視での確認作業が多かったため、より正確かつ効率的に仕事を進められないかと課題を感じていました。私はこうした業務への苦手意識が強かったため、効率化に向けてExcelを使って試行錯誤を重ねていました。

このような経験をするにつれ、自分が本当にやりたいことを自問するようになり、興味や関心が経理業務そのものから、バックオフィス業務の課題解決に移っていることに気づきました。そこから「自分でも便利なソフトウェアを作れるようになりたい」という願望が強くなり、プライベートの時間でプログラミングをはじめとしたITの学習をするようになりました。

プログラミング熱が高まり、受託開発会社へ転職

そこからはプログラミングの面白さに一気にのめり込み、IT業界もエンジニア職も未経験ではありましたが、受託開発企業にエンジニアとして転職をしました。

転職後1年が経過し、ようやくエンジニアとして自立できるようになった頃に、前職で感じていた「バックオフィスの業務課題を解決したい」という思いを改めて思い出しました。特に会計業務にはアナログな作業が多く、自身も課題として感じていたため、会計とエンジニアリングのバッググラウンドを活かし、こうした課題を解決していきたいという思いが沸々と湧き始めました。

会計×エンジニアリング領域を追求すべく、メルカリに入社

次の挑戦の場として選んだのがメルカリでした。メルカリは2014年頃に初めて出品したのをきっかけにずっと利用しており、とても好きなサービスでした。そんなメルカリで内製の会計システムを開発しているAccounting Productsチームの求人を見つけ、「ここしかない！」と思い応募しました。

最終的にメルカリを選んだ理由は、2点あります。まずは「顧客との近さ」です。ここで言う顧客というのは、メルカリの「お客さま」ではなく社内のメンバーです。内製のシステムであるため、利用者は常に社内にいます。成果物に対してすぐさまフィードバックをもらえ、スピーディーな改善サイクルを回せるというのは、非常に面白そうだと感じました。

次に「技術的な成長機会の多さ」です。これまで、エンジニアとして大量のトラフィックやデータを扱うシステムの経験はなかったため、メルカリという大規模サービスの一端を担うことで、技術的な学びを多く得られそうだと感じました。

エンジニアの枠を超え、大胆にチャレンジ

メンバーの裁量が大きなチーム

私が所属するAccounting Productsチームは、社内のお金の流れを可視化することをミッションとしています。お金の移動を伴うメルカリやメルペイのあらゆる事業と伴走しながら、経理チームがミスなく効率よく業務を推進できるようサポートするチームです。

業務内容としては、メルカリグループの新規事業の会計システム連携の検討、会計システムの新規機能の開発、運用・保守です。管轄下の会計システムは3つあり、これらを少数のメンバーで支えているため、一人ひとりの裁量が大きいのが特徴です。

メインの技術スタックとしては、Go, Kubernetes, GCPを利用しています。ただし、入社前からこれらの技術すべてに習熟していたメンバーはあまりいません。どちらかといえば、タスク遂行の都度、公式ドキュメントを読み込むなどしてキャッチアップしながら取り組んでいます。

1年がかりのGCPのリソース最適化

入社後半年がたった2023年初頭からGCPのコスト削減の取り組みに携わりました。運用している会計システムには、メルカリやメルペイ内のお金に関わる全取引データが集約されているため保持しているデータ量が多く、GCPのコストは社内のMicroserviceの中でもトップクラスに多い状況で、コストの削減が急務となっていました。Accounting Productsチームでは2名体制でこのプロジェクトを進め、私がCloud Spannerを、もう1名のメンバーはCloud Storageの最適化に取り組みました（Cloud Storageの取り組みの話はこちらが詳しいです）。

しかし、会計システムが扱うデータは法定に基づき保持期限が定められているため、コスト都合のみでデータを削除するわけにはいきません。経理や内部監査といったチーム外のステークホルダーと、コスト削減とオペレーションのバランスを取りながら折衝し、落とし所を見つけながらデータ削除のルールを策定しました。

いざSpannerのデータを削除し始めると、いくつもの問題に遭遇しました。例えば、他のMicroserviceから会計システムに想定し得なかった過去のデータが送られていることがわかり、データ削除の中断を余儀なくされました。このためにAPIやバッチの設計を見直しながら、発生した問題に1つずつ対処しました。

2023年12月にデータ削除とインフラの見直しが完了し、プロジェクトを完遂できました。結果として、会計システムにかかるGCPコストは約半減できました。自動化までは至っていないのですが、データ削除のルール策定とオペレーションの確立ができたことで、今後も少量の作業で定期的にデータを削除することが可能となりました。

この経験を通して、Cloud Spannerのデータ操作への理解が深まりました。削除処理は数週間かかる想定だったため、この間の本番環境への影響を最小限にするためにいくつかの方法を検討しました。結果として、テーブルの特性に合わせてPartitioned DMLによる削除とDataflowを用いた削除処理を使い分けるようにしました。こうした超大量データの操作を行う経験は、今後の業務においても役立つと考えています。

また、エンジニアではありますが、開発業務を超えて本プロジェクトに携われたのは良い経験となりました。特に、他チームと折衝に関わる機会は初めてでしたが、大きな組織でインパクトのある仕事をするためには密なコミュニケーションが必要なのだということを学びました。

I&Dが浸透。心理的安全性の高いチーム

Accounting Productsチームは多様なバックグラウンドを持つメンバーが集まっています。社内のAndroidチームから異動してきたエンジニア、通訳や秘書を経験したエンジニア、元々SaaS開発に携わっていたEMとPdMなど非常にユニークです。また、2025年春には新卒のメンバーも入社予定です。

毎週のバックログリファインメントでは、PdMが作成するバックログだけでなく、エンジニアの課題提起を発端としたバックログが多く作成されるのも我々のチームの特徴です。各々のメンバーが現状のシステムに満足することなく課題をチームに共有し、優先順位を付けて取り組んでいます。様々なバックグラウンドを活かしながら、オーナーシップを持ち同じゴールを目指せているため、とてもエキサイティングです。

各自がオーナーシップを持つとはいえ、些細なことでも疑問があればチームで議論し、よりよい解決策を見つけられるよう協力しています。全社で取り組んでいる Inclusion & Diversity（以下、I&D） がチームにも浸透しているため、相談や議論をする際の心理的安全性が高く保たれています。

チームではEM主導でI&Dに関するワークショップが定期的に開催されています。言語面での I&Dという観点では、現在のチームメンバーの国籍は全員日本ではありますが、毎日の定例会（デイリースタンドアップミーティング）を週に1度は英語で実施するなど、英語話者とのコミュニケーションも円滑にできるようメンバー全員で練習に取り組んでいます。

守りから攻めのAccounting Productsチームへ

一方で、チームには課題もあります。現在チームで抱えている案件は、事業サイドを発端とした案件や、システムの運用課題の解消など、どちらかと言えば「守り」の側面が強い案件が多いです。こうした取り組みは事業の推進には必須ではありますが、チームとしてはより「攻め」の仕事もしていきたいです。例えば、チームには会計マスタを扱う新システムの企画があり、一部の開発はされたのですがリリースまでは至っていません。他にも個人的には、経理チームに業務上の支障をヒアリングし解決を試みるなど、ステークホルダーの潜在的な課題に対してもアプローチしていきたいと思っています。

技術的にも課題を抱えています。例えば「データ量の増加によりデータベースへのクエリ時間が長期化している」、「監視が適切にできていない」など、ミドルウェアからインフラ領域の課題が多いです。こうした課題に対しても優先順位を付けながら、一つひとつ解決をしている最中です。

私がAccounting Productsチームで働く理由

私がAccounting Productsチームで働く上で大切にしていることは、疑問や意見を積極的に伝えるということです。先述の通り、チームは少人数でありながら複数のサービスの開発、運用をしているため、メンバーが能動的に業務を遂行する必要があります。結果として、自分の意見が会計システムの品質にダイレクトに影響することもあります。プレッシャーはありつつも、自身の判断による成功や失敗から得られる学びは多く、今後のエンジニアとしてのキャリアに活かせることばかりです。

技術的にも非常にチャレンジングな環境です。会計システムにはAPIを通してあらゆる事業の会計データが送信されるため、事業の成長に伴ってリクエスト数が急増しています。今では、月間で数億のリクエストがされています。こうした大規模データを扱うシステムを開発、運用できるのはAccounting Productsチームやメルカリならではの経験だと思います。これらのサービスを支えるGo, Kubernetes, GCPなど社内で主に使用されている技術は、それぞれが非常に深く学びがいがあります。

また、担当システムだけでなくメルカリ全体のアーキテクチャと構成されるMicroserviceを深く知れるというのも面白さの1つです。メルカリグループが提供するサービスのMAUは2,300万人です。こうした大規模サービスが、どのようなアーキテクチャで実現されているか、どういった課題があるのか、その一端を知ることができます。

入社の動機である「会計とエンジニアリングのバッググラウンドを活かしたい」という思いは、着実に実現しつつあるものの、まだ発展途上でもあります。社内にいる「会計」や「エンジニアリング」それぞれの領域のプロフェッショナルから学びながら、チームや会社により大きなインパクトを出せるように様々なチャレンジをしていきたいです。さらに多様なスキルやバックグラウンドをもった仲間とも働いてみたいですね。「正確性と効率性を兼ね備えた日本一の内製会計システム」を開発するのが個人的な野望です。

編集・撮影：瀬尾陽（メルカン編集部）