自社サービスのアクセシビリティ向上、良いパターンとアンチパターン

Transcript

1. 自社サービスのアクセシビリティ向上、

   良いパターンとアンチパターン

   2022/05/19

   伊原 力也

   @magi1125

   

   View Slide

2. 自己紹介 兼 前置き

   

   View Slide

3. 3

   伊原 力也: 本

   

   View Slide

4. アクセシビリティ向上活動の増加！🥳 しかし……

   ● アクセシビリティ向上の取り組みを始める人は増えた

   ● そのままうまく活動が継続・拡大していくところも増えた

   ● しかし、始めたあとにどう続ければいいか分からなくなったり、

   途中でしぼんでしまったりするケースも見かけるようになった

   4

   

   View Slide

5. アクセシビリティの組織浸透にはガッツが必要💪

   ● 必要とするユーザーと縁遠い感じがある

   ○ 何が問題なのかを知らない、どう問題なのか？の理解が難しい

   ○ 現場が見れないと意義を感じにくい

   ● ガイドラインのイメージが強すぎる

   ○ ガイドラインが読みにくい、解決方法の理解が難しい

   ○ 「最低限」の要求が高い

   ● Webアクセシビリティ難しすぎる問題

   5

   

   View Slide

6. 書籍出版以降のわたし

   ● 主に自社サービス提供会社において、アクセシビリティ向上活動

   ● 本業のfreeeで4年半、ここ2年ぐらいではnote、Ubie、STUDIO、

   東京都新型コロナ対策サイトのお手伝い

   6

   
 領域
 プロダクト数
 従業員数

   freee
 バックオフィス
 たくさん
 656人（21年6末時点）

   note
 メディア
 少ない
 163人（22年5月時点）

   Ubie
 医療
 そこそこ
 114人（21年4月時点）

   STUDIO
 デザインツール
 ひとつ
 21人

   東京都新型コロナ
 情報提供
 1サイト
 協力者多数

   

   View Slide

7. そこで見えてきたもの

   ● 🥳 良いパターン：進捗が良くなる進め方がある

   ● 😈 アンチパターン：足踏みになりがちなやり方がある

   ● 自社サービス提供会社において、ボトムアップで

   アクセシビリティ向上活動を継続・拡大するための参考に！

   ● ※再利用性を考えて、すごく文字文字してますがご容赦を！

   7

   

   View Slide

8. 🥳良いパターン、😈アンチパターン

   

   View Slide

9. 🥳良いパターンのまとめ

   1. オーナーを明示し、信頼できる仲間に声がけする

   2. 仲間と共に、座学だけじゃなく体験を積む

   3. 製品のコアを定義し、着手箇所を絞る

   4. 観点ごとに分担してチェックする

   5. 社外PRを念頭に、改修観点を絞る

   6. ユーザーの操作の様子をみんなで見る

   7. 公式感あるところで社外向けに発信する

   8. 研修動画＋振り返り教材で輪を広げる

   9. 別チームとも密に伴走する・切り出す

   10. 小さな勝利を積んだあとに仕組み化する

   9

   

   View Slide

10. 🥳良いパターン

    オーナーを明示し

    信頼できる仲間に声がけする

    

    View Slide

11. 🥳オーナーを明示し、信頼できる仲間に声がけする

    

    ● アクセシビリティやっている会社、

    ◯◯社といえばあの人だよね！っていうのが思い浮かぶ

    ● どの会社をみても

    アクセシビリティ推進には数人の中心メンバーがいる

    ● 先進企業ではデザイナー、エンジニア、QA、サポート、広報など

    複数のロールの人たちで構成されている

    11

    

    View Slide

12. 😈アンチパターン

    

    View Slide

13. 😈オーナーを決めずに進む

    

    ● しばらくは「あなたがやろうと言ってるから乗ろう！」という構造

    ● 周りからすると、話す相手の目印がないと声がけしにくい

    ● 勇気を持ってオーナーを名乗っていきましょう

    13

    

    View Slide

14. 😈全体に声がけしてメンバーを募集する

    

    ● 相手は「自分に言われている」と思わないので反応が薄くなる

    ● 募集した人は反応が薄くて残念な思いをする

    ● 一緒に進めたいと思う仲間を個別に誘おう

    ● まだそのフェーズでなければ、まず今の業務で信頼を勝ち取ろう

    14

    

    View Slide

