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
コンパウンドスタートアップにおける フロントエンド技術選定のこれまでとこれから
Search
tatane
February 28, 2024
Technology
4
2.8k
コンパウンドスタートアップにおける フロントエンド技術選定のこれまでとこれから
2024/02/28 TechBrew in 東京 登壇資料
tatane
February 28, 2024
Tweet
Share
More Decks by tatane
See All by tatane
ひとりで頑張らないオンボーディング
tatane616
11
2.9k
LayerXのフロントエンドの現状の課題と理想の技術戦略
tatane616
8
3.9k
Other Decks in Technology
See All in Technology
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
330
『Firebase Dynamic Links終了に備える』 FlutterアプリでのAdjust導入とDeeplink最適化
techiro
0
140
Platform Engineering for Software Developers and Architects
syntasso
1
520
CDCL による厳密解法を採用した MILP ソルバー
imai448
3
160
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
180
AIチャットボット開発への生成AI活用
ryomrt
0
170
OTelCol_TailSampling_and_SpanMetrics
gumamon
1
220
Taming you application's environments
salaboy
0
200
Lexical Analysis
shigashiyama
1
150
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
10
1.2k
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.2k
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
KATA
mclloyd
29
14k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
The Language of Interfaces
destraynor
154
24k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
506
140k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Music & Morning Musume
bryan
46
6.2k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Transcript
© LayerX Inc. コンパウンドスタートアップにおける フロントエンド技術選定のこれまでとこれから 2024/02/28 TechBrew in 東京 @tatane616
© LayerX Inc. 2 • 加藤 健太 (@tatane616) • 株式会社LayerX
バクラク事業部 エンジニア • 2022年7月に入社して以来、 「バクラク申請・経費精算」の開発に従事 • 2019年にSaaS事業会社に新卒入社し、 現職に至るまで主にフロントエンド領域を担当 • LayerXに入社後ほとんどVue.jsしか書いてない (ので、社内のReact事情は解像度低いです。免責…) 自己紹介 自己紹介
© LayerX Inc. 3 • LayerX バクラク事業部を例とした、事業戦略と組織体制にマッチした技術選定について • Vue.jsとReactが共存するプロダクト開発組織について •
余談:Vue2(Nuxt2)→Vue3(Nuxt3)のリアル ※ 特定技術が一般的にどうこうというよりは、 あくまでもLayerXという会社での1事例として見ていただけるとうれしいです! 今回のLTで話すこと 今回のLTで話すこと
目次 Agenda • バクラクシリーズについて • バクラクとReact • バクラクとVue.js • Vue.jsとReactが共存する開発組織
• これからのバクラクの技術選定
バクラクシリーズについて コンパウンドスタートアップとは?
© LayerX Inc. 6 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 事業紹介 バクラク事業 企業活動のインフラとなる法人支出 管理(BSM)SaaSを開発・提供
Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン
© LayerX Inc. 7 バクラクシリーズについて
© LayerX Inc. 8 「コンパウンドスタートアップというLayerXの挑戦」 から、「コンパウンドスタートアップとは」 • 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供 • 部署でサービスを区切るのではなく、データを中心にサービスを統合する
• プロダクト間の連携の良さそのものがプロダクトである • 複数のプロダクトを管理、ローンチするケイパビリティを持つ つまり、開発組織として次のような特徴が強くなる • 開発リソースに対してプロダクト数が多くなる • UXの統一も含め、プロダクト間のシームレスな連携が必要 ◦ それに伴い、プロダクトを横断する機能開発プロジェクトが発生しやすい コンパウンドスタートアップ バクラクシリーズについて
© LayerX Inc. 9 バクラクシリーズについて まだ見ぬ新規プロダクトがたくさん! プロダクト間の連携が重要
© LayerX Inc. 10 現在のプロダクトの技術スタック React (Next.js) • バクラクビジネスカード (Next.jsは利用せず)
• バクラク請求書発行 Vue.js (Nuxt) • バクラク請求書受取・仕訳 • バクラク申請・経費精算 • バクラク電子帳簿保存 • バクラク共通管理 • 共通ファイルアップロード画面 バクラクシリーズについて
11 © LayerX Inc. 初プロダクト誕生から今までのフロントエンド的な転換点 バクラクシリーズについて 2021年1月 バクラクとして 初のプロダクト リリース(Vue2)
2022年8月 初のReactプロダクト リリース 2023年7月 初のVue3移行完了 2023年8月 今後の型となるReact/Next.js プロダクトリリース 今
バクラクとReact
© LayerX Inc. 13 新規開発時の Vue.js or React の意思決定 悩んでVue.jsのままにしたケース
• バクラク電子帳簿保存 • 意思決定のタイミングで、プロダクトに関わる法改正まで約2週間しかなかったこともあり、不確実性を 下げて既存メンバーが慣れている技術スタック&既存資産(コンポーネント)活用で爆速開発したかった バクラクとReact 悩んでReactにしたケース • バクラクビジネスカード • Vue2時代に、propsやVuexでうまく型があたらないなどのペインが大きくなってきており、 TypeScriptの恩恵を十分に受けたいモチベーションが高まっていた • 会社としてReactの採用事例をつくっておきたかった
© LayerX Inc. 14 React/Next.js での新規プロダクトの型作り • バクラク請求書発行 • React/Next.js
での新規プロダクト開発がスタートし、コンパウンドスタートアップとして今後連続し てプロダクト開発を続けるために「今後Reactでプロダクト開発をするときの”型”をここで整備しよう」 というモチベーションがあった • 別枠で進んでいたデザインシステムをReactで実装に落とし込んだり、フロントエンドアプリケーション のモノレポ化にチャレンジし始めたりしている 詳しくは 「Next.js App Router を例に考える、技術選定・技術との距離感」 バクラクとReact
バクラクとVue.js
© LayerX Inc. 16 • 「Vue2とTypeScriptの相性の悪さ」や「2023年末のVue2のEOL」などが主な理由 • React移行案もあったが、以下の理由からVue3へ移行する意思決定に ◦ 移行コストが大きかった
▪ 移行対象のアプリケーションではフロントエンドで多くのロジック(コンポーネントに密結合) を持っていたり、Vue.jsやそのUIライブラリに依存した細かい挙動の実装が多かった ◦ 移行期間中に新規機能開発をストップすることが厳しい ▪ 別のライブラリへの移行中に並行して機能開発するのは困難で、冷静に事業ロードマップを 見た時に機能開発よりReact移行を優先するのは開発者のエゴの域を出ないと思われた ◦ 既存実装でも型エラーなどが多く、React移行する場合でもVue3を経由したほうが安全 詳しくは 「バクラクの Vue3 移行戦略と詰まったポイント」 Vue3移行時のモチベーションと意思決定 バクラクとVue.js
© LayerX Inc. 17 実際にVue3移行してみて よかったこと • 開発者体験が明らかに改善した ◦ TypeScriptとの相性改善
(Vue3.3からはコンポーネントのGenericsも) ◦ HMR、build高速化 (Vite) • 機能開発を並行してすすめることができ、事業成長を止めなかった 困っていること • Vue2時代から使っているライブラリ(bootstrap-vue)の利用箇所はVue3の恩恵を受けにくい ◦ ほぼ全てのページで利用しているUIライブラリのため、剥がすのに労力がかかる… バクラクとVue.js
© LayerX Inc. 18 実際にVue3移行してみて 気づいたこと • 型が効くようになっても、開発生産性向上やバグの抑制が思うように実現できないところがあった ◦ そういったホットスポット的な箇所は、利用技術関係なく、そもそものコンポーネント設計や
実装が複雑で認知負荷が高いことが原因だとあらためて認識した バクラクとVue.js
Vue.jsとReactが共存する開発組織
20 © LayerX Inc. (再掲) 初プロダクト誕生から今までのフロントエンド的な転換点 Vue.jsとReactが共存する開発組織 2021年1月 バクラクとして 初のプロダクト
リリース(Vue2) 2022年8月 初のReactプロダクト リリース 2023年7月 初のVue3移行完了 2023年8月 今後の型となるReact/Next.js プロダクトリリース 今 Reactで開発し始めて2年弱が経過
© LayerX Inc. 21 Vue.jsとReactが共存するようになって2年弱 よかったこと • 会社としてキャッチアップするトピックの幅が広がった • 採用の間口が広くなった(React経験者が圧倒的に多い)
• 既存資産を活かしづらいので、結果としてゼロベースでの改善/Bet Technologyがやりやすかった • 型の効いたプロダクト開発の良さを社内に広めることができた 困っていること • プロダクトをまたぐ開発でのコンテキストスイッチが大きい ◦ バクラク事業部では全員がfront/backendを書き、機能単位でプロダクトをまたいで開発 • 全てのプロダクトで利用できる共通コンポーネントライブラリを作りづらい • 別のライブラリを使っているプロダクトチーム間でのお悩み相談をしづらい Vue.jsとReactが共存する開発組織
これからのバクラクの技術選定
© LayerX Inc. 23 現状を振り返ると 継続したいこと • TypeScriptを活用した開発生産性・メンテナンス性の高いコード • 新規プロダクト開発時の型や共通資産の(全員での)ブラッシュアップ
◦ 「Bet Technology」 かつ 「Be Animal」 (LayerXの行動指針)なチャレンジ 改善したいこと • 異なるライブラリを使うプロダクト間のコンテキストスイッチ ◦ 今後もしばらくは複数プロダクトを横断で開発する組織体制は変わらない雰囲気 • Vue2時代から使っているライブラリの利用箇所はVue3の恩恵を受けにくい ◦ ただし、剥がすにはVue3移行かそれ以上に工数がかかりそう これからのバクラクの技術選定
© LayerX Inc. 24 これからのバクラクの技術選定 方針 • 新規プロダクトはReact(with Next.js)でつくる •
既存のVue.jsプロダクトも可能なかぎりReactに移行していく ◦ ただし、事業ロードマップ的に現実的な移行計画の準備が大前提 • 共通基盤の実装はReactを前提としておこなう ◦ フロントエンドのモノレポ化も実験的に進んでおり、既に一部Reactのpackageがある ◦ スタイルはTailwind CSSで共通化しているが、スタイルに閉じないものはやはり UIライブラリ(React)で作るのが楽 これからのバクラクの技術選定
© LayerX Inc. 25 Why React? • 自分たちでBe AnimalにBet Technologyな技術選定をしやすい
◦ ReactはUIライブラリ、Vue.jsはフレームワーク的な性質がある。UI部分以外を委ねられてい ることによって、自分たちでチャレンジングな技術選定をやりやすくなる力学がはたらく • Goのバックエンド開発者との相性が良い ◦ バクラクのバックエンドはGoで、全員がフロントエンドも実装する GoのSimplicityな思想はReactのSimpleな思想にマッチする • LayerXのフロントエンド採用候補者との相性が良い ◦ Factとして、LayerXのフロントエンドの技術課題はReactで書かれている割合が高い • PMF以降の、保守性・スケーラビリティを重要視するバクラクのフェーズにマッチしている ◦ Reactのmodularな思想や単方向データフローは、認知負荷削減やリファクタリングを促進し、 アプリケーションの耐用年数を伸ばしてチューニングしやすくする これからのバクラクの技術選定
© LayerX Inc. 26 まとめ 技術選定は事業戦略や組織体制から考える • 「コンパウンドスタートアップ」かつ「流動性の高い組織」では以下の項目が重要となる ◦ あらゆる面で連携性の高いプロダクトを複数管理できること
◦ プロダクトをまたいだときのコンテキストスイッチが低いこと • バクラク事業部のような開発組織では、複数ライブラリ・フレームワークの共存はデメリットの方が強い ◦ が、例えば1つのプロダクトを固定メンバーで磨き込むような体制であればその限りではない • Reactも、ライブラリとしての良し悪しというよりはメンバーや事業との相性やタイミングが大きい ◦ Vue.js(Vue3)自体に大きな不満はなく、開発スピードが落ちたりバグにつながるのは、 あくまでも自分たちの書き方が悪いということを再確認できた まとめ
© LayerX Inc. 27 We're hiring! • LayerX(バクラク)では 「フロントエンドLead」と「フロントエンドEnabling」を募集しています!! ◦
フロントエンドLead ▪ プロダクトチームのフロントエンド開発をLeadする ◦ フロントエンドEnabling ▪ プロダクト横断の「フロントエンドギルド」をLeadし、各プロダクトチームがフロントエンド的 な改善活動をやりやすくするためにEnabling(環境整備やサポートなど)活動をする • カジュアル面談お待ちしています!! LayerX OpenDoor [検索] お待ちしてます!