アカウント名:
パスワード:
ていうかですね、入力するシステムまで官庁が用意するのが おかしいんですよ。
国の事務関係のファイルフォーマットとその送付方法だけ 定めれば、あとは(Intuitとかみたいな)民間が使い勝手の よいアプリケーションを開発・販売するのではないか?
そこを官庁が使い勝手と品質に劣るシステムをわざわざ作って 無料化とかやるから民間のビジネスチャンスは潰すわ、 駄目システムで利用者を減らすわ、縦割り弊害でコストは かかるは電子政府をせっせと潰しているんだから世話ないと しかいいようがありません。
元ACですが、クライアント側で各アプリケーションが 独自に色々なことをするのははっきりいって望ましい。
例えば会計ソフトに申請機能を組み込む、CADソフトに 建築設計の審査申請機能を埋め込む、などなどです。 もちろん拡張部分はそのアプリ固有に閉じますが、その シェアを奪わんとする側は移行ツールを用意するなど 製品をさらに改善してくるでしょう。また逆に、アプリに 閉じない汎用ツールを目指す側はシンプルな申請ツールを 開発するでしょう。
申請操作ではなく、本質的な申請情報の部分に国の役割を 限定することがクライアント側に自由をもたらし、一定 ルールの下での自由競争が多様性と品質の改善を もたらします。最終的にはこのような民間がドライブする 努力こそが優れた電子国家を作るのであって、国は申請を 受け付けるプレーヤでもあるものの、基本的にはそれを 阻害しない範囲での審判に徹しなくてはなりません。
リファレンス実装に関していえば、あくまでリファレンスに とどまる(MIT X 的?)のであれば有益ですが、現状では 実提供にシフトしてしまっていること、また、実装に 傾きすぎて、本質である情報交換フォーマット・プロトコルの 制定からかけ離れていることから、現状反対です。彼らは 単なる「リファレンス」実装の表面動作に囚われすぎており、 規格制定の重要性・意義について理解しているとは 思えません。これは各省庁の責というより、e-japanという 大本の基本方針が「枠組み作り」ではなく「動かすこと」に 実質なってしまっていることが大きいかとは思いますが。
なお、ここから先は枝葉末節な技術論ですが、フォーマット対 パラメータについては、フォーマットであるべきと思います。 これらの情報の応用分野を広げるには、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
Webは不便だ (スコア:5, すばらしい洞察)
Java必須とかFlash必須とかActiveX必須とかはイントラ向けならありですが、多くの人が自由に使えるサービスには不向きです。特に公のものならなおさら。
WebアプリケーションはWebブラウザから使え、クライアント側のアプリケーション更新も必要なく、「多くの人が利用できる」反面、ネイティブアプリケーションに比べて制約が多く入力補助や画面の変化がスムーズでなく、UI操作をリンクとボタンのクリックのみに縛られるなど「ユーザにとって不便」です。
最初に「ユーザにとって不便」という面の認識をきちんと分かってもらってないと、不便さを克服しようとしてJavaやFlash等を持ち出してネイティブアプリ寄りなことを実現し、その代償としてWebアプリケーションとしての「多くの人が利用できる」利点を失っているのだと思う。
Re:Webは不便だ (スコア:4, すばらしい洞察)
ていうかですね、入力するシステムまで官庁が用意するのが おかしいんですよ。
国の事務関係のファイルフォーマットとその送付方法だけ 定めれば、あとは(Intuitとかみたいな)民間が使い勝手の よいアプリケーションを開発・販売するのではないか?
そこを官庁が使い勝手と品質に劣るシステムをわざわざ作って 無料化とかやるから民間のビジネスチャンスは潰すわ、 駄目システムで利用者を減らすわ、縦割り弊害でコストは かかるは電子政府をせっせと潰しているんだから世話ないと しかいいようがありません。
Re:Webは不便だ (スコア:0)
>官庁が使い勝手と品質に劣るシステムをわざわざ作って無料化
選択の自由を認めた上で、リファレンス実装として存在するのはムダではないでしょう。
それが無いままだと、一時期のブラウザ競争みたいに民間企業の競争による独自の機能拡張を許し、
制定したフォーマットとプロトコルが形骸化する恐れがあるからです。
>民間のビジネスチャンスは潰す
民間に食い物にされて、国民が馬鹿を見る [srad.jp]という話もありますね。
望むと望まざるに関わらず、さまざまなコスト・利権が発生し、長期運用が大前提な問題だけに、
仕様設定から調達に到るまで一筋縄ではいかない難しい問題があるのでしょう。
Re:Webは不便だ (スコア:2, 参考になる)
> 制定したフォーマットとプロトコルが形骸化する恐れがあるからです。
そんなことはあり得ないでしょ。
元ACの提案は、
ユーザーインターフェース周りは民間にまかせて、
官庁の電子申請用サーバは、
・制定したプロトコルを通して
・制定したフォーマット形式のデータが届いたら
・申請を処理する
・UIの無いシステム
にしたらどうかということですから、プロトコルやフォーマットに独自の機能拡張なんかしようとしても、官庁サーバ側が受け付けてくれません。
問題が起きるとしたら、
「官庁ごとに勝手な独自拡張をして、官庁間の互換性が取れなくなる」
可能性でしょうか。
縦割りでいかにも起きそうです。
Re:Webは不便だ (スコア:0)
しかし、元AC [srad.jp]は
>国の事務関係のファイルフォーマットとその送付方法
と言ってるので、パラメータから具体的ファイル形成して転送する実装に読めました。
(流石にそんなことは無いと思いますが)PDFやDOCを郵送するとも読めます。
ローカルでの閲覧・作業を考慮すると、ファイルはローカルにも作られるでしょう。
そうなると、あるクライアントUIで表示したときに有効になる情報を動的に埋め込み、
それをもとにクライアントの優位性、差別化を計る事が可能になります。
中央で管理するサーバーが、それを殺ぎ落とすから問題ないという考えもありますが、
入力の使い勝手が異なるものが散在するのは、人事異動、教育コスト面で不利です。
競争の結果、脱落していく企業を製品運用のために税金で支援という事にもなりかねない。
リファレンスは、あるに越した事はありません。
「官庁ごとに勝手な独自拡張をして、官庁間の互換性が取れなくなる」が、
より自社の製品を売り込みたい民間企業主導で行われないとも限らないと言う事。
縦割りでいかにもというより、利権争奪戦で行われがちです。
国は枠組みを作り、民間が実行を担う (スコア:4, 興味深い)
元ACですが、クライアント側で各アプリケーションが 独自に色々なことをするのははっきりいって望ましい。
例えば会計ソフトに申請機能を組み込む、CADソフトに 建築設計の審査申請機能を埋め込む、などなどです。 もちろん拡張部分はそのアプリ固有に閉じますが、その シェアを奪わんとする側は移行ツールを用意するなど 製品をさらに改善してくるでしょう。また逆に、アプリに 閉じない汎用ツールを目指す側はシンプルな申請ツールを 開発するでしょう。
申請操作ではなく、本質的な申請情報の部分に国の役割を 限定することがクライアント側に自由をもたらし、一定 ルールの下での自由競争が多様性と品質の改善を もたらします。最終的にはこのような民間がドライブする 努力こそが優れた電子国家を作るのであって、国は申請を 受け付けるプレーヤでもあるものの、基本的にはそれを 阻害しない範囲での審判に徹しなくてはなりません。
リファレンス実装に関していえば、あくまでリファレンスに とどまる(MIT X 的?)のであれば有益ですが、現状では 実提供にシフトしてしまっていること、また、実装に 傾きすぎて、本質である情報交換フォーマット・プロトコルの 制定からかけ離れていることから、現状反対です。彼らは 単なる「リファレンス」実装の表面動作に囚われすぎており、 規格制定の重要性・意義について理解しているとは 思えません。これは各省庁の責というより、e-japanという 大本の基本方針が「枠組み作り」ではなく「動かすこと」に 実質なってしまっていることが大きいかとは思いますが。
なお、ここから先は枝葉末節な技術論ですが、フォーマット対 パラメータについては、フォーマットであるべきと思います。 これらの情報の応用分野を広げるには、
Re:国は枠組みを作り、民間が実行を担う (スコア:0)