Dockerが面白い

ここ1ヶ月ほど、Linuxに熱中しています。

だいたい10年に1回くらいの周期で「Linux熱」がやってくるのですが、これまでは「Windowsの代わり（デスクトップ用途）にするにはまだ早いかな……」という結論に至り、いつの間にか熱が冷めるのがお決まりのパターンでした。

しかし、今回は少し違います。きっかけは「Pleasanter（プリザンター）をLinuxで動かしてみたい」という、サーバー用途での興味でした。

Dockerとの出会いで変わったLinux体験

実際にやってみて驚いたのが、Dockerの便利さです。 Docker Engineさえ入れてしまえば、環境構築が驚くほどスムーズ。Windows版よりもずっと簡単に構築できました。

Dockerの何が良いかというと、「本体の環境を汚さない」「コンテナは使い捨て。再構築も簡単」という点に尽きます。この手軽さに魅了され、今ではいろいろなツールを試しています。

• Nextcloud（オンラインストレージ・予定表・オンライン会議）

• WordPress（ブログ・サイト作成）

• Minecraft（統合版）サーバー

今回は、その中でもネット上に意外と情報が少なかった「Minecraft 統合版（Bedrock）サーバー」の構築手順をメモとして残しておきます。特に設定ファイルの扱い（手順1）で迷っている方の参考になれば幸いです。

---

Docker ComposeによるMinecraftサーバー構築手順

0. 前提条件

• インターネットに接続されていること

• Docker Engine / Docker Compose がインストール済みであること

• プロジェクトディレクトリ（例：minecraft）が作成済みで、そこを作業ディレクトリとしていること

1. 各種設定ファイルの用意

カレントディレクトリに、データ保存用の bedrock ディレクトリを作成します。アローリストや権限設定を行う場合は、あらかじめファイルを用意して配置しておくのがスムーズです。（server.propertyの内容は後で作業します）

1. bedrock ディレクトリを作成

2. その中に allowlist.json および permissions.json を作成して配置

2. compose.yml の作成

以下の内容で compose.yml を作成します。 environment セクションのコメントアウトを外すことで、server.property同様、サーバー名やゲームモードなどの詳細設定を反映できます。

参考記事：

Minecraft Bedrock Server を Docker で構築する（Official）

 

services:
  bedrock:
    container_name: mc_bedrock # なんでもよい
    image: itzg/minecraft-bedrock-server
    tty: true         # ターミナルの割り当て（-t オプション）
    stdin_open: true  # 標準入出力ストリーム（-i オプション）
    environment:
      SERVER_NAME: "Bedrock Server" # なんでもよい
      # 詳細設定が必要な場合は以下のコメントを解除して編集
      #GAMEMODE: "SURVIVAL"
　　　#FORCE_GAMEMODE: "TRUE" # 基本的にTRUEで
      #DIFFICULTY: "EASY"
      #ALLOW_CHEATS: "FALSE"
      #MAX_PLAYERS: 10
      #ALLOW_LIST: "FALSE" #まずはFALSEで動作確認
      #SERVER_PORT: "19132" #変更したい場合は下のports:で変更するためここは変更しない
      #ENABLE_LAN_VISIBILITY: "TRUE"
      #VIEW_DISTANCE: 12
      #TICK_DISTANCE: 4
      #PLAYER_IDLE_TIMEOUT: 30
      #MAX_THREADS: 8
      LEVEL_NAME: "lv1"
      EULA: "TRUE"    # 利用規約への同意。かならずTRUEで
      VERSION: "LATEST"
    ports:
      - 19132:19132/udp # ポート番号を変更したい場合は前の番号を変更
    volumes:
      - ./bedrock:/data
      - /etc/timezone:/etc/timezone:ro
    restart: unless-stopped #alwaysでも良い。お好みで。

構築を終えて

あとは docker compose up -d を実行するだけ。 サーバーがこれほど簡単に立ち上がるのはDockerならではの面白さですね。次は何をコンテナ化してみようかと、今回のLinux熱は当分冷めそうにありません。

マイナンバーカードを用いた運転免許証更新のオンライン講習を受講しました

先日、運転免許証更新時のオンライン講習を受けました。
その結果、交付当日の免許センターでは、

	これまで	今回
何時に行くか	朝イチ	15:30
所用時間	ほぼAMいっぱい	20分くらい

と劇的なユーザー体験をしました。

免許更新手続きは、申請書記入→証紙購入→視力検査→講習→免許証交付という流れですが（運用では視力検査を証紙購入より先にしているみたいですが）、このうち、講習を好きな場所で好きな時間にオンラインでできるというものです。

マイナンバーカードをスマホで読み取る必要があります。
スマホとMNCの位置関係が非常にシビアなのが難点ですが、試行錯誤すればなんとかなります。
時間にして約30分（優良の場合）ですが、途中に自分の顔写真の撮影タイムがあり、カラ視聴を抑止しているようです（免許証交付手続きの際に旧免許証の顔写真と照合しているようです）

現地講習は講習時間が決まっています。
ある時間帯の講習が埋まっていたら次の時間帯の講習まで待たねばなりません。
それを踏まえて即日交付を希望するなら14:00までに受付を終えておくことになっています。
いつもは朝イチで行って終わったら昼でした。半日仕事です。

今回は15:30に行きました。ガラガラに空いていました。

北海道・千葉県・京都府・山口県でモデル事業としての取組みですが、早く全国に広がるといいですね。

Pleasanterがすごいかも

1年半ぶりくらいにブログ書きます。なかなか時間が取れず・・・。

地方自治体のDXに関わっていますが、結構、情報共有・集約にExcelを用いているがうまくいっていないというケースがあります。例えば、

• 出先機関からExcelファイルをメールで送ってもらい、本庁で手作業でコピペしているが、出先機関の数が多くて面倒
• 共有ファイルサーバにExcelファイルを置き、職員に入力してもらうが、同時編集できないため待ちが発生している

というものなどです。前者はメール提出ではなくファイルサーバに置いてもらい、マクロなりRPAで集約するという方法もありますが、後者とあわせて考えると、そもそも「Excelで管理」がどうなのよ？というところです。Excelは表計算ソフトであり、本質的にDBではありません。｢できなくはない｣程度のものを主機能のように使用しているので、不便なのは当然なのです。Excelが機能不足なのではありません。

したがって、データベースを使用すべきであり、利用者にブラウザでアクセスしてもらうということを考えることになります。

