デザインシステムの設計とアクセシビリティの実現

by ymrl

Slide 1

Slide 1 text

freee 株式会社デザインシステムの設計とアクセシビリティの実現 2019.03.26

Slide 2

Slide 2 text

慶應SFC大学院修了後、モバイルゲームベンチャーを経て 2014年に17番目の社員としてfreeeに入社。インフラ以外はだいたいやる感じのエンジニア。 2015年からは人事労務freee（当初は給与計算freee）を開発。現在は人事労務freeeのUI改善プロジェクトと同時並行でデザインシステムの開発もしている。最近の趣味は自作キーボードだが、腕が2本しかないので作ったキーボードを人に貸したりしている。 @ymrl Engineer 2

Slide 3

Slide 3 text

01 会社の成長によって起きたこと 3 Section

Slide 4

Slide 4 text

Company Profile 会社情報 4 会社名 freee株式会社（フリー株式会社）設立年月日 2012年7月9日代表取締役佐々木大輔資本金 161億603万円（資本準備金など含む）従業員数 505名（2019年1月1日時点）事業内容クラウド型バックオフィスサービスの開発・販売

Slide 5

Slide 5 text

Products 製品・サービス 1/2 5 中小企業の経理業務を効率化。帳簿や決算書作成・請求業務に対応。リアルタイムに数字を把握できる給与計算や労務管理を大幅に効率化。給与明細作成や年末調整、入社手続きから勤怠管理まで対応税務申告書作成業務を効率化。法人税・消費税・法定調書・申請届出や電子申告にも対応

Slide 6

Slide 6 text

Products 製品・サービス 2/2 6 低コストでマイナンバーの収集から保管、利用、破棄までがクラウド上で完結画面に沿って入力するだけで、会社設立に必要なすべての書類を 5分で作成できる無料サービス個人事業の開業手続きが無料、簡単、最速。ガイドに沿って質問に答えるだけで書類作成が完了 Webで申し込みでき、最短4営業日で発行。創業時でも本人確認書類だけで審査可能

Slide 7

Slide 7 text

7 freeeに入って5年間での変化 ● 資金調達 3億円→160億円 ● 従業員数 17人→500人超 ● エンジニア・デザイナー 11人→100人超 ● 会計freeeのみ → 会計・人事労務・申告を筆頭に7つの製品 ● 個人事業主が大半 → 数百人規模の上場企業にも導入

Slide 8

Slide 8 text

02 サービス開発で変化したこと 8 Section

Slide 9

Slide 9 text

9 会社の成長の開発への影響: 品質 ● アーリーアダプターの個人事業主や小規模法人がメインだったが、数百人規模の法人までカバーするようになった ● 尖ったサービスより普通のことができるサービスが求められるようになった ● ユーザビリティやアクセシビリティが重要になってきた

Slide 10

Slide 10 text

10 会社の成長の開発への影響: 開発組織 ● 開発に関わる人数が増え、誰がどこで何を作っているのか見えづらくなった ● 製品が増え、求められるもの・満たすべきものがわかりづらくなった ● 最初の頃に試行錯誤しながら作ったものが技術的負債となってきた

Slide 11

Slide 11 text

11 freeeのWebフロントエンド開発スタイル ● UIデザインは主にデザイナーが行い、画面モックをエンジニアに渡す ○ Sketchなどを使ってfreeeっぽい画面（の画像）を作る ● HTML/CSS/JavaScriptコーディングは、ほぼ全部エンジニアが担当 ○ エンジニアにサーバーサイド/フロントエンドの区別はないのでフロントエンドに不慣れなエンジニアでもやる

Slide 12

Slide 12 text

12 会社が大きくなってきた頃の Web UI 開発 ● BootstrapベースのUIを徐々に卒業し、freee独自のUIに変化していった ● 人事労務freeeがリニューアルし、ここだけカラースキームが緑系になった ● エンジニアもデザイナーも増えたが、CSSが得意な人はあまり増えなかった ➔ UIデザイン・フロントエンド実装で求められる要件が複雑化する一方で、それを支える環境整備の不備が目立つようになってきた

Slide 13

Slide 13 text

13 陥ってしまった事態 ● デザイナーごとに作る画面モックのUIの差異が大きくなっていった ● フロントに不慣れな人も実装するので、画面モックと実装にも差が産まれる ● 画面モックを再現するのにCSSが足りておらず、毎回書く（コピペする） ● CSSの配置や書き方の指針がなく、stylesheetsディレクトリがカオスに ➔ 見た目が揃っていなかったり、同じ見た目でも違う挙動をするUIが大量発生 ➔ それっぽいCSSを毎回探したり書いたりコピペしたりしていて生産性も低下

