「どこまでやるか」をチームで決める。少人数の推進役から始めるアクセシビリティの伴走プロセス

開発プロジェクトの中で、まずは一部のメンバーが推進し、その後にチームみんなで取り組むように広げていきたいという状況はよくあるのではないでしょうか。
今回の記事では、アクセシビリティ推進をチーム全員で取り組むようシフトしていったプロセスの実例を書いてみたいと思います。

この記事ではアクセシビリティの推進にフォーカスしますが、それに限らず、何らかの取り組みでチーム全体への浸透・普及に苦労している方に読んでいただけたら幸いです。

職能横断で取り組む方向にシフトする

プロジェクトスタート時は、「アクセシビリティよくわからない」というチーム組成になるケースも多いのではないかと思います。

そのような出だしでは、まずは推進役の数名で、

• アクセシビリティの対応基準を決める
• アクセシビリティ対応に必要なドキュメントを用意する
• 企画やデザインの FIX 前に、アクセシビリティ観点からレビューを行わせてもらうよう声かけをする
• 実装のアクセシビリティチェックを行う
• 実装の修正を行う

ところから始めます。

が、このやり方を続けていくと、アクセシビリティ推進の属人化という課題を抱えることになります。プロジェクトのゴールとして企画やデザインの段階から「アクセシビリティのトレードオフ」を全員が判断できる体制を作りたい。

そんな時は、職能横断で取り組める方向に徐々にシフトしていく必要があります。

職能横断で取り組む6つの施策

そこで、職能を横断してアクセシビリティに取り組むための一歩として、以下のような施策を進めてみます。ここではひとつひとつは深掘りせずに紹介します。

• 運用定例： アクセシビリティに特化した定例を週一くらいの頻度で実施。困りごとや課題感、浸透具合を早期に吸い上げ、その場で次のアクションを判断します。現場を観察し、軌道修正をこまめに行い、意思決定の停滞を防ぎます。
• 職能を横断したワーク： ワーク形式で目線合わせや意識の醸成を目指します。「なぜやるのか」というアクセシビリティのアンチパターンを体験し、どのような状態がユーザーにとってクリティカルな問題となるか目線をそろえます。次に、「どうやるか」という、チームで取り組む時の課題感の洗い出しや、アイディア出しを行います。
  段階的に Why と How の理解を促すのが重要で、全員でアクセシビリティに取り組むという文化の下地を作ります。
• チェックリストの作成： アクセシビリティを推進するとき、対応の基準となる「チェックリスト」の存在は不可欠です。WAIC が公開している実装チェックリストなどお手本はたくさんありますが、プロジェクト、チーム、対応方針に合わせてカスタマイズするのがよいと思います。職能ごとにチェックしたい場合は、職能で項目を分けて用意します。
• アクセシビリティチェック会： 推進役と一緒にページごとにアクセシビリティチェックを行います。、同期的に行うのが重要で、個々のアクセシビリティ習熟度にフォーカスして判断軸の材料や達成手段を伝えます。デザイナーやエンジニアが自分でアクセシビリティ品質を担保できる範囲を広げます。
• ワークフローへの組み込み： 企画立案から開発まで、どの職能においてもアクセシビリティのチェックができるよう運用プロセスとチェックリストを整理します。これまでになかったプロセスを組み込むわけですから、ハレーションも起きやすいところです。それぞれの職種のコアな責務や、前後の工程の職種と重なり合う領域を定義し直す。「なぜこのプロセスが必要なのか」を言語化する。この2点を周知して、全員が全工程でアクセシビリティ品質を担保できるようにします。
• 座学型の勉強会：チームのアクセシビリティ習熟度が上がってきたタイミングで、WCAG などの読み合わせで知識をインプットします。体験が伴った状態で知識をインプットできると理解が深まりますし、複数人で読み合わせをすることで達成方法についてのディスカッションで判断軸を育てることができます。

負荷にあわせ、プロセスやチェックを柔軟に変化させる

こうして実際にアクセシビリティを少しずつチームの中に醸成していった時、「チェックリストの項目を守ると制限がかかり、やりたいことができないのでは」「プロセスが増えるので機能開発のスピードが遅くなるのでは」という懸念が出たことがありました。

その時はどこが負荷と感じているか観察・対話し、チェックリストのメンテナンスやプロセスの見直しを行いました。

• チェックリストの項目に優先順位をつけ、職能別にクリティカルな項目に絞り込む
• チェックリストは同じ項目内容であっても職能ごとに優先順位に傾斜をかけ、企画段階ではクリティカルにしないがデザイン段階でクリティカルに設定する、開発段階では達成できてるものとして別の項目をクリティカルとする、など、ロールごとに品質を担保するようにする
• 職種を横断するアクセシビリティ観点でのレビュープロセスは、「気軽に会話する場」として設計し直す
• アクセシビリティ対応をどこまでリリース内容に含めるか、推進側で基準を作るのではなくチーム内で都度判断してもらう

このような細やかな軌道修正によって負荷を調整し、形骸化せず、チームにとって持続可能な体制、関係者全員がオーナーシップを持って取り組めるプロセスを作っていきました。

全員で取り組みたい、全員に浸透させていきたい時に、がちがちにやっても長続きしません。チームの形にあわせてオーナーシップを持たせる柔軟さが、重要に感じます。

アクセシビリティ対応をチームでコントロールする

こうした取り組みで、アクセシビリティに対するチームの認識が少しずつ変わることを実感しました。

アクセシビリティは推進側から押し付けられるものではなく、コストや期間という制約の中で調整する「判断基準のある技術」として認識してもらえるようになったかなと。

その変化によって、品質とスピードの落とし所をチーム全体、エンジニアだけでなく PdM やデザイナーも巻き込んで、議論のテーブルに乗せられるようになったと思います。

「たしかに△△といった対応もできた方が望ましいが、この企画には⚪︎⚪︎という背景や制約があり、可逆的なアクションのため、今回は△△対応は行わなくてもユーザーに大きな影響はない」

「企画・デザインの意図は◻︎◻︎のため、この alt テキストは空であってもデリバリーしたい情報は欠落しない」

こういった小さな合意形成が、推進役の介在なしに方方で進むようになりました。

推進役が判断を独占するのではなく、チーム全員でプロジェクトのさまざまなバランスを考えながら、対応へのさじ加減をコントロールできるようになりました。

伴走者としての役割

推進する側の役割は、正しい答えを出し続けることではありません。 現場の負荷を観察し、チームが自ら「やる判断 / やらない判断」を含めた意思決定をできるようにガイドすることだと思います。

仕組みを現場に合わせて変化させ、自分ごととして捉えられる材料をそろえ続けることが、チームの持続的な開発を支える武器になるなと思います。

Gaji-Laboは、私たちが抜けた後もチームが同じ判断を続けられる状態を目指して支援しています。

特定の誰かの知識や熱意に依存せず、職能が違っても共通の論点で話し合い、チームとしてアクセシビリティに向き合えるようになることが、アクセシビリティを特別な取り組みにせず、当たり前のものとして定着させることができると考えているからです。

以下記事も、ぜひ合わせてご覧ください。

また、Gaji-Laboが支援させていただいたジョブメドレーのアクセシビリティ向上の取り組みと、「プロジェクトをやりきる」文化を読んでいただけると、よりリアルにプロジェクトの現場感がわかると思います。こちらもお読みいただけたらうれしいです。