|
| 資料２−２ |
|
2004年12月24日 株式会社ＮＴＴデータ 公共システム事業本部 技術統括部 島田孝宜 スライド2 生活の場におけるWebシステムの重要性の向上 今後、生活の場でWebシステムの利用は増加する！ （通信メディアによる情報・サービス提供時期の概念図。以下は事務局による図の補足説明テキスト） 縦軸下が、情報、縦軸上がサービス 横軸は1955年から2005年までに時系列 1955年天気予報開始 1980年固定電話、以後、テレホンサービス 1985年ファックス、以後、ファックス情報サービス 1980年代後半パソコン、以後、パソコン通信、1995年頃よりインターネット 1995年携帯電話・PHS、以後、i-modeなど 1995年頃よりWebサイト 2000年電子政府開始、電子申告、電子申請、オンラインバンキング、電子商取引などWebシステム 「情報」の提供から「サービス」の提供に発展 （概念図の説明ここまで） スライド3 例えば○○を電子化するとき・・・ （RFP（request for proposal）：提案依頼書が発注者によって書かれる概念図。以下は事務局による図の補足説明テキスト） 「自宅からでも多くの人が参加可能なようにサービスをしたい！」 という発注者はRFPに必要な依頼事項を書く。 スライド4 もしもこんなRFP（提案依頼書）があったら・・・ （例） 電子申請システム開発 RFP（request for proposal）：提案依頼書 ○システム概要 ・（利用者）インターネットを介して、本システムを利用することができる。住民、企業及び団体など ○提案依頼事項（システム構成） ・（アプリケーションソフトウェア） インターフェースはWebベースを基本とする ・（ハードウェア） クライアントPCはWindows98以上の利用を想定する ○保証要件 ・（セキュリティ） 組織認証基盤(LGPKI)の秘密鍵を用いて、公文書に電子署名を付与する ・（アクセシビリティ） 「JIS x 8341-3」に準拠するよう努力する ＜参照＞特定非営利活動法人 ＩＴコーディネータ協会 開発委託用RFP見本 http://www.itc.or.jp/w_tool/rfpsla/rfpsla_main.html スライド5 もしもこんなRFP（提案依頼書）があったら・・・ （システムイメージと発注者、受注者の合意の概念図。以下は事務局による図の補足説明テキスト） 電子申請システムの発注者が受注者に、アクセシビリティへの対応をJIS準拠で依頼 それに対し、受注者はJISがあれば対応できるものと捉え、互いに合意 （概念図の説明ここまで） スライド6 しかし、開発してみると受注者は以下のことに困る。 利用者の定義によって対応範囲が遷移する・・・ 電子署名のアクセシビリティ確保は難しい・・・ JIS対応のシステム開発は思った以上に作業が多くて大変・・・ 利用者への配慮はどう測るの？JISでは評価できない・・・ つまり、 サービスレベルは？ 対応項目は？ 専門知識・ノウハウ（技術）は？ スライド7 アクセシビリティ要件の検討のステップ 一歩一歩確実に穴を埋めて、利用者が目的を達成できるアクセシビリティの要件を導き出す。 以下ステップ例のイメージ １．必要なサービスレベルの把握 ２．必要な対応項目の把握 ３．必要な専門知識・ノウハウ（技術）の把握 ４．アクセシビリティ達成 スライド8 アクセシビリティ確保の問題 アクセシビリティが確保できないシステムの多くは、要件の検討不足と受発注業者の意識の相違が原因 特に気を付ける点 (１) アクセシビリティの達成度は「JIS X 8341」では測れない (２) 「Webシステム」は「Webサイト」より、アクセシビリティに対応すべき範囲が広い (３) 利用技術とアクセシビリティの整合性は事前の検討が必要 スライド9 (１)アクセシビリティの達成度は「JIS X 8341」では測れない 「JIS X 8341」準拠と言われたときも、利用者配慮レベルは決めないといけない ・利用者配慮レベルというゴールが明確になったときに、アクセシビリティの達成度は測れる（評価可能な項目を決定する） ・JISは利用者配慮観点を設定しているもので、利用者配慮レベルは特に設定していない ・アクセシビリティの達成度を左右するのはJISではなく、利用者配慮 レベルを決定する発注者である ※利用者配慮には、「利用者は誰なのか、どういう配慮が必要なのか、システムでどの程度までアクセシビリティを確保するのか」などの決定が必要 スライド10 解決の取り組み例 （ＮＴＴデータ） 利用者配慮観点の調査 利用者配慮レベルを検討するために多様な利用者情報調査を実施 （利用者特性調査の表。以下は表内テキストを抜き出し並べたもの） 小分類 点字を利用できない 利用者の特徴 全く視覚を利用できず、点字によるコミュニケーションもできない。弱視を含めた視覚障害者のうち点字の読み書きが出来る人は全体の1割と言われている 代表的な利用環境と特性 ・音声読上げソフト ・音声読上げソフトはHTMLソース内のテキスト情報を上から下へ単線的に読みあげる。晴眼者のようにページ内容を一覧できず、時間がかかる 小分類 点字を利用できる 利用者の特徴 全く視覚を利用できない。点字を習得している 代表的な利用環境と特性 ・音声読上げソフト ・点字入力（点字ディスプレイ・プリンタ） ・キーボード操作 （表のテキストここまで） 利用者配慮レベルと評価項目の検討 必要な配慮レベルと評価検討体制を整備 ・実践経験を積んだ専門家の育成 ・専門家によるコンサルティングと開発支援 スライド11 (２) 「Webシステム」は「Webサイト」よりアクセシビリティの対応範囲が広い Webシステムは利用者の目的達成まで保証する必要があり、情報だけでなく機能を開発するプレーヤーの意識が重要である （WebシステムとWebサイトの違いの概念図。以下は事務局による図の補足説明テキスト） Webサイト：情報に対し要求し取得する JIS X 8341 デザイナー Webシステム：目的達成（情報取得＋サービス利用） アプリケーションサーバ・DBによるサービス部分で、JIS X 8341に対応するものが無い。プログラマー・SEも関わる。 （図の補足説明ここまで） スライド12 (２) 「Webシステム」は「Webサイト」よりアクセシビリティの対応範囲が広い ・Ｗｅｂシステムは多数のアプリケーションで実現されているので、表示部分への配慮だけでは解決できない ・利用者が目的を達成できる評価方法は複雑である ・表示部分以外のバックエンド開発の現場で、アクセシビリティ確保方法を顕在化することが必要 ・表示部分をつくるデザイナーだけでなく、システムをつくるプログラマー・SEのアクセシビリティに関する意識の共有が必要 ・利用者の目的達成を評価するには、機能、利用者特性・環境毎に多数の評価が必要 スライド13 解決の取り組み例 （ＮＴＴデータ） 関係プレーヤーの連携と開発体制の整備 管理者と組織の有機的な連結により、プロジェクト現場へ定着を進めている （関係プレーヤーの連携と開発体制の整備の概念図。以下は事務局による図の補足説明テキスト） 横軸：プロジェクト、Plan→Do→Check→Act 縦軸：管理者、開発者、協業者（デザイナーなど） Planの段階では、UD教育 管理者には、How toガイド 開発者、協業者には、開発標準、アクセシビリティ指針、UD方針書 （図の補足説明ここまで） スライド14 解決の取り組み例 （ＮＴＴデータ） 専門家による診断 NTTデータ・アクセシビリティガイドライン（JIS整合＋ユーザビリティ）に沿って策定した199個の点検ポイントについて対応状況を詳細評価 ユーザーテスト 一般ユーザテストや社内ユーザテストの活用で、利用者配慮レベルを実際の利用者の目で評価 ※ユーザテストの導入頻度を高める取り組みとして社内ユーザテストのしくみも整備 スライド15 (３) 利用技術とアクセシビリティの整合性は事前の検討が必要 例）電子申請システム （電子申請システムの利用技術とアクセシビリティの整合性概念図。以下は事務局による図の補足説明テキスト） Java Appletを用いたユーザーインターフェースは音声読み上げソフトで読み上げられない （図の説明ここまで） スライド16 (３) 利用技術とアクセシビリティの整合性は事前の検討が必要 アクセシビリティの実現が難しい技術は、事前に把握しておく必要がある ・利用技術とアクセシビリティとの整合性を事前に検討 ・支援技術（音声読み上げなどソフト等）と連携できる技術の選択 特に必要な知識 （１）提供サービスで利用するアプリケーション技術のアクセシビリティに関する知識(Java AppletのアクセシビリティAPIなど) （２）利用者環境で利用される技術（支援技術など）のアクセシビリティに関する知識(想定利用者の音声ブラウザがJava AppletのアクセシビリティAPIに対応した実装を行っているかなど) リッチクライアントなどへの対応も今後は課題になる！ スライド17 解決の取り組み例 （ＮＴＴデータ） 個別技術のアクセシビリティ・ガイドライン ・情報システム開発時に使用する技術のアクセシビリティに関する課題と解決策、実装方法を調査・社内共有を実施 PDF、Java Script、Java Applet、Flash など 個別技術の情報収集と社内サポート ・個別技術メーカーとの意見交換、情報共有（常時） ・欧米アクセシビリティ動向の調査（半期毎） ・アクセシビリティ確保のための営業・システム開発支援部門の設置 ・社内にアクセシビリティやユーザビリティに関する情報提供ポータルサイトの開設 スライド18 まとめ： Webシステムのアクセシビリティ確保に必要なアプローチ（ＮＴＴデータ） ＮＴＴデータは、Webシステムのアクセシビリティを確保するためのシステム開発体制を整備している。 以下、ＮＴＴデータの開発体制を説明。 ・第1に、システム開発時に「開発プロセスと連動したアクセシビリティガイドライン」を使用することにより、システム開発の各工程(企画、用件定義、設計、製造、試験・運用）で実施しなければならないことを明確にしている。 ・第2に、社内の支援体制を充実させ、アクセシビリティ確保が確実にできるようにしている。支援体制は4つの項目から成る。 ・支援体制1:開発手法「TERASOLUNA(テラソルナ)、開発標準、技術・機能ごとの指針や方針書の準備 ・支援体制2:専門家によるアクセシビリティ確保サポート。 専門家が開発現場でアクセシビリティ確保ノウハウを展開し、現場の問題や改善の方法は専門家が開発手法にフィードバックする。 ・支援体制3:教育(社内研修、e-learning) ・支援体制4:評価(一般・社内ユーザテスト、アクセシビリティ診断) このような体制が連携することにより、Webシステムのアクセシビリティを確保できるようにしている。 スライド19 最後に・・・ 誰にでも使える・使いやすいサービスを実現するためには、情報システムだけで完璧を目指すのではなく、社会全体で最良のUD対応とは何かを考えることが大切 （概念図。以下は事務局による図の補足説明テキスト） 社会全体のUD対応は「情報システム」「人のつながり」「サービス改善」「法整備」などがそれぞれ向上する必要があり、情報システムだけがすべての解ではない。 （図の説明ここまで） 以上 |
