motchie.com

The Golden Rule

IoTシステムのアクセシビリティを考える

記事の作成にあたって

この記事は、Webじゃないアクセシビリティ Advent Calendar 2016の24日目の記事です。

「Webじゃないアクセシビリティ」という視点でカレンダーを作られたkim_upsilonさんの見識に敬意を表しつつ、記事を書かせていただいております。

[イメージ写真]

Photo credit: adafruit via VisualHunt / CC BY-NC-SA

はじめに

"Ubiquitous"という単語がIoTに置き換えられるようになって数年になります。日本でも、官民で推進の取り組みが活発化してきました。

そんな中、今年の7月に経済産業省から『IoTセキュリティガイドライン』が公表されました。これは、IoT機器やシステム、サービスについて、その関係者がセキュリティ確保の観点から求められる基本的な取組を、セキュリティ・バイ・デザインを基本原則としつつ、明確化することによって、産業界による積極的な開発等の取組を促すとともに、利用者が安心してIoT機器やシステム、サービスを利用できる環境を生み出すことが目的と書かれています。

IoTにおけるセキュリティ・ガイドラインの必要性は疑いの余地がなく、これを見ると、同時にアクセシビリティのガイドラインも必要ではないだろうか、と思ったことが、本記事執筆のきっかけでした。

ハードウェアの低価格化・高性能化と、IoTをターゲットとしたパブリック・クラウドなどのサービスが続々登場している中、IoTデバイスを開発・販売する敷居が下がっていることは疑いようのない状況です。こうした「誰でも手軽に扱える」状況が、アクセシビリティやユーザビリティに配慮されていない製品やサービスが登場する土壌となることは、Webと全く同じ構図に見えます。そのため、黎明期の段階で、システムやデバイスの設計段階からアクセシビリティに配慮する考えを持つことは引き続き重要と思われます。

この『IoTアクセシビリティ・ガイドライン』の必要性について、「アクセシビリティな」人たちが多数集まった今年のアクセシビリティの祭典後の懇親会で話題を振ってみたもの、話が発散したところで時間切れになってしまったので、個人的にたたき台として検討してみた結果でもあります。

とはいえ、諸々の事情により、現時点では「ガイドライン」の体をなしていないため、検討すべき事項の列挙にとどまっています。

IoTシステムの特徴からIoTのアクセシビリティの検討事項を考える

検討を行うシステムの範囲

例えば「Webアクセシビリティ」であれば、その検討範囲は最も狭くて1ページ、一番広くても検討を行うWebサイト全体ということは自明です。

しかし、IoTシステムの場合、検討する範囲の定義がまず難しいように思われます。

最も簡単なものを考えると、例えばシングルボード・コンピューター1つでシステム(系)が閉じているのであれば、それ自体が検討範囲ということになります。

しかし、それぞれが単独でサービスを提供しうるシステム同志が連携して動くSoSと呼ばれるようなシステム(系)である場合は、その系全体が対象範囲になり得ると考えられます。

例えば、工場のラインにおいて、各製造機械の稼働状況をセンサー・デバイスによって収集し、それをクラウドサービス等に集約、同じくクラウドサービスで提供される機械学習サービスに流し込んで、各製造機械の故障予測を行うシステムがあるとします。

この場合、主に注目されるのは、最終的にデータを集約した結果を表示するUIとなり、それは主に、PCまたはスマートデバイス(スマートフォンやタブレット)が、クラウドサービスの機械学習APIなどを呼び出して結果を表示していると思われます。

この部分に関しては、そのUIがWebであれば従来からの「Webアクセシビリティ」の知見が利用できますし、あるいは各OSのネイティブ・アプリケーションであれば、それぞれのOSが持つユーザー補助機能に適した開発を行うことで、OSにビルトインされたアクセシビリティ機能などを利用できます。

しかしながら、各製造機械に取り付けられたセンサーデバイスの電源のオン・オフの状況が、LEDインジケーターのみで表されているとしたら、それは問題があると考えられます。

検討を行うUIについて

IoTシステムにおけるアクセシビリティを検討するにあたり、その対象はUIになると考えられます。

この点に関しては、JIS X 8341-1で、対象が「インタラクティブ・システム」と書かれていることからも、間違いないと思われます。

このUIについて、先の例にもあったように、その作りによって以下のように大別されると考えられます。

  • ハードウェアによるUI
  • ソフトウェアによるUI
    • Web技術をベースとするUI
    • ネイティブOSのUI機構を用いたUI

