『電子政府の効果、実はけっこうあります』でコメントを頂いているJREの問題については、すでに『電子申請のJRE問題を解決するには』で作者としての意見を述べています。
結論は、いたってシンプルで
・JREに限らず、利用者の負担を増やすものは廃止する。
電子署名の利用を前提とした電子申請システムを構築する際に、JREを採用した方が楽になるとしても、その一方で利用者の負担を増やしてはいけないのです。
そうした行為は、サービス品質への妥協を意味するもので、利用者視点から離れたものです。
『宮城県電子申請システムポータルの説明(ソフトのダウンロードとインストール)』によると、
電子申請システムで電子署名が必要な手続をご利用頂くためには,申請者側の端末にJRE(Java動作環境:Java Runtime Environment)がインストールされている必要があります。JREとはJava言語で開発されたソフトウェアを実行するために必要なソフトウェアであり,電子申請システムでは申請入力画面の表示等に利用しています。
「電子署名」があるために、「JRE」が必要になるとも読み取れるのですが、詳細は確認しないとわかりません。
しかしながら、実際に様々な電子政府サービス(電子申請、電子申告、電子入札、登記情報サービスなど)で、JREのバージョンが異なることにより、サービスごとにパソコンの設定を変えたり、別のパソコンを用意したりする必要があり、利用者の負担を確実に増やしています。
もともと、特定のOSやマイクロプロセッサに依存することなく、どのようなプラットフォームでも動作することを売りとしているJavaを採用したサービスが、一台のパソコン内ですら共存できない・動かないというのは、何とも皮肉な話しですね。
もし、本当にJRE問題を解決したいのであれば、
・電子政府サービスは、一般的なインターネット環境で快適に動くものとする
ことを電子政府の基本ポリシーとした上で、
電子政府サービスの新規構築・改訂等にあたっては、政府全体を統括する組織(GPMOなど)や専門の委員会等が、運用前に審査・評価するようにします。
そこで、一定の品質を満たさないサービスや、相互運用性を確保できていないシステムについては、国民に提供できない(運用を開始できない)ようにします。
審査・評価は、少なくとも
・技術(相互運用性など)
・サービス(実務を考慮して)
・財務(費用対効果)
の視点から実施しましょう。
JRE問題は、一朝一夕に解決できるものではなく、
・相互運用性を確保できる「政府調達の改革」
・抑制・停止等の実行力を伴う「審査・評価体制の確立」
といった仕組み(インフラ)作りが必要です。
当面は、バージョンを統一するといったルール作りでも一定の効果はあるかもしれませんが、そうした対処療法的な取組みでは、同じような問題が再発することでしょう。
結論は、いたってシンプルで
・JREに限らず、利用者の負担を増やすものは廃止する。
電子署名の利用を前提とした電子申請システムを構築する際に、JREを採用した方が楽になるとしても、その一方で利用者の負担を増やしてはいけないのです。
そうした行為は、サービス品質への妥協を意味するもので、利用者視点から離れたものです。
『宮城県電子申請システムポータルの説明(ソフトのダウンロードとインストール)』によると、
電子申請システムで電子署名が必要な手続をご利用頂くためには,申請者側の端末にJRE(Java動作環境:Java Runtime Environment)がインストールされている必要があります。JREとはJava言語で開発されたソフトウェアを実行するために必要なソフトウェアであり,電子申請システムでは申請入力画面の表示等に利用しています。
「電子署名」があるために、「JRE」が必要になるとも読み取れるのですが、詳細は確認しないとわかりません。
しかしながら、実際に様々な電子政府サービス(電子申請、電子申告、電子入札、登記情報サービスなど)で、JREのバージョンが異なることにより、サービスごとにパソコンの設定を変えたり、別のパソコンを用意したりする必要があり、利用者の負担を確実に増やしています。
もともと、特定のOSやマイクロプロセッサに依存することなく、どのようなプラットフォームでも動作することを売りとしているJavaを採用したサービスが、一台のパソコン内ですら共存できない・動かないというのは、何とも皮肉な話しですね。
もし、本当にJRE問題を解決したいのであれば、
・電子政府サービスは、一般的なインターネット環境で快適に動くものとする
ことを電子政府の基本ポリシーとした上で、
電子政府サービスの新規構築・改訂等にあたっては、政府全体を統括する組織(GPMOなど)や専門の委員会等が、運用前に審査・評価するようにします。
そこで、一定の品質を満たさないサービスや、相互運用性を確保できていないシステムについては、国民に提供できない(運用を開始できない)ようにします。
審査・評価は、少なくとも
・技術(相互運用性など)
・サービス(実務を考慮して)
・財務(費用対効果)
の視点から実施しましょう。
JRE問題は、一朝一夕に解決できるものではなく、
・相互運用性を確保できる「政府調達の改革」
・抑制・停止等の実行力を伴う「審査・評価体制の確立」
といった仕組み(インフラ)作りが必要です。
当面は、バージョンを統一するといったルール作りでも一定の効果はあるかもしれませんが、そうした対処療法的な取組みでは、同じような問題が再発することでしょう。
さて 一度書いたらどこでも動くはずが動かない。
わずかに、登記情報提供サービスでMacが使えるくらい。
もともとの電子申請の理念にはなかったのではと疑ってしまいますが、XMLと相性がいい、とりわけXMLの電子署名に関して言えば、Java以外に今のところ使えるものがない。
正確には調べていませんが、導入時はそうだったのではないでしょうか。
電子政府推進員掲示板で尋ねたけど、事務局からの回答はなかったですね。確か。
MacやLinuxでも動くという点では、PDFフォーム、フラッシュなんかもあるはずで、政府にはその気がないから採用しない。
データの入力や、保存、印刷などの機能は、ほとんどサーバ側のJavaのプログラム(サーブレット)でもなんとかなるようで、ICカードを使った電子署名の部分だけアプレットを使うパターン、大分県のがそうですが、それであるなら、電子署名を要求する手続きの絞り込み、あるいは、電子署名を要求する手続きについてはオンライン申請を当面凍結するなどして、クライアント側、申請側の負担を軽くしてもらいたいものです。
http://shinsei.moj.go.jp/new/new_top.html
【重要】JRE1.4.2_11に関するエクスプロイト対応のための緊急措置について (平成19年6月22日)
とりあえずエクスプロイト対策ですが。
JPCERT/CCの方から、法務省に言ってくれるというメールが22日にありました。
コメントありがとうございます。
法務省の対応は、今後の電子政府のあり方を示唆するものと思います。
つまり、行政が一方的に提供するだけでなく、国民がチェックして、「これは間違っているんじゃないですか」と言うことができ、かつ実効力も働くということです。
電子署名については、PDFでもいけたと思いますが、Javaの方がオープン性や開発のしやすさでリードしていたのかもしれませんね。
以前に比べてフラッシュやPDFも進歩しましたし、民間ウェブサイトはもちろん、多くの省庁や自治体で採用されていますので、今後は電子申請への活用も進むと思います。
特定の技術や手法に固執することなく、利用者の環境や市場の動向を見据えながら、柔軟に対応することが大切と思います。
法務省も以前は、セキュリティホールが発表されたらすぐ対応していた時期もあったのですが、利用者が増えてかえって慎重になったのでしょうか。
さてGoogleで使われているAjax(Asynchronous JavaScript + XML)で、電子署名やローカルファイルの取扱が可能になれば(もう可能になってるのかもしれませんが、私が知らないだけか)プラグイン不要の時代がくるかもしれませんね。
コメントありがとうございます。
Ajaxは、実際のサービスがわかりやすくて良いですね。
古くて新しいAjaxの真実を見極める
http://www.atmarkit.co.jp/fwcr/special/ajax01/01.html
では、
・一見Flashかと思わせるが、実際にはFlashなどのプラグインは利用していない(HTMLとJavaScriptで実現)
・ブラウザによってはうまく利用できない機能がある
Webアプリに使えるAjaxライブラリ8選!
http://www.atmarkit.co.jp/fwcr/special/ajax_kaitai03/01.html
では、
「ユーザビリティ」と「相互運用性」の大切さを指摘しています。
上手に活用すれば、電子署名の「重たい」「準備や設定が面倒」といったイメージを払拭できるかもしれませんね。
パソコンの能力や通信速度等の向上により、以前は「重たい」「うざい」といった印象のFlashや動画も、わりと一般的な存在になり、あまりストレスを感じなくなりましたし。
いずれにせよ、開発者の自己満足にならないように、「利用者中心思考」が必須です。
http://shinsei.moj.go.jp/new/new_top.html
エクスプロイト対応とかあります。
申請者にこの用語を理解しろ、と言ってるようでなんとも恥ずかしい対応です。
申請者利用者は、このような用語を理解しないと手続できないのか?
ほんと失笑ものの用語です。
コメントありがとうございます。
現在の電子申請の多くは、残念なことに、マニアのためのシステムであり、一般の理解はあまり考えていないようです。
気になるのが、各省庁の電子申請システムにおいて、JREの脆弱性が発表され、対応のためにバージョンアップされると、ベンダーが国から別途費用を徴収しているのか?という点です。
JREへの対応が通常の保守費用に含まれていないのであれば、「JREの採用」はベンダーにとってオイシイことであり、JREにこだわる理由も納得できます。
やはり、政府の電子申請システム全般に、(契約内容を含む)事前・事後のチェックが必要のようです。。
電子政府と電子自治体における申請システムでのJRE利用にて。
牟田さんのように勘ぐりたくなりますね。ほんと。
>JREへの対応が通常の保守費用に含まれていないのであれば、「JREの採用」はベンダーにとってオイシイことであり、JREにこだわる理由も納得できます。
法務省オンライン申請システムでの「お知らせ」などは、申請者側に対するものというよりベンダー側から省庁担当者向けではないか、と思われる部分もありますね。(失笑)
むたさんのご指摘に関係ありますが
どうもここにでて来るのですが
http://slashdot.jp/articles/06/03/26/0418227.shtml
長いのですが、次のところだろうと思われますね。
-------------------------------------------------
仕様書の書き方がわるいのか? (スコア:2, 興味深い)
技術的な問題で互換性問題が発生することももちろんあるんだろうけど、
「技術的にはある程度過去のバージョンのJREでも動く様にできるけど入札仕様書でそれが要求されてないんだから現行のバージョンだけ(もしくは自分たちが使い慣れたバージョンだけ)で動くようにしておいて、さらに文句が出ないようにそれ以外では動かないように制限しておこうっと
-------------------------------------------------
仕様書といってもベンダー側が原案作ったものでしょうが、バージョンに幅を設けてしまうと、おいしい部分を逃してしまうからか。
ところが、事前準備サイトでJREのダウンロードが1.4.2_15になるのです。
もう、なにがなんだか分け解らなくなります。
もう少しきめ細やかな説明をしてもらいたいところです。
申請者はマニアでもなんでもないんだからね。