今日仕事関係で研修を受けてきた。そこで題記のような話に、講師の方となったのである。

俺は一応SIERの会社で仕事をしている。今日はたまたま受講者として研修を受けさせてもらったが、基本的にはその路で飯を食っている。京野講師の方も、IT関連の仕事をしている方だった。

研修が終わった後の雑談で、講師の方から「企業内システムのアクセシビリティについて案件をもらうことがあるが、なかなか実現してもらえないんですよ。」という話になった。アクセシビリティ関連の仕事をしている方からするとそれは嘆かわしいし、ユーザーとしては切実な問題である。

障害者のIT利活用というコンテキストでのアクセシビリティについて、その重要性は様々なところで指摘される昨今。しかしながら、その実現は、なかなか進んでいない。JISやW3Cのおかげで、カスタマーレベルでのアクセシビリティ意識は10年前に比べて非常に高まってきたと思える事例は増えてきた反面、これが内部的あるいは閉鎖的な環境ではまだまだである。具体的には、会社の社内システムなどである。一般消費者に対しては、その市場規模から、アクセシビリティに配慮することは一定の利益になるかもしれないが、社内という限定的な環境ではなかなか進まないのが実際のところであろう。

現実に、私が勤務している会社のシステムは、社内システム向けのパッケージを使っているが、アクセシビリティなんて全く考慮されていない。一般的なユーザビリティは十分考慮されており、例えばWebブラウザから利用するアプリケーションでも、ネイティブのクライアントアプリケーションを使うような感覚で利用できる。けれども、こうしたアプリケーションは、とりわけスクリーンリーダーユーザーにとっては欠陥だらけの糞役にも立たないファッキンゴミ屑システムである。

細かいことを書き始めるとめんどくさいし、今そういう気分じゃないからここでは詳細は割愛するが、とにかく企業向けのシステムはぜんぜんアクセシビリティが浸透してないわけである。

で、今日の講師の方の話に戻すと、企業システムのアクセシビリティ対応ということで案件をもらい、アドバイスすることはあるが、費用面がボトルネックとなり、なかなかアクセシビリティを実現してもらえないとのことだった。

これはなかなか難しい問題だ。一般にシステムを開発する際、開発費をどうやって見積もるかというのは様々な手法があるが、大まかには、一般的に設計工程の段階で開発規模を予測する。画面数だったり、機能数だったり、あるいは要件から推測される実際のソースコードのステップ数だったり・・・。そして、アクセシビリティ対応となると、見積もりの段階で考慮すべきことが増えるので、当然費用も増えるわけだ。実際、素人が普通のシステムをアクセシビリティ対応にしようと設計した場合、通常の設計よりも多くの工数がかかる。

要するに、ここで題記の話。「アクセシビリティに金はかからないというのはうそだ」ということになるのだ。はっきり言って、アクセシビリティは金がかかる。調達要件にでも入ってない限り、普通はアクセシビリティなんて考慮しないだろう。特に、日本では法的にも義務はないし。

では、アクセシビリティを実現する上でどうしたら金がかからなくなるか。私はそういう現場に携わってるわけじゃないから、あくまで一般論として理想論を述べる。

一言でいうと、アクセシビリティの実現方式や実装方式について、設計段階で盛り込むことを辞めることである。これは容易なことではないが、第1歩ではある。もちろん、アクセシビリティに配慮することを要件とするのは必須だが、具体的にどう実現するかを設計するから金がかかるということだ。

これは少々説明が必要だろう。まず、アクセシビリティを実現する上での指針となるJISX8341とかW3Cの勧告(WCAGだったかな?)では、アクセシビリティの要件として求められる事項が記載されている。従ってアクセシビリティと言われれば、一般にこれらの要件を満たすように設計を行う必要がある。これは結構正しい。例を挙げれば、画面デザインとか配色とかは、設計段階で各種規格の要件を満たしている必要がある。

だが、これらの規格は要件であって、具体的な実装方法には触れられていない。一部はソースコードを示して実現方式を述べている部分もあるが・・・。しかしながら、アクセシビリティに求められるものは、前述のような非機能要件の他に、実装技術に関する部分も、案外大きなウェイトを占めるものである。

例えば、システムの開発に使用するプログラミング言語として、VBとC#のどちらかを使えると仮定する。この場合、細かいことは知らないが、標準的なAPIを使用する限り、C#の方がスクリーンリーダーにとってアクセシブルなアプリケーションを作製できる。

その理由は、原理は不明だが、例えばメッセージボックスを一つ出すだけのプログラムにしても、VBで書いたコードをコンパイルしたときの挙動と、C#で書いたプログラムをコンパイルしたプログラムの挙動が異なるためである。そして、私の経験則であるが、C#の方が、スクリーンリーダーにとって読み上げ出来る部分が多いプログラムを出力する。あくまでプログラム内部からスクリーンリーダーを操作するAPIなどを使用せず、標準APIを使ったときの話であるが。

もちろん、標準APIといっても、同じ機能を実装するのにどんなロジックを使うかは、実際のところ製造者、すなわちプログラマ任せのことが多く、それによってもアクセシビリティの品質が異なってくる。

さて、実装技術とアクセシビリティの関係を述べたところで、再度設計段階での話に戻そう。

実際の設計現場においては、顧客要件を満たすためにどのような画面や機能、データ構造が必要なのかといった、いわば「プログラミング言語でプログラムを組むこととはあまり関係ない」部分を突き詰める。そして、多くの設計者は、設計段階から製造工程の細かい技術、とりわけどんなAPIを使用するかなどを検討することが嫌いである。というか、システムの全体像も見えていない段階で、そんな細かいことを議論してもしょうがない、というのが一般的な考え方である。

従って、アクセシビリティ要件と言った際、まずやり玉に挙げられるのが、設計段階で決めておくべき各種要件の実現方式というわけである。だが、先にも述べたように、アクセシビリティとプログラムの実装技術は密接に関わっており、設計がよければアクセシビリティの高いシステムができるかといえば、必ず しもそうではない。

そこで、アクセシビリティをうまく高めるためには、設計で多くの方式を考えなくとも済むよう、どうにかしてラッピングしてやる必要があるのではないだろうか。すなわち、製造者(コーダ)の裁量で決めていたAPIやロジックを、コーディング規約などでカバーし、設計の機能要件及び非機能要件には取り入れないように、うまくコンサルティングするのである。

と、ここまで書いたところで、眠くなってきた。まぁ、酔っぱらっているので・・・。読み返すとなんか、訳分からんことを書いている気がするけど、まぁいいか。戯れ言だしね。じゃあ。お休みなさい。