Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
freee申告の税額計算を支える技術 / freee tech day 2023
Search
mosa
April 19, 2023
Programming
1
24k
freee申告の税額計算を支える技術 / freee tech day 2023
mosa
April 19, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
Honoを使ったリモートMCPサーバでAIツールとの連携を加速させる!
tosuri13
1
180
プロダクトオーナーから見たSOC2 _SOC2ゆるミートアップ#2
kekekenta
0
220
並行開発のためのコードレビュー
miyukiw
0
180
AtCoder Conference 2025
shindannin
0
1.1k
MUSUBIXとは
nahisaho
0
130
AIによる高速開発をどう制御するか? ガードレール設置で開発速度と品質を両立させたチームの事例
tonkotsuboy_com
7
2.3k
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
280
0→1 フロントエンド開発 Tips🚀 #レバテックMeetup
bengo4com
0
570
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
1
730
Grafana:建立系統全知視角的捷徑
blueswen
0
330
例外処理とどう使い分ける?Result型を使ったエラー設計 #burikaigi
kajitack
16
6.1k
責任感のあるCloudWatchアラームを設計しよう
akihisaikeda
3
180
Featured
See All Featured
The Language of Interfaces
destraynor
162
26k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
110
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.3k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.4k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.4k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
230
The Spectacular Lies of Maps
axbom
PRO
1
520
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
0
210
A better future with KSS
kneath
240
18k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
The Illustrated Children's Guide to Kubernetes
chrisshort
51
51k
Transcript
freee申告の 税額計算を⽀える技術 mosa 2023年4⽉16⽇
ここに円に切り抜いた画像を入れてく ださい mosa Software Engineerとして数社を経て2022年 にfreee⼊社。現在はfreee申告の開発を担 当。 Webアプリケーションエンジニア
freee申告
税額計算とは • [16]と[17]を⼊⼒すると[18]は⾃動で計算されて表⽰される
税額計算とは • 他の帳票にも値は連携され更新先や更新元が複数あることも
項⽬間の依存は⼤量にある... •
どのように税額計算をしているか • RelationalTreeという税額計算をするためのモジュールを作成 • RelationalTreeは名前の通り項⽬間の関係を⽊構造として動的に組み ⽴てながら計算を⾏う
RelationalTreeの動作例 A C D B 下記のような1項⽬を表す
項⽬Aをユーザーが⼿動で⼊⼒ A C D B 未到達 更新対象 差分あり 差分なし
⾊の意味 キュー
A(root node) をキューに詰める A C D B 未到達 更新対象
差分あり 差分なし ⾊の意味 キュー A
キューからAを取り出して計算 A C D B 未到達 更新対象 差分あり 差分なし
⾊の意味 キュー A • 今回はユーザーが A を⼊⼒したとしているのでAはユーザーの⼊⼒値となり、 差分ありになる
Aが差分ありなのでAに依存する項⽬ (B, C) を取得してキューに詰める A C D B 未到達
更新対象 差分あり 差分なし ⾊の意味 キュー A B C
A C D B 未到達 更新対象 差分あり 差分なし ⾊の意味
キュー A B C キューの先頭から B を取り出して計算 • 今回は計算の結果、差分があったとする • Bに依存している項⽬は無いので差分ありでもキューに詰める項⽬は無い
A C D B 未到達 更新対象 差分あり 差分なし ⾊の意味
キュー A B C キューの先頭から C を取り出して計算 • 今回は計算の結果、差分はなかったとする • Cに依存している項⽬はあるが差分は無いためキューに詰めない
A C D B 未到達 更新対象 差分あり 差分なし ⾊の意味
キュー A B C キューが空になったので計算処理を終了してDBに書き込む • 今までの計算によって得られた A, B の差分はメモリ上に保持してある
RelationalTree動作まとめ 1. 根 (root_node) となる項⽬の計算を⾏う 2. 計算前後で差分があるか確認し、差分がなければ終了する 3. その項⽬に依存している項⽬を取得してキューに詰める
4. キューにある先頭の項⽬について計算を⾏う (FIFO) 5. 2.に戻る
RelationalTree作成の背景 • 帳票が増えていく中で「1回のリクエストで税額計算に数⼗秒かか る」というパフォーマンス的な問題が発⽣ • ⼀項⽬ずつ⼿続き的に計算→保存を繰り返すことで DB の read/write
処理が膨⼤な量になってしまい結果として数⼗秒かかってしまった
RelationalTree作成後 • 問題を解決するためにRelationalTree は下記のアプローチをした ◦ メモリ上に計算過程の結果を保持し最後にまとめてwriteする ▪ → write回数の減少
◦ 差分が無い項⽬については依存する項⽬の再計算を⾏わない ▪ → 計算回数の減少 RelationalTreeの導⼊によって数⼗秒かかっていたリクエストが、遅く ても数秒以内に返ってくるようになった!
すごい!!!!
RelationalTreeの課題 • パフォーマンス最適化の余地 ◦ 動的に⽊構造を作成しているため read 処理が多い ◦ 部分⽊の計算が繰り返し⾛ることがある
◦ 同期的な計算が強制されてしまう • 計算結果の品質担保 ◦ 複数ユーザーが同時に触った時の挙動が担保されていない • 依存関係の表現⽅法 ◦ 依存関係が有向⾮巡回グラフであることを強制できていない
RelationalTreeの 改善は続く!
None