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

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

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

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

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

      by Anonymous Coward

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

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

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

      • by Anonymous Coward on 2006年03月26日 23時02分 (#909346)
        基本的な部分、「国はフォーマットとプロトコルを決めれば良い」には同意する。

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

        >民間のビジネスチャンスは潰す
        民間に食い物にされて、国民が馬鹿を見る [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 のほげほげパラメータとかではまったく不足です。

              親コメント

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

処理中...