Unification of the middle scale services by Nuxt.js

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.
2019年5月18日 
ヤフー株式会社
笹沼啓　沢田晃一
Nuxt.js 中規模サービスを統
合した話

自己紹介
❏ 氏名
笹沼啓（ささまじめ）
❏ 入社年数
入社３年目
❏ 社歴
入社後から現在ま電子書籍サービス携わ
る（JS 触れた入社しから）
❏ そ他
趣味バレーボール（週１〜２回）

自己紹介
❏ 氏名
沢田晃一（さわだこういち）
❏ 入社年数 / 所属
新卒入社12年目 / 名古屋オフィス勤務
❏ 担当しきたサービス
ニュース、天気、防災速報、地図、ミュージッ
ク、ファンクラブ、電子書籍
❏ そ他
最近趣味ペットわんこお出かけ

質問こちらへ
https://app2.sli.do/event/bswcoysn/live/questions
slido.com
#IF_A3

Agenda
1. サービス紹介
2. サービス構成
3. リリースま挑戦苦難
a. 風土違い
b. Atomic Designへ挑戦
c. 実装する上直面した課題
4. リリース後改善
5. さらる改善を進めるため

ebookjapan
● ヤフー株式会社（以後、「ヤフー」）株式会社イーブックイニシアティブジャパン（以
後、「EBIJ」）が協力・連携し運営する電子書籍販売サービス
● それぞれ会社が運営しいた電子書籍販売サービスを統合し、2018年10月リ
リース
https://ebookjapan.yahoo.co.jp/

ebookjapan
● 2016年6月、両社資本業務提携契約が締結
● 2017年冬、新サイト開発開始
● 2018年10月、新サイトリリース
約１年

ebookjapan
60万冊を超える
取り扱い冊数を誇る
国内最大級
電子書籍販売サービス
常時2,000冊を超える
無料まんが
背表紙表示や新刊自動購入
独自機能も豊富

サービス構成 - 役割分担 -
ユーザー FE API DB
ヤフー EBIJ
新規新規

FE
ヤフー
新規
● ヤフー資産が利用きる
○ プラットフォームやビッグデータヤフーが
管理する資産を利用するこがきる
● WEBデザイナーがいる
○ 専門職しデザイナーがヤフー存
在する（イーブックデザイナーいう専門
職がかた）

● 機能が豊富
○ Yahoo!ブックストア比べ
eBookJapan 方が機能が豊
富だた
○ 電子書籍サービスを運営する
上必要データも多く保持し
いた。
API DB
EBIJ
新規

サービス構成 - FE環境 -
ClientSide
出展：https://ja.nuxtjs.org/出展：https://jp.vuejs.org/index.html
Vue.js × Nuxt.js
ServerSide
出展：https://ja.wikipedia.org/wiki/Node.js
Node.js × Express

Vue.js × Nuxt.js を選んだ理由
● デザイナーが理解しやすい
○ Vueファイル HTML × CSS × JavaScript
○ デザイナーがFE開発参加する予定だた
● ライブラリをアップデートする手間削減
○ タイトスケジュールを見越し
● ドキュメントが豊富
● 採用事例が増えき盛り上がりそう
○ React 二択り、最終的 Vue.js × Nuxt.js

FE 規模

ヤフー
風土違い
EBIJ
GOOD
● 社内プラットフォームが充実し
いる
● データが豊富
● 属人化を避け、誰もきるよ
う体制作り
BAD
● 制約が多い
GOOD
● スピード感ある対応や選択
● 自由度が高い
BAD
● 属人化や場当たり的対応が
多い
● デザイン注力するカルチャー
がい

風土違い
スクラム
写真：アフロ

● アジャイル開発手法一
● 固定短い期間（うちチーム 1Week）単位開発を区切り、そ中
計画を立る
● Developer 皆が平等。チーム成果ため自発的計画を立る
必要があるため、自立したチームりやすい
● デイリースクラムやレトロスペクティブを通じ、チーム内問題を発見しや
すい（チーム問題チーム解決）
風土違い
スクラム？

風土違い
FEエンジニア
（ヤフー）
BEエンジニア
（EBIJ）
デザイナー
（ヤフー）
企画
（EBIJ）
スクラムマスター
（ヤフー）
Aチーム
FEエンジニア
（ヤフー）
BEエンジニア
（EBIJ）
デザイナー
（ヤフー）
企画
（ヤフー）
（EBIJ）
Bチーム
プロダクトオーナーステークホルダー

風土違い
FEエンジニア
（ヤフー）
BEエンジニア
（EBIJ）
デザイナー
（ヤフー）
企画
（EBIJ）
（ヤフー）
Aチーム
FEエンジニア
（ヤフー）
BEエンジニア
（EBIJ）
デザイナー
（ヤフー）
企画
（ヤフー）
（EBIJ）
Bチーム
プロダクトオーナーステークホルダー
所属関係く同じチームするこ足
並みを揃え、相互理解を促進！