15. 😈エンジニアとデザイナーだけで進める

    

    ● 始めやすいかわりに、あとで後手に回る可能性

    ● 初期からQAやサポートや広報がメンバーにいると強力

    ○ QA：チェックプロセス化

    ○ サポート：フィードバック共有

    ○ 広報：外部発信

    ● 比較的興味持ってくれる傾向にあるので、声がけして損はない

    

    15

    

    View Slide

16. 🥳良いパターン

    仲間と共に

    座学だけじゃなく体験を積む

    

    View Slide

17. 🥳仲間と共に、座学だけじゃなく体験を積む

    

    

    ● イベントを一緒にやったほうが、心に残ってモチベにつながる

    ○ いっしょにセミナー受ける

    ○ イベントや展示会にみんなで行く

    ○ freeeの研修動画をいっしょに見る、トレーニングページを触る

    ○ OSのアクセシビリティ設定やスクリーンリーダーをみんなで触ってみる

    ○ いまの微妙っぽい箇所を一緒にちょっと直してみる

    17

    

    View Slide

18. 😈アンチパターン

    

    View Slide

19. 😈WCAGをひたすら読む

    

    ● 「ガイドラインのイメージが強すぎる」なかで、

    しかし読みにくい、解決方法の理解が難しい、

    「最低限」の要求が高いので、どんどん辛くなっていく

    ● ここから入れるのは、仕様読むの自体が好きという一部の人だけ

    19

    

    View Slide

20. 😈書籍の輪読会「だけ」をやる

    ● 本を色々出している身ですが……

    ● 正直、本だけだとなかなかみんなの気持ちがアガらない

    ● 読むのはアリだけど、他の活動と混ぜたい

    20

    

    View Slide

21. 😈オーナーの自分が理解してから進める

    

    ● 座学は、仲間にとっても、自分にとってもしんどい

    ● 勉強が進まない→始められない→モチベ下がる→後回しになる

    ● アクセシビリティは沼。ここまで分かればいいというラインは無い

    ● 「自分もあんまりわからないけど一緒にやりましょう！」がいい

    ● 今日登壇している人たちも、私含め最初はみんな初心者。

    いろいろ動いては「これでいいのかな？」を繰り返してきた

    21

    

    View Slide

22. 🛠ハック！：業務委託で詳しい人を呼ぶ

    

    ● 一定レベルで詳しい人がいると安心があるのも事実

    ● 「聞ける人がいたから進んだ」ケースがnote、Ubie、 STUDIO

    ● 詳しそうな外部の人に、副業として定例で壁打ち役を頼むのはアリ

    ● Ubieでは、実際の改善を行う業務委託も募集していた。これもアリ

    22

    

    View Slide

23. 🥳良いパターン

    製品のコアを定義し、着手箇所を絞る

    

    View Slide

24. 🥳製品のコアを定義し、着手箇所を絞る

    

    

    ● チェックするのも改善するのも、稼働は発生する

    ● プロダクトのコア部分、つまり「ここが使えないと

    この製品としては意味がないというレベルの部分」は案外少ない

    ● 合理的に使える人を増やし、フィードバックを得ていくには、

    ユーザーインパクトが出やすい箇所から取り組むのがよい

    ● どの提供形態の、どの機能単位（画面）を改善対象にするかを、

    リストアップして絞り込んでいく

    ○ freeeの例（動画解説）、noteの例

    24

    

    View Slide

25. 😈アンチパターン

    

    View Slide

26. 😈各自が気がついた機能から散発的に改善する

    ● メンバー各自が異なるプロジェクトに携わっていることも多い

    ● それぞれが手持ちの案件に対して動くと、対応箇所も散発的になる

    ● プロダクト単位でみたときに、改善の程度がわかりにくくなる

    ● 改善度合いを社内外にプレゼンテーションすることも難しい

    26

    

    View Slide

27. 😈いきなり全機能で改善しようとする

    ● アクセシビリティには、最初から「全機能を、全ての観点で」

    改善しないとならない、という考え方がある気がする（主観）

    ● 確かに、最終的には全てがアクセシブルになるのが理想。

    しかし、はじめからそれを目指すのは現実的ではない

    ● まず「ユーザーにとって意味ある単位」でアクセシブルすること、

    それが「すこしでも始めることに意義がある」ことだと言える

    27

    

    View Slide

28. 🥳良いパターン

    観点ごとに分担してチェックする

    

    View Slide

29. 🥳観点ごとに分担してチェックする

    ● 製品のコア部分に対して、まずは課題の洗い出しを行う

    ● 東京都新型コロナ対策サイトでは、分担してチェックした

    ● 観点ごとにチェック担当を分けたので、方法の理解が早かった

    ○ 東京都新型コロナ対策サイトの事例 （動画解説）

    ○ チェック大会に参加した方の所感

    ● みんなで状況を共有しながら進められるのは一体感があった

    29

    

    View Slide

