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

by Rikiya Ihara / magi

Slide 1

Slide 1 text

自社サービスのアクセシビリティ向上、  良いパターンとアンチパターン  2022/05/19  伊原力也  @magi1125 

Slide 2

Slide 2 text

自己紹介兼前置き 

Slide 3

Slide 3 text

3  伊原力也: 本 

Slide 4

Slide 4 text

アクセシビリティ向上活動の増加！🥳 しかし……  ● アクセシビリティ向上の取り組みを始める人は増えた  ● そのままうまく活動が継続・拡大していくところも増えた  ● しかし、始めたあとにどう続ければいいか分からなくなったり、  途中でしぼんでしまったりするケースも見かけるようになった  4 

Slide 5

Slide 5 text

アクセシビリティの組織浸透にはガッツが必要💪  ● 必要とするユーザーと縁遠い感じがある  ○ 何が問題なのかを知らない、どう問題なのか？の理解が難しい  ○ 現場が見れないと意義を感じにくい  ● ガイドラインのイメージが強すぎる  ○ ガイドラインが読みにくい、解決方法の理解が難しい  ○ 「最低限」の要求が高い  ● Webアクセシビリティ難しすぎる問題  5 

Slide 6

Slide 6 text

書籍出版以降のわたし  ● 主に自社サービス提供会社において、アクセシビリティ向上活動  ● 本業のfreeeで4年半、ここ2年ぐらいではnote、Ubie、STUDIO、  東京都新型コロナ対策サイトのお手伝い  6    領域  プロダクト数  従業員数  freee  バックオフィス  たくさん  656人（21年6末時点）  note  メディア  少ない  163人（22年5月時点）  Ubie  医療  そこそこ  114人（21年4月時点）  STUDIO  デザインツール  ひとつ  21人  東京都新型コロナ  情報提供  1サイト  協力者多数 

Slide 7

Slide 7 text

そこで見えてきたもの  ● 🥳 良いパターン：進捗が良くなる進め方がある  ● 😈 アンチパターン：足踏みになりがちなやり方がある  ● 自社サービス提供会社において、ボトムアップで  アクセシビリティ向上活動を継続・拡大するための参考に！  ● ※再利用性を考えて、すごく文字文字してますがご容赦を！  7 

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

🥳良いパターンのまとめ  1. オーナーを明示し、信頼できる仲間に声がけする  2. 仲間と共に、座学だけじゃなく体験を積む  3. 製品のコアを定義し、着手箇所を絞る  4. 観点ごとに分担してチェックする  5. 社外PRを念頭に、改修観点を絞る  6. ユーザーの操作の様子をみんなで見る  7. 公式感あるところで社外向けに発信する  8. 研修動画＋振り返り教材で輪を広げる  9. 別チームとも密に伴走する・切り出す  10. 小さな勝利を積んだあとに仕組み化する  9 

Slide 10

Slide 10 text

🥳良いパターン  オーナーを明示し  信頼できる仲間に声がけする 

Slide 11

Slide 11 text

🥳オーナーを明示し、信頼できる仲間に声がけする    ● アクセシビリティやっている会社、  ◯◯社といえばあの人だよね！っていうのが思い浮かぶ  ● どの会社をみても  アクセシビリティ推進には数人の中心メンバーがいる  ● 先進企業ではデザイナー、エンジニア、QA、サポート、広報など  複数のロールの人たちで構成されている  11 

Slide 12

Slide 12 text

😈アンチパターン 

Slide 13

Slide 13 text

😈オーナーを決めずに進む    ● しばらくは「あなたがやろうと言ってるから乗ろう！」という構造  ● 周りからすると、話す相手の目印がないと声がけしにくい  ● 勇気を持ってオーナーを名乗っていきましょう  13 

Slide 14

Slide 14 text

😈全体に声がけしてメンバーを募集する    ● 相手は「自分に言われている」と思わないので反応が薄くなる  ● 募集した人は反応が薄くて残念な思いをする  ● 一緒に進めたいと思う仲間を個別に誘おう  ● まだそのフェーズでなければ、まず今の業務で信頼を勝ち取ろう  14 

Slide 15

Slide 15 text

😈エンジニアとデザイナーだけで進める    ● 始めやすいかわりに、あとで後手に回る可能性  ● 初期からQAやサポートや広報がメンバーにいると強力  ○ QA：チェックプロセス化  ○ サポート：フィードバック共有  ○ 広報：外部発信  ● 比較的興味持ってくれる傾向にあるので、声がけして損はない    15 

