こんにちは、守谷（@emim）です。

今までWebアクセシビリティについて、デザイン部*1内で勉強会を実施したり、クリエイティブ職以外への啓蒙活動などを社内でちょこちょこ開催してきました。

実施内容すべて漏れなくは報告できていませんが、このCreator's Noteでも私以外の複数のメンバーもブログ記事にまとめてくれています（Accessibilityあるいはa11yというタグで、閲覧いただけます）。

そんな中しばらく私を悩ませていたのは、いくら自分自身（デザイナー）が知識を貯めて啓蒙を進めたところで、実際プロダクトの設計フローに「アクセシビリティ施策実施」という要件が乗らない限り、永遠に改善を深部まで進められない……という現実とのジレンマでした。

そんな中！

今夏やっと、プロダクトに改善施策を反映していくためのチームを立ち上げることができました！！！👏🏻

名付けて……と思ってはいたのですが、色々あってまだ仮称「アクセシビリティやってくぞい！」チームとなっています。

せっかくなので、今回はその経緯やプロセスをご紹介していこうと思います。

仲間を増やす
- エンジニアを味方につける
- Accessibility Fridayで現状を知る
できるところから実行する

仲間を増やす

結果的には、「動いたタイミングと世界的な流れが合致した」というだけなのですが、それでは何の参考にもならないので、少しプロセスを掘り下げてみます。

エンジニアを味方につける

最近*2のWWDCやGoogle I/Oでは、それまで以前よりアクセシビリティに関するセッションが増えているのをご存知でしょうか？

ちょうどデザイン部でも開発側でも、デザイナーとエンジニアと合同で勉強会を実施できないか……と模索していた際に、公開されているWWDCやGoogle I/Oの動画を一緒に見つつ、意見交換ができないかとの企画が持ち上がりました。

ちなみにこの会は、現在も2週に1度程度の頻度で定期的に開催されています。

そしてこの会で、主催者がわりと早い段階から採用してくれたテーマが、前述のアクセシビリティ関連のセッションでした。

WWDC 2019のアーカイブサイトのキャプチャ — 出典：Writing Great Accessibility Labels - WWDC 2019 - Videos - Apple Developer

YouTubeのGoogle I/O'19のキャプチャ — 出典：What’s New in Android Accessibility (Google I/O'19) - YouTube

今までで取り上げられたのは、以下の動画です（閲覧順）。

動画はまだまだ残りがありますが、この勉強会をキッカケに、デザイナーとエンジニアが「アクセシビリティ」を軸にした会話のできる機会が増えるようになりました。

特に初回では、Appleの動画なのにクライアント*3を超えた開発（プロダクト設計概念）の話題にまで波及しました。

それまでは私が定期的にパトロールをして、プロダクトのアクセシビリティ対応状況を記録していたのですが、この会を機に「デザイナー・エンジニアみんなで使用感をチェックする会を別に作らないか」と盛り上がりました。この後の流れでAccessibility Fridayという、軽食やお酒を片手に端末の「アクセシビリティ」機能を有効にした状態で試用してみる、という別の会が発足しました。

Accessibility Fridayで現状を知る

そのAccessibility Fridayは、結局一度年明けに開催したきり、新型コロナウィルスでの在宅勤務突入の都合もあり第2回の開催が叶っていません。しかし、その1度が割と肝となりました。

実施方法としては、ひとところに参加者が集まり端末の「アクセシビリティ」機能を有効にし（とはいえ、一旦対象機能はスクリーンリーダーにフォーカス）、使用感のマズいところや意図しない挙動をする部分を録画しながら、チャットに記録を残していきました。

Accessibility Fridayで見つけた使用感の悪い部分のピックアップキャプチャ（名前は伏せています） — 意図していない挙動をするところをチャットで報告

それまでスルーされていた点が明るみに出た瞬間です。この時点で、エンジニアからすれば「少し直せば期待通りにできるのに……」という気になったようでした。

できるところから実行する

エンジニアのムズムズを手にしたら、後はもうそれを施策に移すだけです。

がそれぞれが好き自由に動くと破綻してしまうため、各クライアントの開発チームから代表担当者を募集することにしました。

動機（やる気）駆動開発

アクセシビリティ施策というのは、表面的には見えづらいものだったり、派手な変化をもたらすものではありません。

無理にお願いをしても続かなくなりそうな気がしたため、エンジニアの自主性に任せて担当者を募ることにしました。するとこれまでの甲斐があってか、iOS、Android、WebFrontendの各クライアントのエンジニアが挙手してくれました。

アクセシビリティ担当エンジニアの似顔絵

たまたまのバランスですが、東京・大阪・広島とバラバラの拠点です。ちょうど新型コロナウィルスの影響で在宅勤務にも突入していたのもあり、概ねオンラインでチームビルドしながら進めました。

