こんにちは。アクセシビリティ・エンジニアのSUGIです。

私は全盲のエンジニアとして、2020年4月からサイボウズのデザイン&リサーチでお仕事をしています。

この記事は、とある全盲の新入社員の働き方を4回にわたって連載していく企画の3番目の記事です。今回は協働編です。前回はツール編・自己表現編でした。次回はテレワーク編を紹介します。

さて、就活および入社前、こんな不安を感じていました。

おそらく同じような悩みを抱えている人がいるのではないでしょうか。

そこで今回は、「（視覚的な情報格差による）周囲との理解や作業の速度差をどう埋めていけば良いか」について、現状の私のやり方を紹介します。一例として参考になれば幸いです。

連載第１回「ツール編」↓

連載第２回「自己表現編」↓

私の仕事の紹介

【仕事内容】

サイボウズ デザイン&リサーチには、アクセシビリティに特化したポカリ(Poca11y)チームがあります。

私はポカリチームで、kintone/Garoon/サイボウズ Officeといったサイボウズが手掛けるプロダクトのアクセシビリティ向上活動と、アクセシビリティの社内外への啓発活動を行っています。
プロダクトのアクセシビリティ情報や社内勉強会の様子は、サイボウズ アクセシビリティ | Cybozu Accessibilityで随時発信していきます。

【作業環境】

スクリーンリーダーはオープンソースのNVDAをメインで利用しています。そのほかアクセシビリティ検証用にPC-Talkerをインストールしています。
NVDAは現在世界で最も使われているスクリーンリーダーです。

協働する上で不安だったこと

私が働く前に不安だったことは、「（視覚的な情報格差による）周囲との理解や作業の速度差をどう埋めていけば良いか」ということでした。

視覚情報の差で後れを取ったり、相手を待たせてしまったとき、プレッシャーを感じたり焦ったりしてしまいます。
スクリーンリーダーの音声は高速で聞いているけれど、多かれ少なかれ速度差は発生します。

それはおそらく、次の2つの問題に起因していると思っています。
1つ目は、情報アクセスの問題です。スクリーンリーダーでは図や映像情報にアクセスできません。
2つ目は一度に受け取れる情報量の問題です。スクリーンリーダーでは画面全体を一度に確認できず、カーソルがあたっているただ1点のみを読みます。

私の課題は、仕事をしていけばかならず直面するであろう、周囲との速度差をどう埋めるかでした。

たとえば「資料xのyページを参照してください」と言われた時、資料xを探してyページの頭出しをするのにだいぶ時間がかかります。
探している間に会議が進行すると、会議の内容を聞き漏らしかねません。

たとえばワークショップで作業タイムになった時、作業を完了させるまで時間がかかるかもしれません。
もし全員の作業完了を待ってから次に進む場合は、ある程度参加者を待たせてしまう可能性があります。
これらの問題はおそらく永遠の課題ですが、今後気持ちよく働いていくためにも、良い方法を模索していきたいところです。

そこでこの記事では、協働していくために行っていることを紹介していきます。一例としてお読みいただければと思います。

協働していくために行っていること

自己流ですが現状のやり方をまとめてみます。

なお、仕事環境として、以下の前提情報があります。

1.事前に資料を読んで予習する

会議や勉強会では、時間中は空いての話を聞くことに注力して、資料は事前に読んで予習するようにしています。
特にワークショップなどの手を動かす作業が発生する場合は、事前に予習して手順を確認するようにしています。
そうすれば理解も深まりますし、スクリーンリーダーの事情で相手を待たせてしまうということも少しは緩和されると思います。

資料を見ながら相手の話を聞いて、kintoneのスペースにコメントもするといったマルチタスクをしている人が多いのですが、
私の場合は資料を見たりコメントをしようとするとスクリーンリーダーの音声と相手の話がかぶってしまうので難しいです。
そのためマルチタスクは最初から不可能と割り切りました。

ここで重要になってくるのが、資料を事前に共有してもらうことと、アクセシブルな資料を作ってもらうこと、わかりやすい話し方で発表してもらうことの3つです。
特に事前に資料を共有してもらうことは大事で、最低1時間前、可能なら前日までに共有して欲しいなと思っています。
また、共有されたところで画像だらけの資料だと得られるものはなにもないので、テキストでの説明をつけたりノート欄にサマリーを書いたりして欲しいところです。欲を言うなら、一番見やすい資料はHTML形式です。
最後に、発表の仕方も重要で、声だけ聴いていてもわかるような構造的な話し方、話題の転換点や強調するところを意識するような話し方をお願いしたいとも思っています。

これらの話は社内勉強会で先日話しました。
資料のアクセシビリティが高まっていけば得られる情報が増えていき会議や勉強会に参加しやすくなります。
今後に期待するとともに、勉強会などで継続的に伝えていく必要がありますね。

2.自分なりの仕事用ドキュメントを作る

普段閲覧するページの一覧を１か所にまとめて管理しています。
ポカリチームは複数のプロダクトを横断して仕事をするため、グループウェア上のあちこちに見る情報が散らばっています。
その中から必要としている情報をすぐ開けるように、自分用のリンク集を定期的に更新しています。
たとえば、今秋取り組んでいるタスク、今後取り組むタスク、確認すべきToDoの一覧ページ、アクセシビリティのガイドライン、過去にメモした仕事用Tipsなどです。

