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
3
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
ハイテク休憩
sat
PRO
2
140
Jetpack Composeで始めるServer Cache State
ogaclejapan
2
160
コンテナセキュリティのためのLandlock入門
nullpo_head
2
320
どちらを使う?GitHub or Azure DevOps Ver. 24H2
kkamegawa
0
670
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
160
OpenShift Virtualizationのネットワーク構成を真剣に考えてみた/OpenShift Virtualization's Network Configuration
tnk4on
0
130
成果を出しながら成長する、アウトプット駆動のキャッチアップ術 / Output-driven catch-up techniques to grow while producing results
aiandrox
0
180
サイバー攻撃を想定したセキュリティガイドライン 策定とASM及びCNAPPの活用方法
syoshie
3
1.2k
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
150
サイボウズフロントエンドエキスパートチームについて / FrontendExpert Team
cybozuinsideout
PRO
5
38k
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
24
11k
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
520
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
327
38k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
95
17k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Facilitating Awesome Meetings
lara
50
6.1k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
96
4 Signs Your Business is Dying
shpigford
181
21k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
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 [検索] お待ちしてます!