新規プロダクトで 爆速開発を実現するために意識したこと

下記イベントの登壇資料です。
https://techplay.jp/event/888763

Transcript

1. 新規プロダクトで 爆速開発を実現するために意識したこと 株式会社LayerX 松本 駿 2023.2.21
2. 2 (C) 2023 LayerX Inc. 自己紹介 経歴 2019年株式会社リクルート 新卒入社 不動産情報サイトSUUMOの新規機能開発やパフォーマンス改 善、技術的負債の解消などを経験。 9ヶ月の副業を経て、 2022年2月株式会社LayerX 中途入社 バクラクビジネスカードとバクラク電子帳簿保存の バックエンドとフロントエンドを担当。 趣味 車, サウナ Github: toshi1127 Twitter: toshi11274
3. 3 (C) 2023 LayerX Inc. バクラク事業 企業活動のインフラとなる法人支出管 理（BSM）SaaSを開発・提供 LayerXの提供プロダクト Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 PrivacyTech事業 パーソナルデータの利活用とプライバ シー保護を両立するソリューションの提 供
4. 圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。 (C) 2023 LayerX Inc.
5. 5 (C) 2023 LayerX Inc. 手作業が多くなりがちな支出管理業務のデジタル化を一気通貫でサポート 管理部門だけでなく、現場社員からも喜ばれる圧倒的な使いやすさにこだわっているため、ITツールが苦手な方でも安心して ご利用いただけます。 現場・全社の課題を解決 経理の課題を解決 経理/総務の課題を解決 回収 稟議 承認 データ 入力 仕訳/支払 データ作成 支払 保管/税務・監査対応 会計ソフト反映 デジタル受け取り 自動受け取り スマホ　・　Slack AI OCR 自動入力 API連携　・　自動出力 クラウド管理　・　電子帳簿保存
6. 6 (C) 2023 LayerX Inc. LayerXに入社後、2プロダクトの立ち上げを経験する中で、 爆速開発×安定稼働を実現するために意識したこと • ドメインロジックの実装など、本質的な部分に実装する時間を費やせること • 爆速開発したものでもバグが起きにくい • 開発に携わるメンバーが自然と効率よく開発できること 今日はなすこと
7. 7 (C) 2023 LayerX Inc. バクラク電子帳簿保存の立ち上げに途中からJoin 3つめのバクラクシリーズのプロダクト。 無料で始められる改正電子帳簿保存法に対応した書類保管サービス 現場・全社の課題を解決 経理の課題を解決 経理/総務の課題を解決 回収 稟議 承認 データ 入力 仕訳/支払 データ作成 支払 保管/税務・監査対応 会計ソフト反映 デジタル受け取り 自動受け取り スマホ　・　Slack AI OCR 自動入力 API連携　・　自動出力 クラウド管理　・　電子帳簿保存
8. 8 (C) 2023 LayerX Inc. • Join後すぐにリリースがあり、初期開発メンバーから主担当を引き継ぎ • バックエンドが得意なEngが中心だったこともありFEの改善の余地がある状態 • BEはGo, FEはVue(Options API)/Nuxt Join当時の開発体制
9. 9 (C) 2023 LayerX Inc. Join当時の開発体制 自身のスキル/プロダクトのフェーズ的にも技術的な挑戦をしやすい状況 →　他プロダクトの開発にもレバレッジが効くようなことを積極的に挑戦することを意識 • Join後すぐにリリースがあり、初期開発メンバーから主担当を引き継ぎ • バックエンドが得意なEngが中心だったこともありFEの改善の余地がある状態 • BEはGo, FEはVue(Options API)/Nuxt
10. 10 (C) 2023 LayerX Inc. 1. できるだけドメインロジックの実装など、本質的な部分に実装する時間を費やす ◦ コード生成の仕組みを導入 ▪ openapi-generator ▪ typescript-vue-apollo 2. 質を担保するため、コードを把握しやすく、テストを書きやすい状態を作る ◦ Composition APIでコンポーネントとビジネスロジックを分けられるようにする バクラク電子帳簿保存の立ち上げで工夫したこと
11. 11 (C) 2023 LayerX Inc. 3. スピード開発したものでもバグが起きにくい ◦ Veturでtemplateの型チェックをすることで、Propsの漏れや型の違いを防ぐ ◦ Vuexである必要がない部分は、swrv(Reactのswrのvue版)を採用 ▪ 少ないコード量で、データ取得における状態管理, 再取得, キャッシュが容易に ▪ より型安全に（Vuex3だとVue Component側で方の恩恵を受けられない バクラク電子帳簿保存の立ち上げで工夫したこと
12. 12 (C) 2023 LayerX Inc. 学びを最大化するために、知見を共有することで 他の既存プロダクトでもComposition API, swrvなど導入が進んだ FEの共有会を開催して知見の共有 • すでにあるアーキテクチャを絶対視するのではなく、積極的に改善 • 成功事例を共有して、他プロダクトにも横展開して改善
13. 13 (C) 2023 LayerX Inc. • 爆速開発 ◦ nuxt dev server立ち上げやbuild, lintに時間がかかる ◦ リソースを共通化していないのでプロダクト横断で同じ実装があり改修するのが手間 ◦ フォームを実装するケースが多いが、実装が辛い（バリデーション/変更有無の判定） • 安定稼働 ◦ TypeScript の型システムを活かしきれない ▪ Store への安全でタイプセーフなアクセス ▪ Component型エラーの検出 ◦ Vue2からVue3に上げるために少なくないコストがかかる(年末にEOL ◦ テストが書かれておらず、リファクタリングが難しい ▪ QAチーム/Autifyによるテストが中心 ▪ 重要な部分にはテストか書いていたが、あえてカバレッジをあげることを目指さな かった バクラク電子帳簿保存を運用してみて 爆速開発と安定稼働の観点イマイチだった点
14. 14 (C) 2023 LayerX Inc. バクラクビジネスカードの立ち上げにJoin 用途別にカード発行可、明細データも即時連携で経理処理をラクにする「次世代の法人カード」 バクラクビジネスカードの５つの特長 与信枠が限定的で高額決済ができない... 最大1億円以上の利用枠、1回数千万円の決済も可能 カードの枚数が限られている... 利用者ごとの柔軟な設定ができない... 枚数無制限。何枚でも発行可能 カード毎の金額上限など柔軟な設定 事前申請・承認機能で統制を強化 * 今冬提供予定 プリペイドだと一部の加盟店で使えない... クレジットカードだから加盟店の制限なし 世界中のVisa加盟店で利用可能 明細データを即座に閲覧可能 一部会計ソフトへのAPI連携、CSV出力にも対応 利用明細の連携が遅く、会計処理が面倒... ① ② ③ ④ ⑤ よくある従来の法人カードの課題
15. 15 (C) 2023 LayerX Inc. 「バクラクビジネスカード」のシステム概要 バクラクビジネスカードには、二つのフロントのアプリケーションが存在 • お客様にご利用いただくサービス画面 • 社内の管理業務（審査, 与信, 入金処理など）を行う管理画面
16. 16 (C) 2023 LayerX Inc. 「バクラクビジネスカード」の技術構成(FE) • Typescript • React • Apollo GraphQL • Vite • Vitest • Turborepo
17. 17 (C) 2023 LayerX Inc. なぜVueではなく、Reactを採用することを決めたのか 他Engメンバーが慣れているという点では Vue に優位性がある 下記の2点を鑑みて、採用を決定 • TypeScriptの恩恵を受けられる • 既存プロダクトで利用しているOSS(BootstrapVueなど) が Vue 3 非対応で 既存のリ ソースを再利用することが厳しい
18. 18 (C) 2023 LayerX Inc. 社内で初のReact採用にあたり生産性を出せるように意識したこと 学習コストが上がりスケジュールや品質に影響が出ないように • デザイナーメンバーとのペアプロを実施 ◦ Vueとの差分を説明しながら小さめの開発案件を一緒に対応 • コンポーネントのスタイリングにはCSS Modules, React-Bootstrapを使用 ◦ 開発体験を既存プロダクトの実装(Sass, BootstrapVue)に寄せる ◦ 既存のSassの資産を流用 • 既存プロダクトのコンポーネントと似た命名、使用感になることを意識 • 他Engメンバーが開発に着手する前に汎用コンポーネントやHooks, Contextなどを充実させてお くことで、各Engが独立して機能実装できるように React × TypeScriptでデータの単方向性やタイプチェックによって 品質を保ちやすく堅牢性が高い状態に
19. 19 (C) 2023 LayerX Inc. ビルドシステムにViteを採用 • create-react-app ◦ create-react-appはフルメンテナが不在で、今後の保守に懸念 ◦ Viteに比べて、dev server立ち上げやbuildが遅い • Next.js, Remix ◦ プロダクトの性質上、SSR/SSG/ISRする仕組みが不要
20. 20 (C) 2023 LayerX Inc. 設計にFragment Colocationを採用 • コンポーネントとコンポーネントで使うデータの依存関係が明確になるため、保守・改修がしやすくなる ◦ Overfetchingしてしまう ◦ コンポーネントのPropsの型をGraphQLのModelの型にしてしまい、UnderFetchingになる • コンポーネントで必要なデータに変更が生じたときに、Fragmentを修正するだけで修正が容易 ◦ 画面単位にQueryを書いていたりすると、Queryの修正箇所が多くなる
21. 21 (C) 2023 LayerX Inc. Monorepoを採用（FE） • 既存プロダクトの開発や管理画面を開発する中で ◦ リポジトリを跨いで同じコードを実装することがあり面倒 ◦ 標準化がしにくい（ESlintなど） ◦ ライブラリのバージョン管理が大変 • 多くのUIパーツ/ロジックを共通化できそうな部分が多かった ◦ 結果、ファイル数がサービス画面 : 管理画面 : 共通 = 5 : 3 : 2とかなり共有化できた 開発に携わるメンバーが自然と効率よく開発できるように 今後はテストを充実させて、自然と質も担保しやすい状況を目指す
22. 22 (C) 2023 LayerX Inc. まとめ • スピード開発×安定稼働を実現するために意識したこと ◦ ドメインロジックの実装など、本質的な部分に実装する時間を費やせること ◦ スピード開発したものでもバグが起きにくいこと ◦ 開発に携わるメンバーが自然と効率よく開発できること • すでにあるアーキテクチャを絶対視するのではなく、積極的に改善をしよう • 成功事例を共有して、プロダクト横断のベースを底上げしよう
23. 23 (C) 2023 LayerX Inc. フロントエンドの現状の課題と今後の話 まだまだフロントエンドの現状の問題が沢山あります。 明日今後の技術戦略についての話があるので、興味ある方は参加ください！
24. 24 (C) 2023 LayerX Inc. PR - 絶賛採用中です！ - https://jobs.layerx.co.jp/ - カジュアル面談も受付中！ - https://open.talentio.com/r/1/c/layerx/pages/68950