このような場合、有名なのはサイボウズ株式会社様のkintone（キントーン）です。インターネットだけではなく、官公庁が使用しているネットワーク（LGWAN）内でもサービスとして利用できます。構築も比較的簡単です。マクロどころかExcelの関数より簡単かもというレベルです。

さて・・・最近、このノーコード・ローコード業界で、株式会社インプリム様のPleasanterというツールが存在感を増しているようです。弊社もデモ環境を試用させていただきましたが、あまりにも感動したので試用期間開始後まもなく契約してしまいました（後述と矛盾しますが、別要件でクラウド版が必要だったためです）。

特徴としては・・・

• アプリ構築が簡単（かつ、複雑な作り込みも可能）
• ユーザ単位課金ではない（スタンダードプラン除く）ため、規模が大きいほど費用対効果が高い
• 機能に制限はあるものの、3ユーザまでなら無料、10ユーザまでなら月1000円のプランもあり、小規模企業にも優しい
• オンプレミスでも構築可能で、サポート不要なら、ほぼ無制限かつ永久無料
• 有償サポに加入すると開発キットが提供され、改造して自社製品として販売可能みたい（一部ベンダーはやってるみたいですね）
• 有償サポは年180,000～と、この手のものとしては格安

この中で重要なのが、オンプレミスで構築可能（なんなら無料で）という部分です。WebサーバやSQLサーバーも構築する必要がありますが、行政機関内のみに閉じたシステムにすることが可能です。当然、インターネット側に構築して施設予約システムに使用したり、ということもできます。

セッアップマニュアルが充実しているので、オンプレミス構築はそれほど難しくはありません。弊社も試しにノートPC・ミニPCに構築してみましたが、きちんと動きました。

もしかしら、kintoneに代わってデファクトスタンダードになるかもしれませんね。

役所のDXを考えたい（第4回「マイナポイント」）

皆様は公的分野のデジタル化についてはどう捉えていますでしょうか。
「デジタル化が遅れてる」「そもそも非効率的」
というイメージ・経験をお持ちかもしれません。

この連載では、私が役所生活で経験したことのうち、特にデジタル化を阻む要因と感じたものを取り上げていきます。これにより、
「なぜそうなのか」「ではどうしたらよいのか or 難しいのか」
について、皆様の理解を深めていただく一助になれば幸いです。

第4回の今回は「マイナポイント」です。

マイナポイントとは

R4.6.30からマイナポイント2弾が開始されました。
マイナポイントとは、マイナンバーカードを作り所定の手続（長いので省きます）をした方が、最大2万円分のキャッシュレス決済のポイントがもらえるというものです。
当初は「R3.3末までにカードを申込み、かつ、R3.9末までに所定手続を済ませることで、最大5,000円分のポイントが貰える」（その後、4月末まで申込、12月まで手続きに変更）というものでした（第1弾）。
しかし、思ったより発行枚数が伸びずさらなるテコ入れとして、上記の期限を撤廃し、かつ、ポイント対象となる手続を増やして合計最大20,000円分のポイントが貰えるようになったものです。

カード交付の裏側

長いので結論を先に書くと、マイナンバーカード導入により、住民登録の現場の業務はかなり増えました。

あまり知られていませんが、カードはJ-LIS（地方公共団体情報システム機構）で作成され、各市町村に送られてきます（市町村では作成していません）。

受取ると、カード1枚ごとに該当者を端末で検索し、カードが役所に届いたことをカードとサーバに記録します（他にもありますが省略。なお、この処理、一頃よりは早くなったそうですが書込み命令を出してから1分以上かかります）。

そして、カード受取案内ハガキを発送します。市民が受取に来た際に迅速に出せるよう保管用IDをカード収納ケースとハガキに記載する必要があります。
カード自体を発送する場合もありますが、その場合はさらに暗証番号書き込みの処理が別途必要です（また検索から）。この辺のフローの違いは省略します。

市民がカード受取に来庁されると、カードを取り出してきて、端末で検索（カード作成時点と住所・氏名に変動がないか確認とか、再交付有無とかいろいろ確認することはあります）、カードに暗証番号を設定してもらい、カードとサーバに交付状態であることを記録して終了です。

交付した後も、住所変更や婚姻・離婚等のたびにカードの変更（裏書もＩＣチップ内も）もあります。電子証明書の有効期限切れによる更新業務もあります。もちろん、マイナンバーカード普及前は一切なかった事務です。減った事務はありません。
カードを使った市外転入の入力処理は楽になりましたが、カードの住所変更処理の方が長くかかるのでトータルで減ったフローはありません。

カード普及の目的

前述のとおり、住民登録の現場についてはカード普及につれ行政コストは上昇傾向にあります。
したがって、その分、他の行政部門をスリム化し国全体でプラス効果を産み出す必要がありますが、カード普及と行政の効率化はどのように結びつくのでしょうか。
ここでは、マイナンバー付番による行成効率化と、カード普及によるそれは分けて論じる必要があります。前者だけならカードを普及させる理由にならないからです。

マイナンバー制度の目的は、税・防災・社会保障ですが、いずれも本人同一性確認でしょう。「必要な人に必要な支援を届けるため」という言い方もあるようですが、所得隠しの防止、市町村を跨いでの給付金二重受取の防止、所得がなくても資産がある人には適正負担を求めるなど、「必要のない人に過度な支援をしない」という面の方が大きそうな気もします（今のところ完全には実現はしていませんが、目指すのはそこでしょう）。財源には限りがありますから、後者は前者の手段とも言えるわけで、全くの筋違いというわけでもありません。ただ、これはDBにマイナンバーが付番されていればできるハナシです。カード普及とは特に関係ありません。

では、どうしてもマイナンバーカードでなければならないシーンは何でしょうか。それは電子証明書の格納媒体としての役割です。大雑把にいうと厳格な本人（意思）確認とオンライン手続の両立です。

オンライン申請が普及すると市民は窓口に行く必要がありません（行政は対面対応が不要となります）。また正しくUI設計すれば手書き申請に比して正確な情報を入力させることができ、事後チェックがスムーズになります。住民対応コストが減少し、それにより余ったリソースをオンライン手続ができない情報弱者と呼ばれる方たちへの支援に回すことが可能になります。

つまり、オンライン申請の普及は、できない人にとっても望ましいものであリ、これこそがマイナンバーカード普及の目的であるべきです。

