バクラク最古参プロダクトで重ねた技術投資を振り返る

バクラク最古参プロダクトで重ねた技術投資を振り返る 2026/03/17：Web Frontend Night — Retrospective Decision ypresto (@yuya_presto)

ypresto © LayerX Inc. LayerX バクラク事業部 (2024-01〜) プロダクト開発部債権債務チーム Software
Engineer "フロントエンド" をよりよくしてます 2

フロントエンドVision © LayerX Inc. 4

「バクラク債務管理」= バクラクシリーズ最古参のプロダクト © LayerX Inc. 5

債務管理というプロダクトの課題 © LayerX Inc. 開発の結果としての重複請求書、経費精算、カード明細、売掛... × 会計ソフトに合わせた仕訳のレイアウト × 仕訳の様々な条件分岐
= 多数の微妙に異なる実装実装コストとエンバグの増大型の不整合、テスト不足、不必要な手続き的操作 6

What we did © LayerX Inc. 7

UIテストの導入 © LayerX Inc. Why: FE起因のクリティカルなエンバグを減らしたい Decision: Playwrightによる UIテストを導入し、"ハッピーパス"
を網羅する How QAチームの基盤の再利用 (Page Object等) チームへのPlaywrightのハンズオン QAメンバーが用意したテストケースの仕分けと実装 8

UIテストやってどうだったか反省 © LayerX Inc. Outcome: シフトレフトの達成テストの実装コスト (B.C.: Before
Claude) QA用repoと実装repoの独立による弊害 CIの独立、テストコードに対する要件の違い根付かせるためには組織や文化まで巻き込む 9

仕訳ドメインの抽出 © LayerX Inc. Why: 重複実装によるコストを減らしたい財務・会計ドメインのルールは本質的に堅い (仕訳というデータ構造、補完ロジック、UI) 請求書、経費精算、カード明細、売掛、あらゆるお金の出入りは仕訳
という表現に落ちる Decision: リプレイスまで持ち越さず、データ構造とドメインロジックの整理から着手 How 仕訳に関わるデータ構造・ドメインロジック・UI部品の抽出と単体テスト Storybookの導入によるデザインのパターン網羅数1000行あるコンポーネントの分解 10

https://speakerdeck.com/ypresto/living-with-state © LayerX Inc. 11

仕訳ドメインの抽出やってどうだったか反省 © LayerX Inc. Outcome: 仕訳部分の拡張コストの削減、他チームでの開発コスト削減抽象化は「いつ」やるのかはとても難しい早すぎても遅すぎてもダメ未来が完全に読めるなら先にできる
本質的に同一にしたいもの、同一の構造であるものは、それでも見極めておいた方が良い 12

Agentic 式年遷宮 © LayerX Inc. Decision: Coding Agentを使って、Vue->Reactへのリプレイスを行う Why 1:
de facto、基盤から外れることによるコスト社内コンポーネントライブラリ、テスト基盤、ライブラリ更新、といった基盤投資レガシーコードのコピペ増幅による品質の低下 Why 2: プロダクトの理想にブレーキを掛けない「投資されないことによるコスト」は、変更を続ける限り発生 13

Agentic 式年遷宮 How © LayerX Inc. 開発の停止をせず、Vue→Reactへ追加の変更も自動変換する Skill化して、チーム内外へ横展開チームメンバーへ意思表示、外堀を埋めて
PdMにお願いしてロードマップに載せていただいた 14

Agentic 式年遷宮やってどうだったか反省 © LayerX Inc. Outcome: Coding Agentによるリプレイスの実証、Skill化による横展開パイロットテスト時点で見積もった期間よりも延長
Coding Agent "完璧" よりも 80点が得意デザインやタイミングといった、FEに関わることがらが苦手品質保証の方法が難しい Agent-eraのテストとQAのあり方は、まだ議論中不確実だからこそ、早めに巻き込む UI is dead? 「未知の未知」なこともある 15

道のりの振り返り © LayerX Inc. UIテストの導入 → リファクタリング対象の外側へのテスト追加仕訳ドメインの抽出 → 移行コストの削減
Agentic 式年遷宮 → プロダクトの理想が技術負債でNo Goにならないようにすべての技術的な意思決定は途中経過 React移行は見据えていたが、それもオプションの1つ 16

技術的な意思決定 #とは © LayerX Inc. ビジネスの不確実性 x 技術上の制約・トレードオフの管理例：今、木を切るか、斧を研ぐか
"Tidy First?" by Kent Beck 将来のオプション (開発の選択肢) を増やすならばTidyする攻めるときは意志を持って説得をいつ、なぜ、攻めるか 18

技術的な意思決定、課題解決はなくならない © LayerX Inc. 大きめのリファクタリングの判断などの意思決定は人間 Coding Agent-eraでもバランスの判断は人間軸を持って判断していこうプロダクトの技術的な意思決定は、すべて繋がっている 20

バクラク最古参プロダクトで重ねた技術投資を振り返る

バクラク最古参プロダクトで重ねた技術投資を振り返る

ypresto

More Decks by ypresto

Other Decks in Technology

Featured

Transcript