教員免許レジストリ と 官報情報検索ツール
文部科学省は、教員免許レジストリ と 官報情報検索ツール を別立てで設計、開発、運用しているのでしょうか?一体のモノだろうに。 Yahoo!Japan 読売新聞【独自】免許失効教員の官報不掲載61人、うち46人がわいせつ事案 2020/12/29(火) https://news.yahoo.co.jp/articles/3211... » 詳しく
- 1ポイント
- 1票
- 0コメント
文部科学省は、教員免許レジストリ と 官報情報検索ツール を別立てで設計、開発、運用しているのでしょうか?一体のモノだろうに。 Yahoo!Japan 読売新聞【独自】免許失効教員の官報不掲載61人、うち46人がわいせつ事案 2020/12/29(火) https://news.yahoo.co.jp/articles/3211... » 詳しく
引用:NHK https://www3.nhk.or.jp/news/html/20201129/k10012736261000.html 政治資金収支報告書 6県がインターネット公開に対応せず 11月29日 4時15分 去年分の政治資金収支報告書が、30日までに、全国のすべての都道府県で公表されます。総務省は、16年前からインターネット... » 詳しく
出典: https://summit2020.code4japan.org/program/?id=149 概要 「BADオープンデータ供養寺」は世の中に災厄をもたらすBADなオープンデータが二度とこの世を彷徨わないように「供養(データクレンジング)」するために建立されました。 (中略) 本セッションでは、デー... » 詳しく
官公庁の公表物は、政府標準利用規約(第2.0版)の下、CC-BY4.0国際ライセンス互換性であるところ、なぜか、内閣府下のウェブサイトの PDFファイル は、すべからく保護設定がかけられているようです。 このために、内閣府という中枢的な政府文書が PDFに対して"テキストをハ... » 詳しく
まだお気に入りがありません。
#118
> 元号処理依存部を最小限に留めるという節度を持っている開発者を選べば
> 出来るのであれば、まずは元号処理依存部を最小限に留めるという
> 節度を持っている開発者を選べば良いだけでは。
ほげさんに、全面同意。
そして、
そのような 節度を持った開発者 らと一緒になって
ほげさんが挙げたようなことを含め
行き届いた 情報システム や 業務 の設計や運用ができていたのであれば、
2001年のe-Japan計画
( https://www.kantei.go.jp/jp/it/network/dai1/1siryou05_2.html )
から
ほどなくして
日本は
実を伴った世界最先端の
電子政府を
実現していたことでしょう。
#115
> 改元費用が大したことがないとおっしゃっている方は、
> ご自身のお財布から59,228千円という大金を捻出できるのでしょうか?
> http://www.pref.saitama...T2018-10/pdf/003867.pdf
( ← http://www.pref.saitama.lg.jp/yosan-info/ST2018-10/main.html )
埼玉県民の方々には、屁でも無いのでしょう。知らんけど。
その費用 6千万円 は、県の15部局のうちの1つであって、
実際は、県全体で、
また、都道府県、市町村、国、
そして、企業・団体 と合わせて、
日本全体で
いくら費やしたのでしょうね。
これだけの 予算 や SEやプログラマの労働力、
そのようなことに動員することが
当時、他にもあったであろう重要なシステム改修を排して
取り組まざるを得なかった。
そして、こんなお祭りごとが
将来的にも
繰り返されていく。
今のままであるなら。
住民記録システムが戸籍システムと分離・独立されていることを前提として、今も議論が進められているように見えるけど、実際、どうなんでしょ。
住民から自治体に提出される出生届。そのバックオフィス処理をオンリーワンス原則で情報システムの観点からも完遂させるために、法的手当ても含めてBPRしようっていうのが、デジタル庁だと期待したのに。今の構想では、その戦いが放棄されているように見える。
これが、私の見落としだったら申し訳ないけれども、もし、本当にそういう問題提起がないのだとしたら、今の時点で、もう終わっている。
住民記録システムが戸籍システムと分離・独立されていることを前提として進められている政府内の今の議論って、なんか、間違ってね?
住民から自治体に提出される出生届。そのバックオフィス処理をオンリーワンス原則で情報システムの観点からも完遂させるために、法的手当ても含めてBPRしようっていうのが、デジタル庁だと期待したのに。今の構想では、その戦いが放棄しているように見える。
これが、私の見落としだったら申し訳ないけれども、もし、本当にそういう問題提起がないのだとしたら、今の時点で、もう終わっている。
住民記録システムが戸籍システムと分離・独立されていることを前提として進められている政府内の今の議論って、なんか、間違ってね?
住民から自治体に提出される出生届。そのバックオフィス処理をオンリーワンス原則で情報システムの観点からも完遂させるために、法的手当ても含めてBPRしようっていうのが、デジタル庁だと期待したのに。今の構想では、その戦いが放棄しているように見える。
これが、私の見落としだったら申し訳ないけれども、もし、本当にそういう問題提起がないのだとしたら、今の時点で、もう終わっている。
住民記録システムが戸籍システムと分離・独立されていることを前提として進められている政府内の今の議論って、なんか、間違ってね?
住民から自治体に提出される出生届。そのバックオフィス処理をオンリーワンス原則で情報システムの観点からも完遂させるために、法的手当ても含めてBPRしようっていうのが、デジタル庁だと期待したのに。今の構想では、その戦いが放棄しているように見える。
これが、私の見落としだったら申し訳ないけれども、もし、本当にそういう問題提起がないのだとしたら、今の時点で、もう終わっている。
住民記録システムが戸籍システムと分離・独立されていることを前提として進められている政府内の今の議論って、なんか、間違ってね?
住民から自治体に提出される出生届。そのバックオフィス処理をオンリーワンス原則で情報システムの観点からも完遂させるために、法的手当ても含めてBPRしようっていうのが、デジタル庁だと期待したのに。今の構想では、その戦いが放棄しているように見える。
これが、私の見落としだったら申し訳ないけれども、もし、本当にそういう問題提起がないのだとしたら、今の時点で、もう終わっている。
to be 要件定義の際に、as isを洗い直したら、米配給も出てきたのね。米穀手帳を電算処理していた自治体さんってどこだろう。当時は先進的だったのだろうな。
https://www.soumu.go.jp/main_content/000706675.pdf#page=234
【実装しない機能】
・米穀の配給の受給に関する情報
【考え方・理由】
・米穀の配給については、運用上管理されていないため標準仕様書には不要。
改修に関するコスト管理・リスク管理として、
日付管理を改修する場合と、
日付入出力変換を改修する場合と。
情報システムのDevOpとしては、
どちらを選択する方がいいんでしょうかね。
住基ネットの日付管理は、和暦。
住民記録システム標準仕様書【第1.0版】 2020年9月11日
https://www.soumu.go.jp/main_sosiki/kenkyu/jichitaishisutemu_hyojunka/index.html
1.1.1 日本人住民データの管理
生年月日については、住基ネット上は、日本人住民は和暦で管理されていることから、住民記録システムにおいても日本人住民は和暦で管理することとする。ただし、データベースに保持する形式として西暦も許容するが、入出力において和暦に変換する機能を有すること。
#092
Caminoroadさん
> これも含めてどれぐらい税金が使われているんでしょうね。
エビデンスの可視化は、議論の第一歩。
内閣官房デジタル改革担当におかれては、
「平成31年4月1日 新元号への円滑な移行に向けた関係省庁連絡会議申合せ」
https://www.cao.go.jp/others/soumu/gengou/index.html
の周辺資料から、要した費用についての材料提供をお願いしたいところ。
次に対する備えとして、何かしらのものはお持ちでしょうから。
これは、e-gov法令検索、対象カテゴリ"法律"で「商法」の検索結果。
商法(明治三十二年法律第四十八号)
公布日:明治三十二年三月九日
施行日:令和二年四月一日
(平成二十九年法律第四十五号による改正)
商法施行法(明治三十二年法律第四十九号)
公布日:明治三十二年三月九日
施行日:平成三十一年四月一日
(平成三十年法律第二十九号による改正)
金融商品取引法(昭和二十三年法律第二十五号)
公布日:昭和二十三年四月十三日
施行日:令和二年五月一日
(令和元年法律第二十八号による改正)
家畜商法(昭和二十四年法律第二百八号)
公布日:昭和二十四年六月十日
施行日:令和元年十二月十四日
(令和元年法律第三十七号による改正)
ここで表記されている年次:明治、昭和、平成、令和○○年(漢数字)。
パッと見で、新古を判断できますか。
数字だけで素直に経過年数を勘定できるようにしませんか。
元号併記はあってもよいでしょう。けど、元号一本足になるとまるでクイズです。
e-gov法令検索。
これ、先月、システム更改されたばかりの最新版なんですよね。
#087
賛成。
問題: この公文書「元号建定ノ詔書案」( http://www.archives.go.jp/ayumi/photo.html?m=91&pm=3 ※)は、何年前の文書か? カンニングは、しないでください。
#074
NAGATOnoWAさんが言うところの
元号の本質的な部分でもって
この議論に決着を付けて下さることを期待。
それは一体、何でしょう?
火を見るよりも明らかな、その理由。
#075
出発点:https://ideabox.cio.go.jp/ja/about/
デジタル改革アイデアボックス 概要
デジタル化は、日常生活や仕事における手続きや情報共有、活用においてストレスを軽減させ、一人ひとりの暮らしを豊かにし、人々をより生産性の高い仕事に向かうことを後押しするために不可欠です。
しかしながら、我が国のデジタル改革は、その理想に比べて十分とは言えず、特に新型コロナウイルス感染症による働き方改革や、対面を伴わない形での諸手続の実現が望まれている中で、その課題解決は急務となっています。
そこで、インターネット上で国民の皆さんにアイデアを投稿いただき、デジタル社会のかたちやデジタル改革の進め方等について議論を行う仕組みとして「デジタル改革アイデアボックス」を急遽開設しました。
デジタル改革は総力戦です。様々なご意見やアイデアを持つ国民の皆さんこそがデジタル改革の大切な担い手です。
皆さんからの率直なご意見やユニークなアイデアをお待ちしております。
問題: この公文書「元号建定ノ詔書案」( http://www.archives.go.jp/ayumi/photo.html?m=91&pm=3 ※)は、何年前の文書か?
※ この文書の年号表記は、大正15年12月25日 (「記録日付」対馬基さんによる)
証拠開示の現場、一体どうなっているのか。
出典: https://www.change-discovery.org
証拠開示というのは、警察や検察が集めた証拠の一部を、弁護士や被告人に利用できるようにする手続です。
証拠は検察官の手元にあります。
そして、検察官は弁護士に証拠を自分でコピーさせるというやり方をします。
その際に弁護士が使える業者も限られており、1枚40円といった高額の費用がかかります。
「証拠のPDFを渡して欲しい」という要望に検察官が応じた例は、まだ一例も報告されていません。
どうしても電子データで欲しい場合、
「弁護士か事務員が検察庁に出かけていって、書類をファイルに綴じたまま1ページずつデジカメで撮影する」
ことを要求されます。
この日でもいいでしょう。
むしろこれを奇貨として、これまでこの手の量産されてきていた類似の「○○の日」を、この 11月11日「デジタルの日」にすべて移し替えて、まとめる機会としてはどうでしょうか。
「○○の日」ができる度に、仕事が増えて(人手も予算もないのに)切ない思いをしている人たちが、人知れず、また、少なからずいらっしゃるのではないでしょうか。
これを契機に、スクラップ^n アンド ビルド(nは自然数)、そして、悪しき前例主義の排除となれば、「デジタルの日」は、真の意味で意義深く、皆に歓迎される日になると思います。
この日でもいいでしょう。
むしろこれを奇貨として、これまでこの手の量産されてきていた類似の「○○の日」を、この 10月10日「デジタルの日」にすべて移し替えて、まとめる機会としてはどうでしょうか。
「○○の日」ができる度に、仕事が増えて(人手も予算もないのに)切ない思いをしている人たちが、人知れず、また、少なからずいらっしゃるのではないでしょうか。
これを契機に、スクラップ^n アンド ビルド(nは自然数)、そして、悪しき前例主義の排除となれば、「デジタルの日」は、真の意味で意義深く、皆に歓迎される日になると思います。
この日でもいいでしょう。
むしろこれを奇貨として、これまでこの手の量産されてきていた類似の「○○の日」を、この 1月1日「デジタルの日」にすべて移し替えて、まとめる機会としてはどうでしょうか。
「○○の日」ができる度に、仕事が増えて(人手も予算もないのに)切ない思いをしている人たちが、人知れず、また、少なからずいらっしゃるのではないでしょうか。
これを契機に、スクラップ^n アンド ビルド(nは自然数)、そして、悪しき前例主義の排除となれば、「デジタルの日」は、真の意味で意義深く、皆に歓迎される日になると思います。
どの日でもいいでしょう。
むしろこれを奇貨として、これまでこの手の量産されてきていた類似の「○○の日」を、この「デジタルの日」この一日にすべて移し替えて、まとめる機会としてはどうでしょうか。
「○○の日」ができる度に、仕事が増えて(人手も予算もないのに)切ない思いをしている人たちが、人知れず、また、少なからずいらっしゃるのではないでしょうか。
これを契機に、スクラップ^n アンド ビルド(nは自然数)、そして、悪しき前例主義の排除となれば、「デジタルの日」は、真の意味で意義深く、皆に歓迎される日になると思います。
政府調達公告における紙媒体に関係する条約とは、何でしょうか?ググりましたが、ちょっと私には分かりませんでした。
条約批准が日本の問題であるのなら(ほかにもそういった例はありますが)、日本の努力(世論の後押し、国会批准)により解決できるものなのでしょうか。
または、これは日本だけでどうこうできる問題でなく、世界的な合意、外交努力が必要な問題になるのでしょうか。
その見極めを付けることができません。
陛下もすなるオンライン会議 https://www.news24.jp/articles/2020/11/26/07769343.html 。
オンライン御名御璽を制約するものは、あるのだろうか。
e-Statが、「統計表における機械判読可能なデータの表記方法」の意見照会を11月25日から12月1日まで行っています。
https://www.e-stat.go.jp
そこでは、"チェック項目1-10 e-stat の時間軸コードの表記、西暦表記又は和暦に西暦の併記がされているか"という案も書かれています。
https://www.e-stat.go.jp/estat/html/topic20201125.pdf#page=14
統計表だけで済む話では、なんですけどね > https://twitter.com/konotarogomame/status/1331478653977325569
#013
> 最終的に、つまり、皆が感じる課題があり、解決方法が幾つもある場合、
> 誰が、どのように、この議論を参照し、採用し、改善するのでしょうか。
> 5W1Hが判然としません。
文字列が上手にData cleasingされて、テキストデータが支障なく利活用できるデジタル社会を目指しているわけであって。
「1.生活者・事業者の声 - 全角英数字入力/表示の全廃」 2020/10/10 00:25 へのコメントのマルチポストになりますが、
人工知能を使っての自然言語処理の際(行政サービスに関するチャットボット開発、など)、このことが足を引っ張り、生産性を下げさせることにならないでしょうか?その意味で、英数字の半角文字使用の励行は、公用文の世界でこそ率先して行うべきもの。
関連して、IME事業者(全角英数文字の非推奨化)や ウェブフォーム開発者(ユーザ入力を研磨・正規化して出力(情報共有基盤 IMIに基づく)) による協力も重要。
(こうなってくると、括弧、鉤括弧に用いるべきは、前者は半角、後者は全角、ってことなのかな?一部は曖昧にしていても、大丈夫か...? )
> > それを入力フォームで利用者に求めるのは単なるUXの問題であって、
> > 文字コードの問題ではないと思います。
> 「自動で変換可能」なはずですが、それを利用者側に強制する(してた)
> 銀行系は万死に値すると思います。
同意します。
ユーザがWebフォームに入力した内容を、システム側でクレンジングして、それを確認画面でユーザに確認させることで実装可能。
実際、米国のECサイトでの経験ですが、送付先として入力したアドレスが、次の画面では正規化された状態で確認を求めてきます。
IMEについては、一太郎Government のATOKはかな漢字変換を公用文統制語彙に基づいて実行しています。IME各社は、次回のバージョンアップからでも、全角英数字等の非推奨化に着手してほしいものです。
> 数字との組み合わせで"3ー5"という具合に長音を使ってしまう誤操作が発生するので問題
カード会社請求の文字列処理では、店舗名のカタカナを半角で表す一方、そこに含まれる長音を半角ハイフン置換する、という日本語破壊が横行。辟易しています。
カタカナは日本語であり、それは全角で。
#057
このアイディアの投稿者 jinmskさん の10/10 12:05 追記(以下に引用)を、支持します。
"併用案のお声をいくつかいただいておりますが、行政手続きにどういった利便性があるのかセットでないとかと思います。中途半端に残すくらいであれば不要なのではと考えております。"
#002 marさん、
5月に決まってます。行政自らが、これを実践することから...
https://cio.go.jp/guides#renkeimodel
○ データ連携モデル
行政基本情報データ連携モデル
略称 行政データ連携標準
最終改定 2020年5月14日
対象 各府省
概要 日付時刻、住所、電話番号等、手続や情報提供において分野を問わず使用される基本的なデータの形式について、データ連携を円滑に行えるよう、基本的なデータの記述形式を示したモデル。
・日付時刻 PDF DOCX
・住所 PDF DOCX
・郵便番号 PDF DOCX
・地理情報 PDF DOCX
・電話番号 PDF DOCX
・POIコード PDF DOCX
・POIコード一覧 PDF XLSX
Fuyuhikosさん <-
> 法律・条約への御名御璽、閣議での決裁への署名と花押、辞令、役所のなかの決裁、
> 大臣認定書への押印等は意思決定の手段として深く行政組織に根付いており、
> 廃止は容易ではありません
御璽は取扱外とする、と、行革担当大臣が最初からそう発言していましたが、国民目線からはこのこと自体を吟味する価値はああると思います。両陛下は国民交流の公務をオンラインで先日行われました。
開会詔書を紙ではなくタブレットで手にして述べられば、旧態依然の国会も変わるのではないでしょうか。
半角全角文字の使用のこだわりは、新聞や文学の世界では縦書きの写植事情という観点では、意味のあることかもしれません。
文字の見栄えの観点からどちらを使うべきかどうか、云々といった、本質とは言いがたいマナー教育があるかもしれません。これは議論の対象外でしょう。全角文字の使用が排除されても、等幅フォント・プロポーショナルフォントや、文字送りの設定など、やり方はいくらでもあるでしょう。
問題は、官報や法令、判決文における縦書き文書におけるテキストデータのクレンジングです。これに関して、半角、全角の使用の考え方について、日本語を用いる者における共通認識を形成する好機は、今だと思います。
公文書に用いる読点の表記法を「,」から「、」に改めるという議論が文化審議会の国語課題小委員会で行われているそうです。意味共通基準IMI や 統制語彙 controlled vocabulary、ベース・レジストリの議論も進んでいます。
そのようなくだらない、でも実は大事な、表記揺れの文字統制の議論があるなら、併せて、この議論も詰めておくべき。英字に付随して登場する感嘆符や統合といった記号や、半角カタカナ、機種依存文字の扱いも。
テキストデータ(文字列)というビッグデータのデータ研磨の際、この際、整理しておきたい論点です。人工知能を使っての自然言語処理の際(行政サービスに関するチャットボット開発、など)、このことが足を引っ張り、生産性を下げさせることにならないでしょうか?
その意味で、英数字の半角文字使用の励行は、公用文の世界でこそ率先して行うべきもの、と、考えます。
#053 残るレターは {K,N,Y,R,W,A I,U,E,O}。
こんなことを令和に向けた決定プロセスの中でマジメに考えていたのでしょうか?
そもそも、このような制約条件は本質的な問題ではないし、 皇室に対しても申し訳ないし。
デジタル改革関連法案WG 第3回(11月13日 https://www.kantei.go.jp/jp/singi/it2/dgov/houan_wg/dai3/gijisidai.html )の「資料1 アイデアボックスに寄せられた意見の紹介」で、本アイディアが「行政パブリケーションの生年月日の表記を西暦表記ベース、あるいは和暦との西暦双方での表記にしていただきたい。…」と引用されている。(p16/25 及び p18/25)
このWG資料で注意が必要なのは、「西暦表記」ではなく「和暦との西暦双方での表記」の方に下線を引いていること
本アイディアが「一方、日本独自の文化を継承することも重要かと思うので、西暦への「統一」は堅持したい考えではなく、西暦が表記される「西暦(和暦)」あるいは「和暦 (西暦)」のようなフォーマットで良い。」で締めくくられていることを読み取っての下線引きの使い分けだったかもしれないのだけれども、この締めくくりは「# その他」なんですよね。
私はこのアイディアのタイトルであり、かつ、2者のうち最初の方「西暦表記」のつもりで、このアイディアを推しています。
不動産取引価格情報検索、
年次の絞り込みで使っていたのは西暦なのに、
その結果、得られる表示・ダウンロードされるデータは元号表記、っていうのには
以前からガッカリさせられている。
e-Statでは、逆に、
得られるデータは西暦なのに、
統計の名前は元号表記で表記されている。
データ収集着手にあたり、
まず、元号に当たりをつけることで一苦労。
オープンデータにまつわるこんな罰ゲームのあれこれ、
いつまで続けてるのでしょう(生産性...)
地理空間情報活用推進会議( http://www.cas.go.jp/jp/seisaku/sokuitiri/index.html 地理空間情報活用推進基本法や地理空間情報活用推進基本計画に根拠を持つ)での取組として、これまでどうだったのでしょうね。
合わせて言えば、国勢調査の小地域統計情報である町・丁字等ポリゴンの、基盤地図情報とのハーモナイゼーションについても俎上に載るべきではないか。
#001 このアイデアのことから脱線しますが、Unicodeの中で、同じように見えるグリフで文字コードが異なるケースが複数あるそうです。
https://twitter.com/hal_sk/status/1281853581218336768
この問題も含めて、キッチリとした実装がされますように。
資料「運転免許証のデジタル化」※によると、有効期限の西暦表記が行われるようになった運転免許証は、元号の生年月日のみ記載のマイナカードに統合されるイメージが表示されています。
日本に居住する者は日本人だけでなく、これから一層の多様性が進展していくのだろう、そのためにも運転免許証は期限の西暦表記が行われるようになっていたのに。
※ デジタル・ガバメント閣僚会議 > マイナンバー制度及び国と地方のデジタル基盤抜本改善ワーキンググループ 2020年11月10日https://www.kantei.go.j...dai4/siryou4.pdf#page=3
#008 NHKの報道での年号表現が元号であり、それを聞かされたり目にしたりする途端に、何年前のことなのか、頭が止まる。こんなことは、民放や新聞ではない。
つまらないことだけど、そんなところから、NHKに対する信認が私の中で低下している。
外務省の日本語ページ https://www.mofa.go.jp/mofaj/index.html 年号の表記は、元号ばかり...利用者に対して罰ゲームでも課しているのでしょうか。流行り言葉で言えば、元号ハラスメント。
資料「運転免許証のデジタル化」※によると、有効期限の西暦表記が行われるようになった運転免許証は、元号の生年月日のみ記載のマイナカードに統合されるイメージが表示されています。
日本に居住する者は日本人だけでなく、これから一層の多様性が進展していくのだろう、そのためにも運転免許証は期限の西暦表記が行われるようになっていたのに。
※ デジタル・ガバメント閣僚会議 > マイナンバー制度及び国と地方のデジタル基盤抜本改善ワーキンググループ 2020年11月10日https://www.kantei.go.jp/jp/singi/it2/dgov/kaizen_wg/dai4/siryou4.pdf#page=3
国税庁法人番号公表サイト https://www.houjin-bangou.nta.go.jp/、ダウンロードやAPIにおける年表記は西暦なのに、ウェブでの閲覧は元号。
これ、何かの罰ゲームでしょうか?
政府統計の総合窓口 e-Statでも、統計名と統計データでも、そうなんだよね。
いい加減にしていただきたい(怒気の意味で)。
行政改革担当大臣が御名御璽を電子化しないと言われてましたが、これがそのままでは御名御璽された書面を物理的に保存する業務が残ってしまい、ペーパレス化の妨げになります。
御名御璽の電子化を契機に、天皇陛下が御公務を遠隔でなさる可能性が出てきます。陛下は長く東京にお出でのままですが(明治150年)、それよりも長く(500年)お住まいだった京都にそろそろお戻りになってもよい頃でしょう。災害リスク(関東大地震、富士山噴火)の回避、そして、皇室・宮内庁による首都機能分散・地方創生、また、働き方改革に叶います。親任式や認証官任命式を京都で行うようになれば、大臣交代時などのスケジュールは、いっそ割り切った、ゆとりを持ったものになるでしょう(先日、深夜に及ぶ役所の対応が話題になったことは、記憶に新しい)。外国から着任した大使を陛下がお迎えする信任状捧呈式も、京都の方が似つかわしいのでは。
電子化は、国債で2003年に始まり、通貨も先頃日本銀行が概念実証を表明。法令書面の完全電子化は「世界最先端デジタル国家創造宣言」(という思わず恥ずかしくなるような宣言)の名に恥じない政策目標になるでしょう。
#026 kyoさん、おっしゃるとおりです。
NHK(テレビ、ラジオ)のニュースは、過去の年を一貫して元号でアナウンスしています。見聞きすることの時間感覚を掴もうとすると「頭も使う」(#005 クロさん)ことを強いられます。報道内容をスムーズに理解することが、その度に妨げられます。
NHKのニュースは、何か意図があってそうしているのか(そうさせられているのか)。勘ぐります。
電話や郵便にはユニバーサルサービスが言われているが、インターネット接続はどうだっただろうか。
電話サービス料金よりも、むしろ、それを包含する情報通信技術であるインターネット接続サービス料金の方こそ、公共料金政策として位置付けられるべき。
経済弱者であってもそれを享受できることを保証することは、政府がデジタル庁を進める中で、市民にとっての重要な要件ではないか。
基本的人権としての情報通信技術へのアクセス を進めることは、国連総会も謳っている:4. (d) Applying a comprehensive human rights-based approach in providing and expanding access to information and communications technology, https://digitallibrary.un.org/record/1639840
参考までに↓ 。総務大臣も、課題として認識している。
【総務大臣会見の概要】( https://www.soumu.go.jp/menu_news/kaiken/01koho01_02000943.html )
今回導入しました非接触の調査方法を基本としながら、更に進んでICTを活用して、インターネット回答を一層推進するほか、現在は残念ながら法令による制約はございますけれども、将来はマイナンバーを活用した行政情報の利用なども検討し、国民負担を軽減しながら、精緻で効率的な統計作成に取り組むべきだと考えています。
まずは、今回の国勢調査を安全で確実に実施することに集中したいのですが、調査終了後にはしっかりと検証を行い、次回以降の調査の発展に結びつけてまいります。
他のユーザからの評価(★の数)の平均が4以上のコメントを表示しています。
住民記録システムが戸籍システムと分離・独立されていることを前提として進められている政府内の今の議論って、なんか、間違ってね?
住民から自治体に提出される出生届。そのバックオフィス処理をオンリーワンス原則で情報システムの観点からも完遂させるために、法的手当ても含めてBPRしようっていうのが、デジタル庁だと期待したのに。今の構想では、その戦いが放棄しているように見える。
これが、私の見落としだったら申し訳ないけれども、もし、本当にそういう問題提起がないのだとしたら、今の時点で、もう終わっている。
to be 要件定義の際に、as isを洗い直したら、米配給も出てきたのね。米穀手帳を電算処理していた自治体さんってどこだろう。当時は先進的だったのだろうな。
https://www.soumu.go.jp.../000706675.pdf#page=234
【実装しない機能】
・米穀の配給の受給に関する情報
【考え方・理由】
・米穀の配給については、運用上管理されていないため標準仕様書には不要。
これは、e-gov法令検索、対象カテゴリ"法律"で「商法」の検索結果。
商法(明治三十二年法律第四十八号)
公布日:明治三十二年三月九日
施行日:令和二年四月一日
(平成二十九年法律第四十五号による改正)
商法施行法(明治三十二年法律第四十九号)
公布日:明治三十二年三月九日
施行日:平成三十一年四月一日
(平成三十年法律第二十九号による改正)
金融商品取引法(昭和二十三年法律第二十五号)
公布日:昭和二十三年四月十三日
施行日:令和二年五月一日
(令和元年法律第二十八号による改正)
家畜商法(昭和二十四年法律第二百八号)
公布日:昭和二十四年六月十日
施行日:令和元年十二月十四日
(令和元年法律第三十七号による改正)
ここで表記されている年次:明治、昭和、平成、令和○○年(漢数字)。
パッと見で、新古を判断できますか。
数字だけで素直に経過年数を勘定できるようにしませんか。
元号併記はあってもよいでしょう。けど、元号一本足になるとまるでクイズです。
e-gov法令検索。
これ、先月、システム更改されたばかりの最新版なんですよね。
#074
NAGATOnoWAさんが言うところの
元号の本質的な部分でもって
この議論に決着を付けて下さることを期待。
それは一体、何でしょう?
火を見るよりも明らかな、その理由。
#057
このアイディアの投稿者 jinmskさん の10/10 12:05 追記(以下に引用)を、支持します。
"併用案のお声をいくつかいただいておりますが、行政手続きにどういった利便性があるのかセットでないとかと思います。中途半端に残すくらいであれば不要なのではと考えております。"
#002 marさん、
5月に決まってます。行政自らが、これを実践することから...
https://cio.go.jp/guides#renkeimodel
○ データ連携モデル
行政基本情報データ連携モデル
略称 行政データ連携標準
最終改定 2020年5月14日
対象 各府省
概要 日付時刻、住所、電話番号等、手続や情報提供において分野を問わず使用される基本的なデータの形式について、データ連携を円滑に行えるよう、基本的なデータの記述形式を示したモデル。
・日付時刻 PDF DOCX
・住所 PDF DOCX
・郵便番号 PDF DOCX
・地理情報 PDF DOCX
・電話番号 PDF DOCX
・POIコード PDF DOCX
・POIコード一覧 PDF XLSX
先行アイディアとして、「1.生活者・事業者の声 - 全角英数字入力/表示の全廃」 2020/10/10 00:25 あり。
#053 残るレターは {K,N,Y,R,W,A I,U,E,O}。
こんなことを令和に向けた決定プロセスの中でマジメに考えていたのでしょうか?
そもそも、このような制約条件は本質的な問題ではないし、 皇室に対しても申し訳ないし。
不動産取引価格情報検索、
年次の絞り込みで使っていたのは西暦なのに、
その結果、得られる表示・ダウンロードされるデータは元号表記、っていうのには
以前からガッカリさせられている。
e-Statでは、逆に、
得られるデータは西暦なのに、
統計の名前は元号表記で表記されている。
データ収集着手にあたり、
まず、元号に当たりをつけることで一苦労。
オープンデータにまつわるこんな罰ゲームのあれこれ、
いつまで続けてるのでしょう(生産性...)
電話や郵便にはユニバーサルサービスが言われているが、インターネット接続はどうだっただろうか。
電話サービス料金よりも、むしろ、それを包含する情報通信技術であるインターネット接続サービス料金の方こそ、公共料金政策として位置付けられるべき。
経済弱者であってもそれを享受できることを保証することは、政府がデジタル庁を進める中で、市民にとっての重要な要件ではないか。
基本的人権としての情報通信技術へのアクセス を進めることは、国連総会も謳っている:4. (d) Applying a comprehensive human rights-based approach in providing and expanding access to information and communications technology, https://digitallibrary.un.org/record/1639840
気象庁ウェブサイトの右肩に出ている「災害関連情報」
令和2年7月豪雨
令和元年東日本台風
平成30年北海道胆振東部地震
平成30年7月豪雨
平成29年7月九州北部豪雨
平成28年熊本地震
東日本大震災~平成23年東北地方太平洋沖地震~
何年前の災害か、即答できますか?
外務省の日本語ウェブサイト。無理にでも元号表記しているのが、痛々しい。
#120
ほげさん。
ですよね?
by だるまさん - 2020/12/14 17:55 問題を報告