30. 😈 アンチパターン

    

    View Slide

31. 😈チェックせず、気になったところだけを改善する

    ● チェックを掛けないと課題の傾向がわからず、目標が立てられない

    ● チェックをやってみないと、改善結果を判定できるようにならない

    ● チェックリストはfreeeが公開中、ぜひ使ってみてください！

    ○ アクセシビリティー・チェック・リスト 

    — freeeアクセシビリティー・ガイドライン

    31

    

    View Slide

32. 😈全部の達成基準を、手本なしでチェックする

    ● さまざまなチェックを一気にやるのは大変、挫折の要因になる

    ● 手本なしだと、やり方があっているのかわからない

    ● お手本動画があるので参考にして進めましょう

    ○ 春だ！既存プロダクトのWebアクセシビリティ改善ことはじめ

    ○ もしあなたが『アクセシビリティ試験』をやることになったら

    ○ 続・もしあなたが『アクセシビリティ試験』をやることになったら

    ● ここでも、詳しい人に声を掛けて監修してもらうのはアリ！

    32

    

    View Slide

33. 🥳良いパターン

    社外PRを念頭に、改修観点を絞る

    

    View Slide

34. 🥳社外PRを念頭に、改修観点を絞る

    

    

    ● 「ある機能が、特定の観点でアクセシブルになった」

    というのが、お知らせやプレスリリースを打ちやすい単位

    ○ freee が「人事労務freee」のモバイルアプリをリリース （スクリーンリーダー対応） 

    ○ 人事労務freee、年末調整をスクリーンリーダーで利用可能 

    ○ アクセシビリティ強化の一環で、 

    スクリーンリーダーによる読み上げのカイゼンを行いました 

    ○ VoiceOver、Dynamic Typeなど、 

    iOSアプリのアクセシビリティ機能の強化を行いました 

    ○ STUDIOサイトのアクセシビリティ強化のお知らせ | STUDIO Blog （Outline改善）

    ○ STUDIOで登場した、アクセシビリティ向上に役立つ3つの新機能をご紹介！ 

    34

    

    View Slide

35. 🥳社外PRを念頭に、改修観点を絞る

    ● 「特定の観点」とはなにか？のさまざまな例

    ○ そこに要素があるとわかる「知覚可能」から取り組む

    ○ コントラストやフォーカス表示などの視覚デザインから取り組む

    ○ キーボードのみで操作可能にするところから取り組む

    ○ 機械チェックで100点を目指すところから取り組む

    

    View Slide

36. 😈アンチパターン

    

    View Slide

37. 😈各自が気がついた観点から散発的にやる

    ● 「気がついた機能から散発的に改善」と同じ

    ○ プロダクト単位でみたときに、改善の程度がわかりにくくなる

    ○ 改善度合いを社内外にプレゼンテーションすることも難しい

    37

    

    View Slide

38. 😈いきなりWCAG レベルAAを満たそうとする

    ● 「いきなり全機能で改善しようとする」と同じ

    ○ まず「ユーザーにとって意味ある単位」でアクセシブルすること、

    それが「すこしでも始めることに意義がある」ことだと言える

    38

    

    View Slide

39. 🥳良いパターン

    ユーザーの操作の様子をみんなで見る

    

    View Slide

40. 🥳ユーザーの操作の様子をみんなで見る

    

    

    ● なにかひとつだけ実施できるとしたらコレ！というぐらい重要

    40

    

    View Slide

41. 🥳ユーザーが操作する様子をみんなで見る

    

    

    ● どういう人が、どういう状況で、どうやって使おうとしているのか？

    これを目の当たりにすることで実感が生まれる

    ● ユーザーを見た感想：「（使えないのは）バグやん」

    ● 技術的な知見と、実際にアクセシビリティを必要とする状況が

    脳内で合体したとき、そこに真のモチベーションが生まれる

    ● 推進活動している知人は、みんなその状態に至っている

    41

    

    View Slide

42. 🥳補足：こうすれば会えますよ（その1）

    

    

    ● アクセシビリティ関連のイベントの登壇者にコンタクトを取る

    ● 社内の障害当事者に話を聞かせてもらう

    ● 障害当事者の生活について発信している人にコンタクトを取る

    ● クラウドソーシングサービスの障害当事者ユーザーに依頼する

    ● 障害に関する支援を行っている団体にヒアリングを実施する

    42

    

    View Slide