Slide 14

Slide 14 text

14 これらの問題解消のためのチーム、AG部の誕生 group_inou / HEART (single mix) https://www.youtube.com/watch?v=w_os8HqfxHc

Slide 15

Slide 15 text

15 AG部 ● 統一的なUIを作るためのチームとして発足 ● AG部 = Atomic Design and Guideline 部 ● Atomic DesignなUIコンポーネントとUIを作る上でのガイドラインを作る ● デザイナー数名とエンジニア数名で組織

Slide 16

Slide 16 text

16 AG部の目標 ● どのデザイナーでも「freeeの統一されたUI」をデザインできるようにする ● フロントエンドに不慣れなエンジニア、特にCSSに不慣れなエンジニアでも「freeeの統一されたUI」を実装できるようにする ● これらを通して生産性を向上して、爆速で機能開発できるようにする

Slide 17

Slide 17 text

03 ガイドラインとデザインシステム 17 Section

Slide 18

Slide 18 text

18 UI/UXガイドライン「Groove」

Slide 19

Slide 19 text

19 UI/UXガイドライン「Groove」 ● もともとガイドラインは存在していたが、網羅性が高くなく、あまりメンテも参照もされず放置されていた ● AG部発足を機にしっかりとオーナーシップを持ってメンテしていくことに

Slide 20

Slide 20 text

20 ガイドラインの例

Slide 21

Slide 21 text

21 デザインシステム「vibes」服部昇大「日ポン語ラップの美ー子ちゃん徳之島編」 https://twitter.com/hattorixxx/status/917720911914004481

Slide 22

Slide 22 text

22 vibes とは服部昇大「日ポン語ラップの美ー子ちゃん徳之島編」 https://twitter.com/hattorixxx/status/917720911914004481

Slide 23

Slide 23 text

23 vibes とは ● Atomic Designによる設計 ● Sketchライブラリと CSS / React Component実装 ● 統一されたブランドイメージ、ユーザビリティ、アクセシビリティを担保

Slide 24

Slide 24 text

24 Atomic Design DeNA DESIGN BLOG「Atomic Design を分かったつもりになる」 https://design.dena.com/design/atomic-design-を分かったつもりになる/ UIを化学物質に見立て、組み合わせによってデザインしていく考え方

Slide 25

Slide 25 text

25 SketchライブラリとCSSとReactコンポーネントデザイナー向けのSketchライブラリとエンジニア向けの実装をそれぞれ提供する

Slide 26

Slide 26 text

26 Sketchライブラリ UIコンポーネントがシンボル化されていて、これらを組み合わせてUIを作る

Slide 27

Slide 27 text

27 Storybook Sketchライブラリと同じ内容のコンポーネントカタログをStorybookで構築挙動やコンポーネントの使い方を確認することができる

Slide 28

Slide 28 text

04 アクセシビリティ 28 Section

Slide 29

Slide 29 text

29 アクセシビリティとは「企業サイトのWebアクセシビリティの今とこれから」 https://www.concentinc.jp/design_research/2018/03/btobcommunications-web-accessibility/

Slide 30

Slide 30 text

30 freeeにとってのアクセシビリティ ● freeeが作っているのは「ビジネスのプラットフォームとなるサービス」 ● 「freeeが使えない」ことで「ビジネスができない」になってほしくない ○ 「経理作業ができないので個人事業ができません」とか ○ 「freeeを使えないので従業員として雇えません」とか ● むしろアクセシビリティ対応を強みにしていきたい

Slide 31

Slide 31 text

31 法定雇用率従業員45.5人以上の企業では2.2%以上の障害者雇用が義務厚生労働省 https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/koyou/shougaisha/04.html

Slide 32

Slide 32 text

32 色覚異常日本人男性の20人に1人は色覚異常がある滋賀医科大学眼科学口座「色覚異常者の色の見え方」 http://www.shiga-med.ac.jp/~hqophth/farbe/miekata.html

Slide 33

Slide 33 text

33 中小企業ほど高齢者比率が高い中小企業白書2016 https://www.chusho.meti.go.jp/pamflet/hakusyo/H28/PDF/h28_pdf_mokujityuu.html

Slide 34

Slide 34 text

Slide 35

Slide 35 text

35 freeeには全盲のエンジニアもいる ● 中根雅文さん (Twitter: @ma10) ● エンジニアとしてアクセシビリティを担当 ● スクリーンリーダーと点字ディスプレイを使ってPCを操作

Slide 36

Slide 36 text