オンライン申請を装った窓口申請？

他の回でも触れましたが、マイナンバーカードはデジタル社会のパスポートたるべき存在であり、社会全体に恩恵を齎す可能性を秘めていることから普及を図るべきです。
本来は利用シーンを増やすことでカード自体の魅力を高めることが肝要なことは言うまでもありませんが、将来的なコストパフォーマンスが見込めないから利用手続きが増えない（予算がつかない）、利用手続きが増えないから便利にならずカードが普及しない、の堂々巡りを断ち切るため、一時的にマイナポイントのような経済的インセンティブによる普及策を採るのは已むを得ないかな・・・と思っています（5,000円でダメなら20,000円、には驚きましたが、驚かせるくらいじゃないと効果は薄い、と判断したのでしょう）。

そのマイナポイント申込ですが、先日、私が住んでいる札幌市から画像のようなLINEが来ました。
マイナポイント手続の急増によりJ-LISのシステムが動かなくなり、全国の役所のマイナポイント申込窓口で対応できなくなった件です。
J-LISのシステムの弱さについては報道されてない部分も含め度々現場で見てきましたが、今回、論じたいのは申込窓口の件です。

マイナポイントの申込手続はすべてオンラインで行う必要がありますが、自力でできない方でも安心してカードを取得してもらえるよう、国が自治体に支援窓口の設置を指導しました。
市町村は民間業者等に委託し窓口を設置し、業者は窓口で市民の申込支援を行います。
国から補助金（たぶん100%）が出るので、わざわざ節約して自前でやるところはないでしょう。地域経済のためにも。
支援内容ですが、

• サイトへのアクセス
• カードの読込（スマホまたはPC）
• ポイントを付ける決済サービスの（画面上の）申込処理

などのいずれか、あるいは全部（結構いると思います）を行っているのでしょう。支援というより一部手続代行に近いのが実態かもしれません。
（暗証番号入力はさすがに自分でやってもらってるでしょうが）

さて、カード普及の目的は、オンライン申請の普及により社会全体を良くするためであるべき、という話をしました。
また、マイナポイントについては、カード普及のためにやむを得ない旨も述べました。
つまり、マイナポイントの目的は「（カード普及を通じて将来的に）オンライン申請の普及により社会全体を良くするため」であるべきです。
「オンライン申請用の窓口を設け、そこで（本人ではなく）担当者が処理をする」は、オンライン申請を装った窓口申請で意味がありません。

政府はデジタル化に「誰も取り残さない」としています。できない人に不利益があってはいけません。ですから、誰もがデジタル化についていくための機会を提供することが重要です（機会平等）。デジタルスキルが平等（結果平等）である必要はありません（無理です。そんなスキル要らない、という方も一定数残るでしょうし）。
「できる人はよりお得に、できない人はそれなりに」で構わないのです。

したがって、支援窓口は「申請の仕方を教室のように教える」ものであるべきです。
膨大な費用をかけてカード普及率は上がったとしても、オンライン申請のやり方を聞くため（というよりオンライン申請を代行してもらうため）に窓口に来庁するような人を増やしてどうするのでしょうか。それって行政コストは下がらないですし、自力不可だった市民自体も全然便利になってませんよね。

時々、レジで今使う分だけチャージしその電子マネーで払う人を見ます。
んなコトするくらいなら現金で払え、とレジ担当者も後ろに並んでいる人も思ってるでしょうね。いや、本来、これはレジでチャージ可能なのが間違っており、レジに並ぶ前に自力でチャージできる手段を用意せねばなりませんし（できればオンライン）、それができない人は諦めてもらうべきです（単に「わからないモノには手をだすな」です）。それと同じことです。

この点、税務署は（良くも悪くも）すごいですね。確定申告時期、税務署の周りに車がどれだけ渋滞し階段にどれだけ行列ができようがお構いなしです。「自宅でe-Taxでやれ」「出来ない人は並べ。e-Taxが普及すれば行列も減るハズだから」という思想なのでしょう。おそらく国の「署」だからできることであって市町村の「所」だとクレーム多数で無理な気もします。
結局のところ、DXを阻むものは日本人の意識なのかもしれません。

役所のDXを考えたい（第3回「ハリボテDX?」）

皆様は公的分野のデジタル化についてはどう捉えていますでしょうか。
イメージとしては、
「デジタル化が遅れてる」「そもそも非効率的」
さらに実際に役所のシステム開発に携わった民間企業の方であれば、
「カスタマイズ多すぎ」「要件が後から後から出てきて、手戻りが多い」
という経験をお持ちかもしれません。

この連載では、私が役所生活で経験したことのうち、特にシステム化を阻む要因と感じたものを取り上げていきます。これにより、
「なぜそうなのか」「ではどうしたらよいのか or 難しいのか」
について、皆様の理解を深めていただく一助になれば幸いです。

第3回の今回は「ハリボテDX」問題です。

住民票のオンライン請求

例として、一部自治体が導入している住民票のオンライン請求を考えてみます。
マイナンバーカードの署名用電子証明書（6～16桁のパスワード要）を用いて、自分の住民票を郵送で取寄せできます（手数料はクレカ払い）。一切、窓口に行く必要がありません。

市民にとっては・・・まぁ便利ですね・・・
コンビニ交付システム（因みにこっちは4桁の暗証番号）と二重投資な気もしますけど、あって困るものではないので、利用者目線ではこれをどうこういうつもりはありません。
また、 DXに関する費用対効果は将来を考慮すべきで現時点の状況のみで評価すべきではありません。将来性については後述します。
では、自治体職員としてはどうでしょうか。

住民票を郵送するまでの事務フローがどうなるかですが、理想は、

• 電子申請すると、自動でAPI連携し、一定時間までに役所のプリンタから証明書と宛名用紙がセットで自動印刷（プリンタ内に残して業務終了しないようある程度の余裕をもって締め時刻を設定）
• それらのセットを間違えないよう確認して窓あきの料金後納封筒に入れて発送する
• 電子申請の進捗管理システムに発送日を登録（請求者がネットで進捗状況を確認可能なように）

となります（あくまでも郵送前提の中での理想像です。後述しますが、そもそも、郵送不要な電子的手段による住民票(?)発行まで行かないとDXとは言えません）。
最悪なのは、

