人事労務freeeのアクセシビリティへの取組み ~ アクセシビリティQAのススメ ~ / hr freee accessibility QA

Transcript

1. freee 株式会社
 2019.05.16 人事労務freeeのアクセシビリティへの取組み ~ アクセシビリティQAのススメ ~

2. 竹田 祥 freee関西支社 開発部長 ・エンジニア ・プロダクトマネージャー ・アクセシビリティ初級 2

3. None

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


5. None

6. 6 アイデアやパッションやスキルがあれば
 だれでもビジネスを強くできるプラットフォーム


7. Q.この数字は何でしょう
 99.7%

8. 中小企業 99.7% A.日本の企業規模の割合
 ※出典：中小企業庁 平成26年 


9. この99.7%のビジネスを
 サポートし、強くしたい


10. None

11. ビジネスをはじめる

12. ビジネスを続ける、育てる

13. アクセシビリティ に取組む理由

14. 14 アイデアやパッションやスキルがあれば
 だれでもビジネスを強くできるプラットフォーム


15. アイデアやパッションやスキルがあれば
 だれでもビジネスを強くできるプラットフォーム


16. だれでも ＝ あらゆる人


17. アクセシビリティ対応
 =
 あらゆる人が使えるようにする


18. freeeが目指している
 ものと完全に一致
 ↓
 やらない理由がない


19. どうやっているか

20. アクセシビリティQA
 という仕組みを始めました


21. そもそも ”QA” とは
 品質保証 サービスの開発において 機能の 、デザインの などは 一般的に実施されている。

22. “アクセシビリティQA” とは
 機能やデザインと同じく 「アクセシビリティの品質保証」 を開発プロセスに組み込む

23. チーム構成

24. アクセシビリティやっていき CAO (Chief Accessibility Ojisan) 会計フリー開発メンバー モバイル開発メンバー etc 人事労務フリー開発メンバー

25. CAO (Chief Accessibility Ojisan) 中根さん / 全盲のエンジニア / AccSell運営

26. AKO (Accessibility no hon Kaiteru Ojisan) 伊原さん / PM /

    アクセシビリティ本の執筆、監修

27. • アクセシビリティやっていき がある • 先ほどの強豪 名を軸に、各開発チームからエンジニアやデ ザイナー、 など複数のメンバーが参加 • 全体で使う共通のライブラリなどの作成

    • それぞれが各プロダクトでアクセシビリティを意識した開発を 行いつつ、 にて情報共有や悩み相談を行う

28. プロセス

29. つの観点でクオリティをチェック システムQA デザインQA アクセシビリティQA 動作テストチーム UI/UXデザイナー 強豪2名

30. アクセシビリティQA 強豪2名 • アクセシビリティ が存在し、他のチェックと同様にリ リースまでのプロセスに組み込まれている • 今は強豪 名がチェック（今後広げたい） •

    画面モック時点での事前チェック、検証環境で実際に動作 する状態でのチェックの 段階実施

31. 強豪のおじさん2名が厳しくチェック

32. 具体的な事例

33. 月リリース 「特別休暇」機能

34. 勤怠管理担当者が会社独自の休暇を定義する

35. 従業員は日々の勤務でその休暇を取得できる

36. アクセシビリティ の流れ

37. DesignDoc(要件まとめ)作成 / PM UXデザイン → UIモック作成 / デザイナー アクセシビリティQA(事前チェック) /

    強豪

38. 強豪のおじさん2名が厳しくチェック

39. Adobe XDで作ったモックに強豪が指摘やアドバイス

40. モックを元に以下のチェックを行う ・デザインで改善できるもの ・実装時に気をつけるもの

41. デザインで解決できるものはモックを修正して報告

42. コーディング時に解決すべきものはgithub issueに

43. ここまで終わったら 実際のコーディングへ

44. コーディング&検証環境へアップ / エンジニア アクセシビリティQA(実動作のチェック) / 強豪 ※システムQA、デザインQAも並行して実施 ※各指摘の影響範囲によっては実施順序を調整

45. 強豪のおじさん2名が厳しくチェック

46. 実画面を元に以下のチェックを行う ・スクリーンリーダーの解釈確認 ・障害を持つ方にとっての操作感 　(実用に耐えうるか)

47. 具体的な指摘内容がコメントされる 要約：aria-labelちゃんと設定してね☆

48. 指摘内容はgithub issueに

49. その後、優先度に応じて実際に対応する

50. レビューする人のために確認方法をしっかり書く

51. 優先度の高い指摘 に対応できたら 無事にリリース　

52. 優先度の低いissueは改善時間に対応 大阪チームだと毎週金曜日の午後は自由に使える 「たこ Hack Day」 この時間にアクセシビリティ対応を進めるエンジニアも。

53. アクセシビリティ に役立つ情報 強豪がいなくても大丈夫！

54. 強豪の一人 中根さん が運用してるサイト

55. 強豪の一人 伊原さん が執筆 監修された書籍 で「アクセシビリティ」で検索

56. デザイニングWebアクセシビリティを実践するためのチェックリスト
 様作成

57. ※その他、随時更新します！
 まずは始めてみることが大事です
 ぜひ一緒にチャレンジしましょう


58. 58 アイデアやパッションやスキルがあれば
 “だれでも” ビジネスを強くできるプラットフォーム
 を実現していきます。ご期待ください。


59. None