Vue.js + TypeScriptによる 新規サービス開発の振り返り/frontend-looking-back

Meetup資料

Transcript

1. Vue.js + TypeScriptによる
 新規サービス開発の振り返り
 株式会社ラクス
 開発本部 第一開発部 UI開発課
 北嶋 初音

2. #RAKUSMeetup
 自己紹介
 • 北嶋 初音 / Hatsune Kitajima
 • 経歴
 ◦ 2016年4月：Web系のITベンチャーに新卒入社
 ◦ 2020年1月：ラクスに中途入社
 • 現在
 ◦ ラクス初のフロントエンドエンジニア
 ◦ 新規サービス（楽楽勤怠）の機能開発を担当
 ◦ フロントエンド組織のベース作り

3. #RAKUSMeetup
 楽楽勤怠
 • 2020年10月1日に無事リリース
 • 今後も新機能を続々追加予定

4. #RAKUSMeetup
 今日お話しすること
 楽楽勤怠の開発初期〜リリースまでの振り返り
 開発体制
 利用技術
 今後の開発

5. 開発体制

6. #RAKUSMeetup
 開発体制 - エンジニア
 • SPA（Single Page Application）を採用
 • FE・BEを分けて開発（社内初）
 FE
 画面表示
 BE
 Web API
 Ajax通信

7. #RAKUSMeetup
 開発体制 - 全体
 FEエンジニア(4)
 BEエンジニア(6)
 PdM(1)
 UIデザイナー(2)

8. #RAKUSMeetup
 開発体制 - 全体
 FEエンジニア(4)
 BEエンジニア(6)
 PdM(1)
 UIデザイナー(2)
 FE,BEを分けて開発

9. #RAKUSMeetup
 開発体制 - 開発フロー
 FEエンジニア
 
 画面実装
 BEエンジニア
 
 API仕様書作成
 UIデザイナー
 
 デザイン作成
 PdM
 
 要件仕様書作成
 BEエンジニア
 
 API実装

10. #RAKUSMeetup
 開発体制 - 開発フロー
 FEエンジニア
 
 画面実装
 BEエンジニア
 
 API仕様書作成
 UIデザイナー
 
 デザイン作成
 PdM
 
 要件仕様書作成
 BEエンジニア
 
 API実装
 ・FE,BEが並行開発
 ・APIは初めはモック
 ・実装後に繋ぎ込み

11. #RAKUSMeetup
 開発体制 - 良かった点
 • SPA
 ◦ 最小限のデータのやりとりでOK
 ◦ スムーズなUI/UXを実現できる
 • Web API
 ◦ SPAと相性が良い
 ◦ FEのモダンなフレームワークを利用しやすい
 ▪ 楽楽勤怠ではVue.js採用
 ◦ 再利用ができる
 ▪ PC版・スマホ版で同じAPIを呼べばOK

12. #RAKUSMeetup
 開発体制 - 良かった点
 • BE,FEを分けて開発
 ◦ それぞれの作業に集中できる
 ◦ FE的には
 ▪ デザインの再現、画面表示・動作に注力できる
 ▪ APIのインターフェースだけ把握しておけばOK
 ◦ BE,FEが並行開発できる
 ▪ 開発スピードが早い（工数削減）

13. #RAKUSMeetup
 開発体制 - 辛かった点
 • 開発フロー
 ◦ FEが要件仕様書・デザイン・API仕様書のすべてをウォッチする必要が あり、変更に気付けないときがある
 ◦ 【対応】ウォッチできる仕組みを作る必要がある
 ▪ 現状は変更者が忘れないように通知するしかない
 ▪ 例）チャットに自動投稿するなど

14. #RAKUSMeetup
 開発体制 - 辛かった点
 • 開発フロー
 ◦ デザインだけでは細かい挙動は読み取れない
 ◦ FEで要件仕様書・デザイン・API仕様書を組み合わせて、動作を想像し て実装する必要がある
 ◦ 実装者以外が動作の正当性を分からない（レビューできない）
 ◦ 【対応】画面仕様書を作成する
 ▪ 細かい動作について記載した資料を作る
 ▪ 実装前にデザイナーや要件定義者のレビューを挟む

15. #RAKUSMeetup
 開発体制 - 辛かった点
 • 開発フロー
 ◦ FEでAPI仕様書を参考にAPIモックを作成しなければならない
 ◦ localで各自JSONサーバーを立ち上げて対応
 ◦ 正常系・異常系の全パターン網羅などがつらい
 ◦ API変更時の出戻りが大きい
 ◦ 【対応】OpenAPIでモックサーバーを立てる
 ▪ npmかDockerで定義ファイルからモックサーバーを立てられない か調査中（参考：swagger-typescript-codegen）

