ほまるさんのページ | デジタル改革アイデアボックス

あなたと創るデジタル社会

デジタル改革アイデアボックス


ほまるさんのマイページ

ウェブサイト
http://
自己紹介文
自己紹介は未記入です。

投稿したアイデア 8

デジタル庁が目指すシステム運用経費3割削減の方針について

ほまるさん

デジタル庁が目指すシステム運用経費3割削減という後ろ向きの取り組みに反対します。 報道によると、2025年度までにシステム運用経費を3割削減するとされています。 政府のIT予算に関する情報がまとまっているITダッシュボードによると、システム運用経費は2013年度比で2021年度まで... » 詳しく

  • 6ポイント
  • 6
  • 2コメント

マイナポータルをIDプロバイダとして広く提供することによる利便性向上とカード普及促進

ほまるさん

マイナポータルをIDプロバイダ(IdP)として、民間を含め広く活用できる認証基盤とすることを提案します。 これによって国民にとっての利便性向上と、それによるマイナンバーカードの普及促進が実現されると考えます。 利便性向上の内容は以下の通りです。 1. 民間サービスはGoogle... » 詳しく

  • 5ポイント
  • 8
  • 3コメント

公共系システムのUI/UX改善とアジャイル開発の適用、それに向けた政府の取り組みについて

ほまるさん

公共系システムの開発を外部のシステムベンダに発注する場合、納期に間に合うように予算内で機能を実装することが最優先となり、定量化が難しい「使いやすさ」は調達仕様に含まれないこともあって、UI/UXはなおざりになります。 (関連トピック @02857 ) ではアジャイルだとなるわけ... » 詳しく

  • 7ポイント
  • 8
  • 9コメント

UI/UXに優れた使いやすいシステム/サービスを作るにはどうしたらよいか(第2回対話を受けて)

ほまるさん

IdeaBox第2回の対話でも述べられていたように、公共系のシステムではUI/UXがなおざりになっていて使い勝手の悪いシステムが多く存在します。 これはメルカリのUI/UX担当者が優秀でシステムベンダがそうではない、という問題ではなくて(そういう側面もあるでしょうが)、公的なシステム... » 詳しく

  • 14ポイント
  • 15
  • 17コメント

クラウドを使ったシステム調達のモデルとなる調達仕様書の提供

ほまるさん

現状において、システムとして求められるサービス品質保証とクラウドサービスプロバイダがSLA(サービスレベルアグリーメント)で追う責任には大きな隔たりがある場合があります。一般的にクラウドサービスプロバイダは問題を起こしても利用料を返金するだけであり、生じた問題には責任を... » 詳しく

  • 11ポイント
  • 12
  • 3コメント

機械可読な法律の記述を実現することによるシステム保守コストの低減

ほまるさん

現在定められ運用されている法律の条文は、大変に解釈が難しくその道の専門家でも解釈がぶれてしまうことがありますが、条文の解釈にルールを定め、条文あるい法令に付随する文書の記法を工夫することで解釈の余地がないようにされることを期待します。 これが実現できると、法令が機械... » 詳しく

  • 10ポイント
  • 16
  • 11コメント

パーソナルデータストアの実現と、パーソナルデータストアを通じた各種手続きのワンストップ化

ほまるさん

国がパーソナルデータストアを運営し、国民がそこに情報を預けるとパーソナルデータストアから各種サービス(電話・電力・ガス・自治体・銀行・等々)に情報が自動で連携される仕組みを実現することで、手続きのワンストップ化が実現され、国民の負担を減らすことができるでしょう。 パ... » 詳しく

  • 4ポイント
  • 4
  • 2コメント

公的個人認証を用いた一人1アカウントの実現

ほまるさん

公的個人認証サービスをIdP(IDプロバイダ)として、民間事業者に個人を特定するトークンを連携することにより、民間事業者にて確実に「一人1アカウント」(複数アカウントを作れない)を実現できるようになります。 これを実現することにより、一人が多数のアカウントを使って買占めを... » 詳しく

  • 18ポイント
  • 20
  • 2コメント

お気に入りアイデア 3

三層分離の見直し(マイナンバー利用事務系とLGWAN接続系の統合)

あきさん

元々行政のネットワークは、住民情報系ネットワークとLGWAN・インターネット系ネットワークの2種類でした。年金事務所の情報流出事件を機にマイナンバー利用事務系、LGWAN系、インターネット系の三層分離されました。 今年の5月に「自治体情報セキュリティ対策の見直し」の方針が示され... » 詳しく

  • 35ポイント
  • 36
  • 16コメント

エストニアのDigiDocの実現

デジタルコンシェルさん

