Upgrade to Pro — share decks privately, control downloads, hide ads and more …

コンパウンドスタートアップにおける フロントエンド技術選定のこれまでとこれから

tatane
February 28, 2024

コンパウンドスタートアップにおける フロントエンド技術選定のこれまでとこれから

2024/02/28 TechBrew in 東京 登壇資料

tatane

February 28, 2024
Tweet

More Decks by tatane

Other Decks in Technology

Transcript

  1. © LayerX Inc. 2 • 加藤 健太 (@tatane616) • 株式会社LayerX

    バクラク事業部 エンジニア • 2022年7月に入社して以来、 「バクラク申請・経費精算」の開発に従事 • 2019年にSaaS事業会社に新卒入社し、 現職に至るまで主にフロントエンド領域を担当 • LayerXに入社後ほとんどVue.jsしか書いてない (ので、社内のReact事情は解像度低いです。免責…) 自己紹介 自己紹介
  2. © LayerX Inc. 3 • LayerX バクラク事業部を例とした、事業戦略と組織体制にマッチした技術選定について • Vue.jsとReactが共存するプロダクト開発組織について •

    余談:Vue2(Nuxt2)→Vue3(Nuxt3)のリアル ※ 特定技術が一般的にどうこうというよりは、   あくまでもLayerXという会社での1事例として見ていただけるとうれしいです! 今回のLTで話すこと 今回のLTで話すこと
  3. © LayerX Inc. 8 「コンパウンドスタートアップというLayerXの挑戦」 から、「コンパウンドスタートアップとは」 • 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供 • 部署でサービスを区切るのではなく、データを中心にサービスを統合する

    • プロダクト間の連携の良さそのものがプロダクトである • 複数のプロダクトを管理、ローンチするケイパビリティを持つ つまり、開発組織として次のような特徴が強くなる • 開発リソースに対してプロダクト数が多くなる • UXの統一も含め、プロダクト間のシームレスな連携が必要 ◦ それに伴い、プロダクトを横断する機能開発プロジェクトが発生しやすい コンパウンドスタートアップ バクラクシリーズについて
  4. © LayerX Inc. 10 現在のプロダクトの技術スタック React (Next.js) • バクラクビジネスカード (Next.jsは利用せず)

    • バクラク請求書発行 Vue.js (Nuxt) • バクラク請求書受取・仕訳 • バクラク申請・経費精算 • バクラク電子帳簿保存 • バクラク共通管理 • 共通ファイルアップロード画面 バクラクシリーズについて
  5. 11 © LayerX Inc. 初プロダクト誕生から今までのフロントエンド的な転換点 バクラクシリーズについて 2021年1月 バクラクとして 初のプロダクト リリース(Vue2)

    2022年8月 初のReactプロダクト リリース 2023年7月 初のVue3移行完了 2023年8月 今後の型となるReact/Next.js プロダクトリリース 今
  6. © LayerX Inc. 13 新規開発時の Vue.js or React の意思決定 悩んでVue.jsのままにしたケース

    • バクラク電子帳簿保存 • 意思決定のタイミングで、プロダクトに関わる法改正まで約2週間しかなかったこともあり、不確実性を 下げて既存メンバーが慣れている技術スタック&既存資産(コンポーネント)活用で爆速開発したかった バクラクとReact 悩んでReactにしたケース • バクラクビジネスカード • Vue2時代に、propsやVuexでうまく型があたらないなどのペインが大きくなってきており、 TypeScriptの恩恵を十分に受けたいモチベーションが高まっていた • 会社としてReactの採用事例をつくっておきたかった
  7. © LayerX Inc. 14 React/Next.js での新規プロダクトの型作り • バクラク請求書発行 • React/Next.js

    での新規プロダクト開発がスタートし、コンパウンドスタートアップとして今後連続し てプロダクト開発を続けるために「今後Reactでプロダクト開発をするときの”型”をここで整備しよう」 というモチベーションがあった • 別枠で進んでいたデザインシステムをReactで実装に落とし込んだり、フロントエンドアプリケーション のモノレポ化にチャレンジし始めたりしている 詳しくは 「Next.js App Router を例に考える、技術選定・技術との距離感」 バクラクとReact
  8. © LayerX Inc. 16 • 「Vue2とTypeScriptの相性の悪さ」や「2023年末のVue2のEOL」などが主な理由 • React移行案もあったが、以下の理由からVue3へ移行する意思決定に ◦ 移行コストが大きかった

    ▪ 移行対象のアプリケーションではフロントエンドで多くのロジック(コンポーネントに密結合) を持っていたり、Vue.jsやそのUIライブラリに依存した細かい挙動の実装が多かった ◦ 移行期間中に新規機能開発をストップすることが厳しい ▪ 別のライブラリへの移行中に並行して機能開発するのは困難で、冷静に事業ロードマップを 見た時に機能開発よりReact移行を優先するのは開発者のエゴの域を出ないと思われた ◦ 既存実装でも型エラーなどが多く、React移行する場合でもVue3を経由したほうが安全 詳しくは 「バクラクの Vue3 移行戦略と詰まったポイント」 Vue3移行時のモチベーションと意思決定 バクラクとVue.js
  9. © LayerX Inc. 17 実際にVue3移行してみて よかったこと • 開発者体験が明らかに改善した ◦ TypeScriptとの相性改善

    (Vue3.3からはコンポーネントのGenericsも) ◦ HMR、build高速化 (Vite) • 機能開発を並行してすすめることができ、事業成長を止めなかった 困っていること • Vue2時代から使っているライブラリ(bootstrap-vue)の利用箇所はVue3の恩恵を受けにくい ◦ ほぼ全てのページで利用しているUIライブラリのため、剥がすのに労力がかかる… バクラクとVue.js
  10. 20 © LayerX Inc. (再掲) 初プロダクト誕生から今までのフロントエンド的な転換点 Vue.jsとReactが共存する開発組織 2021年1月 バクラクとして 初のプロダクト

    リリース(Vue2) 2022年8月 初のReactプロダクト リリース 2023年7月 初のVue3移行完了 2023年8月 今後の型となるReact/Next.js プロダクトリリース 今 Reactで開発し始めて2年弱が経過
  11. © LayerX Inc. 21 Vue.jsとReactが共存するようになって2年弱 よかったこと • 会社としてキャッチアップするトピックの幅が広がった • 採用の間口が広くなった(React経験者が圧倒的に多い)

    • 既存資産を活かしづらいので、結果としてゼロベースでの改善/Bet Technologyがやりやすかった • 型の効いたプロダクト開発の良さを社内に広めることができた 困っていること • プロダクトをまたぐ開発でのコンテキストスイッチが大きい ◦ バクラク事業部では全員がfront/backendを書き、機能単位でプロダクトをまたいで開発 • 全てのプロダクトで利用できる共通コンポーネントライブラリを作りづらい • 別のライブラリを使っているプロダクトチーム間でのお悩み相談をしづらい Vue.jsとReactが共存する開発組織
  12. © LayerX Inc. 23 現状を振り返ると 継続したいこと • TypeScriptを活用した開発生産性・メンテナンス性の高いコード • 新規プロダクト開発時の型や共通資産の(全員での)ブラッシュアップ

    ◦ 「Bet Technology」 かつ 「Be Animal」 (LayerXの行動指針)なチャレンジ 改善したいこと • 異なるライブラリを使うプロダクト間のコンテキストスイッチ ◦ 今後もしばらくは複数プロダクトを横断で開発する組織体制は変わらない雰囲気 • Vue2時代から使っているライブラリの利用箇所はVue3の恩恵を受けにくい ◦ ただし、剥がすにはVue3移行かそれ以上に工数がかかりそう これからのバクラクの技術選定
  13. © LayerX Inc. 24 これからのバクラクの技術選定 方針 • 新規プロダクトはReact(with Next.js)でつくる •

    既存のVue.jsプロダクトも可能なかぎりReactに移行していく ◦ ただし、事業ロードマップ的に現実的な移行計画の準備が大前提 • 共通基盤の実装はReactを前提としておこなう ◦ フロントエンドのモノレポ化も実験的に進んでおり、既に一部Reactのpackageがある ◦ スタイルはTailwind CSSで共通化しているが、スタイルに閉じないものはやはり UIライブラリ(React)で作るのが楽 これからのバクラクの技術選定
  14. © 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な思想や単方向データフローは、認知負荷削減やリファクタリングを促進し、 アプリケーションの耐用年数を伸ばしてチューニングしやすくする これからのバクラクの技術選定
  15. © LayerX Inc. 26 まとめ 技術選定は事業戦略や組織体制から考える • 「コンパウンドスタートアップ」かつ「流動性の高い組織」では以下の項目が重要となる ◦ あらゆる面で連携性の高いプロダクトを複数管理できること

    ◦ プロダクトをまたいだときのコンテキストスイッチが低いこと • バクラク事業部のような開発組織では、複数ライブラリ・フレームワークの共存はデメリットの方が強い ◦ が、例えば1つのプロダクトを固定メンバーで磨き込むような体制であればその限りではない • Reactも、ライブラリとしての良し悪しというよりはメンバーや事業との相性やタイミングが大きい ◦ Vue.js(Vue3)自体に大きな不満はなく、開発スピードが落ちたりバグにつながるのは、 あくまでも自分たちの書き方が悪いということを再確認できた まとめ
  16. © LayerX Inc. 27 We're hiring! • LayerX(バクラク)では 「フロントエンドLead」と「フロントエンドEnabling」を募集しています!! ◦

    フロントエンドLead ▪ プロダクトチームのフロントエンド開発をLeadする ◦ フロントエンドEnabling ▪ プロダクト横断の「フロントエンドギルド」をLeadし、各プロダクトチームがフロントエンド的 な改善活動をやりやすくするためにEnabling(環境整備やサポートなど)活動をする • カジュアル面談お待ちしています!! LayerX OpenDoor [検索] お待ちしてます!