こんにちは、Corporate Solutions Engineeringグループ（以下CSE）で Product Managerをしている津田です。
僕が所属するCSEグループでは「組織づくりを技術で解決する」というミッションのもと、以下の3つのチームに分かれてそれぞれの業務を進めています。
- People Products・・・組織や人事評価関連のプロダクトを開発する
- Communication & Knowledge Products・・・社内の知識や情報の流通を促進する
- PR & Branding・・・コーポレートサイトなど、会社が運営するWebサイトを開発する
先日、その中で新たに「Accounting Products」というチームが誕生しました！
このチームでは、会計に関する課題を解決するため、「会計システム」と呼ばれるメルカリグループが運営する各サービスで会計・税務上の処理で必要となる数値を集計する仕組みを開発します。僕はこのAccounting Productsチームに所属しています。
そもそも僕はAccounting/Taxチームで、月次や四半期、年度での決算や税務申告のほか、国内・海外グループ会社との連結決算やIPO準備としての開示資料作成などを行っていました。そんな僕がなぜCSEのAccounting Productsチームのメンバーになったのかを、チーム誕生の経緯とともにご紹介させてください。
企業やサービスとともに成長してきた、メルカリの会計システム
メルカリグループが運営するサービスでは、日々たくさんのお金の動きがあります。
たとえば、フリマアプリ「メルカリ」で取引が完了すると、株式会社メルカリにとっては決済代行会社に対する債権と、お客さまに対する債務が発生します。つまり、メルカリでは決済や配送の手段、取引が進捗するタイミング、取引の内容、取引先との契約関係によってさまざまな商流が生まれるのです。
サービス開始当初からAccounting Productsチーム発足まで、メルカリではこういったお金の管理をするためにバックエンドエンジニアが会計・税務上の処理に必要な数値を集計するプログラムを開発していました。
さらにいうと当時、担当するバックエンドエンジニアはプロダクト開発と兼務で会計システムを開発しており、
- 1：月初に自動で集計プログラムが動く
- 2：経理で数値をチェック
- 3：追加で集計すべき事項があれば調査してフィードバック
- 4：プログラムを追加・修正
- 5：また月初に集計プログラムを動かす
といったサイクルで会計処理を行っていました。
2年ほど前には会計システム専任のバックエンドエンジニアがジョインし、数値の詳細な検証や集計プログラムの追加・修正、会計や内部統制の監査に迅速に対応できるようになりました。
ここでホッとしたのもつかの間、一方で、メルカリは組織として急拡大し、事業としても新プロダクトや新機能を次々とリリースしていました。つまり、あっという間に集計などが追いつかない状況になったのです。
その中で、僕と会計システムのバックエンドエンジニアはそれらのデータ構造を把握し、会計上必要となる要件を整理し、必要に応じて取引先と議論を重ねたりプロダクトの開発者にフィードバックしながら開発を進めていくという地道な作業を重ねていきました。
しかし、ある時期には会計処理に必要なデータ量が膨大になり、月次決算の締め日ギリギリまで集計が終わらないことも…。このとき、チーム内で相談し、会計システムのデータベースをAmazon Redshiftに移行し高速に計算が終えられるようにしました。これには、月次決算後に損益の詳細な推移分析が効率的に行えるという副次的な効果もありました。
また、メルカリの会計システムを振り返る上で最も大きな出来事と言えるのが、上場準備です。
このタイミングでは上場準備に加えて、会社法上の会計監査人による監査が義務付けられていました。そのため、取引先やお客さまへの債権債務を正確に集計できているか、集計の過程や結果について継続的に監査法人による監査を受けていたのです。
特に上場時は申請書類や投資家向け資料の作成スケジュールが厳しい中で、監査で初めて見つかる問題がないようにあらかじめ長時間かけて発見的統制・予防的統制の整備をしていました。おかげで、スムーズに決算の締めや監査対応を行うことができました。無事上場が承認されたときはチームメンバーと喜び合ったのをよく覚えています。
会計システムもマイクロサービス化に合わせた仕組みへ
改めて振り返ってみると、メルカリの会計システムは修正を重ねながら決算を乗り越えてきました。同時に、事業や会社の規模が拡大するにつれ、正確な決算を行うために解決すべき課題も見えてきたのです。その課題は「会計システムの開発者が、サービスの仕様やデータ構造を把握する」ことでした。
そもそも、サービスのデータから会計上で必要となる数値を集計するには「翻訳」が必要です。
例えば、データベースのこのカラムのこの値は会計上この項目を表し、この値がこれであれば税務上このような取扱いになるので別で集計する必要がある...など。これまでは会計システムのエンジニアがサービス側のエンジニアに随時ヒアリングすることで対処していました。しかし前述のとおり、組織拡大とさまざまな新プロダクト・新機能の開発やリリースで、会計システムの開発者への負担も徐々に大きくなっていきました。
そしてメルカリでは今、プロダクトの開発方針として「マイクロサービス化」を掲げています。これによって、メルカリの各サービスではコードだけでなくデータベースも分割されていく予定です。そうすると、会計システムのエンジニアが全サービスのデータにアクセスしたり開発や変更に追随したりすることは非常に難しくなります。
では、どうすればいいのか。組織内で話し合った結果、「会計システムもプロダクトと同様、マイクロサービス化の流れに沿うように仕組みを変更しよう」という方針となりました。そこで誕生したのがCSEのAccounting Productsチームです。
各サービスのデータから、必要な数値を集計する仕組み
Accounting Productsチームでは、メルカリの商流の中で取引先やお客さまに対する会計・税務上の債権債務が変動するタイミングで件数や金額を集計し、会社の決算や税務申告を行うコーポレートのAccounting/Taxグループに報告しています。
また、そこに付随する業務として、会計システムに対するIT内部統制やJ-SOX（内部統制報告制度）などの監査対応を行っていきます。
マイクロサービス化した各サービスからどのように必要な会計上のデータを集計しているのか。ここでは、各サービスから会計システムに必要なデータを送ってもらい、そこから会計や税務上で必要な数値を集計する仕組みへアーキテクチャ自体を変更することにしました。
このアーキテクチャを完成させるには、信頼性の高いシステムだけでなく、各マイクロサービスのエンジニアが会計に与える影響を迅速に検討できるようなガイドラインが必要です。
また、何か会計上の問題が起きたときに即座に検知するシステムなど、さまざまな仕組みを準備する必要があります。その仕組みをまさしく今、CSEのAccounting Productsチームで実装しようとしているところです。
Accounting Productsチームで、経理や財務の課題を解決したい
メルカリは2018年6月19日に東証マザーズに上場し、これからは四半期ごとに投資家の方々へ決算を開示していきます。また、上場企業として相応しい内部管理体制を整えていく必要があります。そこには会計システムだけではなく、様々な課題が存在しています。
私たちはコーポレートの各チームに対して定期的に課題のヒアリングを行っており、今後は経理業務の自動化や決算早期化、管理会計などにも取り組んでいきたいと考えています。
CSEのミッションは、経営課題をエンジニアリングで解決していくこと。Accounting ProductsチームもCSEの一員として、会計だけでなく、将来的には評価や人事関連など幅広い経営課題の解決に挑んでいきます。
僕個人としては、Accounting Productsチームはメルカリだけでなく、各企業でこれまで経理・税務に関わる人たちが感じていた課題を解決できる可能性を感じています。もしもそうなったら、経理や税務といった役割はどのように変わっていくのか。そんな未来が見たくて、Accounting Productsチームの1人として走り続けています。