• 電子申請の有無を職員が一定時間ごとにシステムを確認
• あった場合には請求書として印刷（ない場合はその行為が無駄）
• 印刷された内容を目視しながら業務用端末で検索し、住民票をプリンタから印刷
• 封筒を用意して宛名を手書きし、申請書と住民票と封筒宛名を再確認
• 郵送受付簿に記入して発送

です。
何が最悪なのかというと、通常の郵送請求と事務フローが複線化してしまう点です。それもかなりの部分まで。ざっくりいうと、

• 郵送請求の場合、書類不備があると連絡しなければならない
• 電子申請の場合、書類不備はない（電子証明書で本人確認を行い、券面入力補助情報を使えば間違い入力は存在しない）

• 郵送請求の場合、手数料が同封されてくる
• 電子申請の場合、手数料は同封されてこない（クレカ決済）

• 郵送請求の場合、宛名を書いて切手を貼った返信用封筒が入っている
• 電子申請の場合、切手も返信封筒もないため職員が用意し、宛名を書かねばならない

という違いがあるため、最終的には郵送するのは同じでも、なかなか郵送申請分と事務フローを統合できません。書類を混ぜてしまうと、
「あれ、この申請、本人確認書類がないぞ？ あ、電子申請か」
「あれ、この申請、手数料が入ってないぞ（以下、略）」
「あれ、この申請、返信用（以下略）」
と見るたびに判断が必要となりますし、郵送受付記録簿（通販している会社の方ならわかると思いますが、いつ届きますか？ というお問い合わせが結構あります）にも電子申請である旨書かねばなりません（受付記録簿を分けるのなら、そこまで書類を分けておかないと事務が大変です）。
つまり混ぜても問題がない部分までは事務フローを統合できません。

「過渡期だからしょうがない、郵送申請より電子申請が広がれば良くなる」という反論があるかもしれません。本当に良くなるのでしょうか。
実は、電子申請の方が「申請有無の確認」「返信用封筒の作成」という２つの手間が増えています。
つまり、この電子申請が増えると内部事務は非効率化していきます。こんなのはDXではありませんし、デジタルによる効率化とさえも言えないでしょう

そしてハリボテに至る

そんなわけで、住民票請求に限りませんが、役所のオンライン申請フォームを見て「我が町はDXに取り組んでるな」と思っても、実は「カタチだけDX」「ハリボテDX」は皆さんが思っているより多いと推定します（R2のコロナ給付金騒ぎの時はボロが出たんですけど、あまり状況は変わってないと思います）。
しかし、役所はサボっているわけではありません。実は、

• 総務省の三層分離モデルにより、自治体においてはインターネット接続系とマイナンバー利用事務系のネットワークは分離されており、電子申請データを自治体の住民記録システムに自動API連携するのは無理

というのが一番大きいと思います。
これ、セキュリティ過剰じゃないかと思われるかもしれませんが、自治体数は多いためどこから穴があくかもしれないですし、総務省が心配するのも理解できます。
なので、

• 市民がカードを使って役所へ手続きするものはすべてマイナポータル経由にする
• マイナポータル → LGWAN → 自治体マイナンバー利用事務系 と申請データを流してAPI連携

としてはどうかなと思っています。
特に自治体マイナンバー利用事務系は、近い将来、標準化により国が用意するクラウド上に構築するみたいですし、よりやりやすいと思います。

とはいえ、住民票請求についてはあくまでも「電子申請された住民票を郵送で届ける」というサービスの中での最適化であり、正直、職員が発行する手間もお金を収受する手間もない、コンビニ交付システムが現時点では最良のものでしょう。
それを超えるDXは、電子申請により「住民票を電子的に取得する」仕組みです。カード交付率によってはコンビニ交付システムさえ不要になるかもしれません。
そもそも、オンライン申請に使用する署名用電子証明書が個人の住民票と（機種依存文字を除けば）同一なので、個人の4情報を証明するだけならそれを相手に送るだけです。役所に対して住民票をオンライン申請する必要ないです

将来的にはこのようにあるべきです。とはいえ、ここまでに至るためにはもっと官民問わず情報リテラシー教育が必要でしょう。
DX系記事でも、

• 役所へのマイナンバーカードによる電子申請を進めるべきだ
• インターネットと役所のシステムは分離すべきだ
• セキュリティと利便性の両立を図るべきだ

というものが散見されます。はい、総論は正しいです。
正しいのですが、役所の住民情報を使わない電子申請なら困難ではありませんが、住民情報を確認しなれけばならない事務について、ネットと役所のシステムを分離してどう利便性を向上するのか各論に入った記事は多くありません。
「役所が遅れている」のは事実でしょうが、それなりに理由があり、解決しなければならない課題の根は深そうです。

選択的夫婦別姓を考えてみる

今回は、DXに関係ありません。いや、最終的にはDXに戻ってくるんですけど。

夫婦別姓を考えてみます。それも、システム系コンサルとしてシステム的に考えてみます。（考えるのは制度についてです。システムのように考えるだけです）。
システム的に考えるということは要件を満たすように設計するということであり、設計はしてみたものの発注者（今回は推進派・慎重派に発注されたと妄想します）にとって受け入れられないものとなる可能性がありますし、当然ですが、私の思想とは無関係に設計すべきものです。

まずは、現制度のおさらい（As-Is）

現行法では戸籍は「氏を同じくする者」で編成されています（ややこしいのですが、「同じ戸籍に違う氏の者は入れない」という意味であって、「同じ氏の者が別戸籍」は問題ありません）。
ここでいう「氏」というのは苗字だけではなく、「氏族」の氏を含みます。「氏族の氏」とは、元々は皆さんが考える「家」制度とほぼ同一といっていいのですが、現行法では3代戸籍はありえませんので、親子2世代までしか同一戸籍に載ることはありません。
この家制度由来の氏のことを「民法上の氏」といい、苗字の「呼称上の氏」とは区別して捉えられています（判例による概念的な話であり、明文の規定があるわけではありません）。

もう少し具体的に言いますと、平重盛さんと藤原経子さんが結婚し、夫の「平」姓を名乗ったとします。この場合、経子さんは元の藤原氏から、平氏に氏が変更になります。これは民法上の氏も、呼称上の氏も「平」です。
数年後に子どもの維盛と資盛が産まれましたが、経子さんの兄、藤原成親さんの行動をめぐり夫婦仲は悪化、2人は離婚することになりました（この物語はフィクションです！ 史実の経子は重盛と別れていません）。
子どもは経子さんが引き取ることとなりましたが、子どもと同じ苗字がよい、かつ、子どもの苗字は変えたくない、ということで経子さんはそのまま平姓を名乗ることとしました。

