列車ダイヤについて -- ３ー１０９ マイナ保険証の問題をプログラミング的発想で考察する
２０２３年６月５日
３ー１０９ マイナ保険証の問題をプログラミング的発想で考察する
マイナンバーカードを健康保険証としても使う「マイナ保険証」を使った際に、
他人の情報がひもづけられていたという問題が発生しました。
厚生労働省やデジタル庁が一丸となって解決する必要があります。
それとは無関係に、プログラミング的発想でいろいろ考察してみた結果、プログラミングが話題になっている今、
世間のいろいろなことをプログラミング的発想で考察してみるのがおすすめですというのが今回のコラムです。
問題解決のための検証であれば、まず事実を調査しなければなりません。
これは個人では無理です。しかし、プログラミング的発想でいろいろ考察するのなら、
それほど厳密に事実を調査する必要はありません。各種のニュースで聞いた範囲の事実から、
自分なりの考えまとめてみます。まずこれがひとつめのメリットです。
ふたつめのメリットは、物事を抽象化して、一見異なる物のあいだに共通する関係を見つける
くせがつくことです。私は、自分が作っているＡｎｄｒｏｉｄアプリとのあいだに共通する関係を見つけて
考察してみました。東海道・山陽新幹線のダイヤグラムに基づいた列車走行位置を表示するもので、
Ａｎｄｒｏｉｄアプリをつくる前にＰＣでＰｙｔｈｏｎでつくったプログラムでデーターが正しいことを検証します。
列車走行位置
人によって、経理・会計システムとのあいだに共通する関係をみつける人がいてもかまいません。
プログラミングする際にも、事象の分類を辞書型ではなく、タクソノミ（生物の分類法）に基づいて分類するというように
抽象化した概念で考えることがあります。
列車走行位置アプリとマイナ保険証にどのような関係があるか見てみます。
列車は始発から終点まで、それぞれの時刻で指定するひとつの区間に居ます。マイナ保険証の場合、
マイナンバーと健康保険証の番号は、その人が生まれてから現在まで、抜けなく重複なく、一対一に対応しなければなりません。
マイナンバーと現在の健康保険証の番号の対応なら、エクセルのコラムを増やして、健康保険証の番号を追加
すれば出来るかもしれませんが、生まれてから現在まで、ひとりが何個の健康保険証に関連したかには上限がありません。
データーベースでは一般に異なるアプローチをとります。
ひとつのテーブルに個人とマイナンバーの一覧を持たせます。他のテーブルに健康保険証の番号と関連する情報を持たせます。
そして、マイナンバーと健康保険証の番号と関連する期間の情報を持ったテーブルをつくります。
関連データーベースと呼ばれる製品ではこのような構成にします。
列車走行位置アプリでは、次のようなことを検証します。
まず始発から終点まで、それぞれの時刻で抜けなく区間が指定されているかどうかです。
区間の境界で、指定を間違えると、何秒間か表示されなくなったり２重に表示されたりします。
続いて、ふたつの列車が同じ区間に入っていないかどうかを検証します。検証方法はまず２４時間について１秒毎に
列車の番号と区間の番号を対にした配列をつくります。ＰｙｔｈｏｎのＮｕｍＰｙ Ａｒｒａｙのライブラリーで、
要素が固有な配列をつくる機能があります。元の配列と要素数が同じならオーケーで、区間の番号が同じで列車の番号が異なる
配列がみつかったら、ふたつの列車が同じ区間に入っていることになります。
列車の番号と区間の番号を対にした配列で要素が入れ子に間違えていると、この方法では見つけられませんが、
作る過程を考えるとほとんど発生する可能性がないので無視しています。
マイナンバーと健康保険証の番号と関連であれば、最年長の人の年齢を考えて１３０年前からかあるいは健康保険制度が
開始された時から考えられる何十年分かのデーターで、マイナンバーと健康保険証の番号の配列を一日毎に作って
同じ方法で検証すれば、関連付けられていない人、同じマイナンバーにふたつの健康保険証の番号が紐付けられているもの、
ふたつのマイナンバーが同じ健康保険証の番号に紐付けられているものが、抽出できます。
マイナンバーと健康保険証の番号の関連が入れ子に間違えているものはこの方法では見つからないので、
他の方法を考えて、現在と過去のすべての日のデーターについて、マイナンバーと健康保険証の番号の紐付けが正しいことを
検証する必要があります。一対一に対応しているだけでなく、対応が正しいことを検証する必要があります。
列車走行位置アプリでは、列車が通過する前にあらかじめポイント（分岐器）が正しく設定されていなければなりません。
マイナンバーと健康保険証の番号と関連ではこのようなことはありません。
ポイントの設定に関しては、実際の列車運行管理システムを考慮して作成していますが、大幅に簡素化しています。
まず、実際の列車運行管理システムでは線路をおよそ１．５ｋｍの間隔で区分し、列車の走行速度によって、
３０ｋｍ/ｈなら、すぐ後ろの区間に入っても良いが、２７０ｋｍ/ｈなら、３区間開けないといけないなどの
決まりがあります。ポイントが列車が通過する何秒前までに設定されていなければならないかも、
列車の走行速度で異なります。アプリの検証でこのままの設定にすると、非常に複雑になります。
複雑なまま、検証を進めると見逃しが出るので、大幅に簡素化するかわりに検証での見逃しは無いようにしています。
どのように簡素化しているかというと、線路をおよそ３．０ｋｍの間隔で区分し、同じ区間に入っていなければ良いことに
しています。ポイントの設定も列車が通過する３０秒前までに設定されていたらオーケーで、可能な場合は
６０秒前に設定することにしています。
実際の列車運行管理システムでは線路をおよそ１．５ｋｍの間隔で区分し、２７０ｋｍ/ｈなら、３区間開けなければならない
というのはものすごく重要な意味があります。新しい新幹線の車両をつくって、非常ブレーキで、
４ｋｍ以内に停止できなければならないので試験を重ねます。４ｋｍ以内で止まれば脱線しないということではありません。
４ｋｍ以内に停止できれば、前の電車に衝突して２重衝突事故になる恐れを排除できるからです。
このように重要な規定ですが、アプリでは、省略しています。
この概念がマイナポータルのシステムにどのように関連するか考えてみます。
どのように考えても良いのですが、アナログな業務手順をそのままシステム化してはならないといえます。
まずシステムに最適な業務手順を考える必要があります。
公金受取口座の設定の例では、マイナポータルの名前にはふりがながなく、銀行口座の氏名はカタカナのみという
ことが問題になります。業務をシステム化する前に、業務にくわしい人と、システムにくわしい人が
検討して、システムに最適な業務手順を考える必要があります。
東海道・山陽新幹線では、別の会社であっても、従来のコムトラックのシステムで１っ箇所で運転司令を行なっています。
九州新幹線が開業しても、博多総合車両所までは、コムトラックで管理するのも従来どおりで、ＪＲ九州の
人が東京総合指令所に常駐し連絡にあたっています。北陸新幹線では、コスモスのシステムは大宮センターに設置し、
司令は会社毎に行い、ＪＲ西日本は金沢総合指令所で行っています。京急は、路線距離だけで考えるなら、
運転指令所は１っ箇所でも可能ですが、従来どおり４箇所の指令所を維持し、デジタルと一部アナログ併用の
業務を行っています。
マイナンバーカードであれば、地方自治体の窓口で行うこと、コンビニのマルチファンクション端末で行うこと、
マイナポータルのネットで行うこと、サポートセンターの電話オペレーターが行うことの連携をとることが重要です。
列車運行管理システムは信頼性の高いシステムですが、１５年位前に、運行管理システムの問題で、
半日間ＪＲ東日本のすべての新幹線が止まったことがあります。前日に雪が降ってダイヤが乱れたことと、
人的ミスが重なって起きました。その対策として、東北新幹線の車両の種類を減らして運用を単純にするという対策をとりました。
システムの入力ミスが原因だから注意しますとか、点検しますというような対策ではなく、
全社的な業務手順を見直して、問題の再発を防ぎました。マイナ保険証の紐付けに関して、各自がマイナポータルに
ログインして、数分で確認できるという発言がありました。確認したほうがよいし、問題ない発言に見えますが、
じつは重大な問題があります。各自が確認できるのは、自分の保険証が自分のマイナンバーに紐付けられている
事です。他のマイナンバーにも自分の保険証が紐付けられていないことの確認は自分ではできません。
海外の犯行グループが日本の長期居住者をよそおって、誰かの保険証を紐付けて犯罪に使うかもしれません。
組織として責任をもってすべてのマイナンバーと健康保険証の紐付けを過去の分も含めて検証するという
決意表明が必要です。行政のデジタル化の問題はシステムの問題ではなく、業務・組織すべてにかかわる
問題だという認識がなく、行政組織全体としてマイナ保険証の問題や行政のデジタル化の問題を解決する
気概が感じられません。民間のキャッシュレス決済などのシステムであれば、信頼を失うとシェアを失うという
歯止めが働きますが、国家が独占するシステムにはこの歯止めがありません。情報の開示とすべての利用者に
よる監視が必要です。国家が独占するシステムであっても、サイバーテロに国境はありません。
情報の誤謬と不正やサイバーテロのような犯罪は別物です。しかし、処理結果に疑問があった時、よくある
誤謬だろうと思って対処するのと、誤謬は無いはずだから、サイバーテロの可能性を検討するのでは
システムの耐性に大きな違いがでます。行政機関のトップの姿勢が問われます。マイナ保険証の問題をみていると、
システムの問題ではなく、縦割りの弊害がある行政組織を温存したまま、その仕組みをデジタル化したことで、
問題が顕在化したという印象です。問題が顕在化したことを好機ととらえて、徹底的な改革を行う
覚悟が必要です。失われた３０年と言われながらも、民間組織は海外からのベスト・プラクティスの受け入れを
検討してきました。行政機関は特別の存在ではなく、問題が顕在化したことで、改革を成し遂げる好機と
捉え海外の事例も参考に改革を成し遂げるべきです。プログラミング的発想で、一見異なる物のあいだに共通する関係を
見つけるならば、マイナ保険証の問題と消えた年金問題は非常に類似性があることに気づきます。
消えた年金問題が、過去の年金記録をすべて明らかにして解決したのなら、１５年後のマイナンバーが
使える時代に、マイナ保険証の問題が解決しないわけがありません。会計検査院も、会計経理・財務報告に関わる
内部統制のみならず、すべての報告に関する内部統制の検査を始める好機ととらえ、問題が発生している今、
関係する機関で実地検査をおこなって問題の解決を確認すべきです。
公金受取口座に本人以外の名義の口座を紐付けられることは、認知症の人の年金を受け取る口座を
無断で変更するなど、消えた年金以上の混乱をまねくおそれがあります。
マイナンバーカードの使用が義務なら、国が賠償を含むすべての責任を負うべきだし、本人の選択で
使用する上での責任も本人にあるなら、責任持って判断できるすべての情報を開示すべきです。
会計検査院は検査を通じて、マイナンバーカードが公共の福祉の増進に資するものであることを
検査で得られた証拠で明らかにすべきです。出来ないなら、会計検査院法 を改正すべきです。
行政のデジタル化はシステムの問題ではなく、すべての行政組織が取り組むべき課題です。
デフレと最近のインフレが話題になっています。
ハイパーインフレが問題になる国があるので、デフレはそれほど悪いこととは思っていませんでした。
しかし、消費者サイドではなく生産者サイドに注目するとやはりデフレは悪いことです。
低金利で資金調達できると、借入金を運転資金にして、生き延びようという企業が増えてきます。
やはり借入金は資本コストを考えたうえで、それでも収益が確保できるという新規事業の設備投資にあてなければ
なりません。高度成長の時代は、石炭から石油、繊維から自動車というように、産業構造の変化もありました。
しかし、失われた３０年といわれるようになり、既存の産業を守るという面が強くなりました。
社会の活力のために新規産業は必要です。ＮＴＴのＩＯＷＮ構想は、単に６Ｇというだけでなく、
回路やモジュール内も電子の動きでなく光で情報伝達することで、大幅な少電力化を可能にする
画期的な技術です。海外展開も含めて、将来の日本の中核となる技術基盤に育てるべきです。
ルーズリーカップルドのマルチ・プロセッサーどおしを光伝送で結ぶ技術はＩＢＭが持ってましたし、
インテルもモジュールどおしを光伝送で結ぶ技術を研究しています。ＩＯＷＮ構想を基礎技術の研究
で終わらせることなく、世界的にビジネスとしてどのように展開するかが鍵です。
デフレ・インフレに関連して、１メートルは１メートルというようなデフレもインフレもない世界が
実現しないのかと思っていました。経済学は勉強したことがないのでわかりませんが、
会計学の世界では、世界的に１メートルは１メートルというような基準があれば、
外国為替に関して、ローカル・カレンシー 、オペレーテイング・カレンシー、レポーティング・カレンシーというような
議論は不要になります。貨幣とはというような何とでもいえそうな議論（個人の感想です）を
展開する能力が、プログラミング的発想を身につけることで得られます。
ウクライナの戦後復興のために、新幹線をＯＤＡで建設するのは良いアイディアです。
ウクライナは、ロシアと同じ間隔の軌道から、標準の軌道間隔に変更する計画があります。
地上設備・車両設備一式で導入するチャンスです。
世界銀行からお金を借りて、戦後復興の仕上げともいえる新幹線を建設しオリンピックを開催した日本が、
長期の有償資金協力で新しい鉄道を建設するといえば、反対する国はほとんどありません。
ウクライナも日本も他国を侵略することも、世界の警察官になることもありません。他国からの侵略に
対応する自衛力をいかに整備するべきか、日本がウクライナから学ぶことは多くあります。
侵略しようとする側は、詳細な３Ｄマップと多数のカメラ画像を持った自動運転のクルマや民間ドローンに、
ネットワーク経由で侵入して、攻略の計画を立てるのではないかと思うのですが、
自衛力の整備について、直近で実戦を経験した、ウクライナから学ぶべきです
生成ＡＩについて懸念するよりどちらかというと、成果に期待する方なのですが、
検索連動型広告が、これからは、生成ＡＩの回答の文書のなかに購買意識を向上させるような文書を
組み込むとか、ステルス生成ＡＩ回答文広告の可能性を考えると、つねに動向に注目し、
プログラミング的発想で考察する必要があります。
リスキリングが流行です。暇ですから、私もＶｅｒｉｌｏｇ−ＨＤＬでＦＰＧＡの回路設計をするようになりました。
成果はでていませんが、おもしろくなってきました。回路合成のあとシミュレーションをしてタイミングチャートで
検討するのですが、鉄道のダイヤグラムをみている感覚になります。
鉄道のダイヤグラムも、例えば新大阪駅の２２番に到着した新大阪終点の列車は、３６分０秒に博多行の列車が
２１番線に到着したあと、３６分１５秒に鳥飼基地に回送し、博多行の列車は２分停車で、
３８分０秒に、九州新幹線からの８両編成の列車が２０番線に到着するのと同時に発車するというように
ダイヤグラムと実際の列車の運行を見比べると楽しくなります。以前は、Ｓ／Ｗは０，１の世界、Ｈ／Ｗの電気的特性は、
動かしてみるまでわからない感じでしたが、ＡＩのＳ／Ｗはデーターを入れて動かしてみるまで、結果が予測できず、
Ｈ／Ｗの論理設計が０，１の世界になり、ＨＬＳ（Ｈｉｇｈ Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ）のように
Ｓ／ＷとＨ／Ｗに境界がなくなっている面があります。
趣味でプログラミングをやってみようという人も増えています。子供がスクラッチを勉強するので、
一緒にやってみるという人がいます。良いことです。大人がひとりでプログラミングを始める時は、
スクラッチは、大人がピアノの「バイエル」をやるようでつまらないという人もいます。
パイソン（Ｐｙｔｈｏｎ）がお薦めです。解説の本を買ってきてサンプル・プログラムをダウンロードして
動かすと動きます。そこで止まってしまう人がかなりいます。
何か自分でやりたいことを見つけて、プログラミングをすると、英語のエラー・メッセージがでるので、
あきらめたという人がかなりいます。
そこでお薦めなのが、このコラムで述べた世間のいろいろなことをプログラミング的発想で考察してみることです。
これなら実際にやっているかどうかは他人にはわかりません。自分でやっていると言えばやっていることになります。
これが、３つ目のメリットです。
そして、どうみても自分のプログラミング的発想は愚の骨頂で、考えれば考えるほどワヤになるという人は、
他の人に、「この課題を、今はやりのプログラミング的発想で考察するとどのようなことが見えてくるだろうか」と
質問します。
プログラミング的発想、おすすめです。