各エンジニアからヒアリングをおこない、取り組みに向けた思い、これまで改善を実施しようとした際に（仕組み的に）躓いていた点、メイン開発と調整のつけられる方法、そして後に負債とならないように対応差異を出さない開発……。

エンジニア視点でまんべんなく出していただいた懸念などを元に、プロダクトマネージャーと調整しながら、メイン開発リソースに影響を与えない開発フローを模索していきました。

既存の仕組みに倣いつつ、相互判断のできるフローに

現在は、プロダクトマネージャーカンファレンス 2020 に登壇しました 👨‍🏫 - Chatwork Creator's Noteでも触れられているQPRD*4という弊社独自の簡易要件ベース開発フローに倣う形で、アクセシビリティ対応PRDという仕組みに落とし込み、アクセシビリティ改善施策を実施していっています。

PRDやQPRDフローでの要件定義とは違う特殊な点としては、要件確認者（職域を限定しないすべての開発関係者）がアクセシビリティに明るくない場合に

どの程度既存ユーザーに影響があるのか
今できていないのは何か（それがどのくらいマズいことなのか）
改修を実施することでどう変わるのか
誰に嬉しい施策（対応）なのか
開発工数がどのくらい掛かるのか（調査にどれくらい掛かるのか）
他社サービスではどのような対応がおこなわれているのか

等がわからないと、実施の承認も出せなければ、開発時間の確保（調整）もできません。

提案テンプレートに上記までカバーできる情報を埋め込む形で、チームで相談しながら新フローを策定していきました。

あとは提案者（エンジニアがメイン）が一度テンプレートに落とし込む形で要件定義をおこない、チーム内で（時には4人で対応方針にまで立ち戻って相談しながら）レビューをし、クライアントごとにマージできる条件は共通仕様として落とす。このアクセシビリティPRDを元に、各担当プロダクトマネージャーに実施承認を得たのち、メイン開発の合間を縫ってアクセシビリティ改修を実行するという流れです。

ちなみに、現時点では「アクセシビリティ施策として絶対的に正しい形」で対応をすることより、「今できる最適の形を模索して速く実行する」ことを重視しています。

夏にこの方式を確定してから今日まで、施策の実施対応（リリース済）件数はすでに8件です。すごい！

また即リリースには至らずとも、ユーザーからのスクリーンリーダーに関するふんわりとした相談なども、担当エンジニアが主体的に調査実施から対応報告を実行してくれるなど、細かな体制変化も起きています。

当面は先のAccessibility Fridayで見つかった問題を重点的に改修して行く予定ですが、気になる点などあればプロダクトのご意見・ご要望フォームなどからフィードバックください。

サービスのアクセシビリティ向上施策で日本をリードしたい

あくまでも私の観測範囲内では……という条件つきではありますが、ネイティブのアプリ開発エンジニアでアクセシビリティのことに声を上げる日本人エンジニアは、まだそんなに多くないように思います。今回たまたま同じ組織で働くことになった、というだけの縁ではあるのですが、同じ方向を向いて開発に向かってくれる仲間ができて嬉しい限りです。

先日もAndroidエンジニアの池田がLTでこんな発表をしてくれました。

speakerdeck.com

じわじわと賛同者も増えて来ています。

（言い訳にはなりますが）私が一人で社外に向けて発信していても「ひとりよがり」感が滲み出てしまうのでは……と、ブログ発信の筆が重くなってしまっていました。今後はエンジニアからの、アクセシビリティに関する情報発信も増えて行くのではと思います。

「すべての人に」使ってもらえるサービスとなるように、エンジニアと協力してひとつでも多くの施策をこれからも実行していければと考えていますので、ご期待ください。

現在、採用も強化中です。ちょっとでも内容に興味を持ってくださった方がいらしたら、ぜひ以下より要項をご確認の上ご応募ください。

recruit.chatwork.com

ところでPRとなりますが、この記事の内容を含め、Webアクセシビリティとデザイナーの関わり方を以下のオンラインイベントで発表します。まだ枠も空いていますので、興味のある方はぜひ。 a11yschool.doorkeeper.jp

*1:デザイン部：現在のChatworkには「デザイン部」ではなく「プロダクトデザイン部」と「ブランドデザイン室」というものが存在していますが、過去記事の状況や両方を合わせた部署を表すラベルとして、デザイン部と表現しています。

*2:最近：……と言いつつ2020年は新型コロナウィルスの影響でいずれも開催されなかったので、用いたソースは2019年のものです。

*3:クライアント：iOS、Android、WebなどOSやプラットフォームなどの差についての表現。名称は色々ありますが、この場では「クライアント」と表現を統一しています。

*4:QPRD：Quick Product Requirements Documentのことで、PRDの要素を抽出した簡易版の要件定義テンプレート