この場合、離婚で経子さんの民法上の氏は藤原氏に戻るのですが、同時に離婚前の氏を名乗る届出を出しているので、呼称上の氏として戸籍の氏が「平」となります。
子どもは別途手続きをしないと平重盛戸籍に入ったままですので、家裁の許可を得て「母の氏を称する入籍届」を出して平経子の戸籍に入籍させることができます（こうなると2人の子どもの民法上の氏も藤原氏になります）。

・・・民法上の氏って「家制度」っぽいのは判ったけど、概念上の話で法的には関係なくない？ と思われたかもしれません。では、もうちょっとストーリーを進めてみましょう。

重盛と離婚後に2人の子どもを入籍させ、3人で東京に移住して生活する経子。そこにイケメンの源範頼が現れます（フィクションです！）。
2人は結婚し経子は源姓を名乗ります（民法上・呼称上とも源氏）。やがて子どもの範円が産まれたものの、範頼の兄、源頼朝さんの干渉により再び離婚（どんな干渉かは長いので省略します。フィクションだし）。
経子は苗字を平に戻すべきか源のままにすべきか悩みましたが、幼い範円を優先し源を名乗り、あとで3人の子どもを入籍させることしました。

・・・複雑化してきましたので、今までの状態を表にしてみます（今回の例では夫は関係ないので記載省略）。

イベント	本籍	呼称上の氏名（＝戸籍の氏名）	民法上の氏	備考
平重盛と離婚	京都	平経子	藤原	新戸籍編成
	京都	平維盛・平資盛	平	平重盛の戸籍のまま。このあと経子の戸籍に入る予定
子どもを入籍	京都	平経子・平維盛・平資盛	藤原
源範頼と婚姻	東京	源経子・源範円	源	源範頼の戸籍に入っている状態
	京都	平維盛・平資盛	藤原	学校があり源姓に変えたくなかった
源範頼と離婚	東京	源経子	藤原	あとで範円の氏を変えなくていいように、源を名乗った
	京都	平維盛・平資盛	藤原	これから源経子の戸籍に入る予定。氏が変わるけどしょうがない
	東京	源範円	源	これから源経子の戸籍に入る予定

子ども3人の入籍手続きですが、戸籍の氏が「源」に変わる平維盛・平資盛は家裁の許可が不要です。民法上の氏が親子とも藤原氏だからです。
一方、源範円については戸籍上の氏名は変更ありませんが、民法上の氏が変わるので家裁許可が必要となります。
「民法上の氏」というものが家制度を元にしたものであり、また法的手続きに影響があることを端的に表してみました。

要件分析

さて、現行制度（As-Is）を分析したうえで本題の夫婦別姓です。まずは要件のとりまとめですね。

• 「家制度」類似の氏は、夫婦親子同一が良い
• 心理的コストの減少につながり婚姻数の増加要因となりうるし、社会的コストも減るので、婚姻でも法的に名前変更しない夫婦別姓の選択肢が欲しい
• 子どもの氏を出生のたびに決めるのは、決められなかった場合に出生届の遅延や無届につながるので避けたい

大雑把にまとめるとこんなところでしょうか。
子どもの名前については、慎重派からは反対理由として聞こえてきますが、推進派からは推進理由としては聞こえてきません（「子供の名前をバラバラにしたいから、夫婦別姓にしたい」というのは聞いたことがないです）ので、慎重派からの要件だけ記載しました。
さて、それぞれの要件について賛成反対各論あるのは承知していますが、システム屋は発注された要件が両立できるよう設計してみるだけです。今回はこの一見矛盾する要件を元に設計してみたいと思います。（しつこいようですが、あくまでも思考実験です）
考え方としては、

• 変更による社会的コストを抑制するため、極力、制度の根幹は変えない（氏を同じくするもので戸籍を編成）。
• 別姓を選択可能にし、戸籍にも記載する。法的にもその姓名を使用することとする。
• 「子どもの名前はどうするのか」という問題は、デフォルトネームをどうするかというだけの問題であり、夫婦別姓の仕組みを大枠設計してから考える。
  うまくいかなそうなら、手戻りも已むを得ない

ということになります。

設計（To-Be）

いきなり結論を書くと、

• 戸籍上、「氏」「名」に加えて「姓」を設ける。
• 夫婦は共にどちらかの氏を選択（夫婦同一氏）。
  姓は別姓を選択可能で、婚姻前の姓を名乗ってもよいし氏と同じにしても良い。
  選択的夫婦別姓というより選択的入籍者別姓であり、婚姻届のみならず離婚届や入籍届や養子縁組等にも適用（特別養子縁組は対象外）。
• 離婚すると除籍となる側は元の氏に戻る。前述のとおり姓は離婚前の姓を名乗って良いし、氏と同じくしても良い。
• 法的にも氏名ではなく「姓名」を使用することとし（氏は名前の構成要素としない）、法定事務以外では本人確認情報として氏の提供を求めてはならないことを法律上明文化。
  ただ、氏と姓が異なる場合など、私的範囲内で自ら氏と姓を併せて名乗ることは妨げない。「平藤原経子」等。
  （ただ、氏姓or姓氏を記載した書類は名義人違いなどとして法的安定性を欠く可能性があり、受領側は困るかもしれません）
• 子どもの「姓」は、婚姻時にそこまで考えて同姓または別姓を選択すべきものであり、「出生の都度選択」は趣旨に合わず、またトラブルの火種になるため採用しない。
  分娩という事実を考慮すれば、母ベースとなるのが自然であり「（母の）氏」「母の姓」のいずれかから選択。
  （離婚後出生の嫡出推定ルールとの関係は、どの戸籍に入るべきかという問題であって、この問題とは関係なく離婚後300日以内は当時の父母戸籍と決まってますので、その時点の「氏」か「母姓」となります。法律文の書き方はともかく制度設計には影響しません）
  下表のとおり、不自然な「父の姓」を除けば「（母の）氏」をデフォルトとするのが自然であり「母の姓」は選択肢とする。両方の選択肢を設けると記載漏れの場合に困るのでデフォルト値は必要。
  

  婚姻種類	氏	親の姓名	子の姓名	備考
  夫の氏・同姓婚	平	平重盛・平経子	平維盛	氏・父姓・母姓、どれをとっても同じなので選択不要。結果的に氏と同一。
  妻の氏・同姓婚	藤原	藤原重盛・藤原経子	藤原維盛
  夫の氏・別姓婚	平	平重盛・藤原経子	平維盛	氏と同一。特に問題ない
  			藤原維盛	母姓と同一。特に問題ない
  妻の氏・別姓婚	藤原	平重盛・藤原経子	藤原維盛	氏と同一。特に問題ない
  			平維盛	父姓と同一。不自然。生物学的に母ならありえるけど、この時代に父は理由にならないでしょう。

