with Advent Calendar 2024 19日目は、QAチームから杞憂(@kiyou77)がお送りします。

当記事では、週次で行っている全社MTGにおいて、アクセシビリティに関しての発表を行ったことについてお話しようかと思います。

アクセシビリティというのは、QA的に言えば品質特性である「使用性」の副品質特性のひとつで、あまりそのように語られることはありませんが「品質のいち要素」と言えるものです。

一方で、使用性のその他の副特性と比べて軽視されがちな問題もあります。私はその原因について、ひとえに「知識不足」と思っており、このような発表で少しずつ知ってもらうことが最初の一歩として重要だと考えます。

アクセシビリティの取り組みを始めたい方のご参考になれば幸いです。

アクセシビリティ社内発表に至る経緯

前提として、昨年10月より有志チームで『Webアプリケーションアクセシビリティ今日から始める現場からの改善』の輪読会を行っていたという話があります。

週1回30分、交代でレジュメを作りながら進めてつい先日、約1年の期間を経てようやく終了しました。やや時間をかけすぎた反省もありつつ、丁寧に読み進めたことでの学びであったり、何よりも中断せず継続できたという喜びもありました。

読んだだけで終わりにすべきではなく、今後どういうアクションを取るべきか、という課題感も残されていたところで、自分としてはもっとアクセシビリティに関心を持つ仲間が必要だと考えました。

とりわけ、今回の課題本が「Webアプリケーション」を対象にしたものだったこともあり、輪読会の常連メンバーは私を除きすべてがサーバーチームのエンジニアとなっていました。

しかし、弊社サービスの主力はモバイルアプリであることや、そもそもアクセシビリティはいちエンジニアだけで改善していけるものではない（品質と同じく要件レベルから改善していくべき）という点でも、様々なメンバーに関心を持ってもらう必要がありました。

そうした経緯もあり、この輪読会を通しての学びの共有（という名のアクセシビリティ啓発活動）を行えるとよいのではと、今回の社内発表に至りました。

発表準備のポイント

「発表を通して様々なメンバーに関心を持ってもらう」というのが今回の目的でした。その点を考えると、輪読会の課題本の具体的な内容紹介は、Webアプリに留まるやや狭いものとなるため、あまり触れないことにしました。

代わりに、アクセシビリティに関する基礎的な話を多く盛り込むことにしました。¹具体的には以下のような内容です。

アクセシビリティとは何か？
アクセシビリティとユーザビリティの違いは？
よくあるアクセシビリティの誤解
アクセシビリティの具体的な実装イメージ
アクセシビリティに取り組む意義

また、輪読会メンバーが現在、手軽な形でアクセシビリティチェックを行える体制を作るべく、Storybookの導入を検討してくれています。この取り組みについて、メンバーから直接紹介してもらいました。

加えて、自社に対して効果的と思われる伝え方ができればと思い、次のような内容を入れました。

競合サービスでの取り組み紹介

まずひとつは、競合サービスでのアクセシビリティの取り組み紹介です。

マッチングアプリ開発を行う上で、競合サービスの動向はできる限り追っています。そんな中でつい先日、競合サービスにおける、開発チームのアクセシビリティへの取り組み記事を拝読しました。

アクセシビリティの取り組みを始めたのもこの1年ということだそうで、立ち上げから地道に活動され、認知度を高めてきた様子が記事から伺えました。私たちが輪読会を始めた時点では、アクセシビリティの取り組みを行っているマッチングアプリはなかったため、withが先行できるかも！とも話していましたが、先を越されてしまいました。

エスニックジョークでよくある日本人には「みんなやっていますよ」というのが効果的であるというのも念頭に置きつつ、競合サービスの開発チームに対する「すごい！　リスペクト！」という気持ちと「先を越された！　悔しい！」という気持ちの葛藤を全社メンバーに共有したかったため紹介することにしました。

自社Visionの引用

ふたつ目は、自社Visionを引用し、その中にあるアクセシビリティに繋がる表現を紹介したことです。

これは『Webアプリケーションアクセシビリティ』の補足的な連載である「アクセシビリティを組織で向上させる──社内外の認知・効果測定から、新規開発への組み込みまで」の第1回記事「アクセシビリティを経営方針とつなげ⁠⁠、プロダクトマネージャーと合意する」を参考に行ったもので、アクセシビリティに取り組む理由の説明として、会社の経営方針との関係から言語化することで、広く理解を得ることができるというものです。

例えばアクセシビリティ活動の活発であるSmartHRでは「well-working 労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる。」をミッションとしています。「誰もがその人らしく働ける社会をつくる」を実現するには、ひろく利用が可能となるようアクセシビリティ改善に取り組むことは必然となります。

上記記事では、着目すべきキーワードとして以下のようなものが取り上げられています。

すべての
あらゆる人々
誰もが
みんな
世界中の
ユーザー
お客様
多様性
持続的
社会

そしてわれわれエニトグループのVision文言を見てみると、まさにこうした文言が含まれているように思われました。