16. 利用技術について

17. #RAKUSMeetup
 利用技術 - フロントエンド開発
 • Vue CLI（4.0.5）
 ◦ Babel
 ◦ TypeScript
 ◦ SCSS
 ◦ Vuex
 ◦ Vue Router
 ◦ Vuetify
 ◦ ESLint
 ◦ Prettier

18. #RAKUSMeetup
 利用技術 - 良かった点
 • Vue.js
 ◦ コンポーネント化
 ▪ 基底コンポーネントが再利用可能
 ▪ 開発が進むほど実装スピードが上がる
 ▪ PC版・スマホ版でも別スタイルを当てるだけで済む
 ▪ scopedなCSS記述が可能
 ▪ アトミックデザインとの相性が良い
 ◦ 高度なUI/UXの表現が可能

19. #RAKUSMeetup
 利用技術 - 良かった点
 • TypeScript
 ◦ 型指定で安全な開発が行える
 ◦ エディタの補完機能が効く
 ◦ ドキュメントとしても機能する
 ▪ 例）メソッドに型指定があると使い方が分かる

20. #RAKUSMeetup
 利用技術 - 辛かった点
 • TypeScript
 ◦ Vue.jsとの相性の悪さ、型が衝突する
 ◦ anyや!で型指定から逃げてしまっている所が多い
 ▪ 既存箇所は徐々に指定していくしかない
 ▪ 【対応】最終的にはlintではじく
 ◦ API仕様書の変更に気付けないと型定義がずれる
 ▪ 【対応】定義ファイルから型生成する仕組みを導入する
 ◦ enumの利用が推奨されていない
 ▪ 【対応】Union Types + as constに置き換える

21. #RAKUSMeetup
 利用技術 - 辛かった点
 • Vuex
 ◦ Storeで持つべきでない値を持ってしまっている
 ▪ グローバルな値なので、最小限にすべき
 ▪ 【対応】local変数に移動する
 ◦ 他画面でfetchした情報がクリアされておらず、別画面に影響を与えて いる
 ▪ 今までは遷移前に画面で利用したModuleの情報をクリア
 ▪ 【対応】画面で利用するModuleを画面呼び出し時にクリア

22. #RAKUSMeetup
 利用技術 - 辛かった点
 • Vue router
 ◦ 履歴管理が大変
 ▪ historyに積む？積まない？
 ▪ 【対応】画面仕様書に記載する
 ◦ URLのparamを直接参照していると、画面間を高速遷移時に別画面の 同名のparam値でAPIを叩いてしまう
 ▪ 【対応】ローカル変数に代入することで対応

23. #RAKUSMeetup
 利用技術 - 辛かった点
 • パフォーマンス
 ◦ SPAなので初期表示のパフォーマンスが悪い
 ▪ 特にテーブル（複数API、要素数が膨大）
 ▪ 【対応】要素の描画を段階的に行うことで回避
 ◦ 基底コンポーネントがリッチになるとパフォーマンスが劣化する
 ▪ 基底コンポーネントはVuetifyをラップしたもの
 ▪ 【対応】使っていない機能が多いので、オリジナルのものに置き換 えていくと良さそう

24. #RAKUSMeetup
 利用技術 - 辛かった点
 • テストコードがない
 ◦ リファクタリング時などにデグレが発生が検知できない
 ▪ 【対応1】テスト環境（jest）の導入
 ▪ 【対応2】自動テストの仕組みを作成（CI）
 ◦ テストを意識したコーティングになっていない
 ▪ Vueファイルにロジックを持ちすぎている
 ▪ 【対応1】helperファイルにロジックを移行
 ▪ 【対応2】Vue3.0への移行、ドメイン駆動思想の導入
 • Composition API

25. これからの開発

26. #RAKUSMeetup
 振り返り作業
 • FEチームでリリースまでの開発の振り返りを行なった
 ◦ 先ほどの辛かった点は振り返りで出たもの（全40件ほど）
 ◦ 各々がスプレッドシートに改善したい項目を記載
 ◦ 重要度・緊急度の2軸でHigh・Middle・Lowで評価
 ◦ 緊急度Highから対応していく予定

27. #RAKUSMeetup
 これからの開発
 • 新規開発・改善タスクを並行で進めていく
 ◦ 優先度は新規開発＞改善タスク
 • FEの新規開発にかかる時間はコンポーネント化により少なく なってくる想定
 ◦ BEよりも工数は小さくなるはず
 ◦ 前倒しで進めて改善タスクを対応したい

28. ラクスでは定期的にMeetupや
 勉強会を開催しています！
 ご参加お待ちしています！
 ラクス 
 中途 
 フロントエンドエンジニアも募集しています。