ということになるんだと思います。現行の「民法上の氏」を「氏」として定義、「呼称上の氏」を「姓」として定義したとも言えるでしょう。
システム屋の発想というより、見方によっては小役人の発想という気がちょっとするのは、私が元公務員だからでしょうか？
両派の要件を満たし、かつ、低コストで導入できるよう設計したつもりですが、推進派からは「小手先」、慎重派からは「家族を破壊するつもりか」と言われそうな気もします（笑）

机上テスト（ウォークスルー）

せっかく設計したので、念のため、藤原経子さんと子どもたちを使って、設計した制度をテストしてみましょう（全部別姓婚で、子の姓は氏と同一を選択、さらに婚姻・離婚等でも誰も姓を変更しないことにしています）。

	本籍	姓名	氏	備考
重盛との婚姻	京都	藤原経子・平維盛・平資盛	平	平重盛戸籍。婚姻時に夫婦別姓選択・子供は「氏と同一」を選択し、その後産まれた状態。
重盛と離婚	京都	藤原経子	藤原	別戸籍を編成
	京都	平維盛・平資盛	平	平重盛戸籍のまま
子どもを入籍	京都	藤原経子・平維盛・平資盛	藤原	藤原経子戸籍に入籍。子どもは入籍者別姓選択。全員、今までどおりの姓名
源範頼と婚姻	東京	藤原経子・源範円	源	源範頼戸籍。婚姻時に「子どもの姓は氏と同一」を選択し、その後、産まれた状態。
	京都	平維盛・平資盛	藤原	そのままの戸籍（藤原経子が除籍された藤原経子戸籍）に残っている状態。
源範頼と離婚	東京	藤原経子	藤原	新戸籍編成
	東京	源範円	源	源範頼戸籍のまま
	京都	平維盛・平資盛	藤原	そのままの戸籍（藤原経子が除籍された藤原経子戸籍）に残っている状態。
子どもを入籍	東京	藤原経子・平維盛・平資盛・源範円	藤原	子どもは入籍者別姓選択。全員、今までどおりの姓名。範円は氏が違ったため家裁許可必要。

どうやら最後まで設計上は動作しそうです。
他の事例もテストしてみないと何とも言えませんが、今のところ現行制度を良くも悪くも活かしつつ、選択的別姓を実現できそうな気がします。
選択的夫婦別姓については長年言われながらさっぱり議論が進まないのは、設計せずに、自分の価値観（＝自らの過去により形成）だけで、いわば先入観だけで意見を投げっ放しにしているからではないでしょうか。
まぁ、最後は「家族とは？」でぶつかってしまう人も残るんでしょうけど、そこまで行けば多数決で決めてしまえば。今はまだどうなるか理解が進んでいなくて親子夫婦バラバラ苗字みたいなのを想像している人もいると思うんですよねー。
このような議論の仕方はデジタル化には向いていません。というより議論になってません。
DXを推進するためには議論の仕方からこの国が変わっていく必要がありそうです。そうでないとこれまで同様に時間とコストをかけて、満足できないシステムが産み出され続けます。
それでも組織内で済む話ならいいのですが、社会の変化に対応すべき公的分野のシステムや法制度がそんなことでは国民が困りますよね。
幸いなことに若い世代にはデジタル教育、社会人になっている世代にはリスキリングを推進することが必要との認識が広がっていますので、この国の議論の仕方も徐々に変わってくると思います。

役所のDXを考えたい（第2回「マイナンバーカードが複雑」）

今回は、マイナンバーカードについてのお話しです。
いや、これはデジタル化を阻害するものではないどころか、政府の言うとおり、デジタル化の進展に欠かせないものであるという認識です。
何が問題かというと、マイナンバーカード（以下、単にカードと言います）の仕組みがいまいち理解されておらず、また、実際に複雑だということです。

カードについては（も？）、とても全部を分析しきれるものではありません。今回は、このカードはどんなものでどう使うのかということについてお話します。
今後も「全部は分析できない」「長いので省略、または今度」が多々登場しますがお許しください。

ＩＣチップに記録されている情報

見えませんが外周付近にアンテナ線が埋め込まれており、近距離無線通信(NFC機能)を行って情報の読取や書込を行うことができます。
スマホで読み取る場合は、スマホにICチップを近づけるのではなく、むしろICチップのない方＝アンテナを近づけてください。
さて、チップに記録される情報ですが、市町村などによる独自サービス領域を除けば、
署名用電子証明書、利用者証明用電子証明書、券面事項入力補助情報､住民基本台帳情報
の４つです
順番をどう書けばいいのか悩みますが、暫定的にこうします。
長いのでそれぞれ署名用電子、利用者用電子、入力補助情報、住基台帳情報と表記します。
本当はもう1個、カード偽造検証のための券面情報がチップ内にありますが、現実の利用シーンがほぼないので割愛。

	主な情報	住民票の情報が変わると	ユーザーの主な用途
署名用電子	住所・氏名・生年月日・性別・シリアルナンバー、有効期限 （機種依存文字は置換）	自動失効するため、必要に応じて再取得手続き	e-Tax
利用者用電子	マイナンバーと紐づいたシリアルナンバー、有効期限	手続不要	コンビニ住民票取得 e-Tax 保険証機能
入力補助情報	住所・氏名・生年月日・性別・マイナンバー （機種依存文字は置換）	手続不要（下の住基台帳情報の手続き時に一緒に役所が書換）	e-Tax
住基台帳情報	住所・氏名・生年月日・性別・住民票コード・マイナンバー （機種依存文字も原則住民票どおり）	書換手続きが必要（義務。自治体を跨ぐ場合、指定期間内に手続しないとカード自体が失効し、そのカードは回復不能）	転出入手続の一部