「世界中へ」「望むなら誰もが」といった表現は、多様なユーザーにサービスを届ける意志の宣言であり、アクセシビリティに繋がる表現と思われたため、これを全社メンバーに紹介しました。

こうした自社組織に対して効果的な話題を入れ込みつつ、今後も継続的な活動を考えていること、Slackのアクセシビリティについて話すチャンネルにぜひ参加してほしい旨を伝えて〆る構成となりました。

発表を終えての感想

12月13日の全体会にてこの発表を行い、いくつもの感想をいただきました。

「素敵な動きだと思う！」というものや、発表の中で紹介した『モバイルアプリアクセシビリティ入門』という書籍を「早速購入しました！」とお声がけいただいたり、あるいは「発表上手ですね！」と純粋に発表を褒めてもらえたりと、嬉しい感想が続々届きました。

そして何人もの方がアクセシビリティについて話すSlackチャンネルに参加してくれました。

これまでサーバーチームのエンジニアを中心に活動してきたところを、その他の職種のメンバーが参加してくれたことで、他の書籍の輪読会であったり、具体的なアクションを始めるにしてもやりやすい状況が整ってきたなと感じています。

一方、自分でふりかえりを行う中で、発表内容について「上手く伝えきれなかった部分もあったな」という反省も出てきました。

「まずは知ることから」という伝え方をすべきだった

発表ではアクセシビリティの取り組みのハードルが上がらないように、「小さなできることから始めよう！」というのを主旨として伝えるように気を付けていました。

しかしながら、それが「実際に改善をはじめる」ということのみに伝わってしまったのではないだろうか、という懸念があります。

アクセシビリティの話をすると、必ず「やったほうがいいのは分かるけど、優先度がね～」というリアクションが返ってきます。通常の開発においては、機能や実装方法を細分化して、コストやリターンを細かく見ながらスコープを決めるのが普通だと思います。しかし、アクセシビリティに関しては、なぜか細分化されない「アクセシビリティ」という巨大な粒度で「やる/やらない」を語られ、その結果「アクセシビリティって大変だよね」とか「優先度的に今は難しいね」とか言われたりします。

これはひとえに、アクセシビリティに対する理解不足から起こっていると自分は思います。具体的なアクセシビリティ改善のイメージを知れば、いま現在開発で行っている他のタスクと比較して、どちらにメリットがあるか、どちらの優先度が高いかというのを現実的に判断できるはずです。（その意味では、提案する側が細分化して提案できれば良いので、提案を受ける側だけの問題では決してありません）

その上で個別に「やらない」という判断になるのであれば、それはそれで良いと個人的に思います。しかし「やれたほうが良いとは思う」と言いつつ積極的に知ろうとはしてもらえないことが多いため、まずはそこから始めないといけません。

ちなみに実際には、他のタスクよりも簡単にやれて効果も高い、というようなアクセシビリティ改善は確実に存在していると思っていて、なので本当に「何もやらない」のは単純に優先度判断に失敗し続けている、というのが輪読会を経ての私の所感です。

とにもかくにも、具体的に改善していくには、アクセシビリティについてもっと知ってもらう必要があります。だからこその今回の発表でしたが、発表の主旨としても「まずはアクセシビリティについて知りませんか？」という、もう少し穏当なメッセージとして発信すべきだったかも、と振り返って思いました。

終わりに

反省点については、今後の動きのところでカバーしていけたらと思います。具体的な改善のための取り組みについても、それはそれで進めていきたい所存です。実際の取り組みこそが身近な知識源となって、組織全体の知見を高めてくれるはずです。

冒頭でも書きましたが、アクセシビリティは品質のいち要素であり、その意味も込めてQAエンジニアである自分が発表を行いました。

小さな改善は自分ひとりでも出来たりしますが、大きな改善を目指すならひとりではやりきれません。「大きな声」で問題提起を行い、人を集める必要があります。

ただし「大きな声」を出すにはかなりの勇気が必要です。実際、そこで下手なことを言って発言の信頼性を失うリスクもあります。これに負けないように、色々とスキルを持っていないといけない、というのを改めて思いました。そのイメージは次のようなものです。

根拠となるデータとロジックを適切に揃えるビジネス力
それらを分かりやすく伝えるデザイン力
理屈だけでは届かない部分にリーチするためのパッション
何はともあれ、リスクを踏む勇気

適切に「大きな声」が出せるようになるのは、QAエンジニアの重要な能力と思います（QAに限りませんが）。というか、自分はそういうのが得意なQAエンジニアとしてやっていきたいです。

アクセシビリティについては、まだまだ訴えていかないといけないことが沢山あります。具体的な動きを取りつつ、活動を広く周知していけるよう今後も発表などを行っていきたいと思います。

この資料作成にあたり、当該書籍の共著者のひとりであるymrlさんのJaSST'24 Niigataでの発表資料「いま求められるソフトウェアのアクセシビリティ」をたくさん参照させていただきました。勝手ながら、ありがとうございました。
JaSST'24 Niigataでの基調講演は輪読会メンバー数人と一緒に参加し聴講しておりましたが、素晴らしい発表で感銘を受けました。 ↩