Slide 16

Slide 16 text

🥳良いパターン  仲間と共に  座学だけじゃなく体験を積む 

Slide 17

Slide 17 text

🥳仲間と共に、座学だけじゃなく体験を積む      ● イベントを一緒にやったほうが、心に残ってモチベにつながる  ○ いっしょにセミナー受ける  ○ イベントや展示会にみんなで行く  ○ freeeの研修動画をいっしょに見る、トレーニングページを触る  ○ OSのアクセシビリティ設定やスクリーンリーダーをみんなで触ってみる  ○ いまの微妙っぽい箇所を一緒にちょっと直してみる  17 

Slide 18

Slide 18 text

😈アンチパターン 

Slide 19

Slide 19 text

😈WCAGをひたすら読む    ● 「ガイドラインのイメージが強すぎる」なかで、  しかし読みにくい、解決方法の理解が難しい、  「最低限」の要求が高いので、どんどん辛くなっていく  ● ここから入れるのは、仕様読むの自体が好きという一部の人だけ  19 

Slide 20

Slide 20 text

😈書籍の輪読会「だけ」をやる  ● 本を色々出している身ですが……  ● 正直、本だけだとなかなかみんなの気持ちがアガらない  ● 読むのはアリだけど、他の活動と混ぜたい  20 

Slide 21

Slide 21 text

😈オーナーの自分が理解してから進める    ● 座学は、仲間にとっても、自分にとってもしんどい  ● 勉強が進まない→始められない→モチベ下がる→後回しになる  ● アクセシビリティは沼。ここまで分かればいいというラインは無い  ● 「自分もあんまりわからないけど一緒にやりましょう！」がいい  ● 今日登壇している人たちも、私含め最初はみんな初心者。  いろいろ動いては「これでいいのかな？」を繰り返してきた  21 

Slide 22

Slide 22 text

🛠ハック！：業務委託で詳しい人を呼ぶ    ● 一定レベルで詳しい人がいると安心があるのも事実  ● 「聞ける人がいたから進んだ」ケースがnote、Ubie、 STUDIO  ● 詳しそうな外部の人に、副業として定例で壁打ち役を頼むのはアリ  ● Ubieでは、実際の改善を行う業務委託も募集していた。これもアリ  22 

Slide 23

Slide 23 text

🥳良いパターン  製品のコアを定義し、着手箇所を絞る 

Slide 24

Slide 24 text

🥳製品のコアを定義し、着手箇所を絞る      ● チェックするのも改善するのも、稼働は発生する  ● プロダクトのコア部分、つまり「ここが使えないと  この製品としては意味がないというレベルの部分」は案外少ない  ● 合理的に使える人を増やし、フィードバックを得ていくには、  ユーザーインパクトが出やすい箇所から取り組むのがよい  ● どの提供形態の、どの機能単位（画面）を改善対象にするかを、  リストアップして絞り込んでいく  ○ freeeの例（動画解説）、noteの例  24 

Slide 25

Slide 25 text

😈アンチパターン 

Slide 26

Slide 26 text

😈各自が気がついた機能から散発的に改善する  ● メンバー各自が異なるプロジェクトに携わっていることも多い  ● それぞれが手持ちの案件に対して動くと、対応箇所も散発的になる  ● プロダクト単位でみたときに、改善の程度がわかりにくくなる  ● 改善度合いを社内外にプレゼンテーションすることも難しい  26 

Slide 27

Slide 27 text

😈いきなり全機能で改善しようとする  ● アクセシビリティには、最初から「全機能を、全ての観点で」  改善しないとならない、という考え方がある気がする（主観）  ● 確かに、最終的には全てがアクセシブルになるのが理想。  しかし、はじめからそれを目指すのは現実的ではない  ● まず「ユーザーにとって意味ある単位」でアクセシブルすること、  それが「すこしでも始めることに意義がある」ことだと言える  27 

Slide 28

Slide 28 text

🥳良いパターン  観点ごとに分担してチェックする 

Slide 29

Slide 29 text

