有効打は「把握・検討・改善・評価」のサイクル　散発的になりがちな既存プロダクトのアクセシビリティ改善

社内アクセシビリティ向上活動がはじまるパターン

伊原力也氏：私から「既存プロダクトのアクセシビリティー改善の第1歩」というところで、前説をお話しします。

アクセシビリティ向上の活動について、初めの1歩と言っているのですが、その初めの1歩の手前で「だいたいこういうふうに事が起こるよね」みたいなことをちょっと書いてみました。

これが社内アクセシビリティ向上活動の始まりパターンです。何社さんかに聞いてみると、だいたいこういうパターンが多そうだなと思いました。

最初に取り組みたいと思う人が社内に出現します。その出現した人が、社内チャットとかSNSのチャンネルとかでアクセシビリティの話をするところを作り、情報が流されていきます。そうすると、そこが気になってる人がリアクションをしていきます。

手前味噌ながら、アクセシビリティ関連書籍をちょっと出しているのですが、その人たちで今度は書籍の輪読会が行われて、それでわかることによって、その集まった人たちが手を出せるところの改善を試みます。

そのあとに「今やってるのはこういうことです」とか「こういうことが必要だと思います」というのを社内プレゼンするという流れが、よくあるパターンなのかなと思います。

その後どうするのかというところで、それ以降に進めるかどうかにちょっと壁や階段があります。「階段があったうえで、上っていけるようにする必要があるよね」と思っています。

既存プロダクトのアクセシビリティ改善は散発的になりがち

今日は既存プロダクトの話なので、これから新しく作るプロダクトの話はあまりしません。ただ少しだけお話ししておくと、新しく作る場合、デベロッパーブログにも書いているとおり、我々が勝手に三種の神器と言っている、やっていこうという人がいて、やっていこうという合意があって、そのためにやるツールがあれば、やり始められることが多いと思います。

品質としてアクセシビリティを「他の品質と分け隔てなくやっていこうよ」と最初に決めていて、それをチェックする仕組みや支援する仕組みがあれば、織り込まれてやるプロダクトが2つや3つ出てきているので、たぶんこれはこうなんだろうとわかります。

既存プロダクトの場合は、取り組んでいくパターンのこの「各々が手を出せるところの改善を試みる」が、既存のプロダクトの「ちょっとよくないな」と思うところを直すところに当たります。

これ自体は必要なことで、やってみてどういう感じに事が進むのかを肌感でつかむという意味では、大いに意味はあるなと思います。

ただ一方で、この課題認識は各々に限られるので、チームとしての取り組みに移行しにくかったりします。また、直してる箇所が各々が触ってる場所になるので、散発的になってしまって、まとまったかたちで「これ、できたね」となるまでの期間がけっこう長くなりがちだと思います。

既存プロダクト改善のサイクルを回す

これに対して僕らが今取り組んでいて「これは有効打なんじゃないか？」と思っていることは、まずは既存プロダクトに対して関わっているチームが、そのアクセシビリティの状況の現状把握するということです。自分たちが日々触っているものが、どのレベルなのかを把握することがまず土台となると思います。

チェックするのを全部見るというよりは、機能的にコアというか「この部分が使えなかったら、そもそもこのプロダクトとして意味を成さない」ところを見定めて、そこをチェックします。

それらをチェックした後に、それを直す難易度とか「ここは今度別の理由で改修が入るから一緒にやろうか」とかそういう一緒に乗れる波に乗る。あとはお知らせやプレスリリースというかたちで言えそうな単位で、これらのバランスでやっていくところを決めるとよいと思います。

ちょっと図解します。最初はこの左側の一番上にある「アクセシビリティを学ぶ」というのがあります。A11yはアクセシビリティの略です。

何にせよそのとっかかりをつかんだ後に現状把握して、対応箇所を検討して、改善して、評価します。この結果を「けっこうできてますよ」と周知することで、またやる人が増えます。そして、学ぶ。こういうサイクルに入るんじゃないかなと思います。

現状を把握して、使えないところのスコアリングをする

特に今日は、この「現状把握する」と「対応箇所を検討する」をお話をしていきたいなと思っています。

ここを詳しく言うと、大きく2つに分けられます。現状把握をする対象を選ぶという意味で、便宜的にユーザーサイドと書いていますが、まず、モバイル、PC、Web、アプリなど、提供形態ごとに提供している機能や画面のリストを作ります。

そこに対して、アクセシブルじゃないとそもそもこのアプリとしての意味を成さない、プロダクトとして意味を成さないという点でスコア付けをします。それに対して、今度はチェックリストを用いてアクセシビリティのチェックをします。結果を元に、それをやるための難易度を見積もります。

