品質と開発速度を両立させるために捨てたものと守ったもの
https://gyazo.com/ca7b2ff75b20843d938f9144eb9e24b4
Tsuyoshi Wada
Frontend Engineer at 株式会社サイバーエージェント
Twitter.icon https://twitter.com/wadackel
GitHub.icon https://github.com/tsuyoshiwada
Soichi Masuda(masuP9)
Web Accessibility Expert at 株式会社サイバーエージェント
Twitter.icon https://twitter.com/masuP9
GitHub.icon https://github.com/masuP9
https://docs.google.com/presentation/u/1/d/13QD86hxp0dB_xHkYcyLrFX1xNt0Vg4wsqIo8yeBQmFs/edit#slide=id.g5a1484322a_2_460
品質を担保するための戦略
WInTicket
https://www.winticket.jp
高い年齢層の利用(50〜70代)
屋外での使用を想定
高い利用体験の提供
パフォーマンス
アクセシビリティ
開発メンバー
リリース前 8人
リリース後 5人
完全に分業制で、Webフロントエンド、サーバー、iOS、Android、デザインがチームとして分割されている。
初期の規模
80〜100p
チーム状況
やったことあるひと 0人
求められるもの
ドメイン知識
LIVE 動画
決済
スケジュール
12ヶ月を想定していたが
4ヶ月しか割けない
品質を担保するための戦略
パフォーマンス
SSR
メディア特性
アプリケーション特性
HTTP Framework には Fastify、View Framework には React を採用
Fastlyを使ってキャッシュ活用
ユーザー固有の情報を扱う場合はプレースホルダーを表示しつつ遅延読み込み
ユーザーのログイン、非ログインで UI の出し分け
Cookie に入っている JWT の有効期限からログイン状態を推測
推測結果を独自 Header に詰める
Cookie は破棄してオリジンには渡さない
Perfomance Budget
競合と比較
SpeedCurve を使った Synthetic Monitoring
Resource Budget
https://github.com/ai/size-limit
CIを落とす
Code Splitting
Dynamic Important
TypeScriptの導入
StorybookでVisual Regression Testing
1コンポーネントにつき最大 36 の表示パターンを検証
Protocol Buffers を元にした型定義の使用
API が定義した Protocol Buffers を元に pbjs, pbts を使って型定義を作成
それらをアプリケーション側で使用する
実際の通信は一般的な HTTP で行う
直接定義を import すると protobufjs がバンドルされてしまうが...
TypeScript Compiler API で型定義を使いやすい形に変換し使用
あたりまえのことを重ねるのを意識
安定した開発基盤を整えた
アクセシビリティ
masuP9は途中でジョインした
他チームとの連携が大事
他チームに負債を返してもらうのは大変
デザイン
プロジェクトの初期から守りたい点を伝える
コントラスト比は基本は 4.5 : 1で、一部難しいところでも 3:1 を下限に
フォーカスリング用のスタイルを統一
フォントサイズベースを16pxで
代替テキストの確保
動的に取得するバナー画像などに必ず代替テキスト用のテキストフィールドを加えてもらう
管理画面の代替テキスト入力欄を必須にする
実装方針の策定
全員で共有するための方針
Must
コンテンツ、UIのマシンリーダビリティ
ライブ動画は除く
最低限のキーボード操作
Usual
要素選択
hx, list
フォーカス順のコントロール
CATS webs development policy - Accessibilityを策定
捨てたもの
パフォーマンス
全ページキャッシュ
会員系のページは諦める
慣れたアーキテクチャ以外の挑戦
負債はある程度許容
ただし局所化させる
戦術的
レイヤードアーキテクチャで構造化
戦略的
複雑なドメイン部分の実装は局所的に、ある程度負債化することを妥協する。ただしテストをしっかりと書くなどしてあとからの変更に耐えられるように!
結果
属人性の高いところが多くなってしまった
ドキュメントを作成したり、実装についてチームメンバーがある程度理解する機会作りができると少しは潰しがききそう
属人性の最小化
スペシャリストが全力で標準化に取り組む
ドキュメントを整備する
機械的なテストの質を向上させる
これからどうするか?
LightWallet の導入
Performance Budgets (Keep Request Counts Low And File Sizes Small)  |  Tools for Web Developers  |  Google Developers
Runtime Performance の改善
GitHub.icon https://github.com/GoogleChromeLabs/quicklink
prefetch / preload の機構を追加
tscからBabelに移行
アクセシビリティ
普通ができなくなってきた
適切な要素選択は諦めた
やらないのではなく徹底をやめる
こだわりになりかねない
完璧なフォーカスマネジメント
全部タブで移動する
結果
70%のWCAG達成
キーボードで一応操作できるはず
Auditsは93
これから
WCAGのテストは引き続きやる
品質テストの自動化
addon-a11y
AOMを用いたname role valueのチェック
スクリーンショットでフォーカスインジケータ
ポリシー展開
ドキュメントの充実
トレーニングの実施
まとめ
やらないを決めることの覚悟と重要性
どこからどのくらい借り入れがあるかは把握する
改善 / 維持ができる基盤は大事
あたりまえを積み重ねる
If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe.
“木を切り倒すのに6時間もらえるなら、私は最初の4時間を斧を研ぐことに費やしたい。”