電子政府の効果、実はけっこうあります

「電子政府は、税金の無駄遣いだ!」と言われることがあります。実際、電子申請など利用率の低迷が続き、投資に見合った効果を上げていないものも多いでしょう。しかし、効果を上げているものありますので、今回はその一部を紹介しておきましょう。

行政効率化推進計画等の取組実績(平成19年2月6日 行政効率化関係省庁連絡会議)

では、「電子政府関係の効率化」として次のような例を挙げています。

・「霞ヶ関WAN及び政府認証基盤(共通システム)の業務・システム最適化計画」
▲約11.6億円の経費削減(年間)、約6,400時間(年間延べ)の業務処理短縮時間

・「予算・決算業務の業務・システム最適化計画」
▲約25億円の経費削減(年間)、約44,560時間(年間延べ)の業務処理短縮時間

・「公共事業支援システム(官庁営繕業務を含む。)の業務・システム最適化計画」
▲約19.3億円の経費削減(年間)、約4,080時間(年間延べ)の業務処理短縮時間

・登記情報システム(法務省)▲13,026百万円
・国税総合管理(KSK)システム(財務省)▲約9,200百万円
・電波監理業務(総務省) ▲約1,250百万円
・指紋業務用システム(警察庁) ▲438百万円
・汎用電子計算機システム(国土交通省) ▲674百万円

いわゆる「業務・システム最適化」に関連するものです。

上記に加えて、「業務・システム最適化」にかかる19年度投資予定額も削減(998億円から692億円へ)されています。

これは、

・政府の情報システムに関するお金の使い方は、あまり上手ではなかった。
・ちょっと見直しただけで、かなり無駄遣いを減らすことができた。

ということです。

「電子政府で便利になった、生活や仕事が楽になった」といった効果を上げるのは大変に難しいのですが、無駄遣いを減らすことは実行しやすいのですね。

何せ、余分な脂肪や垢がたんまりこびり付いていたのですから、ちょっとダイエットしたり洗っただけで、ボロボロ無駄が取れていくわけです。

また、「合理化効果」として次の例を挙げています。

・法務省 ▲100人
・財務省 ▲216人
・厚生労働省 ▲628人
・農林水産省 ▲382人
・国土交通省 ▲211人
・防衛省 ▲237人

これは、無駄な人員が多いということではなくて、人の配置や使い方、仕事のやり方が上手ではなかったということです。

「電子政府関係の効率化」とは別に、「公共調達の効率化」の中で「随意契約の適正な運用等」が取り上げられています。

所管公益法人等(天下り団体ですね)との随意契約についての見直しで、

平成18年6月:2兆1,743億円 >> 7,160億円(▲1兆4,584億円減、67%減)
平成19年1月:1兆1,973億円 >> 5,212億円(▲6,761億円減、56%減)

電子政府関連だけの調達ではありませんが、実に一兆円規模の削減効果です。

これまで、政府の情報システム関連の契約は、圧倒的に(競争がない)随意契約が多かったのですが、今後は調達方針も変わり、かなり厳しいチェック(事前、途中、事後において)がされるようになります。

電子政府ベンダーにおいては、収益構造の見直しが求められることでしょう。

最後に、住基ネット(住民基本台帳ネットワークシステム)の効果について見ておきましょう。

何かと悪者扱いの住基ネットですが、維持費用はかかるものの、かなりの効果を上げています。

もともと、住基ネットは、それ自体が国民向けのサービスを提供するものではなくて、行政内部の事務処理の裏方として機能するものです。

ですから、住基ネットの効果も、国民からは見えにくい(実感しにくい)わけです。

住民基本台帳ネットワークシステム調査委員会の配布資料「住民基本台帳ネットワークシステムの利用状況」によると、

・国の行政機関等に対し年間約3000万件の情報提供
・地方公共団体において年間約360万件の情報提供

※年間約510万件の現況届等が省略(平成17年度)
※年間約370万件の住民票の写しの添付が省略(平成17年度)

・厚生年金・国民年金等における現況確認(平成18年10月から)

※年間約2600万件の現況届が省略

などの効果(上記以外もあります)が挙げられています。

ざっと見積もっても、年間の効果は数百から数千億円でしょうか。