散財している情報を１か所でまとめることでスクリーンリーダーでの情報の入手効率は格段に高まります。
情報を探している時にスクリーンリーダーの音声に集中しなければならず、会議など他がおろそかになってしまいがちです。
しかしリンク集を充実させておけば、毎回探しに行く手間が大幅に軽減されたり、省けたりします。

リンク集作戦が効果的なのは、情報リソースがウェブ上で完結しているからです。
ウェブ以外にパワーポイントのローカルファイルや紙の資料などが混在してくると、一元管理が難しくなってきます。
私の場合は、情報入手のアクセスをよくするために情報は可能な限りウェブ上で完結して欲しいですね。

3.モブプログラミングでは認識を合わせる

モブプロ（モブプログラミング）とは、ソースコードを共有して、複数人でひとつのプログラムを書いていく手法のことです。

コードを書く人を時間制で交代しながら、アドバイスしたり質問したりして全員で理解を深めつつ進めていきます。

ポカリチームではモブプロを日々行っていて、全盲・ロービジョンのメンバーが十分に理解できるよう工夫しています。

【Visual Studio Codeの導入】

Visual Studio Code（VSCode）というエディタをチーム全体で導入してもらいました。
VSCodeはあらゆる面でモブプロには必須と判断しました。
<スクリーンリーダーとの相性>
NVDAでプログラミングをするならVSCode一択です。
NVDAと相性の良い（読み上げる）エディタは意外と少なく、プログラミングをするのであればなおさら限られてきます。
VSCodeであれば入力補完・定義へジャンプ・ターミナル出力の読み上げなど必要なことは代替できるようになっています。

<カスタマイズ性>
VSCodeは細かい設定をJSON（テキストファイル）でできるようになっており、好みの設定にしたり変更内容を共有するといったことが容易にできます。
ロービジョンメンバーはフォントや色などを見やすいようにいろいろカスタマイズしているそうです。

<モブプロに必須の拡張機能>
Live Shareという拡張機能があり、これがモブプロに必須の機能です。
これがあるからこそVSCodeをチームで導入した、これがあるからこそモブプロが成り立っているといっても過言ではありません。
Live Shareを使うと、複数人でソースコードを共有し、全員でリアルタイムに編集できます。
たとえば、AさんがLive Shareでソースコードを共有した場合、BさんやCさんは各々の（使い慣れた設定の）VSCodeを使ってAさんのコードを閲覧したり編集したりできるわけです。

この機能のおかげで、メンバー全員で同じソースコードを見ながらプログラミングが可能になりました。

【ファイル名や行番号を共有する】

ソースコードを編集する時、該当のファイルや行番号を伝えてもらっています。
Live Shareで共有しても、どこが編集されたかは（たまたま編集箇所にいない限り）わかりません。
また、ファイル数が膨大だったり１ファイルの行数が多かったりするとその頭出しをするのはなかなか大変です。

行番号を伝えてもらえればすぐに該当箇所に飛べるので、ほぼリアルタイムで他のメンバーの編集内容を確認できます。

【何をしようとしているのかを言語化する】

コードを書く人は、どこをどのように変更しようとしているのか伝えます。
共通認識ができるので、見通しがたったり、適切なアドバイスや質問がしやすくなります。

【変更したデザインを説明する】

CSSを変更したなどでデザインに変化が生じた時は、変化を説明してもらっています。
私はデザインを確認できませんんが、デザインやCSSの知識が増えていくので説明してもらっています。

4.自己発信の結果プラスに働くこともある

自己表現の結果として、周囲から声をかけてもらうケースもあります。
前回の自己表現編の記事で、グループウェアに投稿する、勉強会を開催するという話をしました。
それをうけてのプラスに働いた事例です。

たとえば、あらかじめVSCodeをインストールしてもらえるケースです。
勉強会でちょくちょくVSCodeを使っている様子を見せているし、新人研修のチーム体験ではVSCodeでモブプロを行いました。
それらの影響が少なからずあると思いますが、（メインエディタが別にあるにもかかわらず）VSCodeをインストールしてくださる人がいます。
そうすると突発的にモブプロをする時にスムーズに進められるのでありがたいなと思っています。
VSCodeについては今後も勉強会を行うなどして広めたいなと考えてます。

他には、日々の会議やイベントを開催する時に、どうしたら自分が参加できるかをあらかじめ相談してもらえるケースが増えました。
どのように資料を提供すれば良いか、このツールは使えるか、あらかじめ考慮しておくことはないか、など。
聞いてもらえるというのは本当にうれしいことです。
知らないから聞きにくいとか、なんとなくこうなのではないかという推測で終わってしまうのではなくて、遠慮なく聞いて欲しいなと思っています。

協働は永遠の課題

「（視覚的な情報格差による）周囲との理解や作業の速度差をどう埋めていけば良いか」について掘り下げてきました。

自分だけが試行錯誤していても限界があり、周囲の人も一緒に工夫してもらう必要があります。
だからこそ視覚的な情報格差による問題を率先的に伝えることが大事だと思うし、同僚の方々は多様なユーザーな課題を知る姿勢がまず大事ですね。

この記事で紹介した私の場合の事例が、誰かの役に立てば幸いです。

予告

次回は番外編として、テレワークという働き方についてお話しします。
9/25に公開予定です。