パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

電子政府が使えない理由、縦割りの弊害?JREの弊害?」記事へのコメント

  • Webは不便だ (スコア:5, すばらしい洞察)

    by yu_raku (419) on 2006年03月26日 14時27分 (#909093)
    基本はHTML+CSSのみできっちり作った上で、あってもなくても困らない入力補助機能のみをJavaScriptでというような作りにしておけば利便性をあまり下げることなく、多くの環境で使ってもらえるWebサービスができると思います。
    Java必須とかFlash必須とかActiveX必須とかはイントラ向けならありですが、多くの人が自由に使えるサービスには不向きです。特に公のものならなおさら。

    WebアプリケーションはWebブラウザから使え、クライアント側のアプリケーション更新も必要なく、「多くの人が利用できる」反面、ネイティブアプリケーションに比べて制約が多く入力補助や画面の変化がスムーズでなく、UI操作をリンクとボタンのクリックのみに縛られるなど「ユーザにとって不便」です。
    最初に「ユーザにとって不便」という面の認識をきちんと分かってもらってないと、不便さを克服しようとしてJavaやFlash等を持ち出してネイティブアプリ寄りなことを実現し、その代償としてWebアプリケーションとしての「多くの人が利用できる」利点を失っているのだと思う。
    • Re:Webは不便だ (スコア:4, すばらしい洞察)

      by Anonymous Coward on 2006年03月26日 19時10分 (#909238)

      ていうかですね、入力するシステムまで官庁が用意するのが おかしいんですよ。

      国の事務関係のファイルフォーマットとその送付方法だけ 定めれば、あとは(Intuitとかみたいな)民間が使い勝手の よいアプリケーションを開発・販売するのではないか?

      そこを官庁が使い勝手と品質に劣るシステムをわざわざ作って 無料化とかやるから民間のビジネスチャンスは潰すわ、 駄目システムで利用者を減らすわ、縦割り弊害でコストは かかるは電子政府をせっせと潰しているんだから世話ないと しかいいようがありません。

      親コメント
      • Re:Webは不便だ (スコア:2, すばらしい洞察)

        by bero (5057) on 2006年03月27日 12時55分 (#909673) 日記
        国ではないですがドメイン関係の申請がコレに近かったと思います。

        ドメインのルート(当時internicやjpnic)は原則として定型フォーマットのメールで申請を受け付けていました。
        事業者はwebform等の皮をかぶせてユーザに提供します。
        そこに使いやすい事業者、使いにくい事業者等の差が出てきます。
        あるいは自力で定型フォーマット書けば事業者通さずに安く上げることもできました。

        現在はjpドメインの場合は必ず事業者通すようになってるので、事業者-jprs間でどのようなやり取りになっているのかはユーザには不明ですが、おそらく内部的には定型フォーマットで、皮や価格の部分で各社競争しているという構図は変わらないと思います。
        親コメント
      • by Anonymous Coward
        基本的な部分、「国はフォーマットとプロトコルを決めれば良い」には同意する。

        >官庁が使い勝手と品質に劣るシステムをわざわざ作って無料化
        選択の自由を認めた上で、リファレンス実装として存在するのはムダではないでしょう。
        それが無いままだと、一時期のブラウザ競争みたいに民間企業の競争による独自の機能拡張を許し、
        制定したフォーマットとプロトコルが形骸化する恐れがあるからです。

        >民間のビジネスチャンスは潰す
        民間に食い物にされて、国民が馬鹿を見る [srad.jp]という話もありますね。
        望むと望まざるに関わらず、さまざまなコスト・利権が発生し、長期運用が大前提な問題だけに、
        仕様設定から調達に到るまで一筋縄ではいかない難しい問題があるのでしょう。
        • Re:Webは不便だ (スコア:2, 参考になる)

          by taka2 (14791) on 2006年03月26日 23時25分 (#909359) ホームページ 日記
          > 一時期のブラウザ競争みたいに民間企業の競争による独自の機能拡張を許し、
          > 制定したフォーマットとプロトコルが形骸化する恐れがあるからです。

          そんなことはあり得ないでしょ。
          元ACの提案は、
          ユーザーインターフェース周りは民間にまかせて、

          官庁の電子申請用サーバは、
          ・制定したプロトコルを通して
          ・制定したフォーマット形式のデータが届いたら
          ・申請を処理する
          ・UIの無いシステム

          にしたらどうかということですから、プロトコルやフォーマットに独自の機能拡張なんかしようとしても、官庁サーバ側が受け付けてくれません。

          問題が起きるとしたら、
          「官庁ごとに勝手な独自拡張をして、官庁間の互換性が取れなくなる」
          可能性でしょうか。
          縦割りでいかにも起きそうです。
          親コメント
          • by Anonymous Coward
            ファイルである必要さえ無いという、パラメータ中心の実装ですね。
            しかし、元AC [srad.jp]は
            >国の事務関係のファイルフォーマットとその送付方法
            と言ってるので、パラメータから具体的ファイル形成して転送する実装に読めました。
            (流石にそんなことは無いと思いますが)PDFやDOCを郵送するとも読めます。

            ローカルでの閲覧・作業を考慮すると、ファイルはローカルにも作られるでしょう。
            そうなると、あるクライアントUIで表示したときに有効になる情報を動的に埋め込み、
            それをもとにクライアントの優位性、差別化を計る事が可能になります。

            中央で管理するサーバーが、それ
            • by Anonymous Coward on 2006年03月27日 11時54分 (#909626)

              元ACですが、クライアント側で各アプリケーションが 独自に色々なことをするのははっきりいって望ましい。

              例えば会計ソフトに申請機能を組み込む、CADソフトに 建築設計の審査申請機能を埋め込む、などなどです。 もちろん拡張部分はそのアプリ固有に閉じますが、その シェアを奪わんとする側は移行ツールを用意するなど 製品をさらに改善してくるでしょう。また逆に、アプリに 閉じない汎用ツールを目指す側はシンプルな申請ツールを 開発するでしょう。

              申請操作ではなく、本質的な申請情報の部分に国の役割を 限定することがクライアント側に自由をもたらし、一定 ルールの下での自由競争が多様性と品質の改善を もたらします。最終的にはこのような民間がドライブする 努力こそが優れた電子国家を作るのであって、国は申請を 受け付けるプレーヤでもあるものの、基本的にはそれを 阻害しない範囲での審判に徹しなくてはなりません。

              リファレンス実装に関していえば、あくまでリファレンスに とどまる(MIT X 的?)のであれば有益ですが、現状では 実提供にシフトしてしまっていること、また、実装に 傾きすぎて、本質である情報交換フォーマット・プロトコルの 制定からかけ離れていることから、現状反対です。彼らは 単なる「リファレンス」実装の表面動作に囚われすぎており、 規格制定の重要性・意義について理解しているとは 思えません。これは各省庁の責というより、e-japanという 大本の基本方針が「枠組み作り」ではなく「動かすこと」に 実質なってしまっていることが大きいかとは思いますが。

              なお、ここから先は枝葉末節な技術論ですが、フォーマット対 パラメータについては、フォーマットであるべきと思います。 これらの情報の応用分野を広げるには、

              • 情報として流通可能で、
              • 他の情報と統合でき、
              • 他の情報から抽出できる
              といった点を満たさなくてはなりません。そして、 このためには、標準の表現形式(=フォーマット)でなくては なりません。官庁 API のほげほげパラメータとかではまったく不足です。

              親コメント
    • Re:Webは不便だ (スコア:1, 参考になる)

      by Anonymous Coward on 2006年03月26日 16時41分 (#909171)

      HTML+CSS+Javascrip のみで署名処理ができるアプリが書けたら神。

      最重要な要求仕様を満たさないと意味がないわけで。

      Java Applet / ActiveX / Java WebStart / .NET ClickOnce / ネイティブアプリ

      一般に実行環境が簡単に準備できそうな 選択肢はこのぐらい。他になんかある?

      親コメント
      • by Anonymous Coward
        クライアント側で重要な処理をさせようというのがそもそも間違いだと思うぞ。
        閉じたネットワーク環境ならそれでも良いけど。
      • by Anonymous Coward
        >HTML+CSS+Javascrip のみで署名処理ができるアプリが書けたら神。
        RSA暗号をJavaScriptで書けるんだからもう少し頑張れば出来そうな気がします。
        http://www.faireal.net/articles/8/01/#d40204
        • by nim (10479) on 2006年03月28日 0時24分 (#910029)
          いや、JavaScript は基本的に sandbox の中で動作し、サーバからコントロールされるものだからこそ電子署名の用途には使えないのです。

          ちょっと考えてもらえればわかると思いますが、JavaScript で署名できるとしたら、サーバ自身がブラウザに署名をさせられることになってしまいます。署名はユーザ自身がある動作を行ったことを証明できないといけないので、ユーザ以外がこれをできるのであれば意味がありません。

          もちろん、JavaScript(というかブラウザ自体)に電子署名を行う暗号化サービスプロバイダへのインタフェースがあればそれで済む問題だとは思いますが。
          親コメント
    • by Anonymous Coward
      >入力補助機能のみをJavaScriptでというような

       w3mではJavaScriptが使えない。
       多くの環境で使ってもらえるWebサービスではないです。

       多くのPCで使ってもらえるWebサービスならば、はじめからWindows+IEの環境想定で充分。
      • Re:Webは不便だ (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2006年03月26日 15時22分 (#909124)
        w3mで使えないくらいで、多くの環境で使えない、と称するのは、あまりに滑稽である。

        #w3mしか使ってない人って、全Webユーザの何ppmくらい?
        親コメント
        • #909100 [srad.jp]は、環境の話であって、人の話ではない。

          どれだけ多くのシステムに、ユーザの閲覧を必要としない
          Web クライアントがあると思ってる?
          ユーザが直接扱う Web ブラウザなんてのは、
          Web クライアントが使われる場面のうちの、ほんの
          一部でしかないよ。
          --
          # mishimaは本田透先生を熱烈に応援しています
          親コメント
        • Re:Webは不便だ (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2006年03月26日 15時54分 (#909150)
          どっちかってえと現代のテキストベースWebブラウザがJavaScriptすらまともにサポートしてないのが原因ですな。
          w3mはページャであるという逃げ道があるからいいけど。
          親コメント
      • by kanie (911) on 2006年03月26日 15時39分 (#909141) ホームページ
        親コメントには「あってもなくても困らない」と書いてあるみたいですが。
        Ajaxも、そういう風に使われていればいいんだけどね。
        親コメント
      • by oku (4610) on 2006年03月26日 15時48分 (#909146) 日記
        >入力補助機能のみをJavaScriptでというような

         w3mではJavaScriptが使えない。
         多くの環境で使ってもらえるWebサービスではないです。

        「入力『補助』機能」に JavaScript が使われるくらいなら構わないのではないでしょうか? JavaScript が実装されていない UA なら自力で入力すればすむことです。

        # JavaScript が画面遷移とかに使われていて、かつ
        # 手動で画面遷移できるボタンだの何だのが
        # 画面上になければ「死ね」ですが。

        親コメント
      • by Y.. (7829) on 2006年03月26日 16時05分 (#909155) 日記
        だから あってもなくても困らない入力補助機能がJavaScriptなんでしょ?
        ブラウザがJavaScriptを解釈できないなら普通に手入力してSubmitできればOKです

        それから
        環境想定でWindows+IEの組み合わせではダメですね
        基本的に環境想定はW3Cの標準に沿ったブラウザ(架空のブラウザ たとえばHTML 4.01 Transitionalを完璧にサポートしたブラウザ...みたいなやつ)で、
        なおかつIEでもきちんと動くという感じがよいでしょう
        そうすればIEが標準にあわせてきても、既存の怪しい挙動を維持しても、きちんと動作するやつが作れるんじゃないかな?
        一応標準に準拠なら他のブラウザでも動くでしょうし、完成時点で動かなくてもブラウザのバグがとれてくればそのうち動くようになると思われます
        でもIEだけにあわせちゃうと....将来のIEを含めた他のブラウザでの動作が怪しくなっちゃう危険が...
        親コメント
        • by MG42 (30424) on 2006年03月26日 23時09分 (#909348) 日記
          わざわざ架空のWebブラウザまで用意しなくても、 CSS1準拠ブラウザ基準というすばらしいソリューションがありますよ。お一ついかがですか。
          #IE用にboxモデルだけはいじらないといけませんが。
          --
          All your base are belong to us
          親コメント
        • by Anonymous Coward
          > 基本的に環境想定はW3Cの標準に沿ったブラウザで、

          [Amaya] [w3.org]

          #ただのうけ狙いなのでAC
      • by Anonymous Coward
        PC限定されるより、携帯対応して欲しいな。
        無駄に飾るより、必要最小限にして欲しいな。
        どうしても無駄に飾ってお金を浪費したいなら
        それこそ各クライアント+環境専用ページでも
        作って下さい。(ActiveXを利用する場合はこちら、とか)
        • Re:Webは不便だ (スコア:2, 参考になる)

          by yu_raku (419) on 2006年03月27日 10時03分 (#909543)
          むしろ、変な独自仕様の携帯のほうが標準的なWebブラウザに歩み寄って欲しい。
          DocomoとかDocomoとかDocomoとか。
          せめてクッキーくらいは使えるようにしないと、セッションキーをURLに含むハメに遭い、セキュリティ面でも相当危ういサイト作りになってるところが多い。
          その点、auは標準的な作りのページにしていれば、携帯であることを意識した作りにしていなくてもしっかり使えるのが嬉しい。
          vodafoneはよくしらない…
          親コメント

※ただしPHPを除く -- あるAdmin

処理中...