"READYFOR フロントエンド" の黎明〜デザインシステム導入/READYFOR Elements 誕生〜

Slide 1

Slide 1 text

1 "READYFOR フロントエンド" の黎明 DesignSystem導入/readyfor-elements誕生 2021.02.05

Slide 2

Slide 2 text

2 江面陽一 a.k.a ねり自己紹介 ● SIerから転向 2018年11月入社 ● 趣味でバンド活動 / 家に猫がいます ● like: React, Netlify, CSS設計, component設計 ● 要素セレクタ警察 @neripark #readyfor_meetup

Slide 3

Slide 3 text

3 自己紹介要素セレクタに関しては過激派 #readyfor_meetup

Slide 4

Slide 4 text

4 本日のお話: "READYFOR フロントエンド" の黎明 1. それまでの READYFOR のフロントエンド 2. UIリニューアルプロジェクト 3. 技術紹介 a. React / TypeScript / Storybook / Atomic Design 4. まとめ a. うまくいった点 b. 反省点 c. 伝えたいこと #readyfor_meetup

Slide 5

Slide 5 text

5 1. それまでの READYFOR のフロントエンド #readyfor_meetup

Slide 6

Slide 6 text

6 ● READYFOR は2011年3月に稼働開始したモノリシックな Ruby on Rails 製のアプリケーション ● 現場の要望を実現するため、スピード重視の開発 ○ 将来を見据えた堅牢な設計＜＜＜兎にも角にも動作すること ● 熟成されていくソースたち ● 少しの修正のはずが、、、 ○ どんどん大きくなる影響範囲 ○ 本番に出して初めて分かる考慮漏れ ○ 突貫で穴を塞ぐ→手を入れにくくなる … のループ 1. それまでの READYFOR のフロントエンド #readyfor_meetup

Slide 7

Slide 7 text

7 ● バックエンドと密結合 ○ View ファイルの中に突如出てくる jQuery コード ■ セレクタ部分だけ Ruby の変数 ■ フロントを見ていたはずが、気づいたら Rails の深いところへ ● 全体像がわからない ○ 一部だけ React、CoffeeScript も（あるある） ○ 特定の環境で生成される yarn.lock ○ Gulp と webpack の共存 ■ 結局 Gulp は使われていなかった 1. それまでの READYFOR のフロントエンド #readyfor_meetup

Slide 8

Slide 8 text

8 わかる、仕方ないよね😢 #readyfor_meetup

Slide 9

Slide 9 text

9 でもつらい😇 #readyfor_meetup

Slide 10

Slide 10 text

10 （...なんとか良い方向に舵を切りたい🤔） #readyfor_meetup

Slide 11

Slide 11 text

11 2019年5月頃の、ある日 #readyfor_meetup

Slide 12

Slide 12 text

12 UIリニューアルやろうやったぜ CTO 町野プロダクト開発メンバー #readyfor_meetup

Slide 13

Slide 13 text

13 UIリニューアルプロジェクト発足💪 #readyfor_meetup

Slide 14

Slide 14 text

14 2. UIリニューアルプロジェクト #readyfor_meetup

Slide 15

Slide 15 text

15 2. UIリニューアルプロジェクト発足 ● 全社的に CI (Corporate Identity) 刷新のプロジェクトが発足。 ○ サービスのUIリニューアルはその一部 #readyfor_meetup

Slide 16

Slide 16 text

16 2. UIリニューアルプロジェクト発足一方、これをきっかけに、良い方向に舵を切れないだろうか？ SPA化? デザインシステム? jQuery 脱却? 大リファクタ? ReactOn Rails脱却? 🤔 #readyfor_meetup

Slide 17

Slide 17 text

17 2. UIリニューアルプロジェクト発足 ● CI刷新は社内外が一丸となって進めるプロジェクト ○ 絶対的な期限のある守りの側面 ● 今後の開発（特にフロントエンド）が良くなる方向に舵を切りたい ○ 未来も見据えた策を盛り込む攻めの側面このバランスをうまく取るために、どういう技術構成にするかめっちゃ考えた #readyfor_meetup

Slide 18

Slide 18 text

18 決まった✌ #readyfor_meetup

Slide 19

Slide 19 text