直近手を入れるところのほうがやりやすいので「そこに乗っかってやれそうなところはあるかね？」と確認して、やっていく順番を決めます。

実際、この使えないところを致命的かどうかスコア付けするのをfreeeでやっている例です。

例えばサインアップ画面や、オンボーディングやログインが並んでいます。ユーザーインパクトの面で、今挙げているところは、そこが通過できないとぜんぜん使い始められないところなので、そういったものを定義しています。

反対に、使えなくてもアプリとして意味がないとまでは言えないところ。例えばレシート撮影は、撮影したレシートをアップロードできれば、アプリ側から撮影をしなくても、経費精算はできるので、代替手段があるのであれば、これが使えなくても直ちにアプリとして使用不能とまでは言えません。そういったところのスコア付けをしています。

こういった情報を集めたうえでチェックをして、やっていく順番を決めます。チェックの仕方についてはまた後ほどお話しします。

修正箇所の対応の順番を決める

このやっていく順番を決めるのは何かというと、提供形態です。例えばPCのWeb、モバイルのWeb、iOSアプリ、Androidアプリなどの機能単位です。サインアップ、ログイン、チュートリアルなど、どのアクセシビリティ観点かというのもあります。

アクセシビリティガイドラインだと、シングルAと呼ばれる、これは満たしてほしいという最低基準があるのですが、それよりもさらに細かい単位で、どこをまずやるかを考えようというのが、僕らのやり方であり提案です。

例えば、キーボード操作はできるようにしようとか、スクリーンリーダーできちんと使えるようにしようとか、コントラストはまずきちんとしようとか、そういった単位ですね。

あるいはアクセシビリティチェッカーで見つかった範囲をまず潰して、100点にするという手法から選ぶこともあるかなと思います。

それに対して、どんなやり方でいつまでにやるかというところで、先ほど挙げたような、これから直すところに乗っかるみたいな話もありますし、目標設定をしてきちんとやっていくみたいなものもありますし、アクセシビリティ云々ではなくて20パーセントルールや品質改善活動の時間を使うというのもありますし、さらにはデザインシステムを当てていこうというプロジェクトがあるのであれば、そこと一緒にやることもあるかなと思います。

これをできたかどうか、どう評価するかですが、チェッカーを通過するか確認したり、開発チーム内でチェックリストでチェックしたり、QAチームにチェックしてもらったり、あるいは障害当事者によるユーザビリティテストで評価します。

このあたりが決められると、ターゲットを絞ってやっていくことができるんじゃないかなと思います。

これを一言で言うと、プレスリリースやお知らせや記事が出せそうな単位で考えるといいのかなと思います。どういった機能が、どういった状況で使えるようになったというかたちにすると、記事やお知らせにしやすいかなと思うので、そういったまとまりで考えるのがいいのかなと思います。

逆に、先ほど言ったような、ガイドラインのシングルA全部満たすとかだと、かなり膨大であったり長大だったり、時間もすごくかかるので、「まずはこういった単位でこれができるようになりました」と言う。例えばスクリーンリーダーでできるようになりましたとか、キーボード操作ができるようになりましたとか、そういった単位で出していくのが、1つのマイルストーンの置き方としてはいいんじゃないかなと思っています。

freeeでも、「人事労務freeeのモバイルアプリがスクリーンリーダーで使えるようになりました」とか「年末調整がスクリーンリーダーでできるようになりました」とか「プロジェクト管理freeeがアクセシビリティを織り込んだ改善スプリントで作られるようになりました」とか、そういったような出し方をしています。

他社さんでもこういった例はあります。例えばSmartHR（株式会社SmartHR）さんは「コントラスト改善しました」というようなものを出したり、STUDIO（STUDIO株式会社）さんだとアウトラインなんですね。「キーボード操作する時のフォーカスの表示がきちんと出るようにしました」とか。アメーバブログだと「キーボードによるいいね！ボタンが操作できます」とか。サイボウズ（サイボウズ株式会社）さんだと「サイボウズオフィスの詳細画面に見出しが付きました」とか。株式会社ヌーラボさんの「Backlog」も「アクセシビリティ改善のこれとこれとこれをやりました」というような出し方をしています。こういうかたちで進めていくのがよいのでは？　と考えています。

次にチェックリストでチェックするところです。ここも今まではチェックすること自体がけっこう大変というか、ガイドラインを見てもなかなかわかりにくいところがあったと思うのですが、freeeの「アクセシビリティチェックリスト」が、4月に出ているので、これを元にチェックしてもらえると捗るのではないかなと思っています。

ということで、アクセシビリティガイドラインとアクセシビリティチェックリストとは何なのか、引き続きお話しいただこうと思います。よろしくお願いします。

（次回へつづく）