このうち、ソフトウェアによるUIについては、先に述べた通り、すでに組み込まれているアクセシビリティ機能を利用することで、ある程度実績のあるアクセシビリティが提供できると考えられます。

ハードウェアによるUIについては、現状のJIS規格をざっと調査する限りにおいては、大まかなガイドラインこそあるものの、IoT機器が属するような、いわゆる組込機器を対象とした個別具体的なガイドラインなどは見つからないため、個々の機器の設計段階において、後述する方法で検討や試験を行う必要がありそうです。

検討事項: UIのないIoTシステムはあり得るのか?

IoTシステムにおけるアクセシビリティに関して、先ほどUIが対象になると書きましたが、全体を網羅的に俯瞰する際に、「UIのないIoT」システムが存在うるのかどうか検討の必要があると考えています。

これは、先の定義に従えば、「アクセシビリティを確保する必要のないIoTシステム」ということになりますが、それが正しいか否かは、実際にUIのないIoTシステムの事例があれば、それを見て検証する必要があると考えています。

しかし、現状「UIのないIoTシステム」が存在しうるのか、結論を出せていません。

IoTシステム設計時の考慮事項

UIの現状分析

すでに稼働しているIoTシステムがあったり、ある程度設計が進んでいるIoTシステムがあった場合に、そのUIのアクセシビリティに関する現状を分析する手段は、何かあるのでしょうか。システム及びソフトウェア製品の品質要求及び評価に関する国際規格ISO/IEC 25000シリーズ、国内規格 JIS X 25000シリーズの総称であるSQuaREに、参考になりそうな式がありました。

視覚障害者のアクセシビリティ = 視覚障害のある利用者が利用可能な機能数 実装されている総機能件数

これは視覚障害に関する例ですが、これをすべての人間的特性について算出していくことで、現状のシステムや設計におけるアクセシビリティをある程度数値化することができそうです。

「アクセシビリティ・バイ・デザイン」

先に引用した『IoTセキュリティガイドライン』には「セキュリティ・バイ・デザインを基本原則としつつ」と記載されていますが、これはアクセシビリティに関しても全く同じアプローチを取るべきと思われます。つまり、システムの設計段階からアクセシビリティについても要件に含むべきと思われます。

UI設計の方針について

前記のように、現状ハードウェアのUIに比べてソフトウェアのUIのほうが、フィードバックを含めたアクセシビリティ対応が容易だと思われます。

そのため、システム全体のUIを、ソフトウェアUIに可能な限り集約し、Web技術向け支援技術やネイティブUI向け支援技術をするこで、システム全体のアクセシビリティをより容易に確保することが可能になると考えられます。

アクセシビリティを考慮したUI設計

あるシステムについて、人間の感覚器や人間の特性への対応について網羅的に設計するために、JIS X 8341-1の付属書 Bには「情報通信機器及びサービスへの適用可能性と適合性とを評価するためのチェックリスト(例示)」という章があり、表が示されています。対応すべき要件として、視覚、聴覚、発話、身体的能力、認知能力その他の、このJIS規格における細分箇条がリストアップされています。このチェックリストで、ここのUIやUIによって提供される情報ごとに検証・試験を行うことで、現在のIoTシステムのアクセシビリティを網羅的に検証することができます(JIS規格本文の引用に関するルールが不明なので、表を引用することは避けます)。

将来に向けた動向

例えばApple WatchにもきちんとVoice Overが搭載されているところを見て、IoTデバイスはかくあるべしと思っていた時期がありました。 とはいえ、各IoTデバイスがそれぞれText to Speechシステムを備えることはハードルが高いのではと懸念しておりました。

しかし、最近になってクラウドサービスでText to Speechを提供するサービスが出てきました。例えばAWSにおけるAmazon Pollyや、Microsoft Azureにおける Bing Speech APIなどです。 IoTデバイスは、HTTPなどを通してこれらのAPIを呼び出しさえすれば音声を提供することが可能となり、こうした動きは、IoTデバイスのアクセシビリティ向上にも寄与すると思われます。

まとめ

IoTにおけるアクセシビリティについて、とりとめもなく検討してきました。まだまだ情報などを整理する必要はありますが、関連規格の整備やクラウドサービスを中心としたサービスによって、現状よりアクセシブルなシステムを提供することは、今後容易になっていくと思われます。

参考文献