こんにちは。サイボウズでデザイナーをしている松井です。
普段は主にサイボウズ Officeという中小企業向けのプロダクトのデザインを担当して活動しています。
前回は同じチームに所属する 西藤さん（KazuMax）に、サイボウズ Officeのアクセシビリティ改善活動の実践編について書いてもらいました（宣伝１）。
今回はアクセシビリティ改善活動のはじめかたや、チームの巻き込み方に悩む方に向けて、「サイボウズ Officeの 開発で、継続的にアクセシビリティの改善が行えるようになるまで」をまとめてみようと思います。
サイボウズ Officeは「誰でもかんたんに使える」という言葉をコンセプトに開発しています。2019年に実施したユーザーアンケートでは、シニアの方を含めた幅広い年齢の方に利用いただけている、という結果も得られています。
当時このアンケート結果をポジティブに捉えた一方で、自分はまだまだ「誰でもかんたんに使えます！」と胸を張れる状況ではないとも考えていました。
それは、サイボウズ Officeにはアクセシビリティの問題があり、使いづらい・使うことができない方がいる、という状態だったからです。
過去に参加した社内アクセシビリティ勉強会で、全盲の方を招いてサイボウズ Officeを操作する様子を見せていただく機会がありました。
そこで、スクリーンリーダーという音声を読み上げてくれるソフトとキーボードを使用した操作では、情報の入手・操作効率面を中心にとても使いにくいものになっていることを目の当たりにしました。
また、勉強会とは別で、お客様から「（サイボウズ Officeのアクセシビリティの問題で）誰かの手を借りないとできないタスクがある（使えない機能がある）」という連絡も受けていました。
前述のアンケート結果についても「シニアの方を含めた幅広い年齢の方に利用いただけている」という結果は得られましたが、例えば「シニアの方の利用する上での問題や不満足ポイント」の有無などは把握できておらず、不安を感じる状況でした。
ちょうどそのころ、PM（プロダクトマネージャー）の河合さんが中心になり、サイボウズ Officeの開発方針を策定しているところでした。
そこで、河合さんに「誰でも使える」プロダクトに近づけるために「アクセシビリティ向上」にも取り組んでいきたいと相談したところ、河合さんも現状に問題意識をもっていることがわかり、開発テーマに「アクセシビリティ向上」を追加する方向で調整を進めていくことになりました。
ここがスムーズに進んだのは、河合さんも前述の社内アクセシビリティ勉強会などに一緒に参加されており、現状に対する認識が揃っていたからだと思います。
アクセシビリティ向上に取り組むことに PMの合意はとれたのですが、具体的に何をどう進めていくかや、開発チームへの紹介や展開方法を考えていく必要がありました。
自分だけで考えるのは不安だったので、Poca11y (ポカリ) というアクセシビリティを扱うチームに所属している、アクセシビリティエキスパートの小林さんに相談をしました。
小林さんは、2014年ごろからアクセシビリティの主担当として、アクセシビリティの啓発活動や、実際の製品改善の取り組みを多数行っている方です。
前述の社内アクセシビリティ勉強会も、小林さん主催で開催されたものですね。
小林さんには、サイボウズの定義するアクセシビリティについてなどを書いてもらってます（宣伝２）。
小林さん・河合さんと活動の進め方を話し合ったところ、まずは「アクセシビリティ的にどんな問題があるか、まずは自分たちで確認してリスト化するところからはじめましょう」ということになりました。
確認は、サイボウズ Officeの主要機能の代表的な画面やパーツを対象に、上の画像のようなチェックリストを使用しておこないました。
このリストは WCAG (Web Content Accessibility Guidelines) というアクセシビリティに関する国際的なガイドラインをベースに、小林さんが社内用にまとめたものです。
その結果、大小合わせて 30件近い問題がみつかりました。
上の画像はみつかった問題リストの一部です。
例えば「見出しが適切にマークアップされていない」というのは、スクリーンリーダーを使用している視覚障害の方などが、その画面にはどんな情報があり、どういう構成になっているかが理解しづらくなってしまう問題ですね。
見出しを見出しとしてマークアップすることは当たり前のことですが、サイボウズ Officeではここからはじめていく必要がありました。
これは身近で容易に行える修正ですが、こういった積み重ねがアクセシビリティの改善につながっていきます。
自分たちのチェックリストを使った確認で、問題になりそうな箇所にある程度あたりをつけることができました。
しかし、実際にサイボウズ Officeを利用する中で、どんな問題が起きるのか・致命的になるのかは推測の域をでていません。
そこで、社内メンバーの当事者の方に協力を仰ぎ、サイボウズ Officeの主要機能を操作している様子を見せていただくことにしました。
このときの操作・様子・発言から、遭遇しやすい問題としてはどんなものがあるか、遭遇したときに致命的になる問題としてはどんなものがあるか、が判断できるようになり、現状の理解が深まります。
今回はロービジョンの kotanoriさんと、全盲エンジニアの SUGIさんに協力いただけることになりました。
kotanoriさんは普段画面を拡大しつつ必要に応じて拡大鏡を使用して作業をされているので、その状態での操作の様子をみせていただきました。
SUGIさんは普段スクリーンリーダーを利用して作業をされているので、スクリーンリーダーとキーボードでの操作の様子をみせていただきました。
実際にお二人に操作してもらいながら、考えていることをそのまましゃべっていただき、ヒアリングを行いました。
事前に自分たちでチェックしていたので想定はしていたのですが、スクリーンリーダーとキーボードを使用した操作を中心に、20件程度の問題が確認できました。
その中でも遭遇頻度が高く、利用への影響度が高いものとしては、次のようなものがありました。
- 見出しが見出しとしてマークアップされていない
- アイコンに代替テキストが設定されていない
- 位置に依存したデザインで、利用が困難なボタンがある
上２つはチェックリストを使用した事前確認でも検出できていたものですね。
これらの問題の詳細については、同じチームに所属する西藤さんが別の記事で紹介してくれていますので、そちらをご参照ください。（宣伝３）
スクリーンリーダーを利用している方にとってはどうみえていて、利用にどんな影響があるかについてイメージしやすくなると思います。
検証活動が終わってからは、具体的な改善活動につなげられるよう、ここまでに発見したアクセシビリティの問題点に対して、優先度をつけていきます。
優先度は、チェックリスト視点での改善必要性と、実利用時にみられた様子をもとにつけていきました。
ここまでで、PMの合意をとりながらサイボウズ Officeのアクセシビリティの具体的な問題点リスト（優先度つき）を作ることができました。
今後これらの改善を進める上では開発チームのメンバーにも協力してもらう必要があるので、資料にまとめて紹介する時間をもらうことにしました。
紹介する際には問題提起だけに終わらず、実際の開発活動につなげられるように、次の３つを意識しました。
- サイボウズ Officeにとってのアクセシビリティ改善の必要性・関連性を認識できる
- 現状起きている問題について、具体的な事象と深刻度がイメージできる
- コードの改修イメージがしやすく、取り組み障壁が低いものを見繕う
まず、アクセシビリティについての理解度は、メンバーによってもまちまちなので、サイボウズのアクセシビリティの定義から共有しました。
この定義と、サイボウズ Officeのコンセプトである「誰でもかんたんに使える」ことを重ねて、アクセシビリティ改善の必要性・重要性について紹介しました。
次に、社内でのアクセシビリティ調査結果の紹介です。
ここでは社内メンバーに協力してもらった際に発見した問題を中心に、実際に利用する方にとっても開発メンバーにとってもインパクトがあるものを選びました。
問題を紹介する際にはスクリーンリーダー自体に関する理解も必要なのですが、開発メンバーによってこちらの理解度も異なります。
そのため、起きている問題がイメージがしやすいように、スクリーンリーダー用の音声ブラウザのキャプチャを添えることにしました。
音声ブラウザはスクリーンリーダー用のブラウザで、画面から装飾やレイアウトなどが排除され、表示的には読み上げられる内容に近い状態になるので、こちらで肌感をつかんでもらう作戦です。
次に「どこからはじめるのがよさそうか」という話です。活動に弾みがつくように、規模が小さく取り組みやすいサイズ感で、開発メンバー的にもコードの改修イメージがしやすく、かつ確実に効果がある（提供価値の高い）ところを、はじめの一歩として提案しました。
具体的には「見出しの対応」「画像の代替テキスト対応」がこれにあたります。
これらは実利用時の深刻度や遭遇頻度が高い問題ですが、改修自体は軽微なマークアップの修正で済むもので、開発チームとしても難易度や影響が想像しやすいものだと思います。
ここまでの紹介で、開発チームからは取り組むことへの疑問や批判的な意見はでることがなく、大まかな合意を得ることができました。
一方で、この取り組みをはじめるにあたり「いまの開発フローにどう組み込むのか？どの範囲を誰が担当して、どういう流れで製品に取り込まれてリリースされるのか？」など、やり方についての質問を多く受けました。
具体的なやり方についてはこの時点で何も決めれていなかったので、私がハブになってPM・開発チーム・小林さんと協力して固めていくことになります。
ちなみにサイボウズ Officeの場合は、PMとは「製品コンセプトへの適合度・提供価値と対応コストのバランス」に、開発チームとは「起きている事象の正確性・解決への糸口・フローの整備」に重きを置いてコミュニケーションをとるとスムーズに進められる感覚があります（ここまでの活動も、この辺りを意識して進めていました）。
ここでは、アクセシビリティ改善を実際の開発フローに沿って進めながら、適宜調整していくというやり方で進めました。
事前に
- 大まかな開発フローの確認
- 各フローでの担当決め
- 直近の作業に必要な情報の共有
- 定例作業時間の設定
あたりだけ認識を合わせ、あとは定例作業時間で走りながら調整していきます。
あらかじめカッチリきめようとするとそこに時間をとられてしまいますし、実際に運用できるかどうかも分からないので、まずは実際に動きはじめることを優先しました。
ちなみに、このあたりで Poca11y (ポカリ) というアクセシビリティを扱うチームが発足しており、Officeのアクセシビリティ改善にも合流してくれることになりました。
その結果、現在では次のような開発フローでアクセシビリティ改善に取り組めるようになっています。
- 1. アクセシビリティに関するリサーチ
- 2. バックログの作成（※要件のようなもの）
- 3. 実装
- 4. アクセシビリティの改善検証
- 5. 実装レビュー
- 6. 試験
- 7. リリース
1〜4 までは主に Poca11yチームと自分が担当し、5〜7 は主に開発チームのメンバーが担当しています。
このフローと体制で、2020年の 5月版からアクセシビリティに関する改善を継続的に行えるようになりました。
過去のリリースはサイボウズアクセシビリティポータルにまとめられています。
今となってはチームで当たり前のようにアクセシビリティに取り組んでいて、常に改善ができる状態になっていますが、思い返すと、一朝一夕にはこのアクセシビリティへの取り組みを文化として根付かせることは難しかったなと思います。
小林さんの地道な啓発活動、西藤さんやアクセシビリティを扱うPoca11y (ポカリ) チームの動き、PM・開発チームのアクセシビリティへの理解などがあってこその今と言えるでしょう。
今後は既存のアクセシビリティ問題の改善だけでなく、新機能が実装されるときにアクセシビリティの問題が作り込まれないようにもしていけたらと考えています。このあたりはまた違ったアプローチが必要そうですね。
引き続き、サイボウズ Officeがより「誰でもかんたんに使える」アクセシブルな製品に近づけるよう、改善を重ねていきます。