Eight Webフロントエンドの開発者体験（DX）向上のための取り組み / Approaches to improve the developer experience of Eight web frontend

■イベント

Sansan Builders Stage 2021

https://jp.corp-sansan.com/engineering/buildersstage2021/

■登壇概要
タイトル：Eight Webフロントエンドの開発者体験（DX）向上のための取り組み

登壇者：技術本部 Eight Engineering Unit Eight Career Devグループ　フロントエンドエンジニア　鳥山 らいか

▼Sansan Engineering
https://jp.corp-sansan.com/engineering/

Transcript

1. 鳥山 らいか Eight Webフロントエンドの 開発者体験（DX）向上のための取り組み STAGE 1 Eight Career Devグループ SESSION TAG
2. 技術本部 Eight Engineering Unit Eight Career Devグループ フロントエンドエンジニア 大学・大学院ではHCI（Human-Computer Interaction）を専攻し、 インタラクションデザインを学ぶ。2019年、新卒でSansan株式会社に入社。 採用サービスのUI開発に従事しつつ、Webフロントエンドの開発者体験 （DX）向上に取り組む。 Twitter: @pvcresin 鳥山 らいか
3. • 開発者体験（DX） • EightのWebフロントエンド • DX向上のための取り組み • まとめ アジェンダ
4. 開発者体験（DX）
5. 開発にまつわる全ての行為を通した開発者の体験 DXの向上 ＝ 快適に開発を行うことができる環境の整備 • 自動化による手間の削減 • 負債解消によって今後の開発や設計を容易に 開発者体験（Developer eXperience）とは 生産性の向上 モチベーションの向上 開発者体験（DX）
6. 1. 議論できる場を作る 2. 徐々に進められる技術選定を行う 3. 完璧を求めない 4. 後戻りしないようにする 5. 積極的にアウトプットしていく 開発者体験（DX） DX向上を徐々に進めていくためのポイント 思い立ったらすぐに議論できる環境が重要 チームで向き合い、合意形成を行う 作業を細かく分割することで、 スキマ時間に差し込むことができる 始めから完璧を求めると進まないため、 ある程度方針が決まったら走りだす 後戻りすれば苦労が無駄になるため、 自動化やドキュメンテーションで防ぐ 技術ブランディングや採用貢献につながり、 モチベーションの向上や工数確保に寄与
7. EightのWebフロントエンド
8. 名刺でつながる、ビジネスのためのSNS • 名刺を正確にデータ化 • 近況情報が届く • メッセージで気軽に連絡 EightのWebフロントエンド Eightとは
9. EightのWebフロントエンド PC版 Eight PCブラウザから おおよその機能を利用可能
10. • チーム内名刺共有サービス • 採用サービス • 広告サービス EightのWebフロントエンド PC版 Eight - 企業向けサービス
11. フレームワーク React / Redux 言語 JavaScript / TypeScript / Sass（SCSS） その他のツール webpack / Prettier / ESLint / stylelint • ドメインごとにフォルダ分けして各チームが開発 • その他にも社内向けライブラリなど、いくつかのリポジトリが存在 EightのWebフロントエンド 技術スタック
12. • 機能開発のフロントエンド実装は各ドメインのチームで行う • 上記とは別に、インフラやバックエンドは改善するチームが存在 ＝ フロントエンドを改善するチームがない ➜ チーム横断で進めている EightのWebフロントエンド Eightの開発体制
13. • 連携用のSlackチャンネルで議論 • 心理的安全性を意識 • カンバンボードでタスクの進捗を管理 • To Doの前にWish（願い）を用意し、 書くハードルを下げる EightのWebフロントエンド チーム横断で進める方法
14. EightのWebフロントエンド 2. 3. 4. 5. ポイント Slackのチャンネル、カンバンボード 発信のハードルを下げる + 心理的安全性の醸成 1. 議論できる場を作る
15. DX向上のための取り組み
16. • コードの自動整形の導入 • TypeScriptの導入 • コンポーネントライブラリの作成 DX向上のための取り組み 本日のトピック
17. コードの自動整形の導入
18. • これまで多くのエンジニアが開発に関わってきており、 コードのスタイルにばらつきがあった そこで、 • 既存のコードを統一されたルールで整形することで、可読性をあげたい • 新規のコードも整形することで、 レビューでの指摘や不要なコード差分を減らしたい コードの自動整形の導入 概要
19. • 自動整形にはPrettierを使用 • CIで整形されているかをチェック • Gitフックでコミット前に自動整形をかける ＝ Husky + lint-staged • ファイル保存時に自動整形をかける ＝ VS Code拡張 コードの自動整形の導入 方針
20. 1. 一定の範囲を設定し、整形されていることを担保 • 既存のコードを整形し、挙動に影響がないことを確認 • 新規のコードもコミット前フックで整形 • CIで整形されているかをチェック 2. 一定の範囲を広げながらPRを出し続け、全体へ コードの自動整形の導入 作業
21. コードの自動整形の導入 1. 2. 3. ポイント GitフックやCIでのチェックによる自動化 周知やドキュメント更新を行う 4. 後戻りしないようにする 5.
22. TypeScriptの導入
23. • PC版 Eightには数年前のコードが多々あり、読み解くのに時間がかかっていた • コンポーネントなど、テストが十分でない部分が一部存在していた そこで • TypeScriptを導入し、型チェックによってコード品質を高めたい • 型をドキュメントの代わりとしたい TypeScriptの導入 概要
24. • 既存のロジックに影響が出ない形で導入する • 拡張子で判別して処理を分ける • 新規のコードは原則、TypeScriptで書く • 既存コードも適宜、TypeScriptに移行していく TypeScriptの導入 方針
25. 1. ドキュメント・書籍・勉強会の資料などで学ぶ • 実践TypeScript、TypeScript Deep Dive等 2. 試しに使ってみる • 新規リポジトリに採用し、設定や書き味を確認 • 既存のJavaScript製ライブラリの移行で相互運用性を確認 TypeScriptの導入 事前準備
26. 1. コンパイル処理の追加 • ts-loader（transpileOnly: true）＋ Fork TS Checker Webpack Plugin • tsconfig.json は “strict”: true で型チェックを厳格に設定 2. Gitフック・CIの設定 • コードの自動整形、Lint、テスト、型チェック等 • TypeScriptを書く準備ができたのでリリース TypeScriptの導入 PC版 Eightへの導入手順
27. 1. 拡張子を変更して型を付与 • 型定義の追加を行い、わかる範囲でコードに型を付与 • ts-expect-errorコメントや Todo型（any型のエイリアス）を付与 現状 • 導入から1年半が経過し、TypeScript率は7割に • ある程度進んだらリファクタリングを行い、型を厳密にしていく TypeScriptの導入 既存のJavaScriptコードからの移行手順
28. TypeScriptの導入 1. ポイント 相互運用性のあるTypeScriptの選択 拡張子やglobパターンによるファイル指定 2. 徐々に進められる技術選定を行う 3. 4. 後戻りしないようにする 5.
29. コンポーネントライブラリの作成
30. • コンポーネントの実装・デザインに バラつきがあった • PC版のUIを刷新し、アプリ版と 合わせる動き そこで、 • コンポーネントライブラリを作成し、実装・デザインを揃える • コンポーネントカタログを作成し、デザイナーと認識を合わせる コンポーネントライブラリの作成 概要 デザインシステム構築
31. デザインの一貫性と開発の生産性を担保するため仕組み • デザインガイドライン デザイン原則や規約を定めた指針 • デザイントークン 色・タイポグラフィ・サイズ等の定義 • コンポーネントカタログ コンポーネントのパターン一覧 • コンポーネントライブラリ コンポーネントの実装 コンポーネントライブラリの作成 デザインシステムとは
32. デザイナー • Figma上でコンポーネントの洗い出しと整理を行う エンジニア • 整理されたコンポーネントを実装し、コンポーネントカタログに反映 コンポーネントライブラリの作成 方針
33. コンポーネントライブラリの作成 全体の流れ エンジニア デザイナー 整理されたコンポーネントから実装 ＋ テスト・デプロイ周りの作り込み コンポーネントライブラリのベース実装 コンポーネントの洗い出し・整理 ＋ デザイントークンの整理 デザインガイドラインへの落とし込み
34. 1. ライブラリのベース実装 • ビルドやテスト、Lintの整備 • カタログ作成 2. テスト・デプロイ周りの作り込み • Snapshot・画像回帰 テスト • PR毎にカタログのPreview生成 コンポーネントライブラリの作成 作業
35. コンポーネントライブラリの作成 1. 2. ポイント コンポーネントが全て洗い出されるのを待たない ライブラリの完成度を最初から求めない 3. 完璧を求めない 4. 後戻りしないようにする 5.
36. • コミュニケーションが増え、DXに向き合うメンバーが増えた • 作業工数が少しづつ確保できるように • 開発のスピードが上がり、その後の開発が快適に DX向上のための取り組み 組織に起こった変化
37. まとめ
38. • コードの自動整形の導入 • TypeScriptの導入 • コンポーネントライブラリの作成 まとめ DX向上のための取り組み
39. まとめ 1. 議論できる場を作る 2. 徐々に進められる技術選定を行う 3. 完璧を求めない 4. 後戻りしないようにする 5. 積極的にアウトプットしていく DX向上を徐々に進めていくためのポイント 思い立ったらすぐに議論できる環境が重要 チームで向き合い、合意形成を行う 作業を細かく分割することで、 スキマ時間に差し込むことができる 始めから完璧を求めると進まないため、 ある程度方針が決まったら走りだす 後戻りすれば苦労が無駄になるため、 自動化やドキュメンテーションで防ぐ 技術ブランディングや採用貢献につながり、 モチベーションの向上や工数確保に寄与
40. Eight Career Devグループ Twitter @pvcresin 8card.net/p/ pvcresin Eight Virtual Card 鳥山 らいか