Vue.jsを8年間使ってきた会社が今考えていること

2025年10月25日に開催された Vue Fes Japan 2025 で使用した登壇スライドです。

8年間にわたるVue.jsプロジェクトの運用を通して見えてきた、Store設計・データフローの複雑化・型定義の課題を整理し、SOLID原則（SRP / DIP）をベースにしたシンプルな設計の考え方を紹介しています。

「なぜ状態管理の設計が重要なのか？」を、実際の事例を交えながら振り返った発表です。

Transcript

1. 1 Vue Fes 2025 Vue.jsを8年間使ってきた 会社が今考えていること
2. 2 Studioについて 会社と私について 01
3. 01 Studioについて © 2025 Studio, inc. 3 Introduction Koya Saito フロントエンドエンジニアとして2018年からStudioに在籍(7年目) Studioのサービス開始のタイミングから参加して、 EditorやCMS, Workspaceなどだいたいの機能は何かしら触れてきた 現在は、 プロジェクトのモノレポ化を着手中 Vue.jsは1系から使用
4. Web Design Platform for allCreators. 世界中の人たちが創造性を発揮できる未来を目指して コードを書かずに多彩な表現ができるノーコード Webプラットフォームをつくっています。 01 Studioについて © 2025 Studio, Inc. 4
5. 01 Studioについて © 2025 Studio, Inc. 5 About 8年物のVue.jsのプロジェクト 2018 I Joined Vue1 Vuex JavaScript コード 4万行 2025 Vue3 Pinia & Vuex TypeScript コード 52万行
6. 01 Studioについて © 2025 Studio, Inc. 6 About エンジニアにアンケートしてみた 2018 I Joined Vue1 Vuex JavaScript コード 4万行 2025 Vue3 Pinia & Vuex TypeScript コード 52万行 ダブスタな実装 Vuex剥がしたい 潜在的なエラーに気づけない 複雑怪奇なデータフロー 歴史を知らないといじれない
7. 01 Studioについて © 2025 Studio, Inc. 7 About エンジニアにアンケートしてみた 2018 I Joined Vue1 Vuex JavaScript コード 4万行 2025 Vue3 Pinia & Vuex TypeScript コード 52万行 実装方針が統一されていない Vuex剥がしたい 潜在的なエラーに気づけない 複雑怪奇なデータフロー 歴史を知らないといじれない
8. 01 Studioについて © 2025 Studio, inc. 8 今日話すこと でかいアプリはStoreの設計が大事
9. 9 実際の事例について データマイグレーション実施とバグの発生について 02
10. 02 実際の事例について © 2025 Studio, Inc. 10 Feature プロジェクトのデータが 構造上の限界に当たり データの構造変更を実施 巨大なプロジェクトのパフォーマンスが著しく落ちていたため、 プロジェ クトとデザインのデータを分けるマイグレーション処理を一部プロジェ クトに適用開始 今回の事例としては、 これが全てのデザインデータの更新処理に影響 するという部分がわかればOK Project Pages Page Page Page Design Design Design Before After Designs Design Design Design Project Pages Page Page Page
11. 02 実際の事例について © 2025 Studio, Inc. 11 Incident 「操作内容が消える」 お問い合わせが届いた データマイグレーション済みのプロジェクトにて、 「エディターでの操作内容が消える/保存されない」 というお問合わせ が届いたが、 怪しいデータ構造はわかったものの再現方法が不明だった また、 あたりを付けようにも対象コンポーネントが多くStoreの構造が複雑で全体像の把握が大変難しい状態だった Components (100箇所~) Store Database いずれかの経路で不正な リクエストが混入
12. 02 実際の事例について © 2025 Studio, Inc. 12 巨大なスコープを持つ課題の解決 マイグレーション後のプロジェクトで たまにデータが消失するので直して Me AI
13. 02 実際の事例について © 2025 Studio, Inc. 13 巨大なスコープを持つ課題の解決 Me AI
14. 02 実際の事例について © 2025 Studio, Inc. 14 巨大なスコープを持つ課題の解決 マイグレーション後のプロジェクトで たまにデータが消失するので直して Me AI 指示が曖昧 エラーの再現方法が不明 → 構造の把握から順番に進める 100ファイル以上が対象
15. 02 実際の事例について © 2025 Studio, Inc. 15 巨大なスコープを持つ課題の解決 構造の把握 詳細調査1 詳細調査2 原因の特定 修正 PR作成 調査結果を レポート化 ・・・ ここでエラー内容を見せる 対象となるファイルの抽出 規模に応じて調査を分割
16. 16 事例からの学び AIを複雑な事例で利用する方法 Storeの在り方 03
17. 03 事例からの学び © 2025 Studio, inc. 17 そもそもの問題はAIの性能ではなく 設計が悪いのがいけない
18. 03 事例からの学び © 2025 Studio, inc. 18 Storeの設計が悪かった
19. 03 事例からの学び © 2025 Studio, inc. 19 StoreのGood/Badから学ぶ
20. 03 事例からの学び © 2025 Studio, Inc. 20 Point 1 - Bad Practice Bad: 同じ画面という 理由でまとめたStore 画面が同じ、 似た構造の関数なので一つのStoreにまとめてある コードが増えてくるにつれて、 変数の関連性がわかりにくくなってくる
21. 03 事例からの学び © 2025 Studio, Inc. 21 Point 1 - Good Practice 関心事ごとにStoreを分ける 1つのStoreに1つの関心事を持たせる 画面が同じ、 似た構造の関数でまとめるのではなく、 役割や関心事が同 じ方向を向いているかでまとめるべき
22. 03 事例からの学び © 2025 Studio, Inc. 22 Point 2 - Bad Practice Bad: actions内で 値の生成も含んでしまっている actions内で新規の値の生成と値の格納の両方を行っている この処理をテストするにはStoreを動かして検証しないといけない
23. 03 事例からの学び © 2025 Studio, Inc. 23 Point 2 - Good Practice 値の生成はStoreの外部に Storeは状態管理に徹底させる 値の生成はStoreの外部に置いてテストしやすく Store側では値の生成に関するロジックを持たないようにし、 動作環境 での値の管理に徹底させる
24. 03 事例からの学び © 2025 Studio, Inc. 24 Point 3 - Bad Practice Bad: Component側で watchして別のactionsを叩く 依存関係が複雑になり、 挙動の追跡が難しくなる このComponentが呼ばれない画面の場合があると厄介 あるいは、 v-forなどで複数個描画されるComponentに記載されてい た場合はwatchが複数回発火されてパフォーマンスが落ちる
25. 03 事例からの学び © 2025 Studio, Inc. 25 Point 3 - Good Practice watchを消して 副作用はactions内で完結 Store内で処理が完結するようにする Store間での副作用が発生するものはActionsで完結するようにする
26. Extra 次のステップへ進むために... 今回のPoint1 ・ 2は、 SOLID原則の 「単一責任の原則 （SRP） 」 をベース に説明しました 
 Point3は、 UIからStoreへの依存を整理する 「依存関係逆転の原則 （DIP） 」 の考え方に近い内容でした さらに設計の考え方を深めたい方には、
 「リーダブルコード」 と 「リファクタリング （第2版） 」 をおすすめします スライドタイトル © 2025 Studio, inc. 26
27. 27 これからの話とまとめ ネクストアクションについて 04
28. 04 これからの話とまとめ © 2025 Studio, Inc. 28 Next Action 根本的な解決は始まったばかり 今回、 バグについては修正, リリースまでたどり着いたものの、 根本的にデータフローが複 雑な問題については現在取り組んでいる課題である。 型定義の再設計 モノレポ化進める Storeをなるべく無くす ドキュメントの充実化
29. 04 これからの話とまとめ © 2025 Studio, Inc. 29 Conclusion まとめ 8年かけてアプリケーションのデータフローが限界に 複雑なバグが発生したが、 ステップを分割することでAIの能力を生かすことができた が、 根本的な原因はStoreの設計にある Storeの設計について Storeの値は関心事ごとに切り分けること Storeを状態管理に専念させるために、 値の生成, 格納を分ける 抜け穴実装はバグの温床なので0にする PR PR - We’re Hiring! 最近、 Studioは盆栽がイケてるオフィスに移転しました。 採用, イベント積極的にやってます。 気軽にお声がけください！ Recruit Site