という感じです。以下はこの表を前提にお話ししますが、一つ一つ順に解説しても余計に混乱するだけだと思いますので、ユースケースからの切り口で、どの情報にどんな役割があるのかを解説していきます。

ＵＣ１、国税庁のサイト「確定申告書作成コーナー」を利用しe-Taxで確定申告

e-Taxへのログイン（利用者用電子を使います）
e-Taxは事前に利用者登録を行い、e-Taxの利用者識別番号16桁を取得しておく必要があります。
しかし、カードを使って利用者登録を行うと利用者用電子のシリアルナンバーとe-Taxの利用者識別番号が紐づけられ、後者を意識する必要はなくなります。
かつては、利用者識別番号(16桁)とe-Taxの暗証番号(8文字以上)でログインする必要がありましたが、利用者電子の登場により暗証番号4桁の入力でログイン可能になりましたので、かなり改善されたと言えるでしょう。

申告する際、暗証番号を使って利用者用電子を呼び出すことで、カード使用者＝カード名義人となります。
システムは利用者用電子で利用者識別番号を検索し、e-Taxへのログインを認証します。
これにより、カード使用者＝カード名義人＝e-Tax利用資格者が成立します。

入力補助情報の出番
入力補助情報を用いて、カードから４情報（住所・氏名・生年月日・性別）を取得しブラウザ上に表示し、カード名義人＝作成申告書データの名義人を確実なものとします。
手入力させると、あとで取得する署名用電子の４情報と微妙な違いが生じたりすることがあるためです。
技術的には利用者用電子を用いてマイナポータル経由で取得できませんか？ という気もしますが、

• 住基ネットの氏名・住所には機種依存文字があるので、上記懸念を払拭できない
• 個人情報保護の観点からマイナポータル経由の情報提供項目は必要最小限にしたい
• 署名用電子が不要な場合でもカードの住所変更手続きを確実にしてもらいたい（後述）

などなど、いろいろな思惑がありそうです。

申告書データの送信（署名用電子を使用）
署名用電子で電子署名し、確定申告書データを送信します。
技術的なことは省きますが、電子署名されたデータは送受信経路（インターネット）で第三者が覗き見したりデータの改竄を行うことは事実上不可能です。
実は、後者が特に大きな特徴で、あとで「自分のデータと違う（送信否認）」と言えなくする効果があります。（勿論、前者の覗き見防止も大事ですが、これは電子署名の効果というよりは・・・省略します）
これで送信申告書データ＝受信申告書データとなります。

受信申告書データ名義人＝署名用電子の名義人
国税システムでは、申告書データの名義人と、署名用電子を比較します。
というのは、確定申告書作成コーナーで作成したデータは、国税庁サイトのサーバからe-Taxシステムへ流されるのではありません。PCにDLされ、電子署名したうえでPCからe-Taxシステムへ送信されるます。
このような場合、システム側は、

• 使われるカードが、入力補助情報を読み取った時点と、署名時で違っている可能性
  （中断・保存して、後日再開することも可能なので、間違って挿し込む可能性はあります）

を考慮する必要があります。
また、e-Taxは確定申告書作成コーナー以外（市販のe-Tax対応ソフトなど）で作成されたデータも受付しますので、カードの入力補助情報を使用しているかの確証が持てません。

比較の結果、一致していれば問題ありませんし、少しでも違っていれば閾値を設けて問題なしとシステム判定するか、人間の目で目視する必要があります。
まったく違っていれば申告書名義人の意思を反映していないデータの可能性があるため慎重に対応する必要があります。

署名用電子の名義人＝住民票上の情報
システムは、署名用電子のシリアル番号を用いて、署名用電子が失効していないか検証します。
署名用電子は、住所変更や氏名変更で失効します。失効していなければ、署名用電子の内容は発行時の住民登録のまま変化していないことが保証されます。
有効期限内なのに失効している場合は、署名用電子が発行された後に住民票の住所や氏名に変更があったことを示しています。

ＵＣ２、転入届の際の転出証明書不要化

A市からB市へ引越しした場合です。通常はA市に事前に転出届を提出、転出証明書の交付を受けたあと、それを使用してB市に転入届をします。
しかし、カードを所有していれば転出証明書を持参不要です。
事前（数日前）に、署名用電子を用いてスマホまたは郵便でA市に転出届を出し、B市にカードを持参して転入届ができます。
（A市窓口に行く必要がなく、また、転出証明書の返送も待つ必要がありません。なお、スマホ転出届は一部の市町村のみです。株式会社グラファー様のシステムが有名です）

転出届
本人が転出届を窓口やスマホ、または郵送によりA市に提出します。所定の本人確認要があります。
通常、転出届を出すと転出証明書が交付されるのですが、カードを持っている人には原則交付されません。

転入届（住基台帳情報を使用します）
本人が転入届をB市に提出します。この際、カード所有者は転出証明書の代わりにカードも提出します。
暗証番号入力により、B市はカード名義人＝届出人であることを確認し、さらにカードから情報をマイナンバーを読み込み（住基台帳情報）、それをキーにA市から転出証明書情報を住基ネット経由で取得します（情報引出しのキーとしての使用）。
A市は、住基ネット経由で取得したデータを自分の住民記録システムに取り込むことで、住民登録の入力事務を非常に素早く正確にできます。

オンラインで完結できないの？
今はスマホ転出届でも処理に3日ほど要しているようです（少し長めに書いている？）。おそらくは職員による確認→自治体システムへの連携処理となっているのでしょう（紙に印刷してから手入力しているとは思いたくありません）。
署名用電子を使用しているということは、本人確認および転出元情報は問題ない（入力補助情報を使えば）ことがわかっていますので、残りは同世帯員と、転出日・転出先住所をどう審査するかクリアできれば、職員による確認は不要で自動連携できるハズです。

でも、これってそもそも論で言ってしまうと、残りの確認は転入先市町村でやればよくないですかね？（法改正は当然必要として）

• B市に転入届を出す際に、窓口にカードを提出。
• B市職員は、本人に利用者電子の暗証番号を入力してもらい、利用者電子を使ってA市の世帯情報を取得。
  （コンビニ住民票請求で世帯情報を取得可能なのでできるハズ）
