この記事はfreee Developers Advent Calendar 2020の18日目です。
こんにちは、freeeの@magi1125こと伊原です。自称「アクセシビリティで一発当て太郎」です。アクセシビリティによるビジネス貢献を模索していますが、最近は「いつ当てるの？」と聞かれて悩んだりもしています。もうちょっと待って。
この記事ではタイトル通り、2020年のfreeeにおけるアクセシビリティ関連の出来事をご紹介します。なお、2019年以前の活動については「2019年、freeeのアクセシビリティを振り返る」をご覧ください。
※アクセシビリティの向上とは、障害者高齢者を含めた幅広いユーザーに利用方法の選択肢を提供し、使える状況を広げる取り組みを指します。
腕力の限界と停滞
freee Developers Advent Calendar 2020の1日目「デザインシステム “Vibes” の育てかた」に、以下のような記載があったことにお気づきでしょうか。
アクセシビリティ「だけ」なら勉強すればいいですが、他の業務をやりながらアクセシビリティ「も」やるのはなかなかハードルが高くなってしまいます。そして、それでもアクションに移すことができた有志のメンバーの活動では限界がありました。
実際のところ、2020年の前半、プロダクト上でのアクセシビリティ改善は停滞していました。
当時の座組としては、私が各プロダクト開発チーム内の有志のメンバーに話を持ちかけ、現状のチェックを伴走したり、目標を立てるお手伝いをしたり、という形で進めていました。しかしこのやり方は上手くいきませんでした。
これにはいくつかの要因があります。
- そもそもWebアクセシビリティは難しい（Webアクセシビリティ難しすぎる問題）
- 既存プロダクトの改善はいろんな制約があり、対応箇所が限られる
- あと付けで開発チームの目標に入れても、他の目標との共存が難しい
- チーム内で自主的に始まっていないので、旗振り役の動き依存になりやすい
今になってわかることは、アクセシビリティが「外からきた、あと付けの、特別なもの」であるうちは、一定以上は改善が進行しない、ということでした。
さらに私自身、デザインリサーチの仕事が増えつつあり、継続的なフォローが難しくなっていました。2年ほど有志で集まって開いていた「アクセシビリティやっていき会議」はいったん解散し、それぞれの持ち場に戻ることになります。
新製品に組み込まれていたアクセシビリティ
こういった状況がある中でも、デザインシステムチームよって、デザインシステムVibesの拡充、アクセシビリティーガイドラインの執筆、チェックリストの作成は粛々と進行していきました。また、ガイドラインの内容をデザイナーに共有したり、チェックリストを使ったチェックをQAチームに試してもらったりと、普及への取り組みも行っていました。
やがて春になり、freee アクセシビリティー・ガイドラインが公開されました（ガイドラインの狙いについては当ブログの記事をご覧ください）。
そして夏を迎え、このブログがバージョンアップお知らせコーナーとなりつつある中で、ひとつの知らせが飛び込んできました。新規プロダクトであるプロジェクト管理freeeにおいて、アクセシビリティの担保を前提として開発が進んでいるらしい、という情報でした。事実、外部のデザイン会社であるコンセントさんにチェックしてもらったところ（この企画については後述します）、一定レベルまでアクセシブルな状態になっていたのです。
また、もうひとつの新規プロダクトであるfreeeスマート受発注でも、アクセシビリティを前提とした開発が進んでいました。ある日、社内SNSに「Lighthouse（アクセシビリティチェックツール）で100点になりました！」という投稿が上がってきたのです。
これにはデザインシステムチーム一同が驚きました。どちらも「以前に軽く頭出しはしていて、チェックは試してくれているのかな……」ぐらいに思っていたからです。まさかそんなにがっつりコミットしているとは予想しておらず、何が起きたんだ？という気持ちで秋を迎えた私たちは、それぞれの開発チームを質問攻めにしました。
アクセシビリティの『発動条件』
ふたつのプロジェクトのメンバーにヒアリングを繰り返す中で、両者に共通した、アクセシビリティ担保がチーム内で実施されるための『発動条件』が見えてきました。それは以下です。
- プロダクトやチームが小規模である
- これにより意思統一がしやすい状況がある
- アクセシビリティの知見を持つメンバーが1〜2人存在する
- 課題に対して相談できるメンバーが少数でも存在していると改善に繋がる
- デザインシステムを前提として開発している
- Vibes、アクセシビリティーガイドライン、チェックリストがこれに相当する
- 高品質を目指す合意があり、その基準のひとつにアクセシビリティを位置づけている
- セキュリティやパフォーマンスなどの様々な側面で品質を高く出そうとしている。その中で、アクセシビリティを単独ではなく他の品質基準と同列として明示している
- 品質観点のチケットを出すサイクルがあり、アクセシビリティのチケットも他と同様に扱う
- デザイナーやQAがチケットを上げるサイクルが明示されている。そして品質という観点では同一で扱うべきものとしてアクセシビリティでも優先度を下げていない
- ユーザビリティテストの実施サイクルがあり、支援技術によるテストもその一環で行う
- 専門家評価だけでなく、ユーザーによる評価も実施する。通常の利用状況におけるテストと同様に、スクリーンリーダー等を使った評価も行う
- チケットは必ず実施判断を行う運用になっている
- 2スプリント以内に必ず完了するか、『やらない』の判断をしてチケットを閉じている
上記を眺めていて感じるのは、「アクセシビリティを特別視せず、満たすべき品質の一部と捉えている」ということです。あくまで高品質なプロダクトを最速で出していこうとする流れや、そのためのプロセスをブラさずに維持し続けるという努力が先で、その中にアクセシビリティ「も」組み込まれている、といった見方が適切なのだろうと感じました。
とはいえ、その状況のなかでアクセシビリティが取り扱われるためには、やはりこれまでのアクセシビリティやっていきの普及活動も必要だったし、その実現を後押しするツールとしてのデザインシステムも必要だったということです。あの人がいたからできた、Vibesがあったからできた。そういった声もヒアリングの中ではたびたび出ていました。
やっていこうという人がいて、やっていくためのツールがあり、それらがチーム内での品質への合意として結実したときに、プロダクト開発にアクセシビリティは織り込まれるということがわかったのです。
意外な発見が続出
その他にも、従来はアンチパターンと思われていたことを覆すような、さまざまなことが発見されました。いくつか代表的なところをピックアップしてみます。
Lighthouseはわかりやすくモチベーションが上がる
これまでは、機械チェックに対してはどちらかというと慎重な姿勢を持っていました。課題指摘の網羅性が低く、しかし大量にエラーが出る恐れがあり、さらにその結果をどう直していいかわからずに混乱する恐れもあると考えていたからです。
しかし、スマート受発注の開発チームがアクセシビリティに取り組んでいるということを知れたのは、Lighthouseという機械チェックツールで100点を取ったよという投稿が社内SNSで流れてきたからでした。やはり100点のバッジはうれしいものですし、アクセシビリティにあまり詳しくない人からしても「そういう観点があるんだ」「品質を高くやっていこうとしているんだ」というのが伝わり、応援の声が集まります。
機械チェックが全てではないということを分かった上であれば、モチベーションを作る・維持していくツールとして活用していける道筋があるんだなと気づきました（このあたり詳細は当ブログの記事をご覧ください）。
チケットを出すフェーズはQA段階でもデザイン段階でもどちらでもイケる
これまでは、開発が一段落してQAに入った段階でアクセシビリティのチケットが大量に出てくるのは開発者の心理的負担が大きいのでは？と想像し、プロセス的にはアンチパターンだと推定していました。
しかし、プロジェクト管理freeeの開発現場では、実際にQAからアクセシビリティ系のチケットがドバっと届いても、特に大きな問題にはならなかったそうです。曰く「もともと品質としての合意があり、そのチケットが来ることが予想できていれば問題ない」とのこと。
また、スマート受発注の開発チーム内では、デザイナーが実装をチェックしてアクセシビリティに関するチケットを出していました。これも同様に「Shota Dayという取り組みの中でUI品質を上げていくという合意があったので、アクセシビリティはその一環として対応していた」とのこと。
つまり真にアンチパターンなのは「特定の人だけがチーム内で合意を得ずにアクセシビリティの指摘を行っていること」だったのです。そしてこれがチケットの滞留を生む原因にもなります。逆にチーム内で合意があれば、フェーズを問わず指摘は歓迎されるのでした（もちろん、問題が大きくなる前に改善するという点では、なるべくシフトレフト＝企画やデザイン段階で改善することが望ましいです）。
QA的には、アクセシビリティチェックはリソース上の負担になっていない
これまでは、QAチームにチェックしてもらうのは単純に作業が追加になって、負担が大きくなるのでは？と漠然と思っていました。
しかし、実際にチェックを行ってみたQA担当によれば、アクセシビリティチェックは通常のQA工程に比べてむしろ負担が少ないという意見でした。その理由は「テスト設計が要らないから」というものです。ガイドラインとチェックリストさえあれば、それを元にチェックをしていくだけなので隙間にシュッと入れられるし、むしろ楽だと言うのです。QAのプロフェッショナリズムと底力を見せつけられる一幕でした。
アクセシビリティは切り出しやすいフィーチャーである
これまでは、もちろん「アクセシビリティは取り組みが難しい課題である」と考えていました。しかし、上記のQA担当の話から考えるに、理解するための難易度は一定レベルあったとしても、わかってしまえば切り出して解決することはむしろやりやすいテーマなのだと知りました。
この「ガイドラインとチェックリストがあれば手がつけられる」という切り出しやすさは、別方面でも活用されました。そのひとつが、インターンの開発テーマとしてアクセシビリティ改善を実施してもらうというものです。2週間という限られた期間のなかでも、読みこなせるガイドラインと共に、適切なサポートとフィードバックがあれば、実際にプロダクトの品質を高めることに貢献できるのです（詳しくは当ブログの記事をご覧ください）。 developers.freee.co.jp
この特性をもとに、つい最近もプロジェクト管理freeeの開発チーム内では「アクセシビリティDay」という試みが実施されました。既存チケットのうち解決難易度が低いものから高いものに並んでいて、何をどうしたら良いかを相談しながら3時間一本勝負で改善を試みるというものです。謎解きのようなゲーム性もあり、とても盛り上がったようです（次回は「両手骨折でプロダクトを使おう」というテーマになる模様です）。
「プロダクトと歩調を合わせてヘルプページも」という話が進む
これまでは、ヘルプページの改善も停滞していました。以前に一度改善しようという動きがあったものの、そのまま着手するきっかけを持てずに時が経過していたのです。freeeのリリースサイクルは早く、それに追従すべく日々原稿がアップされ、内容も更新されていきます。そんな中で、アクセシビリティだけに的を絞って手を入れるのが難しいのは、ヘルプページにしても同じだったのです。
しかし、プロダクトと目標を同じくするなら、話は別です。スマート受発注のリリース準備を進めるなかで、ヘルプページ作成チームにも「プロダクトがアクセシブルになるので、ヘルプもそれに準じたい」という話を持ちかけました。こちらも背景が明確であることからスムーズに進み、原稿レベルの段階から取り組みを進めることができました。
はじめから合意があれば進めやすいという点は、ここでも明らかになったのです。また、実際に作業を進めてもらうなかで、チェックリストのフィルタや並び順などにもフィードバックをもらうことができました。
チェックリストをフォームから呼び出せるようにすると捗る
これはちょっと裏方の話です。デザインシステムチームではアクセシビリティチェックリストが使いやすくなるように改善を細かく行っており、常に最新版を使ってもらうためにフォームからチェックリストを生成出来るようにしました。
これは、チェックリストを提供するデザインシステムチーム側としても、ちょっとした革命だったと言えます。チェックされている現場がどこなのか把握してアクティブサポートができるし、社内でのチェックの実施状況が数値としてカウントできるようになりました。実施されたチェックをあとから振り返ってフィードバックループにも役立てられます。
もし同じような取り組みをはじめるかたがいたら、おすすめしたい手法です。
他社と一緒に進めると強力な後押しになる
もうひとつ大きくご紹介したい取り組みがあります。それは「他社と一緒に進める」というものです。プロジェクト管理freeeは、受託制作会社をターゲットユーザーのひとつとして開発してきました。そのターゲットにあたる人なら誰でも使えるようにすべきだと考えた結果、受託制作をビジネスとして実施しつつ、インクルーシブデザインチームを擁しているコンセントさんにレビューいただくのが最適だと考えたのです。その取組の詳細はこちらの記事をご覧ください。
結果としてこのコラボレーションは大きな成果を得ることができました。「アクセシビリティの視点」と「実際のターゲットとしてのユーザーの視点」の両方から見たフィードバックが得られるのは非常に貴重であり、開発チームとしても深い納得が得られるものでした。また、ターゲットユーザーに近い会社とのやりとりは、開発チームとしては「高めた品質が届く先」が可視化されていく体験でもあります。これは改善サイクルを回していくモチベーションをより高めることに繋がりました。
なお、個人的には、自分が元いた受託デザイン業界と、今いるSaaS業界がアクセシビリティ案件によってつながるきっかけを作れたことは、ひとつの喜びだったりします。ビジネスとしてアクセシビリティに取り組む会社がつながっていくことで、そこに取り組む意義が明文化され、世の中が変わっていくスピードをより加速できたらいいなと感じました。
デザインシステムと共に、再び「既存」に切り込む
新規プロダクト開発においてアクセシビリティを織り込む方法は明らかになりました。このナレッジを活かして、私たちは既存プロダクトのアクセシビリティ改善に再びチャレンジしていこうというフェーズにいます。
やっていこうという人がいて、やっていくためのツールがあり、それらがチーム内での品質への合意として結実したときに、プロダクト開発にアクセシビリティは織り込まれる
これを既存プロダクトにおいても再現していくことが、これからの取組みとなります。
そのためのカギは、やはりデザインシステムVibesです。Vibesはアクセシブルなコンポーネントとして実装されています。そして同時に、フロントエンドの共通化による開発生産性の向上が見込めるため、各プロダクト開発チームからの歓迎ムードもあります。アクセシブルになるものを、導入したいと言われる状況があるのです。というか、Vibesはそれを狙って作られています（詳しくはブログ記事をご覧ください）。
しかし、各プロダクトにVibesを適用していくときに「とにかく入れるんだ」という形で進めてしまっては、やはり品質への合意がおろそかになり、アクセシビリティ的にも不本意な展開になってしまいます。Vibesをただ適用するだけでは（もとよりは改善される可能性はあるものの）狙ったアクセシビリティは発揮されませんし、正しく使われなければアクセシビリティ以外の品質も下がってしまい、導入の意義が薄れてしまいます。
Vibes適用を実施する際に、まず各プロダクトの開発チーム内にアクセシビリティを理解する人が存在する状態を作っていく。そして「Vibesがもたらす品質のひとつ」としてのアクセシビリティ担保をチーム内で合意していく。これができれば、新規プロダクトと同じ構図が実現され、ガイドラインとチェックリストが活用され、改善が実施されていくはずなのです。
期待の星、モバイルアプリ
アクセシビリティ改善のプロセス化の目処が立っていくなかで、次の期待の星と目されているのが、モバイルアプリです。
これまでも、freeeのモバイルアプリはアクセシビリティの改善を試みてきました。
corp.freee.co.jp developers.freee.co.jp
こうした改善を重ねてきたエンジニアがいるモバイルチームは、アクセシビリティ改善の必要条件である「プロダクトの開発チーム内にアクセシビリティを理解する人が存在する」をすでに満たしています。
そして、モバイルアプリの立ち位置をあらためて整理したところ、これは本腰をいれてアクセシブルにするべきなんじゃないか？というチームの合意を得ることもできました。その理由は以下です。
- モバイルアプリユーザーには、アクセシビリティを必要としている絶対数が多そう
- 経費精算・勤怠打刻・給与明細確認といった従業員側が使う機能の割合が多いため
- アクセシビリティを必要とするユーザーに評価してもらいやすそう
- アクセシビリティチェックに応じてくれそうな実ユーザーが何名か存在するため
- Webと比較して、実装とチェックがやりやすそう
- ブラウザやスクリーンリーダーの違いがなく、OS・スクリーンリーダー・アプリが垂直統合されているため
- やり切るまでの道筋が見えやすそう
- Web版に比べて機能がコアに絞られており、かつ先に取り組みが進んでいる部分があるため
こういった話が出る中で、モバイルチーム内からは、品質としてクリアするというだけでなく、「誰にどこまでのことを提供する、何人に使ってもらえるようにする」といった攻めたゴール、野心的なゴールを設定してもいいのでは？という声まで挙がりました。ユーザーの課題を直接的に解決していくというプロダクト開発の目標と、アクセシビリティがもたらす「利用できる状況を増やす」という効果を、天秤に掛けるのではなく掛け算として考えるフェーズに突入したのです。
折しも、2021年3月1日からは障害者の法定雇用率が引き上げになります。企業に所属する従業員がアクセシビリティを必要とするケースは今後も増えていくでしょう。SDGsへの取り組みが企業の評価軸に加わっていく動きもあります。このようなインクルージョン、ダイバーシティといった時代の流れ、空気の移り変わりも影響しているのかもしれません。
このようにして、アクセシビリティ推進の三要素のうち、「理解がある人の参加」と「品質としての合意」が実現できました。残る要素は「ツール」です。モバイル向けデザインシステムに対するアクセシビリティ面での調整や、ネイティブアプリを前提としたガイドラインおよびチェックリストの準備といった取り組みを進めていこうと話して、一昨日のミーティングを終えました。これからの動きが楽しみです。
来年もお楽しみに！
アクセシビリティ推進の三要素は、それなりに確度が高い仮説な気はしています。しかし、それ適用できる範囲に限りがあるかは、まだわかりません。新規プロダクトではゼロベースでやり方を考えられますが、既存プロダクトではさまざまな前提や制約があります。さらに、Webとネイティブアプリではまた違った角度の問題が起きるかもしれません。
いろいろ一筋縄では行かないかもしれませんが、freeeのミッションである 「スモールビジネスを、世界の主役に。」を実現するために、私たちの戦いは続きます。
最後にすこし宣伝です。WEB+DB PRESS Vol.116にて、freeeのアクセシビリティへの取り組みを30ページほどの特集記事としてご紹介しています。ぜひご覧ください。 gihyo.jp
そして、手を貸してもいいぞという方、いらっしゃいましたらぜひご連絡ください。 jobs.freee.co.jp
明日はミスターモバイルアクセシビリティ、abeちゃん（@RyoAbe）です。