🥳観点ごとに分担してチェックする  ● 製品のコア部分に対して、まずは課題の洗い出しを行う  ● 東京都新型コロナ対策サイトでは、分担してチェックした  ● 観点ごとにチェック担当を分けたので、方法の理解が早かった  ○ 東京都新型コロナ対策サイトの事例（動画解説）  ○ チェック大会に参加した方の所感  ● みんなで状況を共有しながら進められるのは一体感があった  29 

Slide 30

Slide 30 text

😈 アンチパターン 

Slide 31

Slide 31 text

😈チェックせず、気になったところだけを改善する  ● チェックを掛けないと課題の傾向がわからず、目標が立てられない  ● チェックをやってみないと、改善結果を判定できるようにならない  ● チェックリストはfreeeが公開中、ぜひ使ってみてください！  ○ アクセシビリティー・チェック・リスト   — freeeアクセシビリティー・ガイドライン  31 

Slide 32

Slide 32 text

😈全部の達成基準を、手本なしでチェックする  ● さまざまなチェックを一気にやるのは大変、挫折の要因になる  ● 手本なしだと、やり方があっているのかわからない  ● お手本動画があるので参考にして進めましょう  ○ 春だ！既存プロダクトのWebアクセシビリティ改善ことはじめ  ○ もしあなたが『アクセシビリティ試験』をやることになったら  ○ 続・もしあなたが『アクセシビリティ試験』をやることになったら  ● ここでも、詳しい人に声を掛けて監修してもらうのはアリ！  32 

Slide 33

Slide 33 text

🥳良いパターン  社外PRを念頭に、改修観点を絞る 

Slide 34

Slide 34 text

🥳社外PRを念頭に、改修観点を絞る      ● 「ある機能が、特定の観点でアクセシブルになった」  というのが、お知らせやプレスリリースを打ちやすい単位  ○ freee が「人事労務freee」のモバイルアプリをリリース（スクリーンリーダー対応）   ○ 人事労務freee、年末調整をスクリーンリーダーで利用可能   ○ アクセシビリティ強化の一環で、   スクリーンリーダーによる読み上げのカイゼンを行いました   ○ VoiceOver、Dynamic Typeなど、   iOSアプリのアクセシビリティ機能の強化を行いました   ○ STUDIOサイトのアクセシビリティ強化のお知らせ | STUDIO Blog （Outline改善）  ○ STUDIOで登場した、アクセシビリティ向上に役立つ3つの新機能をご紹介！   34 

Slide 35

Slide 35 text

🥳社外PRを念頭に、改修観点を絞る  ● 「特定の観点」とはなにか？のさまざまな例  ○ そこに要素があるとわかる「知覚可能」から取り組む  ○ コントラストやフォーカス表示などの視覚デザインから取り組む  ○ キーボードのみで操作可能にするところから取り組む  ○ 機械チェックで100点を目指すところから取り組む 

Slide 36

Slide 36 text

😈アンチパターン 

Slide 37

Slide 37 text

😈各自が気がついた観点から散発的にやる  ● 「気がついた機能から散発的に改善」と同じ  ○ プロダクト単位でみたときに、改善の程度がわかりにくくなる  ○ 改善度合いを社内外にプレゼンテーションすることも難しい  37 

Slide 38

Slide 38 text

😈いきなりWCAG レベルAAを満たそうとする  ● 「いきなり全機能で改善しようとする」と同じ  ○ まず「ユーザーにとって意味ある単位」でアクセシブルすること、  それが「すこしでも始めることに意義がある」ことだと言える  38 

Slide 39

Slide 39 text

🥳良いパターン  ユーザーの操作の様子をみんなで見る 

Slide 40

Slide 40 text

🥳ユーザーの操作の様子をみんなで見る      ● なにかひとつだけ実施できるとしたらコレ！というぐらい重要  40 

Slide 41

Slide 41 text

🥳ユーザーが操作する様子をみんなで見る      ● どういう人が、どういう状況で、どうやって使おうとしているのか？  これを目の当たりにすることで実感が生まれる  ● ユーザーを見た感想：「（使えないのは）バグやん」  ● 技術的な知見と、実際にアクセシビリティを必要とする状況が  脳内で合体したとき、そこに真のモチベーションが生まれる  ● 推進活動している知人は、みんなその状態に至っている  41 

Slide 42

Slide 42 text