36 中根さんに聞いてみた「freeeって働きやすいですか？」 ● 人事労務freeeの給与明細がWebやスマホアプリで見られるので給与明細を誰かに読んでもらう必要がない ● 自社サービスだけでなく、ありとあらゆる業務がペーパーレス化されていて色々なものがWebにあるので困ることが少ない freeeはサービスを通してこういう世界をもっと作っていきたい

Slide 37

Slide 37 text

37 Webアプリとしてのfreeeがアクセシブルであるには ● 機能がどんどん増えていくので少ない人数でやっていくのには限界がある ● アクセシビリティ人材を確保するのが難しい ○ いきなりWCAG準拠は難しいので、「いい塩梅」でやっていくしかない ○ サーバー/フロントの役割分担がないので全員が教育される必要がある ➔ デザインシステムがアクセシビリティを担保して、それを使って画面を組むとアクセシブルになるなら解決するのでは！！

Slide 38

Slide 38 text

38 デザインシステムがアクセシブルであるために ● 視覚障害者へのヒアリングやコンポーネントの挙動についての議論 ● eslint-plugin-jsx-a11y や @storybook/addon-a11y の導入 ● アクセシビリティチェックするべき内容の定義

Slide 39

Slide 39 text

39 ヒアリング・議論 ● VibesのUIコンポーネント定義ができてきた段階で中根にヒアリング ● UIコンポーネントごとにそのあり方について議論 ○ スクリーンリーダーのユーザーへどういう配慮が必要か ○ キーボード操作時にどういう挙動をすれば良いのか ○ そもそもそのUIコンポーネントが使われるべきなのかどうか

Slide 40

Slide 40 text

40 議論したコンポーネントの例タブ: もともとはTabキーによるフォーカスを全てのタブに対してやる予定だったが、現在アクティブなタブへのフォーカス + 左右キーによる移動に変更もちろん role=”tab” 属性を指定

Slide 41

Slide 41 text

41 eslint-plugin-jsx-a11y ReactのJSXに対してアクセシビリティ観点のlintをしてくれる

Slide 42

Slide 42 text

42 @storybook/addon-a11y Storybookの内容についてアクセシビリティチェックを自動でかけてくれる

Slide 43

Slide 43 text

43 アクセシビリティチェック内容の定義各フェーズにおいて誰が誰向けに何をチェックすれば良いのかを定義した誰向けに見えにくい（色覚）見えにくい（弱視）見えない（スクリーンリーダー使用）上肢障害（晴眼・キーボード操作）誰が何を製作者第三者製作者第三者製作者第三者製作者第三者デザイナーパーツコントラストチェッカー具体的な画面色覚シミュレーション社内当事者によるチェックモックを拡大・反転してチェックエンジニアパーツ（各OSでの確認） lintツールによるチェック社内当事者によるチェックキーボード挙動のガイドラインを満たすかチェックキーボード挙動のガイドラインを満たすかチェック

Slide 44

Slide 44 text

05 これから 44 Section

Slide 45

Slide 45 text

45 Vibesの現在 ● Vibes自体の実装はほぼ完了したところ ● freeeアプリストアなど一部サービスへの導入を始めている

Slide 46

Slide 46 text

46 Sketchライブラリの課題 ● Sketchライブラリをどう共有して、各自が最新版を使えるようにするか ○ GitHubで管理する→デザイナーに馴染みがない、Gitの旨みがない ○ Abstractで管理する→全員がAbstract上のプロジェクトで作業する前提 ○ 結局Sketch Cloudで配布 ● 将来的にFigmaやAdobe XDなどSketch以外のツールを使うかもしれない ○ Figmaについてはインポートしての使用を試行中

Slide 47

Slide 47 text

47 CSS / React Component の課題 ● 配布方法の問題：現在CSSは1つのファイルにSCSSをトランスパイル ○ 無秩序にオーバーライドされたり、治安の悪い使われ方をされそうで怖い ○ CSS Modulesにするには設計の大幅な変更が必要 ● ReactやFlowtypeへのロックイン問題 ○ TypeScriptには一部最低限の対応はしたが不完全なまま ○ Vue.jsなど、React以外を採用するプロジェクトが出現したら……

Slide 48

Slide 48 text

48 アクセシビリティの課題 ● Vibesを導入するまでのアクセシビリティ対応が属人的になってしまう ○ 知識、技術、「いい塩梅」を知っている人しかなかなかできない ○ 開発生産性を上げるためにもVibes導入を高速前進でやっていく ● まだ取り組みを始めたばかりでわからないことが多い ○ 「デザインシステムでアクセシビリティを実現する」が本当にできるのか ○ 俺たちの戦いはまだ始まったばかりだ！