対戦画面読み上げの舞台裏 モニターテスト編
ポケモン対戦画面読み上げアプリのエモい開発記録、第2弾です。今回はモニターテスト開始から初版公開までの話をします。
視覚が使えないプレイヤーとの対話を重ね、当事者のプレイング環境についての理解が深くなるだけでなく、開発スタンスにも大きな影響を受けました。ついでに、このアプリのソースコードに関するポリシーにも言及しています。
前回のあらすじ
ゲームアクセシビリティを研究している Invisible Gaming Labo (以下、IGL) と出会い、視覚が使えないポケモントレーナーとの交流を通して、ポケモン対戦における情報保証について考察するようになりました。そして、配信で使っていたぱにぱにツールをきっかけに、相手チームを読み上げるアイデアを思いつき、読み上げアプリのプロトタイプを作りました。
モニターテストの手配
プロトタイプができたので、視覚情報を使えないプレイヤーにモニターをお願いすることにしました。IGLのうとんつゆさんに取り持っていただき、同じくIGLの白井崇陽さんにご協力いただけることになりました。
先立って、有識者であるうとんつゆさんにレビューしていただきました。このレビューでは、期待通りの動作が確認できた上で、「ボタンをクリックするよりもキーボードで操作できたほうがよい」というフィードバックをいただきました。キーボード操作については完全に意識の外でしたが、言われてみれば当然そうだよなと思い、すぐに実装しました。
なお、その後本職でもWebアクセシビリティについて学ぶ機会があったのですが、キーボード操作は当然のように紹介されていました。このアプリの開発はアクセシビリティの基本も知らずに始め、ひたすら実践指向で進めてきたなと実感するのでした。
全盲プレイヤーによるモニターテスト
6月19日、全盲プレイヤー白井さんによる初めてのモニターテストが行われました。このときは相手チームに加え、相手HPをキーボード操作で読み上げるところまで実装できていました。
当事者の課題を把握する目的で、プレイしている様子を拝見したいとリクエストしたところ、快く受け入れていただき、Zoomで通話しながら実施することになりました。通話の冒頭、白井さんから、視覚なしでポケモン対戦をする上で感じている課題について説明いただきました。その後、対戦画面を共有してもらい、読み上げアプリを用いた対戦の様子を見守りました。
当事者を交えた初めてのテストということで、多くの学びを得ることができましたので、それぞれご紹介します。以下、想定ユーザーによるテストの記録ということで「ユーザー」という表現を使っていますが、すべてテスト中の白井さんのことを指します。
誤った情報を受け取ることの評価
テストを始めて最初の対戦では、相手チームの読み上げはうまくいったものの、相手HPの読み上げでは実際の割合よりもかなり小さい値を発話する不具合が生じました。あとで調査したところ、キャプチャボードの機種によって映像の色合いが若干異なることに起因する不具合のようでした。
認識難易度が低いHP満タンの場面で読み間違えてしまい、もう少し詰めてから試してもらったほうがよかったかなぁと少し気落ちしていました。一方でユーザーの意見は「全く情報がない状態と比べたらはるかに良い状態、不具合の傾向が分かるので大丈夫」というものでした。
何気ない一言のようですが、私にとっては意外な反応でした。私は、誤った情報を伝えることでミスリーディングにつながることを深刻視しており、間違えるくらいなら発話しないほうがよいと考えていました。一方で当事者にとっては、情報を獲得するために自ら工夫することが日常で、特にゲームに関しては全く情報がない状態と比べれば予測可能な間違いは許容範囲であり、むしろ取っ掛かりとなる情報が得られることに価値を感じているようでした。
開発者として納得ができなくても、ユーザーにとっては有益であるケースがあることを知りました。見えている情報をなんとか伝えようとしている開発者と、今まで全く情報が得られていなかったユーザーでは、異なる評価をすることはごく自然なことだと思います。あまり甘えすぎてもストレスを与えることになるので注意は必要ですが、これ以降「自己評価は甘めにして、まずは使ってもらう」というスタンスをとるようになりました。
時間に追われる感覚
当事者の課題を把握する目的で、アプリを使うシーン以外のプレイングも観察していました。特に気になった点として、「たたかう」「ポケモン」などの指示が開始されたことに気が付かない場合があることに気づきました。話を伺うと、普段の対戦でも操作が必要な場面であることに気づかず、持ち時間が無為に消費されることを課題に感じているそうです。
ユーザーはテストの中で、指示中ではないときにはHPの読み上げがエラーになることに気づき、HP読み上げが成功するかどうかによって指示中かどうか判断するという行動をとるようになりました。この適応力には感心しましたし、手段を与えることができたことは喜ばしいと思いました。
他方、操作を行うべき場面へ遷移したことは速やかに把握すべきで、より直接的に支援すべきだと思いました。場面の切り替えに応じて自動で読み上げる機能はこのあと実装するつもりでしたので、ついでに場面の切り替え自体も通知することにしました。
操作タイミングから少し一般化した話をすると、視覚が使えないプレイヤーがはとにかく時間に追われるという感覚を持っていることがわかりました。理由はシンプルで、一つ一つの情報の獲得に時間がかかるため、持ち時間が不足しがちだからです。ユーザーからも「限られた時間の中で」という言及が何度もなされていたことが印象的でした。
この感覚は、視覚が使えるプレイヤーと差があると考えています。私自身も、持ち時間はあくまでも極端な長考を防ぐルールであると認識しており、常に時間に追われるというほどのプレッシャーは感じていません。*1
視覚が使えないプレイヤーは時間に追われているという感覚に気づいてからは、無駄な時間を作らないこと、短い時間で伝えることを今まで以上に強く意識するようになりました。
GUIが邪魔をする
少し意外だった話題として、「このアプリって何が表示されていますか？」という、GUIへの言及がありました。キーボード操作を実装したことでアプリの視覚情報は理論上不要だと思っていたので、そもそも話題にあがることを想定していませんでした。
言及があったポイントは、ゲームをプレイしている間は画面全体の文字情報をOCRで読み取ることにしており、このアプリも読み取り対象に含まれるということでした。文字情報が少ないGUIを採用すると、余計な読み取りが発生しづらくなり好都合だということです。*2
当時はウィンドウにボタンを2つ表示するだけの質素なGUIだったのですが、今後ボタンが増えることも想像できましたし、そもそもキーボード操作だけで十分に思えました。いずれボタンを非表示にするオプションを実装しようと考えました。
情報保障に対する期待
プロダクトそのものに対する全体的な評価は「欲しかった情報が得られた」というポジティブなもので、狙い通りの反応が得られて一安心でした。
一通りテストが終わり、情報保障によってポケモン対戦がどのように変わりそうか伺いました。対戦しやすくなるのはもちろんですが、中でも「構築の組み方が変わる」という言及が印象的でした。
前提として、視覚が使えない対戦ではどのような思考をしているか教えてもらいました。まず、相手チームが分からないことから、選出は当てずっぽうにしかならないので固定されます。対戦中は鳴き声を聞けば対面はわかるので、生じた対面にアドリブで立ち回ることになります。しかし互いのHP残量はわからないので、HP残量に関係なく確実に倒しきる方法を用意することが望ましいそうです。
実際に白井さん自身が採用しているチームは、できるだけ対面不利になりづらい汎用的なポケモンを並べ、最終的には積みエースを展開して勝ち切る流れが多いとのことでした。これはいわゆる積みリレーであり、視覚があるプレイヤーでもごく普通に採用する戦術です。選出が固定されたチームも存在しますし、これ自体は視覚が使えないプレイヤー専用構築というわけではないと思います。問題はこの戦術しか採用できないという点です。選出合わせやHP管理を前提とする構築を採用しづらく、ポケモン対戦の限られた部分しか楽しむことができないことにもどかしさを感じるとのことでした。
このアプリをはじめとする情報保障により、相手ポケモンに対する役割を持たせる戦術や、HP管理を前提とする戦術を採用できることを楽しみにされていました。「白井さんがサイクル戦できたらゴールですね」という話もしました。*3
モニターテストのまとめ
長くなりましたが、モニターテストの話はここまでです。特に重要だと思ったトピックを以下にまとめます。
- 開発者と当事者の評価は異なる。とにかく試してもらうことが大事。
- 持ち時間がシビアであることを認識し、無駄な時間や情報密度に意識を向ける。
- GUIはかえって邪魔になることがあるので軽視しない。
- 情報保障によって戦術の幅が広がることが期待されている。
本当はもう一つ、OCRによる文字情報の保障という重要トピックがあったのですが、構成の都合で次の記事で紹介することにします。
まずは公開
さて、充実したモニターテストを終え、自信をもって次の段階へ進むことになりました。取り掛かったことはアプリの公開です。一日も早く公開できるよう、準備を開始しました。
公開を優先した最大の理由は、このアプリに価値があるならば、必要としてくれる方に少しでも長く使ってもらいたいからです。特にポケモンは新作が発売されるとプレイヤーが移行するコンテンツですので、使ってもらうならば時間との勝負だと考えました。
副次的な理由として、公開することでオープンな議論ができるようになることを期待しました。もちろんオープンな場で話題に挙げても構わなかったのですが、非公開の状態だとなんとなく心理的抵抗を感じるので、公開して気楽に話せるようになることを目指しました。
技術転用の許諾
公開準備の一環としてやるべきことの一つが、ぱにぱにツールから技術転用の許諾を得ることでした。前回の記事で述べた通り、このアプリはぱにぱにツールの有料記事を参考にして開発しました。オープンではない技術を使用する以上、技術転用にあたっては筋を通しておくべきだと考え、作者のぱにぱにさんに相談し、アプリ公開の許諾をいただきました。
実はご相談したのはこのタイミングが初めてではなく、モニターテストを始める段階で一度お声かけしていました。クローズドな配布とはいえ、転用した技術が他者に渡ることになるので、ここでも筋を通しておこうと考えたためです。アプリ公開前というタイミングでの相談は、不特定多数の方がツールを使うことについて確認いただくという意図でした。
ソースコードに関するポリシー
私自身は個人開発はオープンソースで行う主義ですが、このツールのソースコードは非公開としています。最大の理由は、参考にした記事へ敬意を表し、この技術を学ぶならば元記事を読んでほしいと考えているからです。今後も全文を公開することはないと思います。
一方、公開したくない技術やソースコードは一部にすぎませんので、特に私が考えたアイデアについては今後公開していくつもりです。聞かれたことには回答しますし、特にコア技術についてはソースコードも含めて解説する記事を少しずつ書くつもりですので、気になる方はまた覗いてみてください。
初版リリース
6月25日、ついに読み上げアプリの初版を公開しました。ここまでに画面遷移の通知と自動読み上げを実装しました。
さっそくその当日、読み上げアプリを用いたポケモン対戦配信が行われました。ここまでに開発された相手チーム読み上げ、相手HP割合読み上げはほぼ想定通りに動作し、プレイングを支援できているといえそうでした。また、シーン変更の通知も予想通り刺さっていました。私も出演してツールの解説をしていますので、よろしければご視聴ください。
なお、この配信で紹介されているプレイ環境が、私がモニターテストで見届けた状況と非常に近いものです。視覚が使えないプレイヤーがどのような状況でプレイしているのか、この配信アーカイブを視聴すれば一目瞭然で、共通見解を持つことが非常に容易になりました。私の周囲で関心を持っている人たちも、この配信アーカイブを視聴したことをきっかけに、ツール開発に助言をくれたりしています。
まとめと次回予告
今回はここまでにします。改めて、モニターテストは当事者の感覚を掴む貴重な機会だったと思います。私が感じたことというフィルターはかかっていますが、当事者の感覚をできるだけお伝えしたつもりですので、アクセシビリティの研究に少しでも貢献できれば幸いです。
「自分で評価するより、まずは使ってもらう」という行動規範はこの時期に会得し、今も変わっていません。とはいえ当事者と直接コミュニケーションをとることができる縁は得がたいもので、恵まれた境遇だと感じています。
この後は必要な支援を順次実装していくことになります。開発経緯の記事は次回で最後にする予定で、その後は技術解説を適宜書こうと思っています。よろしければまた読んでいただけると嬉しいです。この記事について気になるところがあれば、X @takosavi までご連絡ください。