🥳補足：こうすれば会えますよ（その1）      ● アクセシビリティ関連のイベントの登壇者にコンタクトを取る  ● 社内の障害当事者に話を聞かせてもらう  ● 障害当事者の生活について発信している人にコンタクトを取る  ● クラウドソーシングサービスの障害当事者ユーザーに依頼する  ● 障害に関する支援を行っている団体にヒアリングを実施する  42 

Slide 43

Slide 43 text

🥳補足：こうすれば会えますよ（その2）      ● 自社サービスのプロフィール欄などから存在を確認する  ● サポートへの問い合わせから障害当事者ユーザーの存在を確認する  ● アクセシビリティを必要とする潜在ユーザーとの商談に同席する  ● サービス上にヒアリングしたい旨をお知らせとして掲載する  ● 支援技術をオンにしたときにのみ伝わるメッセージを掲載する  43 

Slide 44

Slide 44 text

😈アンチパターン 

Slide 45

Slide 45 text

😈アクセシビリティが必要な人と会わずに進める  ● 利用状況や、使っている人がイメージできないので……  ○ 重要なことだという実感を持てない  ○ 改善結果に自信が持てない  ○ 間違った改善、過剰な改善を行ってしまう  45 

Slide 46

Slide 46 text

😈そもそもユーザー調査・評価のプロセスがない  ● そもそも企画・開発プロセス上でユーザーインタビューや  ユーザービリティテストの実施が定着しているだろうか？  ● これをやらないプロセスの場合、  まずユーザーに会う状況づくりから始める必要がある  ● 参考：freeeの事例  ○ freeeの「成果を生み出すデザインリサーチチーム」の秘密  - ポップインサイト  46 

Slide 47

Slide 47 text

🥳良いパターン  公式感あるところで社外向けに発信する 

Slide 48

Slide 48 text

🥳公式感あるところで社外向けに発信する      ● 社外には、技術ブログだけでなく、広報経由で  公式感あるところ（お知らせ、プレスリリース）で社外告知する  ○ ボトムアップなのに「会社として取り組んでいる感」が出せる  ○ なぜか「社外発信のほうが社内の人に届く」という現象がある  ○ アクセシビリティを必要とするユーザーに届くきっかけが生まれる  ● 小さな勝利を積み上げることが、今後の展開への説得力を作る  48 

Slide 49

Slide 49 text

🥳補足：取り組む理由を言語化して毎回記載する      ● 社外発信するときは毎回冒頭や末尾で言う必要がある  ● 推進活動を実施している知人はみんなこれをパッと答えられる  ● 会社のミッション・ビジョンに接続するのが良い  ○ freeeの例：だれもが自由に経営できる統合型経営プラットフォーム  ■ 統合型経営プラットフォームはみんなで使うもの。  だれもが自由に自然体で使えるプロダクトを作っていきたい  49 

Slide 50

Slide 50 text

😈アンチパターン 

Slide 51

Slide 51 text

😈発信を後手に回す  ● 社外発信しないと、そもそもユーザーに伝わらない  ● 社外発信を積み上げておかないと、パッと出せる実績がない状態に  ● IRで出すとか、商談時にまとめて送るなどの機を逸する可能性がある  51 

Slide 52

Slide 52 text

😈なぜ取り組むのかがあいまいなまま進める  ● 「なんとなく大事そう」では、話に乗っていいのか不安になる  ● チームメンバーも、周りにうまく話せず、広がりが絶たれる  ● 今日、企業の取り組み紹介で登壇している人は  みんな「取り組む理由」を言っていると思うので、ぜひ参考に！  52 

Slide 53

Slide 53 text

🥳良いパターン  研修動画＋振り返り教材で輪を広げる 

Slide 54

Slide 54 text

🥳研修動画＋振り返り教材で輪を広げる      ● 小さな勝利の発信で興味が作れたら、それを皮切りに輪を広げていく  ● 取っ掛かりとしてfreeeの新入社員研修動画がオススメ  ● 「自社で実際に起きていた事例」を教材にすると非常に説得力がある  ○ noteの虚空ボタンを顕現させる社内勉強会を開催しました  ○ ユビーAI受診相談でほんとうに起きていた怖い話  ○ freeeの「やってしまいがちな課題」を網羅した「赤本」  54 

Slide 55

Slide 55 text

😈アンチパターン 

Slide 56

Slide 56 text