前職でエストニアの技術を提供する企業にいた関係で、自分自身もe-Residencyを持ち、エストニアの技術に触れて参りました。 その中で日本に居てもとても便利だと感じたのがDigiDoc(https://en.wikipedia.org/wiki/DigiDoc)でした。 これは、エストニア政府が発行しているIDカードを使... » 詳しく

  • 7ポイント
  • 7
  • 1コメント

自治体システムの共同利用の義務化

下書きさん

昨年より、総務省にて自治体システム等標準化検討会が立ち上がり 第1段として住民記録システム等標準仕様書が公表されています。 ・自治体システム等標準化検討会(住民記録システム等標準化検討会) https://www.soumu.go.jp/main_sosiki/kenkyu/jichitaishisutemu_hyojunka/index... » 詳しく

  • 36ポイント
  • 37
  • 23コメント

投稿したコメント 51

デジタル庁が目指すシステム運用経費3割削減の方針について

ついでに本投稿の元ネタとなったITダッシュボード( https://www.itdashboard.go.jp/ )についてコメントします。
掲載されているデータが古くて2016年とか2017年くらいまでのデータしかないものが散見されますので、最新化をお願いします。
内閣官房IT総合戦略室で整備されているようですが、データ戦略の旗振り役であるIT室がこの状況で大丈夫だろうかと。
今多忙で手が回らないのだろうと推察はしますが、しっかり予算を付けて体制を整備し、やることをやるのが重要ではないでしょうか。システム運用も同様です。

by ほまるさん - 2020/11/29 01:08 問題を報告

[事務局]第3回データ戦略TFへのご意見をお願いします。

#014 の続き

■コードやIDの整備について
データ間の連携にあたっては、ベースレジストリを構成する複数のデータベース間、あるいはベースレジストリと民間との間で個人に関するデータをどうやって紐づけるのかが課題になるはずです。(紐づけのためにマイナンバーを使えるように法整備するのか、マイナンバーに代わる紐づけ用のIDを作るのか、あるいは情報提供NWSのような仕組みを作るのか…)
また複数のデータベースにまたがって検索したくなるケースもあるはずで、それができる仕組みも念頭に入れておいた方が良いでしょう。(児童手当対象かどうかの判定のため、世帯のデータと個人の所得のデータを組み合わせて、世帯所得を算出するなど)

by ほまるさん - 2020/11/28 23:38 問題を報告

データ戦略 第一次とりまとめ(案)にコメントします。

■図3 データ戦略のアーキテクチャ について
利活用環境がルールの下に置かれていることには違和感があります。ルールそのものは価値を生むわけではなく、利活用環境を通じて価値が提供されるわけでなので。ルールはデータから行政・民間までの縦軸を貫く概念になるのではないでしょうか?

■基盤となるデータについて
携帯電話会社、鉄道会社や日本郵便などの運輸業を営む事業者、電力・ガス・水道会社、MaaSを展開する自動車メーカー、気象情報を提供する会社、などの社会インフラを担う企業を巻き込むことが重要だと思います。
また災害時には、CivicTechの力を発揮できるように、それらのインフラ企業のデータを即座に無償で一般公開できるようにするなどのルールができると良いのではないでしょうか。

(次のコメントに続きます)

by ほまるさん - 2020/11/28 23:36 問題を報告

国産OAuthでWeb会員登録を撲滅しよう

似たアイデアを過去に投稿していますので、こちらもご参照いただければと思います。

@00139 公的個人認証を用いた一人1アカウントの実現
@03704 マイナポータルをIDプロバイダとして広く提供することによる利便性向上とカード普及促進

これらのアイデアでは、公的個人認証と結びついていることがGoogleなどとの差別化となっています。公的に存在が確認された個人を認証することができ、また一人1アカウントが保証されます。
また個人情報の連携は本人同意を前提としています。(それに加えて、利用目的を偽ることがないよう国の認定があると確かに良いかもしれません。運用は大変になりそうですが)

by ほまるさん - 2020/11/27 23:13 問題を報告

官公庁では、多段階契約で安くならず、高くなるおそれ

1円入札は公正取引委員会が低入札価格調査を入れて独禁法違反になるので、今時はなかなかないのでは。
とはいえ多段階契約で工程で契約を分ける場合、ウォーターフォール型の開発が前提になってしまいます。ウォーターフォール型開発ではUI/UXがおろそかになりがちなので、現代的な開発手法として好ましいとは言えません。また途中で事業者が変わる場合、上流を受注した事業者が低品質の成果物を納入することで、実際にその成果物をインプットとしてシステムを構築する事業者が設計からやり直しになってしまうこともあるため、そういった意味でも問題があります。
多段階契約と似ていますが、IPAが基本/個別契約モデルという開発サイクルごとに契約するモデルを示しているので、こちらを検討してもいいかもしれません。

by ほまるさん - 2020/11/23 21:03 問題を報告

マイナポータルの課題

同感です。
@03679#016 のコメントでも書きましたが、世帯という管理単位は税や社会保障の観点で重要であると思います。

例えば特別定額給付金の例でいうと世帯人数を把握するため世帯の情報が必要で、また世帯単位で振込先の口座の登録が必要でした。
また例えば現在検討されている児童手当ならば、収入が多い世帯は給付の対象外にする案が出ていますが、夫の収入・妻の収入ではなく世帯収入が必要になります。世帯情報と、国税庁が保持しているであろう収入データとの紐づけが必要になるはずですがどうやって紐づけるか。給付に使うなら「世帯所得が〇〇万円以下の世帯を抽出」といった条件による対象世帯抽出ができることが要件になってきます。

富士通総研の研究レポートにおいても「世帯」に注目した研究レポートが出されているので、参考にしてほしいと思います。

マイナンバーの検証と今後の展開に関する研究
https://www.fujitsu.com/jp/group/fri/knowledge/research/2019/report-465.html

by ほまるさん - 2020/11/23 17:27 問題を報告

法律をわかりやすく

近いアイデアを投稿しています。
@00180 機械可読な法律の記述を実現することによるシステム保守コストの低減

法律家、SEやプログラマ、あるいはシステムにとっても読みやすく解釈がぶれない記述ルールを確立することで、様々な業種・業務で生産性の向上が図れるのではないかと思います。

by ほまるさん - 2020/11/22 13:10 問題を報告

診療報酬のオンライン化について

近いアイデアを投稿しています。

@00180 機械可読な法律の記述を実現することによるシステム保守コストの低減

システムの改修コスト低減や改修にかかる期間の短縮することにも寄与すると思います。
コメント欄で「医科点数表」を例として取り上げています。

by ほまるさん - 2020/11/19 08:42 問題を報告

国のシステムもOpenID採用すべき

同様のアイデアを投稿しています。

@03704 マイナポータルをIDプロバイダとして広く提供することによる利便性向上とカード普及促進

by ほまるさん - 2020/11/19 08:36 問題を報告

アイデアボックス投稿者へのインセンティブ付与

アイデアボックスとしては幅広いアイデアを募るべきであり、バッジ制度では逆効果になってしまうのではないでしょうか。(少数の投稿者による大量投稿を助長する)
多くの意見を募るにあたっては広報を強化すべきだと思います。

私としては、何より意思決定で参考にしていただくのが何よりのモチベーションになります。
その意味では、先日公開された「デジタル改革アイデアボックス
(取りまとめ)」を見る限り(一人一人の意見を見るとは言いつつも)結局は人気ランキング上位のものだけがピックアップされているようで少し萎えました。

by ほまるさん - 2020/11/15 00:34 問題を報告

デジタル政府の実現には専門IT人材が不可欠

CITP認定情報技術者のサイトを確認しましたが、現時点での認定者は「社内資格制度が本制度に適合すると認定された企業」の従業員ばかりとなっているようです。そして「社内資格制度が本制度に適合すると認定された企業」の多くは国の調達案件に入札するような大手です。
一方で、現在デジタル庁の設立に向けての採用では、当該職員が現在所属するか過去2年間所属していた事業者はその職員が関わる調達案件には入札できない、という留意事項がついています。

要するに、CITP認定を保持する人材のうちの多くは、今いる会社に迷惑をかけることになるためデジタル庁の創設に向けた採用には応募できない、ということになりそうです。

民間から起用するとしていながら、国の調達案件に詳しいベンダ側の実務経験者を実質的に弾き出すような留意事項をつけているのはいかがなものか、と思いますが…。理由は理解できますが、デジタル庁に国のシステムの予算や権限を集中させる中で本当にそれで成り立つのか心配です。

by ほまるさん - 2020/11/15 00:16 問題を報告

[事務局]第2回データ戦略TFへのご意見をお願いします。(データ整備)

想定されるユースケースで検証してみると、足りないものが見えてくるのではないでしょうか。
例えば特別低額給付金の例でいうと世帯人数を把握するため世帯の情報が必要で、また世帯単位で振込先の口座の登録が必要でした。
また例えば現在検討されている児童手当ならば、収入が多い世帯は給付の対象外にする案が出ていますが、夫の収入・妻の収入ではなく世帯収入が必要になります。世帯情報と、国税庁が保持しているであろう収入データとの紐づけが必要になるはずですがどうやって紐づけるか。給付に使うなら「世帯所得が〇〇万円以下の世帯を抽出」といった条件による対象世帯抽出ができることが要件になってきます。

ベースレジストリが一元管理でないとするなら、データベース間のデータの紐づけは何かしら必要です。情報提供NWSではマイナンバーを使わずに、情報保有機関間で個人に関するデータを紐づける仕組みが提供されていますが、それを踏襲するのか新しい仕組みを作るのかも検討が必要になると思います。

by ほまるさん - 2020/11/15 00:11 問題を報告

[事務局]第2回データ戦略TFへのご意見をお願いします。(プラットフォーム整備)

なお、個人情報と個人情報以外ではデータの流通方法は変わると思います。上記 #013 のプラットフォームで提供される情報は個人情報でないもの、匿名加工がされ個人を特定できない状態になっているものでなければなりません。
匿名加工されない個人情報は、マイナポータルを通じて利用用途を含めて本人の同意を得た上で、官民に提供されるのが良いと思います。
民間サービスに個人情報を提供する仕組みとしてはOpenID Connectを使ったアイデアを @03704 に投稿しています。

by ほまるさん - 2020/11/14 23:57 問題を報告

オープンデータはAPIがRead Onlyに特化した一形態だと考えると良いです。そして民間のデータを流通させるにはデータそのものをプラットフォームに提供させるのではなくデータそのものは民間が保有したままとした上で、APIへのアクセスにサブスクリプションとして課金するAPIマーケットをプラットフォームとして提供するといいのではないでしょうか。プラットフォームにデータを提供させる場合、データの量によっては時間や通信コストがかかるし、データのリアルタイム性が失われることになります。
APIの可用性はデータ(API)提供組織に依存することになるのが課題ですね。
行政からのオープンデータ提供は無償でアクセスできるべきですが、プラットフォームとしては同じものが使えるはずです。

また、流通されるデータの匿名加工が十分であるかについて、個人情報保護委員会に監査してもらってはいかがでしょうか。

by ほまるさん - 2020/11/14 23:53 問題を報告

マイナポータルをIDプロバイダとして広く提供することによる利便性向上とカード普及促進

本アイデアは @00139 「公的個人認証を用いた一人1アカウントの実現」をベースにしています。
OpenID Connectに詳しい識者の方に、本アイデアに穴や課題がないかご指摘いただければ幸いです。

by ほまるさん - 2020/11/11 21:17 問題を報告

マイナンバーやそのカードに関する「仕組み」を説明サイトを作る

こちらではいかがでしょうか。
マイナンバー 社会保障・税番号制度 概要資料
https://www.cao.go.jp/bangouseido/pdf/seidogaiyou.pdf
21ページ目で情報提供ネットワークシステムを使った情報連携の仕組みが表現されています。
個人に紐づく属性情報は一元管理されず、各情報保有機関に分散管理される仕組みとなっています。

マイナンバーカードの証明書を使った認証や署名については、この資料ではわかりませんが、一般的な公開鍵認証基盤(PKI)の仕組みになります。
少し話がずれますが、義務教育ではプログラミングよりもPKIを情報リテラシーとして教えてほしいと思います。

by ほまるさん - 2020/11/09 22:19 問題を報告

「データ共同利用権」という基本的人権に反した権利の新設に反対します。

この資料の序文でGDPRが取り上げられているように、データの活用にあたっては「個人の情報自己決定権」が重要であるという考え方のもと、ルールが整備されてきています。自己決定権というとわかりにくいですが、自己の個人データ開示や利用を自身で決定する権利を意味しています。
一方、この資料中の本旨である「データ共同利用権」は、個人の同意を得ることなくデータを利用できるようにしよう(公益性があればいいでしょ)、ということを言っているようです。これは個人の情報自己決定権と相反する内容にも読めます。

どのようにデータの利用に関して同意を得て、またプライバシーを守る枠組みが作れるか、ということがまず議論されるべきであり、それを飛び越えて同意なしに個人データの共同利用を進めよう、という路線で議論を進めることには反対します。

by ほまるさん - 2020/11/08 22:36 問題を報告

データ戦略へのご意見をお願いします!![事務局]

データ戦略やベースレジストリの議論にあたり、データ戦略タスクフォースでは以下の研究・提言を参考にされているでしょうか。

マイナンバーの検証と今後の展開に関する研究 ―「マイナンバー世帯」についての試論 ―
https://www.fujitsu.com/jp/group/fri/knowledge/research/2019/report-465.html

住民サービス、給付や税等を考えるにあたり「世帯」や「戸籍」をどう扱うかが重要な課題になると思いますが、データ戦略タスクフォースの資料上はそれらについて触れられていませんでした。
上記の研究レポートの特に後半第5章、第6章では「世帯」等をどう扱うか、制度設計やデータ整備にも踏み込んで将来像を描いた提言になっています。
もしまだであれば、このレポートから論点を抽出し、しっかり議論されてはいかがでしょうか。

by ほまるさん - 2020/11/07 12:16 問題を報告

ゼロトラストネットワークの導入

リモートワークについては、自宅からクラウド上の仮想デスクトップ(DaaS)に画面転送方式で接続しつつクラウドからVPN(仮想閉域網)経由でオンプレミス環境のシステムにアクセスするとか、あるいは自宅から直接VPN接続して画面転送方式でオンプレミス上の仮想デスクトップ(VDI)に接続する、というのも現実的な解です。
ゼロトラストは一般企業にとってはまだ先に書いたように課題も多く、またガートナーのハイプサイクルでいうところの「過度な期待」期にあり、幻滅期を乗り越えて一般普及するかまだ見極めが必要なコンセプトです。

三層分離のようなネットワーク分離は標的型攻撃やランサムウェア対策として民間でも導入が進んでおり、一概に時代遅れだとも言い切れませんが、業務に支障が出ないよう対策は必要です。とはいえゼロトラストとはまた別の議論かと思います。

by ほまるさん - 2020/11/03 21:47 問題を報告

ゼロトラストは、モダンなクラウドサービス(SaaS)を中心としたシステムと統一された認証基盤、そして従業員の高いITリテラシーがあってようやく成り立つものであろうと思います。
これまでネットワーク境界で守られていてセキュリティパッチの適用もさほど急がなくても何とかなっていたようなシステムがインターネットにさらされれば、すぐに脆弱性を突かれて不正アクセスを受けてしまうでしょう。
また不審なデバイスやアカウントからのアクセスであればポリシーにより検知して防止することはできても、逆に言うと不審だとシステムが判断できなければ自由にアクセスできてしまうことになります。例えば未知だったり世に出て間もないウィルスに感染したデバイスは検知できないかもしれません。クレジットカードには不正利用を検知するシステムがありますが100%検知できるわけではないのと似たようなものです。

ITリテラシーの高い先進的な企業、あるいは既存システムのしがらみのないスタートアップ企業などであれば導入しやすいでしょうが、行政システムでの導入に向けてはまだ慎重な判断と検証が必要だと思います。

by ほまるさん - 2020/11/03 09:59 問題を報告

システムベンダー間の競争性確保が必要

(続き)
ベンダにドキュメントを求めるのは当然だと思いますが、重要なドキュメントとそうでないドキュメントはメリハリをつけ、いらないものはいらないと整理した方がいいと考えます。
納品物として定めた瞬間、それが後から使われるかどうかにかかわらず網羅的かつ均質に作成する必要が出てきます。当然開発コストや納期に大きく跳ねます。
重要な機能やアーキテクチャの設計書についてはしっかり残す、そうでない機能については省略を許す、といった判断ができると良いでしょうね。

監視制御システムには詳しくないので、ポイントずれていたらすみません。

by ほまるさん - 2020/11/01 16:43 問題を報告

より重視すべきは、ソフトウェア内部の詳細な仕様・設計ではなく、外部的な仕様やビジネスルールとなります。

システムそのものの内部設計書があってもベンダロックインは解消は難しく、より大事なのは外部的な仕様が明確であることです。
そのシステムを使った業務が何を目的としていて、そのためにシステムがどのようなサポートをするのか、そしてシステムがユーザや他システムとどのようなインタフェースを持つのか、インプットに何を与えればどのようなアウトプットが得られるのか、ということが明確であれば、老朽化したシステムを別のベンダが新しいアーキテクチャで作り直すにあたってのリスクは軽減します。

逆にソフトウェア内部の詳細設計書があったとしても、多くの場合信用はできません。
詳細設計書とプログラムコードの情報量は大して違いがないうえに、プログラムと詳細設計書は多くの場合乖離してしまっているため、結局はプログラムコードを読み解き、そもそも何をやりたくてこんなプログラムになったのかを推測するという非常に難解な作業が必要になるため他ベンダは手を出しにくくなります。

by ほまるさん - 2020/11/01 16:38 問題を報告

公共系システムのUI/UX改善とアジャイル開発の適用、それに向けた政府の取り組みについて

#001
コメントありがとうございます。
アジャイル開発には準委任契約がふさわしいとされているのはIPAの出しているモデル契約によるものかと思います。
https://www.ipa.go.jp/files/000081484.pdf

ただ、実のところ準委任契約であっても「発注者側が直接指示できない(受注者側の判断で作業を行う)」契約形態であり、上記のモデル契約の16~18ページにも書かれているのですが、発注者から指示に相当するコミュニケーションがとられた場合は偽装請負(偽装準委任)に相当する可能性があります。

つまり準委任契約であったとしても、発注者側の代表者がプロダクトオーナーとなりまたチームが一体となりコミュニケーションを重視しながら開発するアジャイル開発では、発注者側からチームメンバへのコミュニケーションに指示が一切含まれないということは考えにくく、コンプライアンス上問題になる可能性が非常に高い、というのが私の理解となります。

by ほまるさん - 2020/10/31 00:31 問題を報告

UI/UXに優れた使いやすいシステム/サービスを作るにはどうしたらよいか(第2回対話を受けて)

皆様コメントありがとうございます。大変共感・納得できる意見ばかりです。
特に公共系のシステムでは、前年度に予算要求して実施年度に仕様を決めて調達し、その時に決めた内容を開発中に変更することが容易でないというプロセスの問題が大きいのではないかと感じました。
発注者側にプロダクトオーナーを立て、その人に開発中であっても仕様・納期等を調整する裁量と権限を与えるような仕組みが実現できないかと思います。

by ほまるさん - 2020/10/30 22:56 問題を報告

データ戦略へのご意見をお願いします!![事務局]

システム屋の観点で思うこと。

・データの構造・形式も大事だが正規化も重要。第三正規形まではやっとかないとデータの整合性が維持できなくなる。
・データのライフサイクルの検討。発生・消去のタイミングを明確にする。例えば死亡した人のデータは何年残す?
・ベースレジストリとして一元管理するのではなく、種類ごとに分けて管理する方が良い。
 ・モノリシックなシステムにするのではなく、マイクロサービスとして設計して必要なタイミングで連携する。例えば個人データと収入・税データ、資格データは分けて管理する。
 ・個人や法人などはマスタデータ、収入・税はトランザクションデータとなる。ライフサイクルも違う。
 ・データの種類によって所管も違うだろうし、分けておいた方が万が一情報流出した場合の影響が限定される
・オープンデータの機械可読性は必須。機械可読じゃないと分析できず活用できない。

by ほまるさん - 2020/10/28 22:27 問題を報告

課題と思うことを挙げておきます。

・例外の扱いを十分に配慮する必要がある。例えば、
 ・男性でも女性でもない人
 ・戸籍を持たない人、住民登録がない人(管理対象外?)
 ・生年月日が不明な人
・ベースレジストリへの個人データ登録が強制かオプトインかオプトアウトか
・個人データ一元管理の合憲性
 ・住基ネット訴訟判決を踏まえる必要があるのでは。
・属性(学歴・資格など)をどう証明するか
 ・個人・法人に対する属性を証明するトラストアンカーと認証パスの構築が必要。国がトラストアンカーとなり、大学とか認定機関に対する認証パスを構築する? 海外の学歴・資格はどうする?
・奇麗でないデータをどうクレンジングするか。そもそもクレンジングしていいのか。
・誰が、何の目的でベースレジストリにアクセスできるのか。参照・更新権限をどう設定するか。
・アクセスに対する監査ログを残す必要がある
・データ活用にあたっての匿名化、プライバシー保護をどう実現するか
・データの鮮度をどう保つか

by ほまるさん - 2020/10/28 22:26 問題を報告

個人認証システムXidを参考に

#004 #005
マイナンバーに乱数など別の情報も追加してから非可逆変換してIDにするなら確かに戻すのは難しそうですが、詳細な仕様は不明なのでわかりませんね。でもそうなるとそもそもUUID使えばいいのではないかと思いますので、マイナンバーを入力させる意味はよくわかりません。
本物のマイナンバーカードで認証・署名するときも使っているのは証明書とカード内の秘密鍵であってマイナンバーそのものは使っていないはずなので、何のために入力させているのか…。

xIDの是非はともかく、日本が学ぶならエストニアで使われている実績があるものを、セキュリティ仕様やユーザエクスペリエンス、サービスデザインの観点で学ぶのが良いと思います。

by ほまるさん - 2020/10/25 20:14 問題を報告

ちなみに個人的にはxIDに違法性がないか懸念しています。

■根拠
・xIDのFAQに「なぜマイナンバーを入力する必要があるんですか?」とあるが、番号法第15条や第19条により、規定された事務以外でマイナンバーの提供を求めてはならないはず。
・上記FAQの回答として「マイナンバーをもとに一意のIDを生成するために、マイナンバーをご入力いただいています。非可逆な形で生成していますので、IDをものにマイナンバーを検出することはできません。」とあるが、元が12桁の数字列(チェックデジット除くと11桁)とわかっているので、非可逆であっても総当たり攻撃で簡単にもとに戻すことができる(対応表を事前に作っておけばミリ秒で戻せる)。

あとは個人認証や署名にかかるセキュリティを一企業に任せることに対する不安もあります。自治体が採用に動いているようなので尚更心配。マイナンバーカードの代わりとして使えるものではないはずなのですが。

by ほまるさん - 2020/10/25 16:07 問題を報告

エストニアに学ぶのは同意ですが、それならエストニアで使われているMobile-IDやSmart-ID、X-Road等に学ぶべきであって、xIDがエストニアで使われているわけではないようです。(エストニアで生まれた、と言っているだけ)
https://www.jeeadis.jp/jeeadis-blog/9108878
> なお、日本でサービスを提供しているblockhive(ブロックハイブ)社の電子契約サービス「e-sign」やデジタル身分証アプリ「xID(クロスID)」は、エストニアのスマートIDとは全く関係がありません。
>
> 「e-sign」や「xID」は、エストニアの電子政府における利用実績は無く、eIDAS規則による適格電子署名等の認定を得たものではないことを理解した上で、ご利用ください。

by ほまるさん - 2020/10/25 16:05 問題を報告

機械可読な法律の記述を実現することによるシステム保守コストの低減

実現手段としては、ドメイン特化言語(Domain Specific Language。以下DSL)と呼ばれる手法を使う想定です。
DSLは特定の領域(ドメイン)に特化した記述法を言語として設計し、それをプログラムに実行させる手法です。DSLでは「どんな条件のときに、どうあるべきか」を宣言的に記述し、どのようにデータにアクセスするかとかどう表示するか、といった処理は書きません。(そのような処理はDSL以外の外部のプログラムに任せます)
例えば上記の診療報酬を題材とするならば、医科点数表に特化した言語を設計することになるでしょう。医科点数表というドメインに特化することで、プログラマやSEでなくても理解しやすい・記述できる言語にすることができます。

by ほまるさん - 2020/10/25 12:00 問題を報告

このアイデアで何がよくなるのかイメージしにくい方も多いと思うので、具体例を出します。
題材として @01991 「システム改修を考慮した診療報酬改定の提案」というアイデアが投稿されており、以下のような課題が読み取れます。

・改定内容の公示から適用までが短期間でシステム改修の時間的余裕がない
・明確でなかった表現に対する疑義解釈が次から次へと通知される
・改定にかかる費用を負担しなければならない

実際に厚生労働省の「令和2年度診療報酬改定について」を見てみましたが、大変にボリュームがあり、改定についていくのは本当に大変だと思います。
システムベンダは改定の度に差分を抽出してシステムへの影響箇所を調査し、難解な日本語を読み解いてシステムに修正を入れているわけです。

「診療報酬の算定方法」の別表第1(医科点数表)などは機械可読にできそうな気がします。
この点数表で示される条件とその条件で判断される結果が機械可読になって、条件に使われるインプット情報さえ外部から与えることができれば、システム改修の短期間やコスト低減に大きな効果があるはずです。

by ほまるさん - 2020/10/25 11:58 問題を報告

#005
> 法律の文章が変わると政府のシステムが自動的に変わるのですか?

法令の解釈を示す機械可読な文書をシステムに読み込ませることで、システムの挙動を変えることができるようになることが理想です。

> 発注者である行政組織に尋ねたら教えてくれると思いますが。

ベンダがシステム仕様を調整する先のシステム課が法令に詳しいわけではないですし、現場の担当者もシステムに頼って仕事をしていますから法令の解釈を知っているわけではありません。
聞いたところで回答を得られるまでに時間がかかったり、回答をもらえなかったり、今動いているシステムの挙動が正しいからそれを同じにしてくれ、と言われることになります。(そして現在動いているシステムのプログラムコードを読み解いて調査することになるわけですが、大きいシステムだとプログラムコードが数百万行あってあちこちにロジックの欠片が散らばっていたりするので、これがまた大変です)
結果としてシステムの改修にかかる期間とコスト、そしてプロジェクトがデスマーチに陥ったり失敗するリスクは膨らんでしまうわけです。

by ほまるさん - 2020/10/25 11:55 問題を報告

AWS等のインフラ契約を中央一括とする

省庁向けにはもうやっていますが、これの自治体版でしょうか。

日本政府、AWSベースの情報システム基盤を運用開始
https://www.itmedia.co.jp/news/articles/2010/14/news053.html

by ほまるさん - 2020/10/18 17:26 問題を報告

デジタル改革アイデアボックス オープン対話について

#001
> 匿名でしかも複数ID持てるから、私はその日ごとにID再作成して投稿してますよ。もう50個位作りました。自分が作成したアイディアに自分で賛成票15票入れたりとか。管理者が適当だから何でもできちゃいますよ、この掲示板。

上記のようなことができないようにするための仕組みとして、公的個人認証サービスやマイナポータルとこのサイトが連携するといいですよね。
このサイトは今のところ Google、Facebook、Twitter、LINE、Instagramと認証連携できる仕組みですが、公的個人認証サービスやマイナポータルと認証連携できれば、それで認証されたアカウントは確実に一人1アカウントが保証されます。
ということができるようにするためのアイデアを以前投稿しましたので、内閣官房IT総合戦略室にはぜひご検討いただきたいなあと思います。
https://ideabox.cio.go.jp/ja/idea/00139/

by ほまるさん - 2020/10/18 12:43 問題を報告

すでに実現のために動いている、検討しているアイデアが選ばれている印象は持ちました。
政治ですしある程度恣意的に選ばれるのは仕方がないかなと思いますが、次回以降の対話では、これまで検討していなかったけど新しいアイデアとして取り組みたいと内閣官房IT総合戦略室で判断したアイデアや、中身をもう少し掘り下げたいようなアイデアを積極的に取り上げてほしいと思います。

選ばれなかった人の中には「自分のアイデアが選ばれないなんておかしい」「透明性がない」などと思う人もいるでしょうが、そんな文句ばかりが寄せられてしまえば対話の場そのものがなくなってしまうので、少なくともこのような対話が行われたこと自体は歓迎すべきではないでしょうか。

by ほまるさん - 2020/10/18 12:27 問題を報告

マイナンバーと生体認証の連携を!

マイナンバーカードによる認証はすでに「(マイナンバーカードの)所有」と「(パスワード・PINの)知識」という二要素を用いる強固な認証となっています。
パスワードやPINの代わりに生体認証を使うというアイデアは利便性の面では理解できますが、以下のような問題もあります。

・生体認証には「本人拒否」や「他人受入」が発生する可能性がある
・それらの発生率はセンサーの精度によっても変わる
・生体認証の種類によってはセンサーが高額だったり大きかったりして導入しにくい
・パスワードやPINと違い、生体情報が流出してしまっても変更できない
・生体情報が偽造される可能性がある(指紋などは簡単に偽造できる)
・生体情報を取られることに拒否感を示す人も多い

ということで生体認証は、サーバでの認証ではなく端末上に閉じた認証として使われたり、あるいはATMのようにしっかり管理されている端末上で使われることが多い印象です。
パスワードやPINを憶えられない人のために生体認証を組み合わせるなら、管理された端末を自治体の窓口等に設置してそこからのみ生体認証を許可するのが良いのでは。

by ほまるさん - 2020/10/18 12:13 問題を報告

InternetExplorer(IE)の規制

#019
マイナンバーカードで認証・電子署名するアプリについては、公的機関の配布するアプリであることを証明するコード署名を入れたものを用意して、利用者にその署名を検証するよう注意を促した方がよいです。
そうでないと、偽物のアプリを使って本来提出しようとした申請とは全然違う内容のデータに電子署名させられたりする可能性があります(クライアント側でデータに署名したものをサーバに送ることになるので)し、そもそもマルウェアを掴まされるかもしれません。

by ほまるさん - 2020/10/15 00:42 問題を報告

マイナンバーのワンタイム化

いいアイデアかもしれません。
マイナンバーが秘匿すべき情報とされているのは、本人の預かり知らぬところで勝手に名寄せに使われるリスクがあるから、という点にあります。どういうことかというと、マイナンバーは通常は一生変わらないため、その番号を使って勝手に買い物履歴や図書館で本を借りた履歴など様々な情報を紐づけされると、その人の行動履歴というプライバシーが丸裸にされてしまいかねない、ということです。
ワンタイム化でもいいのですが、例えばマイナンバーカードの更新期限ごとにマイナンバーが変更されれば、そこで一旦は履歴を切ることができるので、一生ついて回る問題にはならないわけです。
つまり、マイナンバーが変わることによってマイナンバーと紐づけられた情報について「忘れられる権利」が実現されるということになります。

そもそも漏洩した場合など正当な理由があればマイナンバーは変更可能ですし、これによって大きなシステムの変更は必要ないはず。
これが実現すれば、マイナンバーは特に秘密にしなくてもよい情報として法改正ができ、事業者やシステム上でのマイナンバー管理も特別な対応が不要になるかもしれません

by ほまるさん - 2020/10/14 23:51 問題を報告

ブロックチェーンを国家戦略にしないでください。

賛成です。新しい技術=良い技術 ではありません。
推進派は制約やデメリットに触れていません。

ブロックチェーンのメリットとしては以下のようなことが挙げられます。
・管理主体が必要ない
・改ざん耐性が高い
・システムが停止しない

ただし上記のメリットを享受するためにはブロックチェーンを構成するノードが大規模分散している必要があり、以下のような課題が出てきます。

・ブロックチェーンノードを誰が運用するか。政府管理ならブロックチェーンである必要はない。改ざん耐性や透明性を求めるなら政府以外の組織・団体にも運営に加わってもらう必要がある。
・政府以外の組織・団体がブロックチェーンのノードを運用するのであればそのモチベーションは何か。運用にかかるコストをどうまかなうか。
・ノードが多数の組織・ノードに分散しているとシステムのバージョンアップが困難。
・攻撃者の保有するノードの計算能力が高ければ改ざん可能(51%攻撃)
・攻撃により不正なトランザクションが記録された場合に正しい状態に戻すことが困難。
・情報流出に対して無力、というか積極的に流出させる技術である

by ほまるさん - 2020/10/14 09:40 問題を報告

国産クラウドの推進を

AWSやMicrosoft、Googleは自前でクラウド基盤技術を開発しており、クラウドを構成するオープンソースコミュニティへの貢献もしています。それらの企業の研究開発費は年間100億ドル単位(Amazonの2019年のR&Dが360億ドル)です。一方で代表的国内ベンダの2019年度の研究開発費は1,230億円くらいです。約30倍差。
オープンソースへの貢献に関するある調査ではトップ30位に日本企業は一つも入っていません。(Microsoft、Google、Amazonはトップ層にいます)

国内ベンダはオープンソースのクラウド基盤ソフトウェアであるOpenStackを使ってクラウド(IaaS)サービスを提供していますが、OpenStackに対してはどれだけ貢献できているでしょうか…。ほとんどフリーライダーに近い状態では。
またクラウドのベースとなるデータセンターの運用についても、三大クラウドは世界中に大量のリソースを抱えているのに比べると、国内中心の小規模なスケールでしか展開できておらず、運用ノウハウの蓄積もできていません。

それでも国産クラウドを推進したいですか?

by ほまるさん - 2020/10/13 00:39 問題を報告

自治体業務システムの機能サービス化(API化)を必須要件に

#003
APIさえしっかり設計されていれば、ユーザインタフェースは後から改善したり、または多様なデバイスに対応したりできますね。
逆にAPIがいけてないとユーザインタフェースだけでは根本的な使いにくさを改善できない場合もありますので、ここが肝要だと思っています。

オープンデータの掛け声が上がった時にも、いけてないデータ(
神Excel、神CSVとか)のせいで機械的な処理が難しい、ということがあったりしました。
データ設計・インタフェース設計はそれなりに専門的な能力が必要なので、それを意識した進め方・体制が必要になると思います。

by ほまるさん - 2020/10/12 01:10 問題を報告

APIの設計には、データ設計に対する理解やインタフェース設計についてのセンスが必要です。
ベンダに任せても使いにくいAPIを設計される可能性があるし、認証・セキュリティをシステムごとに設計するのも大変です。
内閣官房やデジタル庁にAPIの認証に対する指針を提示していただいたり、横串を通してAPIをデザインしたりレビューする組織があると良いと思います。

by ほまるさん - 2020/10/11 23:40 問題を報告

デジタル化にブロックチェーン技術を

文書に対するはんこの代わりになる技術としては電子署名になります。
ブロックチェーンははんこの代用としては適しません。

ブロックチェーンのメリットとしては以下のようなことが挙げられます。
・管理主体が必要ない
・改ざん耐性が高い
・システムが停止しない

ただし上記のメリットを享受するためには、ブロックチェーンを構成するノードが大規模に分散している必要があり、そうした場合に以下のような課題が出てきます。

・ブロックチェーンのノードを誰が運用するか。政府が管理するならブロックチェーンである必要はない。改ざん耐性や透明性を求めるなら政府以外の組織・団体にも運営に加わってもらう必要がある。
・政府以外の組織・団体がブロックチェーンのノードを運用するのであればそのモチベーションは何か。どうやって運用にかかるコストをまかなうのか。
・ノードが多数の組織・ノードに分散しているとシステムのバージョンアップが難しい。
・攻撃者の保有するノードの計算能力が高ければ改ざん可能
・攻撃により不正なトランザクションが記録された場合に、正しい状態に戻すことが困難。

by ほまるさん - 2020/10/11 23:23 問題を報告

PDF 文書を受け付けて欲しい

PDFでは、Readerソフトウェアで入力欄に入力可能となるフォームを作ることができます。
役所側で入力可能なPDFフォームを準備しておいて、そのフォームに入力したものの提出でも受け付けますよ、ということができればいいですね。
マイナンバーカードを使って電子署名を付けることも技術的には可能なので、入力可能なPDFフォームを表示して入力を受け付け、マイナンバーカードを使って電子署名をする、ということをシンプルに実現できるクライアントが用意されると良いなあと思います。

標準のReaderだとマイナンバーカードによる署名に対応していないため、マイナンバーカードに標準対応するようにAdobe社などに働きかけてもらえないかな。

by ほまるさん - 2020/10/11 10:08 問題を報告

いろんなカードの統一

ほとんどのポイントカードはgoogle payでまとめられますよ。
買い物履歴はプライバシー情報でもあるのでマイナンバーのように厳密に本人と紐づいて管理されると、一生付きまとうことになりかねません。
あまり厳密な管理が必要でないものはマイナンバーカードにまとめなくてよいと思います。

by ほまるさん - 2020/10/11 09:15 問題を報告

クラウドを使ったシステム調達のモデルとなる調達仕様書の提供

#001
クラウドの利点は理解しているつもりですし、私企業のサービス方針に対してどうこう言っているつもりもありません。
オンプレミスも当然選択肢にはなると思いますが、政府としてクラウド・バイ・デフォルト原則を示した「政府情報システムにおけるクラウドサービスの利用に係る基本方針」を出しており、オンプレミスは排除されていく方向にあります。これを受けて公共の調達案件においてもクラウド以外の提案はしにくくなっている状況です。
それに対して、クラウドサービスを利用するリスクを調達する側が(受託側も、ですが)よく理解されておらずクラウド・バイ・デフォルト原則のためクラウドで提案せざるを得ない受託企業側にリスクを押し付けている形になっていないか、クラウドを安心して調達・提案するにあたり調達側・受託側がクラウドのリスクを共有し、その扱いを整理した調達仕様書のモデルなどが提供できないか、ということがこの提言となります。

by ほまるさん - 2020/10/11 02:24 問題を報告

個人認証方法の多様化を〜印鑑証明に変わるデジタル個人証明方法の確立

xIDにはいくつか疑問があります。

1.「エストニアで誕生した」とはあるが「エストニアで使われている」わけではない
2.マイナンバーカードから公的個人認証に使われる秘密鍵を取り出すことはできないので「マイナンバーカードの代わりに認証・署名できる」わけではないはず。
3.マイナンバーをもとに一意のIDを生成するためでありマイナンバーそのものは扱わないから大丈夫、といったことが書かれているが、番号法第2条第8項によると「個人番号」とは「個人番号に対応し、当該個人番号に変わって用いられる番号」が含まれる、とあるためマイナンバーから生成したIDは個人番号扱いになる。この使い方は違法である可能性がある。
4.エストニアで使われるアプリ方式の電子認証・電子署名であるSmart-IDは、アプリとサーバに秘密鍵を分散させる方式を採用しており、当然サーバ上でHSM(ハードウェアセキュリティモジュール)で厳重に管理されていて、アプリ内の秘密鍵とサーバの秘密鍵を両方組み合わせないと使えないセキュアな仕組みになっている。このアプリは秘密鍵はどう扱っているのか不明。

by ほまるさん - 2020/10/11 01:18 問題を報告

InternetExplorer(IE)の規制

なぜ公的機関のシステムでIEがよく使われてきたのかは、楠CIO補佐官のブログに詳しく経緯が書かれており、この話題に興味のある方、特に技術者であればぜひ読まれるとよいでしょう。
https://comemo.nikkei.com/n/n1c9103c81c79

マイナンバーカードを使うシステムにおいてブラウザをフロントに使うには、大変に技術的な困難があったことがよくわかります。
ブラウザは時代とともにセキュリティに関する仕様も変わっていくので、マイナンバーを使うシステムではブラウザにこだわらず全てネイティブアプリとして実装したほうがいいのでは、と個人的には思います。

by ほまるさん - 2020/10/10 13:21 問題を報告

マイナンバー連携システムの疎結合化

・個人の秘密鍵はマイナンバーカードの中の耐タンパ性のあるICチップ(取り出せない)の中に保管されています。
・マイナンバーカードを使った認証は公的個人認証サービスが提供しており、このサービスを使って各システムは個人を識別して利用できるようになります。
・個人番号は公開情報として扱うためには、個人番号によって様々な事業者・機関で管理される個人に関する情報が名寄せされてプライバシーが侵害されるのではないか、という過去の議論に立ち戻る必要があります。
・マイナンバーを使った個人情報の流通には情報提供ネットワークシステムが使われます。
・マイナンバーを使った疎結合な連携の仕組みについては、この資料の21ページ目あたりに仕組みが分かりやすく示されています。
https://www.cao.go.jp/bangouseido/pdf/seidogaiyou.pdf
・ただし情報提供ネットワークシステムを使って情報を流通させることができるのは、マイナンバー法で規定される機関と事務に限定されています。
・情情報提供ネットワークシステムの運営については個人情報保護委員会が監視しています。

by ほまるさん - 2020/10/10 13:00 問題を報告

パーソナルデータストアの実現と、パーソナルデータストアを通じた各種手続きのワンストップ化

#001
民間で進められている情報銀行は、収集したデータを分析してビジネスに活かす、という観点であり、手続きのワンストップ化は視野に入っていないように思われます。
民間にやってもらってもよいのですが、民間の情報銀行を経由して行政・自治体に対する手続きを代行させるのは個人としても抵抗があります。
官民の手続きのワンストップ化、行政手続きの効率化につなげるためのプラットフォームとしては、官がこの仕組みを構築するのがよいのではないでしょうか。

by ほまるさん - 2020/10/10 09:51 問題を報告

機械可読な法律の記述を実現することによるシステム保守コストの低減

#001
コメントいただいたように法改正は現実的には難しいですね。
法解釈を示す文書・ガイドラインに機械可読な文書を付けるのではいかがでしょうか。

by ほまるさん - 2020/10/10 09:43 問題を報告

投票履歴 42

法律をわかりやすく
法律記述言語の整備

高評価コメント 9

他のユーザからの評価(★の数)の平均が4以上のコメントを表示しています。

評価の平均値
4
コメント日時
コメントしたアイデア

デジタル政府の実現には専門IT人材が不可欠

CITP認定情報技術者のサイトを確認しましたが、現時点での認定者は「社内資格制度が本制度に適合すると認定された企業」の従業員ばかりとなっているようです。そして「社内資格制度が本制度に適合すると認定された企業」の多くは国の調達案件に入札するような大手です。
一方で、現在デジタル庁の設立に向けての採用では、当該職員が現在所属するか過去2年間所属していた事業者はその職員が関わる調達案件には入札できない、という留意事項がついています。

要するに、CITP認定を保持する人材のうちの多くは、今いる会社に迷惑をかけることになるためデジタル庁の創設に向けた採用には応募できない、ということになりそうです。

民間から起用するとしていながら、国の調達案件に詳しいベンダ側の実務経験者を実質的に弾き出すような留意事項をつけているのはいかがなものか、と思いますが…。理由は理解できますが、デジタル庁に国のシステムの予算や権限を集中させる中で本当にそれで成り立つのか心配です。

評価の平均値
4.5
コメント日時
コメントしたアイデア

データ戦略へのご意見をお願いします!![事務局]

システム屋の観点で思うこと。

・データの構造・形式も大事だが正規化も重要。第三正規形まではやっとかないとデータの整合性が維持できなくなる。
・データのライフサイクルの検討。発生・消去のタイミングを明確にする。例えば死亡した人のデータは何年残す?
・ベースレジストリとして一元管理するのではなく、種類ごとに分けて管理する方が良い。
 ・モノリシックなシステムにするのではなく、マイクロサービスとして設計して必要なタイミングで連携する。例えば個人データと収入・税データ、資格データは分けて管理する。
 ・個人や法人などはマスタデータ、収入・税はトランザクションデータとなる。ライフサイクルも違う。
 ・データの種類によって所管も違うだろうし、分けておいた方が万が一情報流出した場合の影響が限定される
・オープンデータの機械可読性は必須。機械可読じゃないと分析できず活用できない。

評価の平均値
5
コメント日時
コメントしたアイデア

データ戦略へのご意見をお願いします!![事務局]

課題と思うことを挙げておきます。

・例外の扱いを十分に配慮する必要がある。例えば、
 ・男性でも女性でもない人
 ・戸籍を持たない人、住民登録がない人(管理対象外?)
 ・生年月日が不明な人
・ベースレジストリへの個人データ登録が強制かオプトインかオプトアウトか
・個人データ一元管理の合憲性
 ・住基ネット訴訟判決を踏まえる必要があるのでは。
・属性(学歴・資格など)をどう証明するか
 ・個人・法人に対する属性を証明するトラストアンカーと認証パスの構築が必要。国がトラストアンカーとなり、大学とか認定機関に対する認証パスを構築する? 海外の学歴・資格はどうする?
・奇麗でないデータをどうクレンジングするか。そもそもクレンジングしていいのか。
・誰が、何の目的でベースレジストリにアクセスできるのか。参照・更新権限をどう設定するか。
・アクセスに対する監査ログを残す必要がある
・データ活用にあたっての匿名化、プライバシー保護をどう実現するか
・データの鮮度をどう保つか

評価の平均値
5
コメント日時
コメントしたアイデア

デジタル改革アイデアボックス オープン対話について

すでに実現のために動いている、検討しているアイデアが選ばれている印象は持ちました。
政治ですしある程度恣意的に選ばれるのは仕方がないかなと思いますが、次回以降の対話では、これまで検討していなかったけど新しいアイデアとして取り組みたいと内閣官房IT総合戦略室で判断したアイデアや、中身をもう少し掘り下げたいようなアイデアを積極的に取り上げてほしいと思います。

選ばれなかった人の中には「自分のアイデアが選ばれないなんておかしい」「透明性がない」などと思う人もいるでしょうが、そんな文句ばかりが寄せられてしまえば対話の場そのものがなくなってしまうので、少なくともこのような対話が行われたこと自体は歓迎すべきではないでしょうか。

評価の平均値
5
コメント日時
コメントしたアイデア

マイナンバーのワンタイム化

いいアイデアかもしれません。
マイナンバーが秘匿すべき情報とされているのは、本人の預かり知らぬところで勝手に名寄せに使われるリスクがあるから、という点にあります。どういうことかというと、マイナンバーは通常は一生変わらないため、その番号を使って勝手に買い物履歴や図書館で本を借りた履歴など様々な情報を紐づけされると、その人の行動履歴というプライバシーが丸裸にされてしまいかねない、ということです。
ワンタイム化でもいいのですが、例えばマイナンバーカードの更新期限ごとにマイナンバーが変更されれば、そこで一旦は履歴を切ることができるので、一生ついて回る問題にはならないわけです。
つまり、マイナンバーが変わることによってマイナンバーと紐づけられた情報について「忘れられる権利」が実現されるということになります。

そもそも漏洩した場合など正当な理由があればマイナンバーは変更可能ですし、これによって大きなシステムの変更は必要ないはず。
これが実現すれば、マイナンバーは特に秘密にしなくてもよい情報として法改正ができ、事業者やシステム上でのマイナンバー管理も特別な対応が不要になるかもしれません

評価の平均値
5
コメント日時
コメントしたアイデア

ブロックチェーンを国家戦略にしないでください。

賛成です。新しい技術=良い技術 ではありません。
推進派は制約やデメリットに触れていません。

ブロックチェーンのメリットとしては以下のようなことが挙げられます。
・管理主体が必要ない
・改ざん耐性が高い
・システムが停止しない

ただし上記のメリットを享受するためにはブロックチェーンを構成するノードが大規模分散している必要があり、以下のような課題が出てきます。

・ブロックチェーンノードを誰が運用するか。政府管理ならブロックチェーンである必要はない。改ざん耐性や透明性を求めるなら政府以外の組織・団体にも運営に加わってもらう必要がある。
・政府以外の組織・団体がブロックチェーンのノードを運用するのであればそのモチベーションは何か。運用にかかるコストをどうまかなうか。
・ノードが多数の組織・ノードに分散しているとシステムのバージョンアップが困難。
・攻撃者の保有するノードの計算能力が高ければ改ざん可能(51%攻撃)
・攻撃により不正なトランザクションが記録された場合に正しい状態に戻すことが困難。
・情報流出に対して無力、というか積極的に流出させる技術である

評価の平均値
5
コメント日時
コメントしたアイデア

国産クラウドの推進を

AWSやMicrosoft、Googleは自前でクラウド基盤技術を開発しており、クラウドを構成するオープンソースコミュニティへの貢献もしています。それらの企業の研究開発費は年間100億ドル単位(Amazonの2019年のR&Dが360億ドル)です。一方で代表的国内ベンダの2019年度の研究開発費は1,230億円くらいです。約30倍差。
オープンソースへの貢献に関するある調査ではトップ30位に日本企業は一つも入っていません。(Microsoft、Google、Amazonはトップ層にいます)

国内ベンダはオープンソースのクラウド基盤ソフトウェアであるOpenStackを使ってクラウド(IaaS)サービスを提供していますが、OpenStackに対してはどれだけ貢献できているでしょうか…。ほとんどフリーライダーに近い状態では。
またクラウドのベースとなるデータセンターの運用についても、三大クラウドは世界中に大量のリソースを抱えているのに比べると、国内中心の小規模なスケールでしか展開できておらず、運用ノウハウの蓄積もできていません。

それでも国産クラウドを推進したいですか?

評価の平均値
5
コメント日時
コメントしたアイデア

デジタル化にブロックチェーン技術を

文書に対するはんこの代わりになる技術としては電子署名になります。
ブロックチェーンははんこの代用としては適しません。

ブロックチェーンのメリットとしては以下のようなことが挙げられます。
・管理主体が必要ない
・改ざん耐性が高い
・システムが停止しない

ただし上記のメリットを享受するためには、ブロックチェーンを構成するノードが大規模に分散している必要があり、そうした場合に以下のような課題が出てきます。

・ブロックチェーンのノードを誰が運用するか。政府が管理するならブロックチェーンである必要はない。改ざん耐性や透明性を求めるなら政府以外の組織・団体にも運営に加わってもらう必要がある。
・政府以外の組織・団体がブロックチェーンのノードを運用するのであればそのモチベーションは何か。どうやって運用にかかるコストをまかなうのか。
・ノードが多数の組織・ノードに分散しているとシステムのバージョンアップが難しい。
・攻撃者の保有するノードの計算能力が高ければ改ざん可能
・攻撃により不正なトランザクションが記録された場合に、正しい状態に戻すことが困難。

評価の平均値
5
コメント日時
コメントしたアイデア

InternetExplorer(IE)の規制

なぜ公的機関のシステムでIEがよく使われてきたのかは、楠CIO補佐官のブログに詳しく経緯が書かれており、この話題に興味のある方、特に技術者であればぜひ読まれるとよいでしょう。
https://comemo.nikkei.com/n/n1c9103c81c79

マイナンバーカードを使うシステムにおいてブラウザをフロントに使うには、大変に技術的な困難があったことがよくわかります。
ブラウザは時代とともにセキュリティに関する仕様も変わっていくので、マイナンバーを使うシステムではブラウザにこだわらず全てネイティブアプリとして実装したほうがいいのでは、と個人的には思います。

ページの先頭へ