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

41104bf685ee28d9c760ef29db690e5b?s=47 ymrl
March 26, 2019

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

41104bf685ee28d9c760ef29db690e5b?s=128

ymrl

March 26, 2019
Tweet

Transcript

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

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

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

  4. Company Profile 会社情報 4 会社名 freee株式会社(フリー株式会社) 設立年月日 2012年7月9日 代表取締役 佐々木

    大輔 資本金 161億603万円(資本準備金など含む) 従業員数 505名(2019年1月1日時点) 事業内容 クラウド型バックオフィスサービスの 開発・販売
  5. Products 製品・サービス 1/2 5 中小企業の経理業務を効率化。 帳簿や決算書作成・請求業務に対応。リアルタイムに数字を把握できる 給与計算や労務管理を大幅に効率化。 給与明細作成や年末調整、入社手続きから勤怠管理まで対応 税務申告書作成業務を効率化。 法人税・消費税・法定調書・申請届出や電子申告にも対応

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

    Webで申し込みでき、最短4営業日で発行。 創業時でも本人確認書類だけで審査可能
  7. 7 freeeに入って5年間での変化 • 資金調達 3億円→160億円 • 従業員数 17人→500人超 • エンジニア・デザイナー

    11人→100人超 • 会計freeeのみ → 会計・人事労務・申告を筆頭に7つの製品 • 個人事業主が大半 → 数百人規模の上場企業にも導入
  8. 02 サービス開発で変化したこと 8 Section

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

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

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

    フロントエンドに不慣れなエンジニアでもやる
  12. 12 会社が大きくなってきた頃の Web UI 開発 • BootstrapベースのUIを徐々に卒業し、freee独自のUIに変化していった • 人事労務freeeがリニューアルし、ここだけカラースキームが緑系になった •

    エンジニアもデザイナーも増えたが、CSSが得意な人はあまり増えなかった ➔ UIデザイン・フロントエンド実装で求められる要件が複雑化する一方で、 それを支える環境整備の不備が目立つようになってきた
  13. 13 陥ってしまった事態 • デザイナーごとに作る画面モックのUIの差異が大きくなっていった • フロントに不慣れな人も実装するので、画面モックと実装にも差が産まれる • 画面モックを再現するのにCSSが足りておらず、毎回書く(コピペする) • CSSの配置や書き方の指針がなく、stylesheetsディレクトリがカオスに

    ➔ 見た目が揃っていなかったり、同じ見た目でも違う挙動をするUIが大量発生 ➔ それっぽいCSSを毎回探したり書いたりコピペしたりしていて生産性も低下
  14. 14 これらの問題解消のためのチーム、AG部の誕生 group_inou / HEART (single mix) https://www.youtube.com/watch?v=w_os8HqfxHc

  15. 15 AG部 • 統一的なUIを作るためのチームとして発足 • AG部 = Atomic Design and

    Guideline 部 • Atomic DesignなUIコンポーネントとUIを作る上でのガイドラインを作る • デザイナー数名とエンジニア数名で組織
  16. 16 AG部の目標 • どのデザイナーでも「freeeの統一されたUI」をデザインできるようにする • フロントエンドに不慣れなエンジニア、特にCSSに不慣れなエンジニアでも「freeeの 統一されたUI」を実装できるようにする • これらを通して生産性を向上して、爆速で機能開発できるようにする

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

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

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

  20. 20 ガイドラインの例

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

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

  23. 23 vibes とは • Atomic Designによる設計 • Sketchライブラリ と CSS

    / React Component実装 • 統一されたブランドイメージ、ユーザビリティ、アクセシビリティを担保
  24. 24 Atomic Design DeNA DESIGN BLOG「Atomic Design を分かったつもりになる」 https://design.dena.com/design/atomic-design-を分かったつもりになる/ UIを化学物質に見立て、組み合わせによってデザインしていく考え方

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

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

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

  28. 04 アクセシビリティ 28 Section

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

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

    • むしろアクセシビリティ対応を強みにしていきたい
  31. 31 法定雇用率 従業員45.5人以上の企業では2.2%以上の障害者雇用が義務 厚生労働省 https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/koyou/shougaisha/04.html

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

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

  34. 34

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

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

  37. 37 Webアプリとしてのfreeeがアクセシブルであるには • 機能がどんどん増えていくので少ない人数でやっていくのには限界がある • アクセシビリティ人材を確保するのが難しい ◦ いきなりWCAG準拠は難しいので、「いい塩梅」でやっていくしかない ◦ サーバー/フロントの役割分担がないので全員が教育される必要がある

    ➔ デザインシステムがアクセシビリティを担保して、 それを使って画面を組むとアクセシブルになるなら解決するのでは!!
  38. 38 デザインシステムがアクセシブルであるために • 視覚障害者へのヒアリングやコンポーネントの挙動についての議論 • eslint-plugin-jsx-a11y や @storybook/addon-a11y の導入 •

    アクセシビリティチェックするべき内容の定義
  39. 39 ヒアリング・議論 • VibesのUIコンポーネント定義ができてきた段階で中根にヒアリング • UIコンポーネントごとにそのあり方について議論 ◦ スクリーンリーダーのユーザーへどういう配慮が必要か ◦ キーボード操作時にどういう挙動をすれば良いのか

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

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

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

  43. 43 アクセシビリティチェック内容の定義 各フェーズにおいて誰が誰向けに何をチェックすれば良いのかを定義した 誰向けに 見えにくい(色覚) 見えにくい(弱視) 見えない (スクリーンリーダー使用) 上肢障害 (晴眼・キーボード操作)

    誰が 何を 製作者 第三者 製作者 第三者 製作者 第三者 製作者 第三者 デザイナー パーツ コントラスト チェッカー 具体的な画面 色覚シミュレー ション 社内当事者に よるチェック モックを拡大・ 反転してチェッ ク エンジニア パーツ (各OSでの確 認) lintツールに よるチェック 社内当事者に よるチェック キーボード挙 動のガイドライ ンを満たすか チェック キーボード挙 動のガイドライ ンを満たすか チェック
  44. 05 これから 44 Section

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

  46. 46 Sketchライブラリの課題 • Sketchライブラリをどう共有して、各自が最新版を使えるようにするか ◦ GitHubで管理する→デザイナーに馴染みがない、Gitの旨みがない ◦ Abstractで管理する→全員がAbstract上のプロジェクトで作業する前提 ◦ 結局Sketch

    Cloudで配布 • 将来的にFigmaやAdobe XDなどSketch以外のツールを使うかもしれない ◦ Figmaについてはインポートしての使用を試行中
  47. 47 CSS / React Component の課題 • 配布方法の問題:現在CSSは1つのファイルにSCSSをトランスパイル ◦ 無秩序にオーバーライドされたり、治安の悪い使われ方をされそうで怖い

    ◦ CSS Modulesにするには設計の大幅な変更が必要 • ReactやFlowtypeへのロックイン問題 ◦ TypeScriptには一部最低限の対応はしたが不完全なまま ◦ Vue.jsなど、React以外を採用するプロジェクトが出現したら……
  48. 48 アクセシビリティの課題 • Vibesを導入するまでのアクセシビリティ対応が属人的になってしまう ◦ 知識、技術、「いい塩梅」を知っている人しかなかなかできない ◦ 開発生産性を上げるためにもVibes導入を高速前進でやっていく • まだ取り組みを始めたばかりでわからないことが多い

    ◦ 「デザインシステムでアクセシビリティを実現する」が本当にできるのか ◦ 俺たちの戦いはまだ始まったばかりだ!
  49. 49 来週もイベントやります https://connpass.com/event/125166/

  50. スモールビジネスを、 世界の主役に。