Atomic Designへ挑戦
Atomic Design ？
パーツやコンポーネントご分割し、それらを組み合わせプロダクトを構築する
いうUIデザイン手法一
出展：Atomic Design Methodology

● 新規開発だたため、途中導入するより導入コストが抑えられる
○ すきいるもをATOMS 分解しいく手間がかかるが、新し
く追加しいく場合コストを抑えられる
● デザイン変更が多発するこが予想されたため
○ デザイン変更も対応きる変化強いシステムが必要だた
○ Atomic Design パーツが共通化されいるため、修正を最小限抑えるこ
がきる
● UI 一貫性を保こがきる
○ ページ寄らず使われいるパーツ共通、一貫性を担保きる
Atomic Designを使おう思た理由

● 新規開発だたため、途中導入するより導入コストが抑えられる
○ すきいるもをATOMS 分解しいく手間がかかるが、新し
く追加しいく場合コストを抑えられる
● デザイン変更が多発するこが予想されたため
○ デザイン変更も対応きる変化強いシステムが必要だた
○ Atomic Design パーツが共通化されいるため、修正を最小限抑えるこ
がきる
● UI 一貫性を保こがきる
○ ページ寄らず使われいるパーツ共通、一貫性を担保きる
Atomic Designを使おう思た理由
しかし、うまくいきませんした…。

原因1: デザイナーエンジニア成果物違い
デザイナー FEエンジニア
html, css
ATOMSや
MOLECULES
デザイナーから html, cssが受け渡され、FEエンジニアがAtomic Design 沿
たVueファイル分割しいた
→ 「分割」いう不要手間が発生

原因2: デザイナーコミュニケーション不足
写真：アフロ
● メンバー出入りが多かた
● デザイナー・エンジニアそれぞれ体制
作りを進めしまた
● エンジニア主導試しみ、後からデ
ザイナーも取り入れもらうもりだ
たが、後回ししまい難しくた

原因3: スクラム相性
写真：アフロ
● スクラムミニマム E2E プロダクトを毎スプリントリリースする手法
● Atomic Design よう共通化対する優先度が低かた
出展：Atomic Design Methodology

Q: うするべきだたか？
A: 最初からデザイナー協力し Atomic Designを導入する
● デザイナーがAtomic Design 沿分割したVueファイル（template style
み）を作成し、FEエンジニアがscriptを加える
● リポジトリを分けるこ、デザイナーがPRを出しやすくるかも
デザイナー FEエンジニア
Atomic Design 分割したVue
（template, style み）
Vue
（script付き）

実装する上直面した課題 - 大小を兼過ぎいるデータ -
FE API
「作品名」が欲しい！
い！「作品」
（作品名・著者・
ジャンル・連載誌・etc）
レスポンス必要過多データが…

↓「作品」レスポンスサンプル
※ 本当データこれ 10倍かく複雑だた

本来 API側必要データだけを返すようすべき
しかし、
必要 APIを作成する精一杯だた…
FE側 mixinsを使 get処理をまめるこ！
写真：アフロ

mixins/publication.js

sample.vue

実装する上直面した課題 - mixins utils化 -
Vueファイル内 mixinsを使データ
を抽出するま良かた！
しかし、
get処理がまま便利りすぎた
ため Vueファイル以外も使い始め
しまた…。
写真：アフロ

getters.js
mixinsをutils よう使しまいる!!

mixins/publication.js

getters.js
isMember がtrue もnormalPrice が返きしまう!!

getters.js
isMember がtrue もnormalPrice が返きしまう!!
➔ mixins Vueファイルみ使う
➔ storeやサーバーサイドも使う処理
common以下 utilsを別途作成する

実装する上直面した課題 - 404 -
● オールグリーンしか表示きい
○ ページを構築する要素を取得するためたたく複数 APIが全成功しい
404
● 直列処理
○ 複数 API 処理が直列処理おり、タイムアウト 404
● 初期描画不必要 APIへリクエスト
○ 初期描画時必須いデータを取得する処理が非同期おらず、タ
イムアウト 404
当たり前内容だが、若いチームやスケジュール優先場合注意！

リリース後改善 - 体制 -
● 「見せられるもを作る」こ集中ししまた
○ スプリント毎、見せられるもを作るこ集中ししまい、エラー処理やシス
テム面改善が放置気味いた
● 経験豊富エンジニアが入いかた
○ FEチーム比較的若いエンジニア構成されおり、新規サービス立ち上
げ携わたこあるエンジニアがほんいかた
（最適配置をおこた結果、アプリ、BE おじさんエンジニアが
集ましまた、、）
リリース至るま体制面課題

改善1: FEチームメンバー追加
FEエンジニア BEエンジニア
デザイナー企画
Aチーム
Bチーム
スクラム
これま

改善1: FEチームメンバー追加
Aチーム
Bチーム
スクラム
FEエンジニア
名古屋チーム(1人)
追加