43. 🥳補足：こうすれば会えますよ（その2）

    

    

    ● 自社サービスのプロフィール欄などから存在を確認する

    ● サポートへの問い合わせから障害当事者ユーザーの存在を確認する

    ● アクセシビリティを必要とする潜在ユーザーとの商談に同席する

    ● サービス上にヒアリングしたい旨をお知らせとして掲載する

    ● 支援技術をオンにしたときにのみ伝わるメッセージを掲載する

    43

    

    View Slide

44. 😈アンチパターン

    

    View Slide

45. 😈アクセシビリティが必要な人と会わずに進める

    ● 利用状況や、使っている人がイメージできないので……

    ○ 重要なことだという実感を持てない

    ○ 改善結果に自信が持てない

    ○ 間違った改善、過剰な改善を行ってしまう

    45

    

    View Slide

46. 😈そもそもユーザー調査・評価のプロセスがない

    ● そもそも企画・開発プロセス上でユーザーインタビューや

    ユーザービリティテストの実施が定着しているだろうか？

    ● これをやらないプロセスの場合、

    まずユーザーに会う状況づくりから始める必要がある

    ● 参考：freeeの事例

    ○ freeeの「成果を生み出すデザインリサーチチーム」の秘密

    - ポップインサイト

    46

    

    View Slide

47. 🥳良いパターン

    公式感あるところで社外向けに発信する

    

    View Slide

48. 🥳公式感あるところで社外向けに発信する

    

    

    ● 社外には、技術ブログだけでなく、広報経由で

    公式感あるところ（お知らせ、プレスリリース）で社外告知する

    ○ ボトムアップなのに「会社として取り組んでいる感」が出せる

    ○ なぜか「社外発信のほうが社内の人に届く」という現象がある

    ○ アクセシビリティを必要とするユーザーに届くきっかけが生まれる

    ● 小さな勝利を積み上げることが、今後の展開への説得力を作る

    48

    

    View Slide

49. 🥳補足：取り組む理由を言語化して毎回記載する

    

    

    ● 社外発信するときは毎回冒頭や末尾で言う必要がある

    ● 推進活動を実施している知人はみんなこれをパッと答えられる

    ● 会社のミッション・ビジョンに接続するのが良い

    ○ freeeの例：だれもが自由に経営できる統合型経営プラットフォーム

    ■ 統合型経営プラットフォームはみんなで使うもの。

    だれもが自由に自然体で使えるプロダクトを作っていきたい

    49

    

    View Slide

50. 😈アンチパターン

    

    View Slide

51. 😈発信を後手に回す

    ● 社外発信しないと、そもそもユーザーに伝わらない

    ● 社外発信を積み上げておかないと、パッと出せる実績がない状態に

    ● IRで出すとか、商談時にまとめて送るなどの機を逸する可能性がある

    51

    

    View Slide

52. 😈なぜ取り組むのかがあいまいなまま進める

    ● 「なんとなく大事そう」では、話に乗っていいのか不安になる

    ● チームメンバーも、周りにうまく話せず、広がりが絶たれる

    ● 今日、企業の取り組み紹介で登壇している人は

    みんな「取り組む理由」を言っていると思うので、ぜひ参考に！

    52

    

    View Slide

53. 🥳良いパターン

    研修動画＋振り返り教材で輪を広げる

    

    View Slide

54. 🥳研修動画＋振り返り教材で輪を広げる

    

    

    ● 小さな勝利の発信で興味が作れたら、それを皮切りに輪を広げていく

    ● 取っ掛かりとしてfreeeの新入社員研修動画がオススメ

    ● 「自社で実際に起きていた事例」を教材にすると非常に説得力がある

    ○ noteの虚空ボタンを顕現させる社内勉強会を開催しました

    ○ ユビーAI受診相談でほんとうに起きていた怖い話

    ○ freeeの「やってしまいがちな課題」を網羅した「赤本」

    54

    

    View Slide

55. 😈アンチパターン

    

    View Slide

56. 😈振り返らず、社員が増えてもそのまま進める

    ● 新入社員は、アクセシビリティを理解していないし、

    過去に何が起きたかを知らないので、同じ課題が起きる

    ● 課題をつぶして回るのにも限界があるし、モチベが下がる

    ● アクセシビリティの課題には、デザインシステムや

    自動チェッカーだけでは防げないものも多々あるため、

    やはり理解は必要

    56

    

    View Slide

57. 🥳良いパターン

    別チームとも密に伴走する・切り出す

    

    View Slide