😈振り返らず、社員が増えてもそのまま進める  ● 新入社員は、アクセシビリティを理解していないし、  過去に何が起きたかを知らないので、同じ課題が起きる  ● 課題をつぶして回るのにも限界があるし、モチベが下がる  ● アクセシビリティの課題には、デザインシステムや  自動チェッカーだけでは防げないものも多々あるため、  やはり理解は必要  56 

Slide 57

Slide 57 text

🥳良いパターン  別チームとも密に伴走する・切り出す 

Slide 58

Slide 58 text

🥳別チームとも密に伴走する・切り出す      ● 「やってみたい！」というチームが出たら、  アクセシビリティチーム発足時と同じように、  いっしょに体験し、いっしょにチェックして、と伴走する  ● 「手伝いたい！」な感じあれば、以下のような切り出し方もアリ  ○ 160個あったアクセシビリティのエラーをエンジニア全員で改善しました   ○ 【社内イベントレポート】STUDIO年末大掃除イベント2021 | STUDIO Blog   ○ サマーインターン生がアクセシビリティの改善に取り組んだお話   - freee Developers Blog  58 

Slide 59

Slide 59 text

😈アンチパターン 

Slide 60

Slide 60 text

😈熱量が上がる前に別チームに対応を任せる      ● 2020年、freeeのアクセシビリティを振り返る  ○ 腕力の限界と停滞  ○ 伴走したけど、密着ではなかった。結果、進捗はわずかだった  ○ どこか「社内的に盛り上がって来たから、きっとやってくれるだろう」と思っている自分がいた  ○ アクセシビリティが「外からきた、あと付けの、特別なもの」  であるうちは、一定以上は改善が進行しない  60 

Slide 61

Slide 61 text

🥳良いパターン  小さな勝利を積んだあとに仕組み化する 

Slide 62

Slide 62 text

🥳小さな勝利を積んだあとに仕組み化する      ● 独自ガイドライン、チェックリスト、自動チェッカー、  デザインシステムといった仕組み化は、タイミングが大事  ● それらが使われるのは、組織としてのアクセシビリティに対する  熱量が上がってきてからになるため  ● ガイドラインやチェックリストは既存のものを使ったほうが合理的  ○ freee 社のアクセシビリティガイドラインとチェックリストを  丸ごと導入した - hey Product Blog  ○ 夏だ！3社のアクセシビリティー取り組み事例から考える傾向と対策  62 

Slide 63

Slide 63 text

😈アンチパターン 

Slide 64

Slide 64 text

😈勝利を積む前に仕組み化から始める  ● 先に仕組みを入れても、使う人が少ないので上手く機能しない  ● 自動チェックでエラー多数だと、割れ窓になって無視される。  まず先に、ある程度の改善が必要  ● はじめから広くナレッジを植え付ける方向で行くのは、  時間が掛かり、モチベ維持がハードなのでおすすめしない  ○ freeeは、先に小さな勝利を掴んだものの、プロダクトが多数あり、  かつ人の増加も激しかった。ゆえに勝利の水平展開よりも、  デザインシステム構築や独自ガイドライン方面に賭けた  64 

Slide 65

Slide 65 text

🥳まとめ😈 

Slide 66

Slide 66 text

Slide 67

Slide 67 text

🥳良いパターンのまとめ  現状把握  する  学ぶ・体験する  対応箇所  検討する  改善する  ユーザー  評価する  周知する 

Slide 68

Slide 68 text

🥳良いパターンのまとめ  ● みんなで学び体験して、現状把握して、改善優先度をつけて、  改善してみて、ユーザーに評価してもらい、  リリースして、周知して、フィードバックを得る  ● これ、じつは普通のプロダクト開発サイクルですよね？  ● そこに、以下2点が加わるだけ、と考えるのが良いのでは  ○ アクセシビリティには「広さ」があるので、そこも段階的に改善する  ○ 広さをカバーする知見としてのガイドラインを、改善の際に活用する  68 

Slide 69

Slide 69 text

🥳次はあなたの話を聞かせてください！😈  ● みなさんもぜひいろいろトライして  良いパターン、アンチパターンを見つけてください！  ● そしてそれを私たちにも教えてください！  ● 1年後のGAADで話が聞けるのを楽しみにしています！  69 

Slide 70

Slide 70 text

自社サービスのアクセシビリティ向上、  良いパターンとアンチパターン  2022/05/19  伊原力也  @magi1125 