● スクラムチーム
○ これま通り機能追加、機能面バグ修正
リリース後追加しいいけい機能がたくさんあた
● 名古屋チーム
○ スクラムチーム FEエンジニアサポート
コードレベル確認や、困たこ相談
○ システム面改善サポート
パッケージアップデートやパフォーマンス改善
各チーム役割

改善2: FEエンジニア話し合う場を作る
FEエンジニア
FEエンジニア
FEエンジニア
FEエンジニア FEエンジニア
● WEB 明るい未来を考える会
○ 新しいこへ挑戦
○ 実装時見けた課題共有
○ 困いるこ相談
スクラム拾いきれいかた
課題を拾えるよう！

リリース後改善 - システム
● パフォーマンス改善
○ 処理フロー見直し
○ レスポンスサイズ削減
○ JSファイル容量削減
● パッケージアップデート、見直し
○ Nuxt.js v1からv2へアップデート
○ より最適パッケージへ変更
● Node.js アップデート等

リリース後改善 - パフォーマンス
改善1: 処理フロー見直し
Server
ユーザ
情報1
ユーザ
情報2
ユーザ
情報3
書誌
情報2
書誌
情報1
60ms 80ms 50ms
Client
120ms 150ms
描画
処理
対応前：460ms
● 必要情報をひひ順番いた
● 描画後ブラウザから取得いいももサーバ取得しいた
Before

改善1: 処理フロー見直し
Server
ユーザ
情報1
ユーザ
情報3
ユーザ
情報2書誌
情報2
書誌
情報1
60ms
50ms
80ms
Client
120ms
150ms
描画
処理
対応後：210ms
● まめられる情報 Promise.all
● 描画後もいい情報描画後
After

改善2: レスポンスサイズ削減
500KB
350KB
Server
80ms
Client
mixins
全加工大き
データ1
500KB
350KB
API
50ms
150ms
Before
大き
データ1
大き
データ2
大き
データ2
850KB JSON。。
● サイズがかくデータを受け取る時間が
かかいた
● 大きデータをそままClient 処理しいた

不要フィールドを
削たデータ1
100KB
削たデータ2
70KB
Server
40ms
Client
最低限を
mixins処理
削たデータ1
100KB
削たデータ2
70KB
API
30ms
20ms
After
必要もだけ
加工したデータ1
必要もだけ
40KB
30KB

削たデータ1
100KB
削たデータ2
70KB
Server
40ms
Client
最低限を
mixins処理
削たデータ1
100KB
削たデータ2
70KB
API
30ms
20ms
After
必要もだけ
必要もだけ
40KB
30KB
● 不要フィールドを削たこ全体やりり
が速くた
● mixins 処理を減らしたこ Client 処理
が軽くた(体感)

改善3: JSファイル削減
● Webpack Bundle Analyzer
○ バンドルされたファイル内容を確
認きるプラグイン
○ Nuxt.js config 1行追加するだ
け利用可能
○ 想像以上必要いファイルが
多く含まれいた。。
対応前: 7.23MB
Before

改善3: JSファイル削減
● style.css 除去
● Package 見直し
● 不要コンポーネント削除
対応後: 2.8MB
After
60%程度削減きた！

さらる改善を進めるため
これから体制(4/1〜)
Aチーム
Bチーム
スクラム
FEエンジニア
名古屋
名古屋もスクラムチーム！

さらる改善を進めるため
● スクラム
○ 70%程度を使い、これまおこいた機能追加等をしかり
進めいく
● スクラム外
○ 30%程度を使い、システム面改善を全員おこいく
パフォーマンス改善、バグ修正、リファクタリング等
スクラムチーム(FEエンジニア) 役割
属人化を避けFEエンジニアら誰も
システム面改善をきる体制

まめ - リリースま挑戦苦難 -
● 風土違い
○ ヤフー EBIJ 文化が違う敵対するよう雰囲気
スクラムを利用し足並みを揃えるこ解決！
● Atomic Designへ挑戦
○ パーツご分割するUIデザイン手法を取り入れようしたが断念
デザイナー協力し進めいくこが重要！
● 実装する上直面した課題
○ 大きすぎるデータ・mixins 使いすぎ・404
mixins 処理をまめる・utilファイルを作る・実装方法注意
写真：アフロ

まめ - リリース後改善 -
● 体制
○ 名古屋チームもスクラム Join
○ FEエンジニア話し合い場を作る
● システム
○ パフォーマンス改善やパッケージアップデート、見直しを行た
○ パフォーマンス改善
■ 処理フロー見直し
■ レスポンスサイズ削減
■ JSファイル削減

最後
ebookjapan これからも改善を
進めいきます！
https://ebookjapan.yahoo.co.jp/

Unification of the middle scale services by Nuxt.js

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Unification of the middle scale services by Nuxt.js

Semelhante a Unification of the middle scale services by Nuxt.js (20)

Unification of the middle scale services by Nuxt.js