あなたと創るデジタル社会
合理性があれば、居住地制限も含めての仕事だと思います。 対応できない人は残念ながらその仕事には向かないということです。
#010 このスレッドや前のやつを関係者のフェイスブックとかに投稿してみれば? 俺たちは応援してるんだぜーって。 オリンピック関係はまだ他にもあったような。 やる気があるならいいかげん具体的な方法を当局が公式に提示すべき時期でしょう。 ずるずる時間だけがすぎて、時間切れで「やめました」と言われてもねぇ・・・ みんな外出自粛して家にいるんだから、オリンピックの実現方法について考える時間はあるでしょうに。
#009 こんにちは ご連絡をありがとうございました。 まだ、100％中止と決まったわけではないでしょう？（イギリスから出た話でしょう？） 私の案を踏襲すれば、無観客ながら、黒字で そして安全遂行できるのですが・・・ ここの事務局も全く無関心なので、話が大臣クラスに伝わらず、残念です。
#028 文書IDの件はユニークな番号を付けるための例えなので、この話の本旨ではないです。 文書にユニークな番号を付ける方法なんていくらでもあります。 法律の施行日に関する法律は知りませんが、そこまで法律の施行日予定の変更が難しいなら、現在の元号のままで良いでしょう。 この話は同一の日付について、予定日と実施後の記録日をどのように区別するかという、説明をしています。 法律上変更できないものは変更しなければ良いだけです。
元号表記は、歴史的公文書と判定されるときのみ、併記できるソフトを使って処理すれば良いのではと提案したことがあります。皇室での管理でのけいいを大切に?と思います。 法文について、4桁数字より元号プラス2桁数字の方が取り違えが少なくなる?の提案もしています。
#011 ご指摘ありがとうございます。 私も現在のポイントは原資の付加的なものだということは理解していますが、ここでの意味は現金支給に代えてポイント（という呼び名の電子マネー）を給付するという意味だと思いました。 それなら政治資金もできるんじゃないかと。なので「ポイント」という名称ではなく、電子化とすべきだったかも知れません。 生活保護支給を電子マネーにして管理するのなら、政治資金関係もできるのではないかという短絡的な発想です。 考えてみれば政治家も日本国民が養っているという意味では、生活保護なのかも知れませんね。
#026 ＞ 文書登録なら登録担当者の個人番号がユーザーIDになるでしょう。 作業者の業務中の社員や公務中の公務員を個人として文書に紐づけるとかちょっと頭おかしい。文書発行というものそのものを理解していないとしか思えませんね。まあそもそも、時間に依存せずに発行主体が文書発行毎にシリアルを生成すれば良いだけの話なので、時間でIDという発想から壊れているのですけど。システムで自動生成する場合とか考えてなさげだし。 ＞ 法律の公布日の場合は、予定の段階では予定日付と解釈して西暦で公表し、実際に公布されたら記録日付として元号で記録します。 法律の施行日なんかは法律の文書自体に記述されそれを含めて成立するもので、成立後に改正手続きを踏まえずに改修する事は許されませんよ。文書として情報が固定されるという認識そのものが欠落してるのかな。 法律の文書自体とは別にその文書に付随する情報管理上のメタデータとして付加されるものであればその限りでは無いけど、それこそ文書を管理する情報システムの話なので記年法が何であるかは全く関係無い話ですね。せいぜい UI や入出力をどうするか程度の話。UI の話であれば設定でどうにでもすれば良いだけの話かな。
#005 その通りと思います。 公務員だからとか、会社員だからというのではなく、その職業により提供するサービスが、対象に対して直接接点が必要かどうかという話でしょう。 散髪屋がリモートでサービスを提供できるでしょうか。 消防署がリモートでサービスを提供できるでしょうか。 そういう話でしょう。
#010 ポイントというのはその原資があって、最終的にはそのポイントと原資を交換する形になりますよね。ポイントは通貨ではないので、それだけではなんの役にも立たないのですから。 サービス提供会社から提供されるポイントであれば、サービス提供価格から割り引かれる形で利用者に還元されますし、この提案の「食料ポイント」であれば、手形と同じく消費者から小売店が受け取ったポイントは、その現金化を政府に請求すればそれに相当する現金が支給される仕組みがあるものと思います。 対して、政治資金というのは民間から政治団体への寄付に相当しますので、それをポイントにするというのはいったいどういうことかと思うのです。ポイントを受け取った政治団体はそれを現金化するには誰に請求するのかと。
#022 予定日付(西暦)は原則として未来の日付で、期間のような範囲を示すものは開始日付と終了日付が両方とも予定日付と解釈します。 データ日付(西暦)はGDP統計や失業率のデータなど数値データに紐付くもの。 記録日付(元号)は現在から過去の日付で、データに紐付かないもの。 専門的なことはわかりませんが、この場合はデータ日付になると思います。 全部を和暦にしろと言っているわけではありません。
#023 私の言うユーザーというのは個人の事です。 法人や事業体の事ではありません。 文書登録なら登録担当者の個人番号がユーザーIDになるでしょう。 個人番号は全国民で唯一とします。 横浜市がユーザーという解釈が出てくるとは想像しませんでした。 私には屁理屈に聞こえますね。 記録日付/データ日付/予定日付は最初に業務設計の段階で決めてしまうので、いちいち考える必要はありません。 予定日付は原則として未来の日付で、期間のような範囲を示すものは開始日付と終了日付が両方とも予定日付と解釈します。 データ日付はGDP統計や失業率のデータなど数値データに紐付くもの。 記録日付は現在から過去の日付で、データに紐付かないもの。 法律の公布日の場合は、予定の段階では予定日付と解釈して西暦で公表し、実際に公布されたら記録日付として元号で記録します。 記録日付/データ日付/予定日付の属性が混在する場合は、予定日付やデータ日付を優先して西暦で記載します。
#003 ニコラ・テスラが勝ったんでしたっけ。 そのような構想も、今の日本には実際に試験してみる場所も機会もないのですね。なのである程度の地域が特区として指定され、そこで小規模でも完結した都市構想実験ができれば有意義だと思います。前にあったケーブルドローンも実際にやってみることもできるし。
#021 なので対馬基さんの主張されることには、私は肯定的です。私は技術にはあまりこだわりませんので、必要があればどんなことでも実現方法は出てくると思うので、比較的無関心です。ただそれもまた偏りすぎているので、それぞれのコメントを自分なりに受け止めながら、自分自身のアイデアを改善・向上させていかれることを期待します。 皆さんのお話しが続いているようなので、私はこれにて。
＞小児用モバイルSuica/PASMOがほしい →上記を利用するシーンを教えてください。 ・親が一緒なら親が支払えばいいと思う。親の口座から安易にキャッシュレス決済を行うことには反対。 ・定期券購入のシーンで本人確認や学割の有無を確認する手段にマイナンバーカードを利用するなら賛成です。 ・小児料金廃止は世論の支持を得られると思えません。
ほげさんは（たぶん）技術畑の方なので、アイデアを見るとまずその技術的問題点に関心が向かわれるのだと思います。そのご指摘は（ほぼ）間違いなく正確なので、できるだけ理解して貴重なアドバイスを自分のアイデアに加えてアップデートするのが良いかと。技術者としての正義感でしょうか。 ただ少し突き放すような表現をされます。例えば #017 の最後の部分も「秒単位での時刻情報が文書IDに対して十分な唯一性を持つとは言えないでしょう。時刻を共有する中で1秒以内に2つ以上の文書が発行された場合はどう対処しますか ? もっと推敲が必要な案だと思います」とでも書けば、言われた方も素直に聞けるんですが。まあ、それも個性だと思うしかないですね。 bさんも似たところはありますが #019 「おまえ・も」と言われているので自覚はあったんですね。 「問題を報告」はまずあてになりません。むしろ担当者自身があえて荒らしているのではないかという陰謀論もあるくらいです。都市伝説ですけどね。（これは本気に取らないでください） 私はアイデアが出された問題意識、動機、視点、手段などに関心があってそこを理解しようとしています。
#021 ＞ 1秒間に2つ以上の文書が発行される確率はとても低いです。万が一そのような事があった場合は、登録処理で1秒間以上待たせれば良いと思います。 例えば横浜市という文書を発行する単独事業体を一つのユーザとした時、そこに住む住人全体個別に文書を発行する場合、人口が 372万人なので秒に一つしか文書IDを発行できないという間抜けな仕様のために発行するだけで 40日以上の時間がかかるという事ですね。 もう少し考えましょうね。 もう少し考えましょうという意味ではこの提案自体、例えば記録日付と呼ばれるものと予定日付と呼ばれるものが一つの文書中に混ざる場合とか考えてないですよね。 そもそも、ある日付が記録日付/データ日付/予定日付のどれにあたるかをいちいち考えて記述しなければならないという方がより混乱するでしょうね。 ＞ 法律の公布日 法律に記載される公布日や施行日は法案や成立時点では予定日付ですよね。法律は成立時点で固定されるので日付文字列だけ書き換えるにしてもまた改正として国会通す事になるんじゃないですかね。でまたその改正の公布日なり施行日なりを修正する改正を出すとかかな。
アイデアに「ビッグデータ（Ｂ２Ｃ取引）」が関係するので大雑把に読んでの「五百字内感想」 （説明文）Ｂ２Ｃの「取引情報」を逐次！管理者のＤＢに格納する。 「取引情報（日時・販売者Ｂ・購買者Ｃ・価格Ｑ・係数（Ｒ・Ｄ・Ｓ・Ｓａ・Ｐａ））」 「日時（西暦・月・日・曜日・時・分・秒）」 情報（データ）はＰＣが集計するので「和暦」は使用しない！ 尚、２４時以降営業の鉄道は「翌日（０時以降）」の「時刻：０１：２２：５５」を記録するが「集計日：２４日」である！ 集計単位は日間・旬間・週間・月間・年間など複数だが、自販機の零時以降は即！翌日集計とする！ 以上、ビッグデータに関する日付の事例！ 次の漢字を「音読み（音）」と「訓読み（訓）」で書け！ 「草（音：そう）（訓：くさ）」 次の「ひらがな」を漢字で書け！ 「はし（橋・端・箸）」など複数だが、教えた「橋」を正解とした！ 今の出題「山田君は大野川の大野はし（ ）を渡って通学する。」 以上、安易な教育（先生）が「罷り通った」昔話 有り得た日付の事例 １９８９年（昭和６４年）１月６日 １９８９年（平成元年）１月７日 １９９０年（昭和６５年）５月１日
悲報です。 さっきテレビ見たら「政府は今年のオリンピックを中止することを内部で決定」とか言ってましたよ。せっかく開催するための方法を信長さんはじめ皆さんで考えようとしていたところなのに。がっかりです。 で、連想したのは大本営発表。戦争に負けていて打つ手がないのに、自分の責任追及を恐れて国民を騙し続け、神風、大和、沖縄、広島、長崎を犠牲にした大本営。 事実かどうかはわかりませんが、やるならやる、やらないならやらないとはっきり言ってもらわないと、私たちは竹槍を持たされる羽目になるのでは? 森大本営会長はどう考えているのだろう。 やる気があるなら、ここで述べられているくらいの具体案・実現方法を森さんが自ら公表して欲しいですね。やる気があるなら。
面白いテーマですね。 1ヶ月停電したデジタル化社会の想像ですが、全国か一部地域かでも異なります。ディザスターリカバリー(DR、災害復旧)のために離れたところにインフラ基盤を正副持つことや自家発電、通信衛星や成層圏ドローンでネットワークをバックアップする。海外に拠点を持つ。このようなことはＢＣＰ(事業継続計画)としてデジタル庁で考えられていると思います。 東日本大震災の教訓は、想定外をゼロにできないまでも想定によりそこで思考を停止することがないように心がけをことでしょう。 ＢＣＰには相応のコストが発生します、リスクの軽減と起きたリスクへのコンテンジェーシープラン(事前対応計画)を織り混ぜることも必要ですね。
#007 こんにちは、再度のコメントをありがとうございました。 N_azoooさんのコメントも参考にしてただけますと助かります。 （5年後に増税するようなら、政府が間違っています。 平行線なので、これ以上のコメントは控えさせていただきます。
#006 つづき マイナンバーカードの数字のパスワードの多くは誕生日だと類推しています。16桁以下の英数字は氏名 (一部)と誕生日が多いのでないでしょうか？このような統計が公表されないでしょうが本人の記憶力で 忘れない、類推や外部記憶に頼らないこと(自己責任)を前提にしています。 いいことだけを並べましたが複数認証を組合せることは認証スピードを犠牲にしては利便性が損なわれます。ハッキングの脅威に常に曝されます。本人拒否と他人受入の両曲線のハザマで精度の調整が必要です。
同様の考え方を持っていて賛成ですが以下の課題をクリアできるとお考えですか？ １.生体情報はカードやパスワードと違い取り替えができないことへの対策は？ ２.識別(あまたある生体情報から本人を選び出す方法)を瞬時に行うことと識別するできるか？(１億２千万分の１) ３.セキュアでないネットワーク上で暗号化通信するにしても盗聴されないか？ ４.通信先の利用される機器＆データがハッキングに利用されいないことを証明できるか？ 上記に対する解は披露しませんが私なりに持っています。 公的認証をトラストアンカー(信用の起点)にして世の中にあるあまたのIDとシームレス＆セキュアに連携 できれば社会全体のコストが削減できます。生体認証がベースとなれればパスワードをメモしないと忘れ るというリスクを解消できます。
マイナンバーカードにスイカ同様のチャージ機能と各利用施設などで登録管理出来れば良いと思いますけど。子供のマイナンバーカード大人が使ったら？、顔認証で、年齢情報はカードに記録されてるでしょうし。
#003 カード不要を前提のようですので、認証装置障害時どうするか？、DNAでさえ、白血病治療で体細胞情報と血液細胞情報が一致しない時代ですので、100%は望めません。100%が望めないなら、変更可能な方法で良いのでは？。
#020 「既に説明していますが UTC は型ではありませんよ。」 これは承知しました。 「ユーザーという単位であったとしても、1秒間に2つ以上の文書が発行されることが無い事をどう保証するのでしょうね。」 ユーザーの画面からの入力である限り、1秒間に2つ以上の文書が発行される確率はとても低いです。万が一そのような事があった場合は、登録処理で1秒間以上待たせれば良いと思います。 「#010 に比べればだいぶマシだと思いますがw ?」 #010 については売り言葉に買い言葉だったので乱暴な表現になってしまいました。 対処が悪かったと思います。 今後は暴言が浴びせられたら、暴言で返すのではなく、通報する事で対処します。 今後は#010 のような対応はしません。 繰り返しになりますが、私の主張は「コンピータの中では人間の使う年号とは異なる日付型数値を使用しており、ユーザーがコンピータの中の日付型を意識する必要はない。だからコンピータの中の日付型を意識して年号に西暦を使うか元号を使うか考える必要はない」という物です。 日付の規格の詳細とは関係ありません。
#018 ＞ 日付型にUTC以外の日付型が存在している 既に説明していますが UTC は型ではありませんよ。いいかげん理解しましょうね。 ＞ そもそもUTCであるかどうかは些末な問題で本旨から外れた話です。 実は全然わかっていない事が露呈したのを誤魔化すのはやめましょうね。無知な人に自分がわかっているかのように誤認させるかのような支離滅裂な文字列を垂れ流したりしたのが悪ですね。 ＞ あと文書IDの件は「日時+ユーザーID」で唯一性を持つと言っています。 ユーザーという単位であったとしても、1秒間に2つ以上の文書が発行されることが無い事をどう保証するのでしょうね。 ＞ それに不必要な暴言が多すぎるので言葉遣いを訂正してください。 #010 に比べればだいぶマシだと思いますがw ?
おまえもだいぶ口が悪いと思うけど
#002 マイナンバーカードの一般的に公開されている機能は理解したつもりです。完全とは言えないかもしれません。 物理的なカードを持つメリットがあまり感じられず、5Gなどのネットワーク環境の拡充により常にネットワークへの接続できる環境を整備すれば良いのでは無いかと考えた次第 それでも不足があるかもしれませんが可能で有ればご教授いただけると幸いです。
民間のITの人間だって、ITのことしかやらないわけではない 例えば国際貿易のシステムをやってるやつとか 貿易の業務知識がなければ話にならないので そっちを勉強するほうが多くて、ついでに通関士の資格をとったとか よくある話 土木をやった経験はいつか役に立つのではないか 関係ないけど、RubyのMatzなんて、日本全国のPython使いよりPythonに詳しいし
#017 私の主張は「コンピータの中では人間の使う年号とは異なる日付型数値を使用しており、ユーザーがコンピータの中の日付型を意識する必要はない。だからコンピータの中の日付型を意識して年号に西暦を使うか元号を使うか考える必要はない」 と主張しています。 コンピータの中の日付型にUTC以外の日付型が存在している事も承知しています。 西暦を使用する物もあります。 そもそもUTCであるかどうかは些末な問題で本旨から外れた話です。 端的に言って下らない揚げ足取りでしかありません。 あと文書IDの件は「日時+ユーザーID」で唯一性を持つと言っています。 誤読しているので良く読んでください。 それに不必要な暴言が多すぎるので言葉遣いを訂正してください。
#001 顔認証ではいけませんか？
うちの親は造園業だけれども 一緒にそのへんを歩いていても、 公園や街並みにある木を一本一本みては いちいち「これを放置したら後戻りできなくなる」などと言ってる つまり、早く枝を剪定してやらねば、木を枯らすしかなくなる ということ 要するに、公共工事の予算削減の影響で、 それらの保全をする数量が減り、 身近な生活環境の樹木の維持に悪影響がでていると、 普段からの口癖のようになってる 予算削減したままでも、うまく生産性上げればよいのかもしれないが 現状はそういう街中の自然の保全に影響が出ている状態だ おそらく、一昨年の房総の台風で被害をうけた送電インフラ周辺の樹木も そういうことで維持のための活動が以前よりも低下していると思われる 少し話がそれるが 人類の歴史から治水と洪水は積年の課題だったのだけれど 20世紀の多くの治水工事で災害減少していたのに胡坐をかいて 治水の努力を怠っていたのが 近年の洪水等の水害の増加の理由だろう
#014 ＞ 「でたらめすぎる。」と思うのなら根拠を示してください。 UTC と UNIX Timestamp や時刻と暦をごっちゃにしていて支離滅裂過ぎてどこから突っ込んで良いのかわからないレベル。 UTC は時差に影響しない基準時刻。コンピュータ独自ではないし、まして年号ではない。 https://ja.wikipedia.org/wiki/協定世界時 個別の時刻データを UTC で扱うかローカル時間で扱うかは個別の実装依存。昨今の多くのシステムで標準的に利用可能な UNIX Timestamp と呼ばれる実装は UTC に統一されているけれど、1970-01-01 00:00:00Z からのエポック秒なのでそれより過去は扱えないと言った問題がありあらゆるシステムで利用されているわけではない。 秒単位での時刻情報が文書IDに対して十分な唯一性を持つとかもはや何言ってるんだ状態。時刻を共有する中で1秒以内に2つ以上の文書が発行される事は無いと言っているのかなw ? 論とか以前の問題。少しは自分で調べろよという感じ
#015 「問題を報告」しました。
そもそも論ずる価値のない便所の落書き
エジソンの直流電源都市構想を主体として、交流電気は安定供給常用定量を目指して、位置エネルギー変換や蓄電設備で負荷調整出来るように、デジタル管理する。
#010 コメントありがとうございます。 個人情報とひも付けされていない点がミソです。 このてのことは国と国民両方がウィンウィンでないと広く素早く普及はしないでしょう。 マイナンバー利用の普及が妨げられている点の一つは個人情報やプライバシーを権力側にもたれる事への抵抗、つまり国や自治体へのこれまでに対する不信感にあります。でなければ2015年の運用開始から5年6年たった今もこれだけの普及率という事はないわけです。これを短期間にひっくり返すことは無理です。強行すれば昨年の混乱に類することが予想され、とにかく迅速に行うことが求められるワクチン接種では回避されるべきです。 そこでCOVID-19対策アプリとして発展させるという提案に至った次第です。個人情報とは紐付けられていない、使ったほうがQRコード読みとりなどで接種時のスムースさが格段に速いなどのインセンティブがあれば多数のひとの利用に結びつくと考えています。
#012 引用部分の除けば、「でたらめすぎる。」の一行だけ。 これで意見を言っているつもりなのだから、呆れます。 「でたらめすぎる。」と思うのなら根拠を示してください。 貴方の書き込みは意見どころか「論」になっていません。 「論」になっていなければ「議論」になりません。 このままならただの誹謗中傷です。 「問題を報告」した方が良いですか ?
私も迷惑メールが山ほどきます。情報発信のルールを定め罰則も設けゴミ情報の発信を規制してほしいと思います。
#011 初めて肯定的意見が来て少し安堵しました。 また初めて10行以上の「論」に纏まった意見が来て良かったと思います。 ある程度の長文で「論」が形成されていないと議論になりませんから。 予定日付(西暦)・データ日付(西暦)・記録日付(元号)の分類に当てはまらない日付が存在したなら、新しい分類を作り、それを西暦にするか元号にするか決めれば良いと思います。 同じ考え方で対処できるはずです。 要するに「使いやすい年号を使いましょう、元号は出来る範囲で残しましょう」という意見です。 最近は「論」にすらなっていない誹謗中傷ばかりで辟易しております。 せめて10行ぐらいの論にまとめて反論してもらいたいですね。 1行で「論」なんて語れませんよ。 意見の内容以前に国語力に問題がある人が多すぎます。
#001 コメントありがとうございます。 自助の面は、それなりにと考えておりますが、公助の面で色々なデータを活用して取り組んでいただきたいと思っています。データの科学的分析力に日本は欠けているのかも?日本語の曖昧さ故なのか?このアイデアボックスで、データ収集と統計的分析で、科学的解析をして公助に貢献できるシステムとなればと思います。
地位向上としてるのは身分そのものを一般事務職員とは違う特別な位置に置いてほしいということです。 昇進というよりも情報処理の技術職職員として、技術者としてのキャリアパスを歩んで専門性を高めていきたいってところが正しいと思う。ITで入ったのに土木とかさ…IT全く関係無い所で足踏みしたくないでしょう。
未経験や異業種からIT業界に入ろうという人に そんなに最初から多くのことは求めんよ プログラム勉強して、ポートフォリオにあるぐらいのものは作れるようになりました、とか CCNAとりました、LPICとりました、AWSアソシエイトとりました、とか そんなので良いだろうと思う
たとえば、セキュリティキャンプというのがあって サイバーセキュリティ分野について子供や学生に 高度人材育成のためにサイバーセキュリティの見分を深めてもらう取り組みはある https://ja.wikipedia.or...83%A3%E3%83%B3%E3%83%97 https://www.security-camp.or.jp/ 問題は、こういう取り組みは色んな分野に存在しているが 親や学校などが知らないので、子どもたちに届きにくいこと
プログラミングは昨今よく話題になっていますが、IT業務の一部分にしか過ぎません。 動作を支えるITインフラや#004 でも記載されていましたがデータ利活用などトータルな知見が必要だと思います。
マイナンバーカードの機能をちゃんと知らないとこういうことを書くことになりがちだけれど 世の中のマイナンバーカードの使い方などを見れば実質こういう認識でもあまり外れてるとはいえないだろう etaxとかでしか実際使ってないし コンビニで住民票発行とか知ってても、なんとなく区役所とかに行く人も多いだろうし
BCP(事業持続計画)、ディザスターリカバリー(DR、災害復旧)は 十数年前からのテーマで、 東日本大震災の際にも大きな課題として社会に広く認識されたが やはり時間の経過とともに取り組みが形骸化しがちなものである 全く手を付けないか、過度に重く取り組むか、の二択ではなく リスク評価を適切に行い、自らの状況に応じた対策をすることが重要だ
労基法適用対象外だからです。 他にも残業とかでもいろんなのあります。 たしか、緊急の時除くみないなのとか書かれてるのとかあったと思います。 緊急の時とか、やむ終えいない時等と記載されてるのって本来災害とかあった場合を想定しているんでしょうが結局組織がどうとでもできてしまう所がありまして、システムで厳密にチェックしてかないとブラック化するのですよ。
技術を磨き続けるのにはコストがかかりますので事務職より若干高い給与とするのが妥当だと思う。 また独占資格の必要が無いことと更に事務職ということでIT全然関係無いところに異動させられてる人多いと思います。土木行かされたり建築行かされたり。技術で雇われたなら戻れる可能性は高いでしょうが本人も不安な上、人事は上に嫌われたらそれまででしょう。しかしそもそも資格持ったその人しかできない仕事となれば話は全く別で少なくとも関係無い部署に異動することは変えが効かないならまず無いでしょう。 資格に手当を出す等という話もここに来てようやく出てくると思います。 現状IT技術者がパソコンに詳しい便利屋位な立ち位置であることに納得できないのです。
経験上ハラスメントする人というのは、そもそもハラスメントをしているという自覚が無い場合も多い。指導だと思ってやった、相手が自分に好意があると思ってやった等言うのがそれだ。 ＡＩがハラスメントと判断したら「パワハラを検知しました。至急やめて下さい。」等と警報が鳴るようにすれば、怒り狂った者も我にかえり、それ以上怒るのをやめるだろう。
最新コメント (総合)
公務員の居住地制限についていかがなものか
合理性があれば、居住地制限も含めての仕事だと思います。
対応できない人は残念ながらその仕事には向かないということです。
世界が納得するオリンピックを安全に実施する方法
#010
このスレッドや前のやつを関係者のフェイスブックとかに投稿してみれば?
俺たちは応援してるんだぜーって。
オリンピック関係はまだ他にもあったような。
やる気があるならいいかげん具体的な方法を当局が公式に提示すべき時期でしょう。
ずるずる時間だけがすぎて、時間切れで「やめました」と言われてもねぇ・・・
みんな外出自粛して家にいるんだから、オリンピックの実現方法について考える時間はあるでしょうに。
#009
こんにちは ご連絡をありがとうございました。
まだ、100％中止と決まったわけではないでしょう？（イギリスから出た話でしょう？）
私の案を踏襲すれば、無観客ながら、黒字で そして安全遂行できるのですが・・・
ここの事務局も全く無関心なので、話が大臣クラスに伝わらず、残念です。
年号の表記規則の標準化を提案します
#028
文書IDの件はユニークな番号を付けるための例えなので、この話の本旨ではないです。
文書にユニークな番号を付ける方法なんていくらでもあります。
法律の施行日に関する法律は知りませんが、そこまで法律の施行日予定の変更が難しいなら、現在の元号のままで良いでしょう。
この話は同一の日付について、予定日と実施後の記録日をどのように区別するかという、説明をしています。
法律上変更できないものは変更しなければ良いだけです。
元号表記は、歴史的公文書と判定されるときのみ、併記できるソフトを使って処理すれば良いのではと提案したことがあります。皇室での管理でのけいいを大切に?と思います。
法文について、4桁数字より元号プラス2桁数字の方が取り違えが少なくなる?の提案もしています。
フードスタンプなどの個人支給に対応したマイナンバーに紐づく目的別電子マネーの提案
#011
ご指摘ありがとうございます。
私も現在のポイントは原資の付加的なものだということは理解していますが、ここでの意味は現金支給に代えてポイント（という呼び名の電子マネー）を給付するという意味だと思いました。
それなら政治資金もできるんじゃないかと。なので「ポイント」という名称ではなく、電子化とすべきだったかも知れません。
生活保護支給を電子マネーにして管理するのなら、政治資金関係もできるのではないかという短絡的な発想です。
考えてみれば政治家も日本国民が養っているという意味では、生活保護なのかも知れませんね。
年号の表記規則の標準化を提案します
#026
＞ 文書登録なら登録担当者の個人番号がユーザーIDになるでしょう。
作業者の業務中の社員や公務中の公務員を個人として文書に紐づけるとかちょっと頭おかしい。文書発行というものそのものを理解していないとしか思えませんね。まあそもそも、時間に依存せずに発行主体が文書発行毎にシリアルを生成すれば良いだけの話なので、時間でIDという発想から壊れているのですけど。システムで自動生成する場合とか考えてなさげだし。
＞ 法律の公布日の場合は、予定の段階では予定日付と解釈して西暦で公表し、実際に公布されたら記録日付として元号で記録します。
法律の施行日なんかは法律の文書自体に記述されそれを含めて成立するもので、成立後に改正手続きを踏まえずに改修する事は許されませんよ。文書として情報が固定されるという認識そのものが欠落してるのかな。
法律の文書自体とは別にその文書に付随する情報管理上のメタデータとして付加されるものであればその限りでは無いけど、それこそ文書を管理する情報システムの話なので記年法が何であるかは全く関係無い話ですね。せいぜい UI や入出力をどうするか程度の話。UI の話であれば設定でどうにでもすれば良いだけの話かな。
公務員の居住地制限についていかがなものか
#005 その通りと思います。
公務員だからとか、会社員だからというのではなく、その職業により提供するサービスが、対象に対して直接接点が必要かどうかという話でしょう。
散髪屋がリモートでサービスを提供できるでしょうか。
消防署がリモートでサービスを提供できるでしょうか。
そういう話でしょう。
フードスタンプなどの個人支給に対応したマイナンバーに紐づく目的別電子マネーの提案
#010 ポイントというのはその原資があって、最終的にはそのポイントと原資を交換する形になりますよね。ポイントは通貨ではないので、それだけではなんの役にも立たないのですから。
サービス提供会社から提供されるポイントであれば、サービス提供価格から割り引かれる形で利用者に還元されますし、この提案の「食料ポイント」であれば、手形と同じく消費者から小売店が受け取ったポイントは、その現金化を政府に請求すればそれに相当する現金が支給される仕組みがあるものと思います。
対して、政治資金というのは民間から政治団体への寄付に相当しますので、それをポイントにするというのはいったいどういうことかと思うのです。ポイントを受け取った政治団体はそれを現金化するには誰に請求するのかと。
年号の表記規則の標準化を提案します
#022
予定日付(西暦)は原則として未来の日付で、期間のような範囲を示すものは開始日付と終了日付が両方とも予定日付と解釈します。
データ日付(西暦)はGDP統計や失業率のデータなど数値データに紐付くもの。
記録日付(元号)は現在から過去の日付で、データに紐付かないもの。
専門的なことはわかりませんが、この場合はデータ日付になると思います。
全部を和暦にしろと言っているわけではありません。
#023
私の言うユーザーというのは個人の事です。
法人や事業体の事ではありません。
文書登録なら登録担当者の個人番号がユーザーIDになるでしょう。
個人番号は全国民で唯一とします。
横浜市がユーザーという解釈が出てくるとは想像しませんでした。
私には屁理屈に聞こえますね。
記録日付/データ日付/予定日付は最初に業務設計の段階で決めてしまうので、いちいち考える必要はありません。
予定日付は原則として未来の日付で、期間のような範囲を示すものは開始日付と終了日付が両方とも予定日付と解釈します。
データ日付はGDP統計や失業率のデータなど数値データに紐付くもの。
記録日付は現在から過去の日付で、データに紐付かないもの。
法律の公布日の場合は、予定の段階では予定日付と解釈して西暦で公表し、実際に公布されたら記録日付として元号で記録します。
記録日付/データ日付/予定日付の属性が混在する場合は、予定日付やデータ日付を優先して西暦で記載します。
ハイパーテクノロジー特区の設立
#003
ニコラ・テスラが勝ったんでしたっけ。
そのような構想も、今の日本には実際に試験してみる場所も機会もないのですね。なのである程度の地域が特区として指定され、そこで小規模でも完結した都市構想実験ができれば有意義だと思います。前にあったケーブルドローンも実際にやってみることもできるし。
年号の表記規則の標準化を提案します
#021
なので対馬基さんの主張されることには、私は肯定的です。私は技術にはあまりこだわりませんので、必要があればどんなことでも実現方法は出てくると思うので、比較的無関心です。ただそれもまた偏りすぎているので、それぞれのコメントを自分なりに受け止めながら、自分自身のアイデアを改善・向上させていかれることを期待します。
皆さんのお話しが続いているようなので、私はこれにて。
小児用モバイルSuica/PASMOがほしい
＞小児用モバイルSuica/PASMOがほしい
→上記を利用するシーンを教えてください。
・親が一緒なら親が支払えばいいと思う。親の口座から安易にキャッシュレス決済を行うことには反対。
・定期券購入のシーンで本人確認や学割の有無を確認する手段にマイナンバーカードを利用するなら賛成です。
・小児料金廃止は世論の支持を得られると思えません。
年号の表記規則の標準化を提案します
ほげさんは（たぶん）技術畑の方なので、アイデアを見るとまずその技術的問題点に関心が向かわれるのだと思います。そのご指摘は（ほぼ）間違いなく正確なので、できるだけ理解して貴重なアドバイスを自分のアイデアに加えてアップデートするのが良いかと。技術者としての正義感でしょうか。
ただ少し突き放すような表現をされます。例えば #017 の最後の部分も「秒単位での時刻情報が文書IDに対して十分な唯一性を持つとは言えないでしょう。時刻を共有する中で1秒以内に2つ以上の文書が発行された場合はどう対処しますか ? もっと推敲が必要な案だと思います」とでも書けば、言われた方も素直に聞けるんですが。まあ、それも個性だと思うしかないですね。
bさんも似たところはありますが #019 「おまえ・も」と言われているので自覚はあったんですね。
「問題を報告」はまずあてになりません。むしろ担当者自身があえて荒らしているのではないかという陰謀論もあるくらいです。都市伝説ですけどね。（これは本気に取らないでください）
私はアイデアが出された問題意識、動機、視点、手段などに関心があってそこを理解しようとしています。
#021 ＞ 1秒間に2つ以上の文書が発行される確率はとても低いです。万が一そのような事があった場合は、登録処理で1秒間以上待たせれば良いと思います。
例えば横浜市という文書を発行する単独事業体を一つのユーザとした時、そこに住む住人全体個別に文書を発行する場合、人口が 372万人なので秒に一つしか文書IDを発行できないという間抜けな仕様のために発行するだけで 40日以上の時間がかかるという事ですね。
もう少し考えましょうね。
もう少し考えましょうという意味ではこの提案自体、例えば記録日付と呼ばれるものと予定日付と呼ばれるものが一つの文書中に混ざる場合とか考えてないですよね。
そもそも、ある日付が記録日付/データ日付/予定日付のどれにあたるかをいちいち考えて記述しなければならないという方がより混乱するでしょうね。
＞ 法律の公布日
法律に記載される公布日や施行日は法案や成立時点では予定日付ですよね。法律は成立時点で固定されるので日付文字列だけ書き換えるにしてもまた改正として国会通す事になるんじゃないですかね。でまたその改正の公布日なり施行日なりを修正する改正を出すとかかな。
アイデアに「ビッグデータ（Ｂ２Ｃ取引）」が関係するので大雑把に読んでの「五百字内感想」
（説明文）Ｂ２Ｃの「取引情報」を逐次！管理者のＤＢに格納する。
「取引情報（日時・販売者Ｂ・購買者Ｃ・価格Ｑ・係数（Ｒ・Ｄ・Ｓ・Ｓａ・Ｐａ））」
「日時（西暦・月・日・曜日・時・分・秒）」
情報（データ）はＰＣが集計するので「和暦」は使用しない！
尚、２４時以降営業の鉄道は「翌日（０時以降）」の「時刻：０１：２２：５５」を記録するが「集計日：２４日」である！
集計単位は日間・旬間・週間・月間・年間など複数だが、自販機の零時以降は即！翌日集計とする！
以上、ビッグデータに関する日付の事例！
次の漢字を「音読み（音）」と「訓読み（訓）」で書け！
「草（音：そう）（訓：くさ）」
次の「ひらがな」を漢字で書け！
「はし（橋・端・箸）」など複数だが、教えた「橋」を正解とした！
今の出題「山田君は大野川の大野はし（ ）を渡って通学する。」
以上、安易な教育（先生）が「罷り通った」昔話
有り得た日付の事例
１９８９年（昭和６４年）１月６日
１９８９年（平成元年）１月７日
１９９０年（昭和６５年）５月１日
世界が納得するオリンピックを安全に実施する方法
悲報です。
さっきテレビ見たら「政府は今年のオリンピックを中止することを内部で決定」とか言ってましたよ。せっかく開催するための方法を信長さんはじめ皆さんで考えようとしていたところなのに。がっかりです。
で、連想したのは大本営発表。戦争に負けていて打つ手がないのに、自分の責任追及を恐れて国民を騙し続け、神風、大和、沖縄、広島、長崎を犠牲にした大本営。
事実かどうかはわかりませんが、やるならやる、やらないならやらないとはっきり言ってもらわないと、私たちは竹槍を持たされる羽目になるのでは?
森大本営会長はどう考えているのだろう。
やる気があるなら、ここで述べられているくらいの具体案・実現方法を森さんが自ら公表して欲しいですね。やる気があるなら。
1ヶ月停電したデジタル化社会の想像を
面白いテーマですね。
1ヶ月停電したデジタル化社会の想像ですが、全国か一部地域かでも異なります。ディザスターリカバリー(DR、災害復旧)のために離れたところにインフラ基盤を正副持つことや自家発電、通信衛星や成層圏ドローンでネットワークをバックアップする。海外に拠点を持つ。このようなことはＢＣＰ(事業継続計画)としてデジタル庁で考えられていると思います。
東日本大震災の教訓は、想定外をゼロにできないまでも想定によりそこで思考を停止することがないように心がけをことでしょう。
ＢＣＰには相応のコストが発生します、リスクの軽減と起きたリスクへのコンテンジェーシープラン(事前対応計画)を織り混ぜることも必要ですね。
世界が納得するオリンピックを安全に実施する方法
#007
こんにちは、再度のコメントをありがとうございました。
N_azoooさんのコメントも参考にしてただけますと助かります。
（5年後に増税するようなら、政府が間違っています。
平行線なので、これ以上のコメントは控えさせていただきます。
カードレス本人認証
#006 つづき
マイナンバーカードの数字のパスワードの多くは誕生日だと類推しています。16桁以下の英数字は氏名
(一部)と誕生日が多いのでないでしょうか？このような統計が公表されないでしょうが本人の記憶力で
忘れない、類推や外部記憶に頼らないこと(自己責任)を前提にしています。
いいことだけを並べましたが複数認証を組合せることは認証スピードを犠牲にしては利便性が損なわれます。ハッキングの脅威に常に曝されます。本人拒否と他人受入の両曲線のハザマで精度の調整が必要です。
同様の考え方を持っていて賛成ですが以下の課題をクリアできるとお考えですか？
１.生体情報はカードやパスワードと違い取り替えができないことへの対策は？
２.識別(あまたある生体情報から本人を選び出す方法)を瞬時に行うことと識別するできるか？(１億２千万分の１)
３.セキュアでないネットワーク上で暗号化通信するにしても盗聴されないか？
４.通信先の利用される機器＆データがハッキングに利用されいないことを証明できるか？
上記に対する解は披露しませんが私なりに持っています。
公的認証をトラストアンカー(信用の起点)にして世の中にあるあまたのIDとシームレス＆セキュアに連携
できれば社会全体のコストが削減できます。生体認証がベースとなれればパスワードをメモしないと忘れ
るというリスクを解消できます。
小児用モバイルSuica/PASMOがほしい
マイナンバーカードにスイカ同様のチャージ機能と各利用施設などで登録管理出来れば良いと思いますけど。子供のマイナンバーカード大人が使ったら？、顔認証で、年齢情報はカードに記録されてるでしょうし。
カードレス本人認証
#003 カード不要を前提のようですので、認証装置障害時どうするか？、DNAでさえ、白血病治療で体細胞情報と血液細胞情報が一致しない時代ですので、100%は望めません。100%が望めないなら、変更可能な方法で良いのでは？。
年号の表記規則の標準化を提案します
#020
「既に説明していますが UTC は型ではありませんよ。」
これは承知しました。
「ユーザーという単位であったとしても、1秒間に2つ以上の文書が発行されることが無い事をどう保証するのでしょうね。」
ユーザーの画面からの入力である限り、1秒間に2つ以上の文書が発行される確率はとても低いです。万が一そのような事があった場合は、登録処理で1秒間以上待たせれば良いと思います。
「#010 に比べればだいぶマシだと思いますがw ?」
#010 については売り言葉に買い言葉だったので乱暴な表現になってしまいました。
対処が悪かったと思います。
今後は暴言が浴びせられたら、暴言で返すのではなく、通報する事で対処します。
今後は#010 のような対応はしません。
繰り返しになりますが、私の主張は「コンピータの中では人間の使う年号とは異なる日付型数値を使用しており、ユーザーがコンピータの中の日付型を意識する必要はない。だからコンピータの中の日付型を意識して年号に西暦を使うか元号を使うか考える必要はない」という物です。
日付の規格の詳細とは関係ありません。
#018 ＞ 日付型にUTC以外の日付型が存在している
既に説明していますが UTC は型ではありませんよ。いいかげん理解しましょうね。
＞ そもそもUTCであるかどうかは些末な問題で本旨から外れた話です。
実は全然わかっていない事が露呈したのを誤魔化すのはやめましょうね。無知な人に自分がわかっているかのように誤認させるかのような支離滅裂な文字列を垂れ流したりしたのが悪ですね。
＞ あと文書IDの件は「日時+ユーザーID」で唯一性を持つと言っています。
ユーザーという単位であったとしても、1秒間に2つ以上の文書が発行されることが無い事をどう保証するのでしょうね。
＞ それに不必要な暴言が多すぎるので言葉遣いを訂正してください。
#010 に比べればだいぶマシだと思いますがw ?
おまえもだいぶ口が悪いと思うけど
カードレス本人認証
#002
マイナンバーカードの一般的に公開されている機能は理解したつもりです。完全とは言えないかもしれません。
物理的なカードを持つメリットがあまり感じられず、5Gなどのネットワーク環境の拡充により常にネットワークへの接続できる環境を整備すれば良いのでは無いかと考えた次第
それでも不足があるかもしれませんが可能で有ればご教授いただけると幸いです。
公務員の中でのIT技術者の地位向上案
民間のITの人間だって、ITのことしかやらないわけではない
例えば国際貿易のシステムをやってるやつとか
貿易の業務知識がなければ話にならないので
そっちを勉強するほうが多くて、ついでに通関士の資格をとったとか
よくある話
土木をやった経験はいつか役に立つのではないか
関係ないけど、RubyのMatzなんて、日本全国のPython使いよりPythonに詳しいし
年号の表記規則の標準化を提案します
#017
私の主張は「コンピータの中では人間の使う年号とは異なる日付型数値を使用しており、ユーザーがコンピータの中の日付型を意識する必要はない。だからコンピータの中の日付型を意識して年号に西暦を使うか元号を使うか考える必要はない」
と主張しています。
コンピータの中の日付型にUTC以外の日付型が存在している事も承知しています。
西暦を使用する物もあります。
そもそもUTCであるかどうかは些末な問題で本旨から外れた話です。
端的に言って下らない揚げ足取りでしかありません。
あと文書IDの件は「日時+ユーザーID」で唯一性を持つと言っています。
誤読しているので良く読んでください。
それに不必要な暴言が多すぎるので言葉遣いを訂正してください。
カードレス本人認証
#001
顔認証ではいけませんか？
1ヶ月停電したデジタル化社会の想像を
うちの親は造園業だけれども
一緒にそのへんを歩いていても、
公園や街並みにある木を一本一本みては
いちいち「これを放置したら後戻りできなくなる」などと言ってる
つまり、早く枝を剪定してやらねば、木を枯らすしかなくなる
ということ
要するに、公共工事の予算削減の影響で、
それらの保全をする数量が減り、
身近な生活環境の樹木の維持に悪影響がでていると、
普段からの口癖のようになってる
予算削減したままでも、うまく生産性上げればよいのかもしれないが
現状はそういう街中の自然の保全に影響が出ている状態だ
おそらく、一昨年の房総の台風で被害をうけた送電インフラ周辺の樹木も
そういうことで維持のための活動が以前よりも低下していると思われる
少し話がそれるが
人類の歴史から治水と洪水は積年の課題だったのだけれど
20世紀の多くの治水工事で災害減少していたのに胡坐をかいて
治水の努力を怠っていたのが
近年の洪水等の水害の増加の理由だろう
年号の表記規則の標準化を提案します
#014 ＞ 「でたらめすぎる。」と思うのなら根拠を示してください。
UTC と UNIX Timestamp や時刻と暦をごっちゃにしていて支離滅裂過ぎてどこから突っ込んで良いのかわからないレベル。
UTC は時差に影響しない基準時刻。コンピュータ独自ではないし、まして年号ではない。
https://ja.wikipedia.org/wiki/協定世界時
個別の時刻データを UTC で扱うかローカル時間で扱うかは個別の実装依存。昨今の多くのシステムで標準的に利用可能な UNIX Timestamp と呼ばれる実装は UTC に統一されているけれど、1970-01-01 00:00:00Z からのエポック秒なのでそれより過去は扱えないと言った問題がありあらゆるシステムで利用されているわけではない。
秒単位での時刻情報が文書IDに対して十分な唯一性を持つとかもはや何言ってるんだ状態。時刻を共有する中で1秒以内に2つ以上の文書が発行される事は無いと言っているのかなw ?
論とか以前の問題。少しは自分で調べろよという感じ
#015 「問題を報告」しました。
そもそも論ずる価値のない便所の落書き
ハイパーテクノロジー特区の設立
エジソンの直流電源都市構想を主体として、交流電気は安定供給常用定量を目指して、位置エネルギー変換や蓄電設備で負荷調整出来るように、デジタル管理する。
COCOAの総合COVID-19対策アプリ化
#010 コメントありがとうございます。
個人情報とひも付けされていない点がミソです。
このてのことは国と国民両方がウィンウィンでないと広く素早く普及はしないでしょう。
マイナンバー利用の普及が妨げられている点の一つは個人情報やプライバシーを権力側にもたれる事への抵抗、つまり国や自治体へのこれまでに対する不信感にあります。でなければ2015年の運用開始から5年6年たった今もこれだけの普及率という事はないわけです。これを短期間にひっくり返すことは無理です。強行すれば昨年の混乱に類することが予想され、とにかく迅速に行うことが求められるワクチン接種では回避されるべきです。
そこでCOVID-19対策アプリとして発展させるという提案に至った次第です。個人情報とは紐付けられていない、使ったほうがQRコード読みとりなどで接種時のスムースさが格段に速いなどのインセンティブがあれば多数のひとの利用に結びつくと考えています。
年号の表記規則の標準化を提案します
#012 引用部分の除けば、「でたらめすぎる。」の一行だけ。
これで意見を言っているつもりなのだから、呆れます。
「でたらめすぎる。」と思うのなら根拠を示してください。
貴方の書き込みは意見どころか「論」になっていません。
「論」になっていなければ「議論」になりません。
このままならただの誹謗中傷です。
「問題を報告」した方が良いですか ?
迷惑メール受信料で、デジタル福祉基金を
私も迷惑メールが山ほどきます。情報発信のルールを定め罰則も設けゴミ情報の発信を規制してほしいと思います。
年号の表記規則の標準化を提案します
#011 初めて肯定的意見が来て少し安堵しました。
また初めて10行以上の「論」に纏まった意見が来て良かったと思います。
ある程度の長文で「論」が形成されていないと議論になりませんから。
予定日付(西暦)・データ日付(西暦)・記録日付(元号)の分類に当てはまらない日付が存在したなら、新しい分類を作り、それを西暦にするか元号にするか決めれば良いと思います。
同じ考え方で対処できるはずです。
要するに「使いやすい年号を使いましょう、元号は出来る範囲で残しましょう」という意見です。
最近は「論」にすらなっていない誹謗中傷ばかりで辟易しております。
せめて10行ぐらいの論にまとめて反論してもらいたいですね。
1行で「論」なんて語れませんよ。
意見の内容以前に国語力に問題がある人が多すぎます。
1ヶ月停電したデジタル化社会の想像を
#001 コメントありがとうございます。
自助の面は、それなりにと考えておりますが、公助の面で色々なデータを活用して取り組んでいただきたいと思っています。データの科学的分析力に日本は欠けているのかも?日本語の曖昧さ故なのか?このアイデアボックスで、データ収集と統計的分析で、科学的解析をして公助に貢献できるシステムとなればと思います。
公務員の中でのIT技術者の地位向上案
地位向上としてるのは身分そのものを一般事務職員とは違う特別な位置に置いてほしいということです。
昇進というよりも情報処理の技術職職員として、技術者としてのキャリアパスを歩んで専門性を高めていきたいってところが正しいと思う。ITで入ったのに土木とかさ…IT全く関係無い所で足踏みしたくないでしょう。
失業者対策案として社会人のプログラミング教育を充実させるべき
未経験や異業種からIT業界に入ろうという人に
そんなに最初から多くのことは求めんよ
プログラム勉強して、ポートフォリオにあるぐらいのものは作れるようになりました、とか
CCNAとりました、LPICとりました、AWSアソシエイトとりました、とか
そんなので良いだろうと思う
得意な科目の能力を伸ばす仕組み
たとえば、セキュリティキャンプというのがあって
サイバーセキュリティ分野について子供や学生に
高度人材育成のためにサイバーセキュリティの見分を深めてもらう取り組みはある
https://ja.wikipedia.or...83%A3%E3%83%B3%E3%83%97
https://www.security-camp.or.jp/
問題は、こういう取り組みは色んな分野に存在しているが
親や学校などが知らないので、子どもたちに届きにくいこと
失業者対策案として社会人のプログラミング教育を充実させるべき
プログラミングは昨今よく話題になっていますが、IT業務の一部分にしか過ぎません。
動作を支えるITインフラや#004 でも記載されていましたがデータ利活用などトータルな知見が必要だと思います。
カードレス本人認証
マイナンバーカードの機能をちゃんと知らないとこういうことを書くことになりがちだけれど
世の中のマイナンバーカードの使い方などを見れば実質こういう認識でもあまり外れてるとはいえないだろう
etaxとかでしか実際使ってないし
コンビニで住民票発行とか知ってても、なんとなく区役所とかに行く人も多いだろうし
1ヶ月停電したデジタル化社会の想像を
BCP(事業持続計画)、ディザスターリカバリー(DR、災害復旧)は
十数年前からのテーマで、
東日本大震災の際にも大きな課題として社会に広く認識されたが
やはり時間の経過とともに取り組みが形骸化しがちなものである
全く手を付けないか、過度に重く取り組むか、の二択ではなく
リスク評価を適切に行い、自らの状況に応じた対策をすることが重要だ
国家公務員の残業代が全て支払われることになった!地方公務員もこれに付け加えてほしい。
労基法適用対象外だからです。
他にも残業とかでもいろんなのあります。
たしか、緊急の時除くみないなのとか書かれてるのとかあったと思います。
緊急の時とか、やむ終えいない時等と記載されてるのって本来災害とかあった場合を想定しているんでしょうが結局組織がどうとでもできてしまう所がありまして、システムで厳密にチェックしてかないとブラック化するのですよ。
公務員の中でのIT技術者の地位向上案
技術を磨き続けるのにはコストがかかりますので事務職より若干高い給与とするのが妥当だと思う。
また独占資格の必要が無いことと更に事務職ということでIT全然関係無いところに異動させられてる人多いと思います。土木行かされたり建築行かされたり。技術で雇われたなら戻れる可能性は高いでしょうが本人も不安な上、人事は上に嫌われたらそれまででしょう。しかしそもそも資格持ったその人しかできない仕事となれば話は全く別で少なくとも関係無い部署に異動することは変えが効かないならまず無いでしょう。
資格に手当を出す等という話もここに来てようやく出てくると思います。
現状IT技術者がパソコンに詳しい便利屋位な立ち位置であることに納得できないのです。
防ハラスメントカメラがあれば良いと思う
経験上ハラスメントする人というのは、そもそもハラスメントをしているという自覚が無い場合も多い。指導だと思ってやった、相手が自分に好意があると思ってやった等言うのがそれだ。
ＡＩがハラスメントと判断したら「パワハラを検知しました。至急やめて下さい。」等と警報が鳴るようにすれば、怒り狂った者も我にかえり、それ以上怒るのをやめるだろう。