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
23k
freee申告の税額計算を支える技術 / freee tech day 2023
mosa
April 19, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
今から始めるClaude Code入門〜AIコーディングエージェントの歴史と導入〜
nokomoro3
0
180
Processing Gem ベースの、2D レトロゲームエンジンの開発
tokujiros
2
130
私の後悔をAWS DMSで解決した話
hiramax
4
210
JSONataを使ってみよう Step Functionsが楽しくなる実践テクニック #devio2025
dafujii
1
530
Namespace and Its Future
tagomoris
6
700
複雑なフォームに立ち向かう Next.js の技術選定
macchiitaka
2
140
Deep Dive into Kotlin Flow
jmatsu
1
350
Navigating Dependency Injection with Metro
zacsweers
3
990
AIコーディングAgentとの向き合い方
eycjur
0
270
旅行プランAIエージェント開発の裏側
ippo012
2
910
チームのテスト力を鍛える
goyoki
3
290
Flutter with Dart MCP: All You Need - 박제창 2025 I/O Extended Busan
itsmedreamwalker
0
150
Featured
See All Featured
The Invisible Side of Design
smashingmag
301
51k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Music & Morning Musume
bryan
46
6.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
840
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
YesSQL, Process and Tooling at Scale
rocio
173
14k
The World Runs on Bad Software
bkeepers
PRO
70
11k
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
How GitHub (no longer) Works
holman
315
140k
Producing Creativity
orderedlist
PRO
347
40k
Context Engineering - Making Every Token Count
addyosmani
3
49
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