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

Retrospective Decision - LayerX Web Frontend Night

https://layerx.connpass.com/event/383492/

Transcript

1. バクラク最古参プロダクトで重ねた技術投資を振り返る 2026/03/17：Web Frontend Night — Retrospective Decision ypresto (@yuya_presto)
2. ypresto © LayerX Inc. LayerX バクラク事業部 (2024-01〜) プロダクト開発部 債権債務チーム Software Engineer "フロントエンド" をよりよくしてます 2
3. © LayerX Inc. 3
4. フロントエンドVision © LayerX Inc. 4
5. 「バクラク債務管理」= バクラクシリーズ最古参のプロダクト © LayerX Inc. 5
6. 債務管理というプロダクトの課題 © LayerX Inc. 開発の結果としての重複 請求書、経費精算、カード明細、売掛... × 会計ソフトに合わせた仕訳のレイアウト × 仕訳の様々な条件分岐 = 多数の微妙に異なる実装 実装コストとエンバグの増大 型の不整合、テスト不足、不必要な手続き的操作 6
7. What we did © LayerX Inc. 7
8. UIテストの導入 © LayerX Inc. Why: FE起因のクリティカルなエンバグを減らしたい Decision: Playwrightによる UIテスト を導入し、"ハッピーパス" を網羅する How QAチームの基盤の再利用 (Page Object等) チームへのPlaywrightのハンズオン QAメンバーが用意したテストケースの仕分けと実装 8
9. UIテストやってどうだったか 反省 © LayerX Inc. Outcome: シフトレフトの達成 テストの実装コスト (B.C.: Before Claude) QA用repoと実装repoの独立による弊害 CIの独立、テストコードに対する要件の違い 根付かせるためには組織や文化まで巻き込む 9
10. 仕訳ドメインの抽出 © LayerX Inc. Why: 重複実装によるコストを減らしたい 財務・会計ドメインのルールは本質的に堅い (仕訳というデータ構造、補完ロジック、UI) 請求書、経費精算、カード明細、売掛、あらゆるお金の出入りは 仕訳 という表現に落ちる Decision: リプレイスまで持ち越さず、データ構造とドメインロジックの整理から着手 How 仕訳に関わるデータ構造・ドメインロジック・UI部品の抽出と単体テスト Storybookの導入によるデザインのパターン網羅 数1000行あるコンポーネントの分解 10
11. https://speakerdeck.com/ypresto/living-with-state © LayerX Inc. 11
12. 仕訳ドメインの抽出やってどうだったか 反省 © LayerX Inc. Outcome: 仕訳部分の拡張コストの削減、他チームでの開発コスト削減 抽象化は「いつ」やるのかはとても難しい 早すぎても遅すぎてもダメ 未来が完全に読めるなら先にできる 本質的に同一にしたいもの、同一の構造であるものは、 それでも見極めておいた方が良い 12
13. Agentic 式年遷宮 © LayerX Inc. Decision: Coding Agentを使って、Vue->Reactへのリプレイスを行う Why 1: de facto、基盤から外れることによるコスト 社内コンポーネントライブラリ、テスト基盤、ライブラリ更新、といった基盤投資 レガシーコードのコピペ増幅による品質の低下 Why 2: プロダクトの理想にブレーキを掛けない 「投資されないことによるコスト」は、変更を続ける限り発生 13
14. Agentic 式年遷宮 How © LayerX Inc. 開発の停止をせず、Vue→Reactへ追加の変更も自動変換する Skill化して、チーム内外へ横展開 チームメンバーへ意思表示、 外堀を埋めて PdMにお願いしてロードマップに載せていただいた 14
15. Agentic 式年遷宮やってどうだったか 反省 © LayerX Inc. Outcome: Coding Agentによるリプレイスの実証、Skill化による横展開 パイロットテスト時点で見積もった期間よりも延長 Coding Agent "完璧" よりも 80点が得意 デザインやタイミングといった、FEに関わることがらが苦手 品質保証の方法が難しい Agent-eraのテストとQAのあり方は、まだ議論中 不確実だからこそ、早めに巻き込む UI is dead? 「未知の未知」なこともある 15
16. 道のりの振り返り © LayerX Inc. UIテストの導入 → リファクタリング対象の外側へのテスト追加 仕訳ドメインの抽出 → 移行コストの削減 Agentic 式年遷宮 → プロダクトの理想が技術負債でNo Goにならないように すべての技術的な意思決定は途中経過 React移行は見据えていたが、それも オプション の1つ 16
17. 技術的な意思決定 #とは 未来に向けたソフトウェアのデザイン © LayerX Inc. 17
18. 技術的な意思決定 #とは © LayerX Inc. ビジネスの不確実性 x 技術上の制約・トレードオフ の管理 例：今、木を切るか、斧を研ぐか "Tidy First?" by Kent Beck 将来のオプション (開発の選択肢) を増やすならばTidyする 攻めるときは意志を持って説得を いつ、なぜ、攻めるか 18
19. 要はバランス © LayerX Inc. 19
20. 技術的な意思決定、課題解決はなくならない © LayerX Inc. 大きめのリファクタリングの判断などの意思決定は人間 Coding Agent-eraでもバランスの判断は人間 軸を持って判断していこう プロダクトの技術的な意思決定は、すべて繋がっている 20
21. すべての技術的な意思決定は途中経過。 判断基準を持ち、積み重ねよう。 © LayerX Inc. 21