住基ネットの維持費用が年間200億円弱と言われてますので、いちおう黒字となっていますね。

今後は、利用対象を拡大すると共に、維持費用を最低でも半分ぐらいに減らすことが必要でしょう。

新聞や雑誌等で電子政府を特集する場合、悪い面ばかりを捉えて、イタズラに批判されることもあります。

しかし、電子政府・電子申請が健全に発展していくためには、効果を上げている部分については素直に認めた上で、足りない部分を補うためにどうすれば良いのかを、国民、行政、メディアが一緒になって考えていくことが大切です。

というわけで、今後とも皆さまのご理解とご協力をお願い致します

“電子政府の効果、実はけっこうあります” に15件のコメントがあります

  1. おーすごい でもこれをなんとか
    じっくり読ませていただきますが

    J2SE1.4.2_11に深刻なセキュリティホール
    http://headlines.yahoo.co.jp/hl?a=20070607-00000098-zdn_ep-sci

    これで、ちょっと見ましたら、法務省、総務省の電子申請体験システム、自動車OSSの指定のJREがいずれもパッチバージョンが結構古い。

    なんかすごい鈍感力を感じますね。

  2. 迅速な対応
    sagoさん、ご無沙汰しております。
    コメントありがとうございます。

    JREの問題は、ずっと引きずってますね。

    JRE問題は、実はコンピュータの問題ではなくて
    ・行政のやり方を国民に強要する
    ・行政間の縦割りがサービス向上を阻害する
    と理解しています。

    今まで(紙申請)は、このやり方で通ったのですが、時代と共に状況や国民の意識が変わり、これらは「怠慢」とみなされ「拒絶」されるようになりました。

    特に、利用者優位のオンラインサービスにおいては、致命的な欠陥となります。

    行政が「利用者視点」を理解し実践するのは、まだまだ先のことになりそうです。

  3. 自己責任という開き直り
    むたさん ありがとうございます。

    リンクをたどると去年から怪しいのであります。

    http://www.itmedia.co.jp/enterprise/articles/0612/21/news019.html

    「Secuniaのアドバイザリーによると、JREに存在する2件の脆弱性は、悪用されると不正アプレットを使ってローカルファイルの読み取り/書き込みやローカルアプリケーションの実行ができてしまう。」

    で、ある方が法務省に指摘すると

    http://www.imatch.jp/blog/shimalog/114.html

    「自己責任で使ってほしい」とは、フリーソフトの作者じゃないのだから。

  4. 事実であれば
    sagoさん、こんにちは。

    ご指摘の内容が事実であれば、政府機関の情報セキュリティ対策基準に違反している可能性が大きいです。

    情報システムの運用時におけるセキュリティホール対策は、「電子政府の信頼性・安全性」に直結する問題ですから

    内閣官房情報セキュリティセンター(NISC)
    http://www.nisc.go.jp/mail.html
    への連絡をオススメします。

  5. 報告しました
    むたさん アドバイスありがとうございました。

    さっそく報告しておきました。
    なにか指導があればいいですが。

  6. 監査からも
    sagoさん、おはようございます。
    ご報告、お疲れさまです。

    各府省では、情報セキュリティ監査を実施しているはずですから、直近の監査で今回のセキュリティホール対策の不備が見落とされている可能性もあります。

    その場合、監査実施者(監査法人など)の責任問題にもなりますね。

  7. 自動車OSSはやってるけれども
    むたさん こんにちは。
    けっこう大きな問題になりそうな。
    さて、自動車OSS最近 対策をしたと思いきや
    http://www.oss.mlit.go.jp/portal/news/news_list.html#2007052501

    JRE1.4.2_09の脆弱性とちょっと古いのです。

    先に出した
    Sun、Java JREの脆弱性に対処
    2006年12月21日 09時06分
    http://www.itmedia.co.jp/enterprise/articles/0612/21/news019.html
    これが「JDK/JRE 5.0 Update 7以前、SDK/JRE 1.4.2_12以前、SDK/JRE 1.3.1_18以前」

    2007年01月18日 08時35分 更新
    http://www.itmedia.co.jp/enterprise/articles/0701/18/news022.html
    「JDK/JRE 5.0 Update 9とそれ以前、SDK/JRE 1.4.2_12とそれ以前、SDK/JRE 1.3.1_18とそれ以前」

    だから、2_09の対策だけしても、2_12だったらやっぱりだめで、今回の最新のセキュリティホールは2_14もだめですから、JRE5のUpdate 11以降にしないとだめなような。

  8. 公的個人認証ポータルもまだ
    なんか次々出てきます。

    対応するJREの更新について(平成19年3月30日)
    http://www.jpki.go.jp/online/caution.html
    まだ今回のはアナウンスなし、

    年金蟻地獄の厚生労働省も

    「※ システムの動作確認は以下の各バージョンで行っています。
    JRE1.3.1_11、JRE1.4.1_07、JRE1.4.2_10
    セキュリティ等の観点から、JRE1.4.2_10でのご利用を推奨しています。(平成18年3月現在)」

    です。呑気なもんだ。

  9. いろいろやってはおりますが
    今回の最新のJREのセキュリティホール情報について各省庁慌てる様子がないので、不思議に思っているのですが、どうも

    脆弱性レポート 一覧
    http://jvn.jp/report/index.html

    これに取り上げられていないからではないかと思いましたね。

    自動車OSSがアナウンスしたのは
    ちゃんとありました。

    「2007/05/08 JVN#44724673:
    Java Web Start において許可されていないシステムクラスが実行される脆弱性」

    どういう仕組みかよくわかりませんが、ネット記事を見る限りは、今回のセキュリティホールはかなり重要だと思うのですが、とりあえすJVNに問い合わせメールだけ送っておきました。

  10. やはりこの国は電子二等国家
    むたさん 連発してすみません。

    過去のセキュリティホール記事を追いかけ回していて気がついたので言わせて下さい。

    法務省の登記の全部事項証明などを送付してもらうオンライン申請では、その請求様式(XML形式)を作成するのに、様式作成支援ソフトを使います。
    これには、JREがいっしょに入ってきて、ブラウザのプラグインではなく独立したプログラムとして使うようになっています。
    こちらのJREは、バージョンが1.4.2_08なんです。
    一応 様式の自動アップデートがありますから、ネットに繋ぐ機能はあります。
    で、1.4.2_08というとどういうバージョンか

    Sun、Java関連の脆弱性7件を修正
    http://www.itmedia.co.jp/enterprise/articles/0602/09/news007.html

    「極めて深刻」だった対象が「JRE 1.4.2_09とそれ以前」です。

    まあ、プラグインで使わないということは、不正アプレットをダウンロードして開く心配がないから、そのまま使っているのでしょうが、この時のSunのアナウンスは2006年02月09日です。1年以上も前。
    で、09のひとつ前の08をダウンロードさせて使わせている。しかも様式作成支援ソフトで使うJREは、自分で選ぶことができないのです。

    開発ベンダもベンダですが、証明書のオンライン申請利用促進にやっきになっている法務省及び各法務局は、司法書士、土地家屋調査士に、セキュリティホール未対応のJREの入ったCDをばらまいて、どうぞ頑張って使って下さいと言っている。

    ちょっとややこしいのですが、このCDには、法務省オンライン申請システムをブラウザで使うのにプラグインとして使うJRE こちらは1.4.2_11ですが、これも入っている。で配布した時点ではやはりセキュリティホール未対応。

    ふたつもJREを使わねば、全部事項証明書1通とれないのです。

  11. JRE問題
    sagoさん、こんにちは
    情報ありがとうございます。

    時間があれば、この問題については別ブログで詳しく取り上げたいと思いますが。。。

    以前から主張しているのですが、個人的にはJREを採用しない(で動くシステムにする)のが良いと思っています。

    これは、もちろんJava言語が悪いと言うわけではなくて、利用者環境への配慮が欠けているということです。

    「利用者中心主義」ではなく、「システム中心主義」になっていると。

    採用するなら、少なくとも「最新版に自動アップデートする」といった電子政府共通のルール(義務付け)が必要でしょうね。

    電子申請の普及が進まない理由として、公的個人認証などが指摘されますが、JRE問題の迷惑度も相当なものです。

  12. JRE問題に対する政府の考え方
    JRE問題に対する政府の考え方は、自動車保有関係手続のワンストップサービスシステムの
    Java 2 Runtime Environment(JRE)の脆弱性について(平成19年5月25日)
    http://www.oss.mlit.go.jp/portal/news/news_list.html
    を見ると良くわかります。

    ・申請ソフトに関するセキュリティホールではない。
    ・申請ソフトをJREの最新バージョンで動作させることはできない。

    つまり、
    ・行政側の問題(責任)ではない。
    ・行政側では対応しない(費用等の関係でできない)

    この結果、「ユーザー側で対応してください」=「自己責任で」となるのでしょう。

    対処方法として、
    「申請ソフトが最新バージョンへ対応するまでは」
    ・申請ソフト利用後、JRE1.4.2_09を無効にする
    ・Java Web Start(JREの自動アップデート)は常に非稼動状態にする
    ・信頼できないサイトにアクセスしない

    が挙げられていますが、ユーザーの負担が大きいので

    最も有効な対処法は、「電子申請なんて二度と利用しない」と考える国民が増えることでしょう。

  13. なぜバージョン固定なのか
    むたさん ほんとJRE問題別ブログでひとつよろしくお願いします。

    自動車OSSや法務省関連はいわゆるパッチバージョンまで固定してアプリを開発している。

    プログラマーの能力の問題なのか?
    上位互換性を意識していないのか?

    まあ 法務省のオンライン申請システム分については現在JRE6でどこまで動くかテスト中です。

    電子署名も公的個人認証の期限切れを見破ったのでかなりな機能は使えていそうです。

    けっきょく役所側がテストをさぼるから、自信を持って、上位のバージョンを指定できないのでしょう。

  14. 過去のセキュリティホールを放置すると
    たびたびすみません。
    JVNの脆弱性レポートを見ていると
    今年の1月にはちゃんと出ていました。

    http://jvn.jp/cert/JVNTA07-022A/index.html

    で 今回の最新の情報に繋がっていくわけですが

    http://news.www.infoseek.co.jp/comp/internet/story/itmedia20070607098enterprise

    長めに引用します。

    「また、この問題とは別のJREの脆弱性を狙うエクスプロイトが確認されたことを受け、SANS Internet Storm Centerは6月7日、注意を呼び掛けている。
     エクスプロイトの対象となっている脆弱性は2007年1月に公表されたもので、JDK/JRE 5.0 Update 9以前、SDK/JRE 1.4.2_12以前およびSDK/JRE 1.3.1_18以前に影響がある。GIF画像の処理に問題があり、細工を施した画像を読み込むとバッファオーバーフローが発生し、システムを乗っ取られる恐れがあるというものだ。
     確認されたエクスプロイトは、細工を施した悪意ある画像を表示させてメモリ破損を引き起こし、コード実行につなげるという。このコードにはダウンローダが含まれており、パスワードを盗み取る別のマルウェアを落としてくる仕組みになっているという。
     SANSがこのコードを30種類以上のウイルス対策ソフトでチェックしてみたところ、悪意あるJavaクラスを検出できたのはわずか1製品だけだった。この結果を受けSANSは、多くのウイルス対策ソフトでは、RTF形式のドキュメントに含まれた実行ファイルと同様、Javaクラスのプロパティをチェックできないことに懸念を示している。」

    1月の段階で手を打っておけば、今回のセキュリティホールの問題だと、二つの対策に右往左往しなくてすんだわけです。エクスプロイトと言われるから素人にはなんのこっちゃわからんわけで、ブラスターみたいなものと言われれば、それはウィルスやんけ、で慌てるはずなのです。

    各省庁もわかってるのでしょうかね。そのくらいは。
    1月の段階で手をうってなかったところは、レッドカードですね。

  15. 電子入札は
    電子入札はもっと大変になりますか。
    http://www.cals.jacic.or.jp/coresc/Member5/johokoukai05_06.htm

    電子署名用のラッパというのが、認証業者ごとに違うJREのバージョンを要求するとか。

    エクスプロイトのことを考えると、メールのやり取りも、入札用パソコンと別にしないと危ないかもしれませんね。

コメントは停止中です。