58. 🥳別チームとも密に伴走する・切り出す

    

    

    ● 「やってみたい！」というチームが出たら、

    アクセシビリティチーム発足時と同じように、

    いっしょに体験し、いっしょにチェックして、と伴走する

    ● 「手伝いたい！」な感じあれば、以下のような切り出し方もアリ

    ○ 160個あったアクセシビリティのエラーをエンジニア全員で改善しました
    

    ○ 【社内イベントレポート】STUDIO年末大掃除イベント2021 | STUDIO Blog
    

    ○ サマーインターン生がアクセシビリティの改善に取り組んだお話
    

    - freee Developers Blog

    58

    

    View Slide

59. 😈アンチパターン

    

    View Slide

60. 😈熱量が上がる前に別チームに対応を任せる

    

    

    ● 2020年、freeeのアクセシビリティを振り返る

    ○ 腕力の限界と停滞

    ○ 伴走したけど、密着ではなかった。結果、進捗はわずかだった

    ○ どこか「社内的に盛り上がって来たから、きっとやってくれるだろう」と思ってい
    る自分がいた

    ○ アクセシビリティが「外からきた、あと付けの、特別なもの」

    であるうちは、一定以上は改善が進行しない

    60

    

    View Slide

61. 🥳良いパターン

    小さな勝利を積んだあとに仕組み化する

    

    View Slide

62. 🥳小さな勝利を積んだあとに仕組み化する

    

    

    ● 独自ガイドライン、チェックリスト、自動チェッカー、

    デザインシステムといった仕組み化は、タイミングが大事

    ● それらが使われるのは、組織としてのアクセシビリティに対する

    熱量が上がってきてからになるため

    ● ガイドラインやチェックリストは既存のものを使ったほうが合理的

    ○ freee 社のアクセシビリティガイドラインとチェックリストを

    丸ごと導入した - hey Product Blog

    ○ 夏だ！3社のアクセシビリティー取り組み事例から考える傾向と対策

    62

    

    View Slide

63. 😈アンチパターン

    

    View Slide

64. 😈勝利を積む前に仕組み化から始める

    ● 先に仕組みを入れても、使う人が少ないので上手く機能しない

    ● 自動チェックでエラー多数だと、割れ窓になって無視される。

    まず先に、ある程度の改善が必要

    ● はじめから広くナレッジを植え付ける方向で行くのは、

    時間が掛かり、モチベ維持がハードなのでおすすめしない

    ○ freeeは、先に小さな勝利を掴んだものの、プロダクトが多数あり、

    かつ人の増加も激しかった。ゆえに勝利の水平展開よりも、

    デザインシステム構築や独自ガイドライン方面に賭けた

    64

    

    View Slide

65. 🥳まとめ😈

    

    View Slide

66. 🥳良いパターンのまとめ

    1. オーナーを明示し、信頼できる仲間に声がけする

    2. 仲間と共に、座学だけじゃなく体験を積む

    3. 製品のコアを定義し、着手箇所を絞る

    4. 観点ごとに分担してチェックする

    5. 社外PRを念頭に、改修観点を絞る

    6. ユーザーの操作の様子をみんなで見る

    7. 公式感あるところで社外向けに発信する

    8. 研修動画＋振り返り教材で輪を広げる

    9. 別チームとも密に伴走する・切り出す

    10. 小さな勝利を積んだあとに仕組み化する

    66

    

    View Slide

67. 🥳良いパターンのまとめ

    現状把握

    する

    学ぶ・体験す
    る

    対応箇所

    検討する

    改善する

    ユーザー

    評価する

    周知する

    

    View Slide

68. 🥳良いパターンのまとめ

    ● みんなで学び体験して、現状把握して、改善優先度をつけて、

    改善してみて、ユーザーに評価してもらい、

    リリースして、周知して、フィードバックを得る

    ● これ、じつは普通のプロダクト開発サイクルですよね？

    ● そこに、以下2点が加わるだけ、と考えるのが良いのでは

    ○ アクセシビリティには「広さ」があるので、そこも段階的に改善する

    ○ 広さをカバーする知見としてのガイドラインを、改善の際に活用する

    68

    

    View Slide

69. 🥳次はあなたの話を聞かせてください！😈

    ● みなさんもぜひいろいろトライして

    良いパターン、アンチパターンを見つけてください！

    ● そしてそれを私たちにも教えてください！

    ● 1年後のGAADで話が聞けるのを楽しみにしています！

    69

    

    View Slide

70. 自社サービスのアクセシビリティ向上、

    良いパターンとアンチパターン

    2022/05/19

    伊原 力也

    @magi1125

    

    View Slide