ソフトウェア開発の現場では、品質維持や向上のための活動が走っています。開発チームの中でQAを行っていたり、QAチームがいたりします。やり方はさまざまですが、何らかの活動はあります。

アクセシビリティも品質のひとつなので、QAの工程が大きく関わります。QAのプロセスにアクセシビリティを織り込み、チェックと改善を定常化させましょう。

シフトレフトを焦らず⁠、まずはQA段階のテストに組み込む

品質保証活動の分野では「シフトレフト」と呼ばれる考え方があります。スケジュール表の右側、つまり開発後のテストの段階で問題に対処するのではなく、表の左側、設計段階から対処することが全体のパフォーマンスの向上につながるという考えです。

「QA段階ではじめてチェック」はアンチパターン？

かつては筆者も、アクセシビリティもはじめからシフトレフトで取り組むべきだと考えていました。設計段階から気を付けば問題は生じにくく、改善コストも押さえられるからです。これは事実です。

そのため、開発後のQA段階ではじめてアクセシビリティチェックが行われるのはアンチパターンだと考えていました。以下の懸念があったからです。

• QAチームにとってチェックの負担が増えるのではないか
• QA段階でアクセシビリティのチケットが大量に出てくるのは開発者の心理的負担が大きいのではないか

しかし、筆者の所属会社であるfreeeでは、予想に反し、QA段階でのアクセシビリティチェックが急速に浸透しました。開発チームもチェック結果を受け入れ、改善に取り組んでいます。これにはいくつかの理由があります。

QAチームは「品質としてのアクセシビリティ」を理解できた

freeeでは、QAチームが『JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価（SQuaRE）―システム及びソフトウェア品質モデル』といった品質標準に明るかったです。使用性（Usability）の副特性としてアクセシビリティを据えています。アクセシビリティをQAチームが追うべき品質として定義できました。

なお、アクセシビリティがソフトウェア品質の構成要素であることは独立行政法人情報処理推進機構（IPA）が発行する「つながる世界のソフトウェア品質ガイド」でも触れられています（図1⁠）⁠。

アクセシビリティチェックは⁠、QAチームには負担ではなかった

QAチームにチェックしてもらうのは単純に作業が追加になって、負担が大きくなるのでは？ と漠然と思っていました。

しかし、実際にチェックを行ってみたQA担当によれば、アクセシビリティチェックそのものは通常のQA工程に比べてむしろ負担が少ないという意見でした。

その理由は「テスト設計がいらないから」というものです。ガイドラインとチェックリストさえあれば、それをもとにチェックをしていくだけなので空き時間ですぐ実施できるし、楽だとすらと言うのです。QAのプロフェッショナリズムと底力を見せつけられる一幕でした。

QAチームと開発チームには信頼関係があった

QAチームはスペシャリスト集団であり、開発チームとの信頼関係がありました。これまで多くの課題をリリース前に未然に防いできたQAチームのアウトプットなのだから、信頼し、改善しようと納得できるのでしょう。

開発チームとQAチームが「品質としての合意」ができれば、チェック結果のチケットが来ても予想できているので問題ありません。

真にアンチパターンなのは「チーム内での品質定義の合意を得ずにアクセシビリティの指摘を行っていること」だったのです。そしてこれがチケットの滞留を生む原因にもなります。逆にチーム内で合意があれば、フェーズを問わず指摘は歓迎され、改善も着手されるのでした。

QAチームとアクセシビリティの関係性については、ブログ記事「2020年、freeeのアクセシビリティを振り返る」もご覧ください。

QAチームのチェックとフィードバックを支援する

QAチームが実際にチェックを行えるようになるには、支援が必要です。連載第3回でも触れたとおり「アクセシビリティチェックの様子をデモする、チームメンバーと一緒にチェックする、そのまま一緒に改善してみる」という伴走を行います。

チェックを伴走し⁠、フォローする

QAチームにチェック方法をブリーフィングします。freeeアクセシビリティー・チェック・リストなどをもとに、チェックツールの使い方や、どのように見ていくかの概要を伝えます。実際の案件へのチェックを伴走し、結果の解釈について伝えます。

チェック実施者は、機械チェック結果のメッセージの読み解き方や、手動チェックで「怪しい」と感じたところの解釈に悩みます。すぐに質疑応答するために、Slackチャンネルなどでフォローしましょう。

フィードバックには推進者が立ち会う

はじめてチェック結果をチケットとしてフィードバックする際には、アクセシビリティに理解がある人が間に立ちましょう。具体的には、チケットの読み合わせや改善施策の検討の場に同席します。開発メンバー側からすると、課題が指摘されても、どう対処すべきかがわからないと、チケットを消化できなくなるからです。

チェック方法と改善方法が確立されていれば、「⁠アクセシビリティが品質であり、維持向上していけるものである」という納得が得られます。維持向上のプロセスに織り込まれます。

アクセシビリティのチケットを特別扱いしない

アクセシビリティの改善を進めるためには、アクセシビリティのチケットとほかのチケットを分けず、同じように扱うことが重要です。

