xtech.nikkei.com
上記記事を読んだ感想。
１．自治体システムが多様ゆえに、国は、全自治体が簡単に対応可能なものを用意できない
ある都内の自治体はExcelの手製ツールを使い、申請データと給付対象者リストを突合し、世帯構成人数の一致を確認。作業を省力化した結果、5月20日時点で申請の9割近くの給付を完了したという。郵送での手続きと比べ、1カ月近く早い給付ができた格好だ。
なぜ「うまくいく自治体」と「うまくいかない自治体」に分かれたのか。
ExcelやAccessの手製ツールを自前で開発することができたら、それはベンダーさんに発注して仕様決めてってやるよりも早いとは思う。でも、全自治体がそんなことができるわけでは当然ない。
「どのような自治体でも普通にやればできる」状態に、オンライン申請データを国がしないと、全国民に早く１０万円をふりこむというのはむずかしい。
ただ、どのような自治体でも普通にやれば早く振り込めるというように国がするのは、自治体システムの多様性から難しい。
自治体システムが自治体ごとに違うので、すべての自治体システムに対応するシステムを国が用意することができないし、国はすべての自治体システムを調査しつくすことは不可能ではある。
これをどうしたらいいのか。私のレベルで考えると、この現状は、当面は変えられなそうでもあるとも思う。
マイナンバーに限らず国がなんらかの制度を作ったり変えたりするたびに、２０００ある自治体のシステム改修が一斉に走ったり、条例改正をしたりというのは、全国レベルで見ると、作業量・人件費・外注費がもったいないと思う。
でも、それをどう打破すればいいかは極めて難しい。
自治体システムの仕様統一みたいな話もあるが、それをやっても、あまり効果が出ない気がするし（結局仕様だけ統一されても、実装がバラバラで、そして統一仕様通りにやっていますといいはる様々なパターンのシステムができて、今回みたいなときにはやはりAシステムだとこうでBシステムだとこうで的な問題が発生するのではないかと私は懸念する。そしてそのように十分な効果を発揮しないのに、にもかかわらず標準仕様に合わせてシステム改修する手間・外注費がかかるのではと危惧する。）、
それより抜本的に自治体システムを共通化していくとか、あとは類型化して何パターン化に収めるとか、そもそも自治体が個別にシステムを発注して維持管理するのも、もちろんそういうのが得意で上手な自治体もあるが、難しい自治体もあるだろう。
国が整備して、自治体は使うだけでいい的な感じになると、良いとも思う。
とはいえ、それを実現するためには、莫大な時間と労力とお金と調整が発生して、たぶん難しいとも思う。
そしてもしそれが実現できたとしても、全国一律のシステムではなく、独自のシステムを使いたいという自治体側のニーズが出てくるとも思う。
では、基礎部分は国が整備して、基本ソフトに対するプラグイン的なものは、各自治体の創意工夫でできるようにすればいいかというと、それが実現できれば良いとも思うが、現実的にそれをやるのは難しい気もする。
自治体の方でもうシステムが整備されていて、そこに後から自治体内でもさまざまなシステムが増設され、国の方でも様々な仕組み・政策を入れる際にさまざまなシステムを入れて、つぎはぎつぎはぎで、「今」必要な手当てだけしていたら、今回のコロナみたいな突発事象に対応できる全国的システムというのは難しいわけで。
ただ抜本的改善策も、私のレベルでは思いつかない。本当に難問だと思う。
２．住基ネット判決は事例判決でしょう
マイナンバー制度に基づき行政機関と自治体のシステム間で住民のデータをやり取りする「情報提供ネットワークシステム」には、自治体が持つ住民の氏名・住所・性別・生年月日、いわゆる「基本4情報」を送信してはならないという運用ルールがある。
この裁判で最高裁判所は住基ネットを合憲と認めたが、その根拠の1つに「個人情報を一元的に管理することができる機関又は主体は存在しないこと」を挙げた。
この判決の後に設計され2015年に運用が始まったマイナンバー関連のネットワークシステムは、この判決を元に「個人情報の一元的な管理」を徹底的に避ける仕様となった。
情報提供ネットワークシステムは、マイナンバーすら持っていない。符号（＝デジタルID笑）しかもっていない。
さらに４情報（氏名・住所・性別・生年月日）も持っていない。
これらを持てば即違憲になるかというと、そうではないと思う。だって、住基ネット判決は事例判決でしょう。「個人情報の一元的な管理」って言ったって、なんだっけ、憲法訴訟でいう、目的と手段のレベルが重要。重要な目的達成のためにその手段が必要ということであれば、違憲とはならないでしょう。
４情報もマイナンバーも持たないで、うまく効果が出るのであれば、それはもちろん良いことだけれども、４情報もマイナンバーも持たないせいで、動かない＝実効性がないのであれば、それこそ「お金の無駄」ではないだろうか（情報提供ネットワークシステムの開発費・運用費・保守費）。
ただ、憲法違反とみなされる可能性が少しでもあるような運用を、行政が現場の判断で実施するのは難しい。ここは「政治」の出番であり、立法府である国会の場で打開の道を探ってほしいところだ。
政治にはもちろん頑張ってほしいですね。
ただ、憲法違反の運用を行政がやることってこれまでもありましたよね？
でもまあ、政治が決断して成立した法律を、裁判所が違憲と判断すれば、それは違憲であるわけです。だから、政治が頑張れば済むという問題でもない。
違憲な法律や条例は作ってはいけない。そもそも人権侵害の法律や条例を作ってはいけない。
でも、違憲でない法律や条例は作るべきであって。
行政に×がついちゃうといやだから、政治に判断してもらって、政治が「×（違憲）でも行くぞ」といえば行政はやるということなのか。だったら違憲な法律でも政治が決断すれば閣法で出すの？それはダメなんじゃないのか。
別に違憲じゃないと行政も思っているけど、行政側がほんの少しのリスクを取りたくなく、政治側にリスクを取ってほしいという話なのか。
ちょっとよくわからん。
３．マイナンバーを使えない理由を探すな
では氏名・住所が呼び出せないとして、個人を特定できるマイナンバーを合わせて送信すれば、少なくとも世帯主の突合作業を省力化できたのではないか。
だがこれも、少なくとも行政の判断では実行できない。2015年に施行されたマイナンバー法は、マイナンバーを利用できる事務（法定事務）を法律の別表で厳格に定めているためだ。この表にない事務にマイナンバーを使う場合、新たな法改正が必要になる。
マイナンバーを使えない理由を探さないでほしい。行政府・立法府は立法と法解釈が業務ではなかったのか。法改正が必要ならさっさとすればいいし、法改正しなくてもできますよね。
この点に関して詳しくは以下を参照。
cyberlawissues.hatenablog.com
４．シリアル番号の件
コンビニ発行を実施していない自治体や、コンビニ発行システムを住民情報と切り離して運用している自治体などは、J-LISからシリアル番号の対応表を受け取ったり、コンビニ発行システムからデータを取り出したりして、住民情報とひも付けるなどの対処が必要だった。対処といっても数日～数週間あれば実行できるものだが、その間は目視など手作業での照合を強いられた。
数日ならできると思うけど、数週間かかったら、もう紙申請が開始しちゃうのでは？5/1ぐらいからオンライン申請開始で、そこから数週間かかったら、6月になるのでは？「数週間」って2-3週間ぐらいのことを言っているのか。でもそれでも紙申請が開始しますよね。
オンライン申請を開始した5月1日当初、自治体に証明書のシリアル番号を送るつもりが、受託したITベンダーのプログラムミスで別のデータを上書きして送信してしまったのだ。
同月3日に自治体からの指摘でデータの不整合に気づき、4日夜に修正した。この間、自治体はシリアル番号を使った突合ができなかった。「テストは実施したが、結果的には発見できなかった」と内閣府の担当者は語る。
がーん。
指摘を受けてすぐ修正したこと自体は、良かったと思います。
でも、さらにいえば、シリアル番号がそもそも空欄の申請データがあって、突合キーがないわけだし！ 詳細は以下の２をご参照。
なぜわざわざ署名用のものを利用者証明に変換したのか。利用者証明を打たせておけば、利用者証明が空白のものは少なるなるのでは。既存のぴったりサービスが、ノーログイン→署名用だったのでしたっけ？ 署名用を利用者証明に変換したのがうまくいかず、バグで間違った番号が入っていて、かつ署名用は入れているが利用者証明を入れていない国民からの申請ではシリアル番号が空欄になるわけだし。
この辺りは、発注者側の国と、受注者側のベンダー、双方から、お互いがいない場で話を第三者が聞いてみないと、どうしてこうなったのか、本当のところがわからないかと。
cyberlawissues.hatenablog.com
５．国がシステム改修したのは良かった
J-LISは2020年5月18日に、CSVファイル形式の申請受付データと住民情報データをシリアル番号で照合して給付金台帳データを出力するWindows用ソフトの配布を始めた。だが、その頃には郵送処理の準備を整えた自治体も多く、遅きに失したと言わざるを得ない。
ぴったりサービスの仕様について自治体の要望を聞き取り、6月1日までに口座情報の入力補助など46件の改修を施した。
突合ソフトをJ-LISが配ったのは良かったですね。5/1でしたっけね、オンライン申請開始が。で5/18に配ったんだから、3週間弱なわけで、そこまで遅いわけではないとも、日数だけ見れば思えるとも思う。ただまあ、給付を急がせられている自治体から見れば、早いに越したことはなく、1週間ぐらいで提供してほしいですが。それよりも、オンライン申請自体がGWとか早めにがーって集中したんで、受け手の自治体さんはとても大変だったと思います。突合ソフトが提供されることが最初からアナウンスされていると良かったですね。
あと、ぴったりサービスの仕様を４６件改修したというのも、良いことですね。ちゃんと改善すべき点を改善していることは、評価されることだと思います。ただ、できれば４６件全部とはいわなくても、最初からそういう状態でサービス提供できれば良かったですよね。
こうした方式は民間のITサービスの使い勝手とはかけ離れている。これがデジタルファースト時代の電子政府のユーザーインターフェース（UI）として適切なのか。セキュリティーやプライバシー保護とUIの向上をどう両立させるか。過去の経緯にとらわれて思考停止することなく、民間を巻き込み、ゼロベースで検討すべきだろう。
主題は、セキュリティーやプライバシー保護とUIの向上の両立ではないと思います。
厳しすぎる運用をしているところ（４情報持たない、マイナンバーをHTTPSでも入力させない、世帯員情報を住基と突合させる、署名者と申請者と世帯主の一致を確認させるなど）と、ザル運用をしているところ（オンライン申請で最初ほぼノーチェックだった、エラー多発、自治体がダウンロードしづらい等）が混在しすぎていて、そんなに厳しい運用するなら全部ちゃんと厳しくすればいいし、ザル運用があるのはなぜなのかとか、厳しすぎかザルかの二択ではなく、平均に近づけて、かつレベルを向上しましょう的な話かと思う。
というか、申請を受ける画面だけ作った、入り口だけ作ったけど、申請を受けた後の処理はあまり深く検討しないで、シリアル番号で管理すれば二重給付は防げるはずだから、各自治体システムに委ねようと思ったのではないか、出口というか、受け手からの処理を考えて、入り口も整備しないといけないなと思いました。
