Vue.js / Nuxt.js から React / Next.js へ移行した話と２年経って残った課題

Transcript

1. リプレイスしたあと、実際どう？システム再構築への挑戦 LT ⼤会 Vue.js/Nuxt.js から React/Next.js へ 移⾏した話と２年経って残った課題 株式会社キカガク 代表取締役会⻑ 吉崎 亮介
2. ⾃⼰紹介 株式会社キカガク 代表取締役会⻑ 吉﨑 亮介 エンジニアとしての学⽣時代 出⾝：舞鶴⾼専 / 京都⼤学⼤学院 世界最⼤級の学会（化学⼯学系）にて若⼿最優秀賞を受賞 ~ 23 歳 新卒で株式会社 SHIFT 配属：社⻑室（社⻑直下で新規事業/R&D を担当） 24 歳 株式会社キカガクを創業（現在：社員数 70 名超） 社会⼈向けに AI を含めた先端技術の教育を提供 現在まで累計 80,000 名を超える受講⽣ 25 歳 ~ 現在 東京⼤学で講義を担当 情報系の⼤学院⽣向けに AI の基礎から実装まで紹介 26 歳 ~ 31 歳 株式会社エイチームの社外取締役 上場企業での経営の意思決定に関与 31 歳 ~ 現在 1991 年⽣まれ 31 歳 京都府出⾝ 趣味：サウナ
3. 今回の話の前提 ベンチャー企業がプロダクト開発を１から始める時に起きたこと • 売上は⼈⼒オペレーション（講義）で⽴っていて、それをスケールさせるための プロダクト開発であるため、時間的に余裕がある ← 本当は最重要 • リプレイスの変⾰にはトップダウンとボトムアップがあり、今回はトップダウン 先に結論 • トップダウン⽅式は現状の改善から⼊らず、新しい技術選定を使って 新しいプロダクトを横で作り、その利点をプロダクトチームに伝えて変える 起点 トップダウン⽅式 起点 起点 起点 ボトムアップ⽅式 既存 新規 詳細はこちら Vue.js & Nuxt.js から React & Next.js へ移⾏した理由
4. 起：Vue.js/Nuxt.js で初のプロダクト開発を開始 Django (Python) や Rails (Ruby) の MTV/MVC デザインパターンとの相性 • Vue.js/Nuxt.js は社内でよく使われていたデザインパターンと相性が良かった • 社内へ知⾒のある⼈が⼊ってきた ← よくあるパターン • React の JSX は書きにくいし、読みにくい印象を持っていた ← 慣れの問題 既存 経験の少ないチームでの開発戦略 C 向け静的（SSG） → 社内向け動的（SSR）→ C 向け動的（SSR)
5. 承：成⻑とともに⾒えてくる課題 Django (Python) や Rails (Ruby) の MTV/MVC デザインパターンとの相性 • Vue.js/Nuxt.js は社内でよく使われていたデザインパターンと相性が良かった • 社内へ知⾒のある⼈が⼊ってきた ← よくあるパターン • React の JSX は書きにくいし、読みにくい印象を持っていた ← 慣れの問題 既存 成⻑と共に遭遇した問題* • ページ単位で SSG/SSR を切り分けたかった（SSR の LP がパフォーマンス低） • TypeScript での開発を前提としないとチーム開発でエラーが多発 → 品質低 経験の少ないチームでの開発戦略 C 向け静的（SSG） → 社内向け動的（SSR）→ C 向け動的（SSR) * Nuxt.js が Ver. 2 のときの話です
6. 転：⼩さなプロダクトとは⾔えど… ⼀度動き始めたものを変えることは容易ではない • 技術選定を変更しても UX が改善されるインパクトが⼤きいか不明 → UX が改善されなかったときには無駄なコストと負債だけが残る最悪の展開 • 数少ないチームで新技術の調査と既存に対する新規機能開発の同時並⾏は困難
7. 新規事業を横に⽴てて技術調査の役割も兼ねさせた • 現状とは別チームで⾛らせることでメリットの部分だけを徐々に融合させた → 半年後に既存チームも Next.js へ変更を決定 → 約１年かけて Next.js へ移⾏を完了 • イノベーター理論の順番を守った変⾰ • 技術負債の解消は⼀朝⼀⼣ではできないため、 会社の⽂化に合わせた戦略が間違いなく必要 → 今回はエンジニアの創業者が推進したパターン 結：イノベーター理論を意識した負債の解消 ⼀度動き始めたものを変えることは容易ではない • 技術選定を変更しても UX が改善されるインパクトが⼤きいか不明 → UX が改善されなかったときには無駄なコストと負債だけが残る最悪の展開 • 数少ないチームで新技術の調査と既存に対する新規機能開発の同時並⾏は困難 既存 新規 詳細はこちら Vue.js & Nuxt.js から React & Next.js へ移⾏した理由
8. あれから２年：今も向き合う負債の問題 もっと難易度の⾼いところに課題があった • Firebase を前提としたことで成⻑痛に遭遇 • DB が Firestore の NoSQL で設計や 実装がスピードダウン • Auth もプロジェクトごとに分けられない → B 向けや C 向けなど複数アプリケーションの統合がややこしい 変更の難易度 Lv. 3 DB、Auth Lv. 2 ⾔語、Web フレームワーク Lv. 1 ディレクトリ構成
9. あれから２年：今も向き合う負債の問題 もっと難易度の⾼いところに課題があった • Firebase を前提としたことで成⻑痛に遭遇 • DB が Firestore の NoSQL で設計や 実装がスピードダウン • Auth もプロジェクトごとに分けられない → B 向けや C 向けなど複数アプリケーションの統合がややこしい 変更の難易度 Lv. 3 DB、Auth Lv. 2 ⾔語、Web フレームワーク Lv. 1 ディレクトリ構成 先⼈から伝えたいこと（屍を乗り越えて...!!） 最近は開発スピードを優先させるために Bubble などのノーコードもあるが コードを書く書かない問わず、DB と Auth は今後の成⻑に合わせられる 選定となるように慎重に選んでほしい...（切実） そして、開発スピードの要因はチーム⼈数が増えると⼤きく変わるのをお忘れなく
10. おまけ：最近ならこんなアーキテクチャーかな？（主観） AI を使うのが主流になる前提でのアーキテクチャー設計が不可⽋ メイン DB： PostgreSQL(RDB) • マルチテナント対応 • ベクトル検索サポート 推し Auth：Azure Active Directory App：App Service Azure OpenAI Service とのシームレスな連携 推し User Azure OpenAI Service 検索 Cognitive Search Grounding Chat サブ DB： Cosmos DB (NoSQL) チャット 履歴保存 FAQ ファイル Blob Storage (JSON など) コーポレート GUI で 編集 例）エンタープライズサーチ 開発する要件によって さらなる作り込みが 必要となりますが プロトタイプなら このぐらいから始めてみては いかがでしょうか？
11. キカガクではエンジニアを⼤募集！ 成⻑期のプロダクト開発に関わりたい⽅、ご応募お待ちしています！ 会社の雰囲気を知れば絶対に⼊社したくなる！ → キカガクカンパニーデック