Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
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
23k
freee申告の税額計算を支える技術 / freee tech day 2023
mosa
April 19, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
S3 VectorsとStrands Agentsを利用したAgentic RAGシステムの構築
tosuri13
4
220
30分でDoctrineの仕組みと使い方を完全にマスターする / phpconkagawa 2025 Doctrine
ttskch
3
640
「文字列→日付」の落とし穴 〜Ruby Date.parseの意外な挙動〜
sg4k0
0
330
モダンJSフレームワークのビルドプロセス 〜なぜReactは503行、Svelteは12行なのか〜
fuuki12
0
150
全員アーキテクトで挑む、 巨大で高密度なドメインの紐解き方
agatan
8
11k
俺流レスポンシブコーディング 2025
tak_dcxi
1
2.2k
20251127_ぼっちのための懇親会対策会議
kokamoto01_metaps
2
260
jakarta-security-jjug-ccc-2025-fall
tnagao7
0
100
Duke on CRaC with Jakarta EE
ivargrimstad
0
340
Socio-Technical Evolution: Growing an Architecture and Its Organization for Fast Flow
cer
PRO
0
120
Reactive Thinking with Signals and the new Resource API
manfredsteyer
PRO
0
140
GeistFabrik and AI-augmented software development
adewale
PRO
0
220
Featured
See All Featured
The Invisible Side of Design
smashingmag
302
51k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.5k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
RailsConf 2023
tenderlove
30
1.3k
Writing Fast Ruby
sferik
630
62k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
990
A better future with KSS
kneath
239
18k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
1
63
Build your cross-platform service in a week with App Engine
jlugia
234
18k
GitHub's CSS Performance
jonrohan
1032
470k
BBQ
matthewcrist
89
9.9k
Optimizing for Happiness
mojombo
379
70k
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