• B市職員は、転入届記載の内容と画面上のA市の世帯住民票データを確認し、世帯員のうちから転入対象者を選択したうえでデータ取込を行う。一旦受付終了し、カードはそのままお預かりする。
• B市職員は、カードのマイナンバーを使って取り込んだデータを呼出したうえで、転入届による住民登録処理を行う。
  （繁忙期などは、前の処理と連続処理できない場合が多いため、アクティビティ分離して書いています）
• カードの住所変更手続きなど、関連事務へ遷移。
• 併行してB市システムは、住民登録したデータから転出届・転入通知データを作成し、住基ネット経由でA市に送信。
  （インターネット経由ではないため本人の署名用電子は不要。必要にするとまた本人を呼ばなくちゃならないし、さらに署名用電子の暗証番号不明だとここまでの作業がパーになる）

というのがあるべき姿な気がします。
ついでに言うと、B市への転入届さえ署名用電子でオンライン手続きできるのが望ましいんですけど、やはり転入届受付は人の判断を介したい理由があります。
詳細は省きますが、キーワードは「転入先の既存世帯有無」「マンション名等の揺らぎ」「カードの住所変更」です。ただ、多少割り切るか、AI化できれば可能とは思います。

とにかく現状ではスマホ転出届は採用自治体が少なく、大抵は事前に紙で転出届をしておく必要があるため、それほどのメリットとはいえませんが、将来的にはデジタル行政手続の代表的なユースケースの1つになるかもしれません。

ＵＣ３、引越し手続きをしたあとの、署名用電子の入れ直し

使用するカード内情報は住基台帳情報です。
その役割は、入力補助情報・住基台帳情報と、署名用電子の情報に齟齬がないようにする（本人のカードであること、さらにカード内情報が最新であることを保証する）ことです。

前述のとおり、住民登録が変更になると署名用電子が失効するので、使うなら入れ直す必要があります。
使用する住基台帳情報は内部事務向けなので理解されにくいでしょうが、ここまで住基台帳情報の４情報の存在感が薄いので弁護しておこうと思います。

皆さんから見える処理は、

• 職員がカードと申請書を預かり、端末で検索。
• カードを差し込み、暗証番号を入力してもらい、署名用電子を入れ直し。

これだけで簡単なようですが２点問題があります。

１つは別人のカードに書き込んでしまう恐れがあることです。
例えば、実際の窓口では、夫婦揃って電子証明書の入れ直しの際、二枚一度にカードをお預かりすることがあります。
この際、端末の検索は正しくても、カードを差し込む際に夫婦を取り違える可能性があります。
したがって、カードの住基台帳情報からカード名義人を取得し、端末で選択した情報と自動比較することで他者のカードに書き込むことを防止しています。

もう1つは、本人には間違いなくても、入力補助情報（＋住基台帳情報）と署名用電子の不一致を起こす恐れがあります。
引越手続きをした場合、カードも住所変更手続きを行う義務がありますが、同時に行う義務はありませんし、実際、家族のカードの暗証番号が不明のため、住民票の変更だけしておきカード手続は後日、というケースが多々あります。
つまり署名用電子の手続時には、カード内の入力補助情報（＋住基台帳情報）が最新のものではない可能性があります。
この状態で発行すると、e-Tax時に申告書の名義人情報と署名用電子の名義人情報が不一致となり、うまくいきません。
システム的に防止するには、カード内４情報と端末からの４情報が一致しているか確認し、一致していない場合には改めてカードの変更手続きを依頼する必要があります（入力補助情報vs端末情報の比較では、機種依存文字があった場合、全てエラーになるので不可）。

カードの展望について

かなりシステマティックな解説になってしまいましたが、それぞれの情報の役割について解説したつもりです。
特に電子証明書の格納媒体を担えるのは発行時に厳格な本人確認を行っているこのカードを置いて他にないというのが国の考えでしょう。

デジタル化を進めるのなら現在のカード普及率に囚われず、国・都道府県・市町村で大胆にカードによるオンライン手続きを構築する必要があります。
また民間企業での本人確認事務についても電子証明書の活用を図ることが重要です。
できれば不動産登記や自動車手続についても、紙の印鑑証明に替えて署名用電子を利用するのが望ましいのですが、後述する事情から難しいかもしれません。

オンラインで本人確認を行う手続き、具体的には金融機関口座開設・クレカ申込・携帯契約などを考えます。
犯罪収益移転防止法では、本人確認書類の画像と、アプリなどによるその場で撮影した本人の写真画像を送信させることになっています。
面倒くさいのですが、免許証等の画像だけでは免許証を手にしている人と手続を行っている人が同一人物か確認できないため、その場で本人を撮影させるようです。
（ICチップ情報でもいいのですが、免許証の2種両方の暗証番号を覚えている人が少ないため。金融庁HP：//www.fsa.go.jp/common/law/guide/kakunin-qa.html内のPDF）
ただ、免許証画像は事前に改竄が可能なため、その場で免許証の厚みまでわかるように撮影させる手法も取られているようですがそれでも改竄を完全には防止できません。（日経2022年6月20日InsideOutに詳しいです）

しかし、マイナンバーカードの署名用電子を使えば、このような手間や懸念は解決できます（犯収法の中で唯一、顔写真画像が不要な方式として定められており、写真を取ってもらう必要がありません。ほぼすべて機械処理で本人確認事務を完結できるハズです）。
さらに署名用電子の有効性確認を行うことで住民票の変更有無が判るので、支払が滞った際に、住民票を請求するのが無駄か否かが事前にわかるメリットもあります。

ここまでできた時に、「カード＝デジタル時代のパスポート」と言える立場になるでしょう。

利用者証明→保険証資格も可能なので、オンライン診療だって仕組み的にはできそうです。（診断技術などの問題は別途解決が必要ですが）

不動産売買・自動車売買の際の印鑑証明は、電子署名にしてオンライン化したらどんな事務フローになるのか不透明です。
現在は、紙の印鑑証明を業者に渡して代理手続きを行うことが多いです。これを電子署名に替えると本人がオンライン申請することになりそうですが、そのようなことを望む人は少数で、従来どおり紙の印鑑証明を使っての代理手続を選ぶでしょう。
（暗証番号ごとカードを預けることは推奨できません。紙の印鑑証明なら必要枚数しか渡さない、書類への印鑑は自分で押して印鑑自体は渡さないという対策がとれるので代理人を立てられますが、電子署名はカードと暗証番号があれば、いつでも何の申請でも署名可能になってしまいます）