先日、board（SaaS）のアクセシビリティー改善の取り組みの現在地（2022年10月）というブログを書きましたが、今回はもう少し細かい話で、どのようにboardのデプロイサイクルの中に組み込んでいるかという話です。
boardの基本的なデプロイサイクル
厳密に決めているわけではないのですが、ほぼ週1でデプロイしています。
大きな機能は開発ロードマップとして半年ごとに公開していますが、これらは開発に数ヶ月〜半年単位でかかるものが多く、それ以外の細かい改善は、問い合わせ状況やメインの開発との兼ね合いを見て、バランスを取りつつ進めています。
細かい改善ばかりに時間を割いていたらメインの開発が進まないし、メインの開発ばかりしていたら細かい改善が進まないので、バランスを取りながら進めています。
アクセシビリティー改善は「boardとしてやりたいこと枠」と「細かい改善枠」
昨年、board（SaaS）の開発内容の決め方（2021年版）というブログを書いてますが、この中で、開発する内容は、大きく以下の4つに分かれると書いていました。
- 要望が多い（ニーズが多い）機能追加や既存機能の改善
- 中長期的な世の中の流れや業務改善の方向性
- boardとしてやりたいこと
- 既存機能の細かい改善
アクセシビリティー改善の取り組みは、このうちの「boardとしてやりたいこと」と「既存機能の細かい改善」に該当します。
アクセシビリティー改善は、1つ1つの開発規模が大きくなるようなものは少なく、どちらかというと小さい修正が大量にあるイメージです。
そのため、短期的に全部やりきるのは無理だし、大量の修正を一気にやると、確認時の集中力の維持が難しくなってミスも発生しやすくなります。そのため、週1のデプロイの中で少しずつ入れていき、数年かけてやりきろう、というスタンスで、無理のないペースでやっています。
Pull Requestは小さく
アクセシビリティー改善の取り組みは、Chrome・Edge・Firefox・Safariというブラウザーだけでなく、いくつかのスクリーンリーダーでも確認するので、そこそこ確認の手間がかかります。
1つのPull Requestが大きくなってしまうと、その確認に時間がかかりマージしにくくなってしまいます。そのため、1つのトピックでも、数画面ごとにPull Requestを分けて、Pull Requestのサイズを極力小さくしました。
それをいくつも溜めておいて、他のデプロイ内容との兼ね合いで、1つだけマージしたり、複数マージしたりして、ボリュームを調整しています。
週1でデプロイしているので、目安として、「半日程度でアクセシビリティー関連のデプロイ予定のものを通しで確認できる程度のボリューム」です。
また、「roleやaria属性の追加だけ」のように既存機能の挙動に影響しないようなものは、テストも楽ですし、心理的にも気楽です。そのため、他のデプロイ内容が重めのときはアクセシビリティー改善を軽めにするなど、デプロイ全体でそういうバランスの取り方をしています。
改善後の再チェックのタイミング
先日のブログに書いたように、アクセシビリティー改善の支援をディーゼロさんにお願いしています。
ディーゼロさんにアクセシビリティーチェックを行って頂き、そのフィードバックを基に修正後、修正したものを再チェックしてもらっていたのですが、こちらのペースが遅いと、ディーゼロさんを待たせてしまうことになります。
別にプレッシャーをかけられたわけでもないのですが、再チェックは週1で行ってもらっていたので、「チェックするものがない」という状態にならないようにすることで、良いペースメーカーになっていました。
再チェック期間は7ヶ月ほどあったのですが、この中で「今週は再チェック対象なしです」というのは1回しかなかったように記憶しています。
継続大事
アクセシビリティー改善の取り組みは、とにかく「継続」に尽きるかなと思っています。
実際、boardもまだまだ改善すべき箇所はいくらでもあるし、「スクリーンリーダーで使えるけど使いにくい」かもしれないけど、1つ1つ潰していくことで前進はするはずなので、地道にやっています。
Webアクセシビリティーは、HTMLの仕様として定められているものが多くあるので、「HTMLの仕様を正しく理解して書く」「View側のリファクタリング」をやっているようなイメージです。
また、1つ1つが小さいので、ある程度理解が進めば、少しずつちょっとした合間にやっていくことができます。そのため、うちみたいに小さい会社で「boardの開発に3人しか関わっていない」という体制でも、アクセシビリティー改善に取り組めるし、それを1年継続すれば、少しずつかたちになってきます。
3年前に取り組んだカラーユニバーサルデザインのときも同じことを思ったのですが、一度しっかりやってある程度理解すると、その後はそれを考慮して開発できるし、ちょっとした改善もやりやすくなります。
今回、最初の5ヶ月ほど、メンバーの1人をアクセシビリティー改善にほぼフルアサインしたのは、社内でそういう体制（ある程度理解した状態）を作るためでもありました。
ひとまず、継続できる土台はできたので、あとは、粛々と全画面に展開していきます。