19 ● デザインシステム導入 ○ プロダクト間で統一されたデザイン運用はどのみち必要 ● UIライブラリ新規作成 ○ 機能部分はどうしても既存仕様・アーキテクチャとの兼ね合いになる ○ それならばデザインシステム文脈の仕様は最初から別リポジトリで用意したほうが混ざらなくて良いだろうと考えた ○ READYFOR Elements と命名 ■ `npm install @readyfor/readyfor-elements` (※まだ社内限定です🙏) 2. UIリニューアルプロジェクト発足やると決めたこと🎉 #readyfor_meetup

Slide 20

Slide 20 text

20 2. UIリニューアルプロジェクト発足 ● ReactOnRails からの脱却 ○ 刷新対象ページの事業数値を落とさない（主にSEO観点）ために SSR を削る選択がしにくい ○ パラメータ１つで SSR できる機構＝生かしたほうが得策と判断 ○ CI刷新が目的なのでSPA化によるUX向上などはマストではない ■ バックエンド工数の確保やらないと決めたこと🙃 #readyfor_meetup

Slide 21

Slide 21 text

21 （いろいろあったものの） 2019年10月、予定通りリリース🎉 #readyfor_meetup

Slide 22

Slide 22 text

22 3. 技術紹介 #readyfor_meetup

Slide 23

Slide 23 text

23 ● React （継続） ○ Vue.js という選択肢もあったが、ReactOnRails を継続するのなら React がコスパが良いだろうと判断 ○ 技術顧問をしてくれていた方が得意だった ● TypeScript（新規） ○ もはや使わない選択肢はなかった ○ どんなデータをもらっているのか、コンポーネントの props の型を見ればわかる状態は非常に快適 ■ 間違いなくコンポーネント分割の助けになった ○ Rails → React への連携部分だけは気をつける 3. 技術紹介 #readyfor_meetup

Slide 24

Slide 24 text

24 ● AtomicDesign（新規） ○ デザイナーとの意思疎通のために、フレームがあったほうがよさそう ○ エンジニアがコンポーネント設計する最初の指標になってよかった ■ 自分含め、慣れていないエンジニアもいた ○ とはいえ銀の弾丸ではない ■ Molecule or Organism 問題 ● Storybook（新規） ○ きっかけは技術顧問をしてくれていた方の勧め ○ データの準備をせずに開発できるのでとても快適 ○ `@storybook/addon-knobs` で状態に応じた変化の確認もらくらく 3. 技術紹介 #readyfor_meetup

Slide 25

Slide 25 text

25 ちょっとだけご紹介 #readyfor_meetup

Slide 26

Slide 26 text

26 例: `Button` のデザイン #readyfor_meetup

Slide 27

Slide 27 text

27 #readyfor_meetup

Slide 28

Slide 28 text

28 4. まとめ #readyfor_meetup

Slide 29

Slide 29 text

29 ● よかったこと ○ コンポーネントを設計・実装する基礎力が身につき、感覚をエンジニア間で共有できた🎉 ■ 責務を考えることはいつでも重要 ○ デザインシステムとUIライブラリの運用が開始できた🎉 ■ 始まっていないと改善もできない 4. まとめ #readyfor_meetup

Slide 30

Slide 30 text

30 ● 反省点 ○ いきなり UI ライブラリを作ると、改善点が見つかったときにアプリケーション側との往復が大変 ■ 別スコープでもよかったかもｗ ■ とはいえ、強制的に設計力が鍛えられた面も ● App 特有の UI → アプリケーション側に ● デザインシステム文脈のパーツ → readyfor-elements 側に 4. まとめ #readyfor_meetup

Slide 31

Slide 31 text

31 ● フロントエンドを変えたい！な方にこの場で伝えたいこと ○ 新しいことをするタイミングは改善のチャンスでもある ■ Biz側のきっかけに全力で乗っかる！ ○ TypeScript は少しずつでも入れたほうがよい ■ 「面倒なもの」が「開発を楽にしてくれるもの」にすぐ変わる ■ コンポーネント開発に慣れていないエンジニアがいればなおさら ○ 社外のスペシャリストに協力を仰ぐ ■ 全力で仰ぐ！！ ○ スコープを切る勇気を持つ ■ やらないことを決める意識 4. まとめ #readyfor_meetup