ほかのチケットと同じ場所にアクセシビリティのチケットも記載する

以前、freeeでは、アクセシビリティのチケットを「アクセシビリティの課題だけを集めておく場所」に貯めていき、優先度も独自に設定していました。

このやり方は、アクセシビリティの課題を俯瞰したり、アクセシビリティのみを集中して改善する点では有効です。しかし、アクセシビリティだけが特別扱いになってしまうという大きなデメリットがあります。

そのため、プロジェクト単位のチケットを記載する場所にアクセシビリティの課題も記載するように切り替えました。プロジェクト単位でアクセシビリティの課題を把握し、通常のテスト後改修に織り込みます。

アクセシビリティの重大度とチケットの重大度をそろえる

QAの結果としてのチケットには重大度が振られます。アクセシビリティの課題も、ほかのチケットと同じ基準で既存の重大度になぞらえて記載します。

freeeでのチケットの重大度は以下のとおりです。

• critical：致命的、リリース前に修正必須
• major：大きな問題
• normal：可能なら直したほうがよい
• minor：直してもよいが保留も可

アクセシビリティの文脈で読み替えると以下のとおりです。freeeアクセシビリティー・ガイドラインおよびチェックリストに、この記載があります（図2⁠）⁠。

• critical：操作不能になる人がいる
• major：操作や情報取得が著しく厳しくなる人がいる
• normal：不便を感じる人が少なからずいる
• minor：問題はあるが影響は少ない

ほかのチケットと同様に重大度を振ることで、それが「使いやすい・使いにくい以前の問題であり、『⁠利用できない』バグである」という認識にそろえられます。

このようにしておかないと、「⁠できればやっておくべきだが、マストではない」「⁠問題があっても、まったく使えないわけではない」と考えてしまいます。アクセシビリティ改善の優先度が下がります。ここは強い気持ちで提言します。

初期には⁠、修正必須とせずリリースする判断も

まだQA段階でのアクセシビリティチェックが始まったばかりのころは、プロジェクト内での意識が育っていなかったり、改善の知見が貯まっていない段階です。リリース前に修正必須とすることは難しいケースもあります。

この場合、いったんリリース自体は実施し、そのあとに改修を積むという考えにスライドします。改善を重ねて、アクセシビリティに取り組むことが前提になったら、ほかのチケットと完全に扱いをそろえることを再び検討しましょう。

チケットのレビューや取り扱いを決める

チェックの結果、課題のチケットが振り出されたとしても、改善しないまま放置してしまうとチェックの意味がなくなってしまいます。また、チェックをする側も、その結果が改善につながらなければモチベーションを保ちにくいでしょう。

そのため、QA期間中に出現したチケットをどう扱っていくか、また、期間中に消化しきれなかったチケットをどう扱っていくかを、チームとして取り決めておく必要があります。これはアクセシビリティのチケットに限った話ではなく、ソフトウェア開発の現場の取り決めとして必要です。

アクセシビリティのチケットだけをあと回しにはしない

チケットをどう処理するかという点においても、アクセシビリティを特別扱いしないことが重要です。特別扱いすると、前述のとおり、それだけがあと回しになっていきやすいからです。

開発チームとQAチームの間で取り決めた「一般的なチケットの取り扱いのプロセス」に、アクセシビリティ関連のチケットの扱いも準ずるようにすべきです。

発生したチケットを処理するルール

freeeプロジェクト管理の開発チームでは次のルールを守っています。

• 発生したチケットは、2スプリント以内に必ず完了するか、「⁠やらない」の判断をしてチケットを閉じる
• 頻発する課題については、別途、品質向上にコミットする期間を設けてまとめて対応する

アクセシビリティのチケットも、このルールで処理しています。保留しないことでクリティカルな問題は潰せます。リリース速度も維持できます。

2周目からシフトレフトを目指す

サービス事業会社のWebアプリケーションは、一回作って終わりではなく、常に改善サイクルを回しながら進化します。アクセシビリティ改善の起点がテストの段階であったとしても、それが適切に次のサイクルに引き継げれば、結局は大きな流れとしては循環します。

そのため、あえて開発後のテスト段階からアクセシビリティを浸透させるというアプローチでも、組織導入が進捗する可能性があるのです。積極的に推進しましょう。

しかし、実装後のQA段階でのアクセシビリティチェックが定着すればそれでよいわけではありません。その対応だけで固定化してしまうと、「⁠QAに入った段階でアクセシビリティのチケットが大量に出てくる」という状態は続き、大量のチケットをさばくことの心理的負担はなくなりません。

アクセシビリティについて注意を払うのがQAチームだけになってしまう危険性もあります。QAチームだけに責任が偏ることは、各職能チームの理解の促進や、持続的な対応の実現という観点でも望ましくありません。

アクセシビリティは、設計、デザイン、実装、QAのすべてのフェーズで意識する必要がある品質です。はじめからシフトレフトを望む必要はありませんが、結局、シフトレフトを目指すことになります。

設計段階から気を付けておけば問題は生じにくく、改善コストも抑えられ、結果として全体のパフォーマンスも向上するのです。