特別定額給付金オンライン申請システムはなぜ失敗しているのか〜システムの構造的な特徴に着目して考える〜
はじめに
残念ながら30日は、ある自治体の支援業務後の移動時間にちょうど重なるので参加できそうにありません。過密対策の分散出勤で土曜日も職員は仕事をしているのです。
というか、多くの自治体にとって特別定額給付金事務のヤマはこれからも続くので、本件を「終わった話」として扱うのならば、多くの職員の感情を逆撫ですることになります。
また、私自身は30日の会を主催される方、参加される方の思惑がわからないので「お手盛りなのでは？」という疑念が拭えません。それだけ信用は失われているのです。
そこで、つまらない議論で時間を無為に費やさないように、今回の失敗の要因のうち技術的な根本原因を指摘しておきます。
この指摘は政策的な課題や自治体側の運用の課題にも影響を及ぼしているのですが、議論が拡散するのでここではあえて触れません。また、その他の技術的な指摘は、どちらかというと各論になります。そこに注視してしまうと根本原因を見過ごすことになりますので、本稿の本論にはしません。興味があれば各人で時間を掛けて考えてみてください。
（本稿とは関係ありませんが）上図は、私が当初提案していた特別定額給付金に関するフローです。この段階ではぴったりサービスの稼働を信じていて、それを補完するために郵送申請を効率化させる仕組みを検討していたのです。ここ最近では、自治体の一部で独自の電子申請システムを稼働させる動きが出てきており、個人的には複雑な気持ちです。
システムの構造的な特徴
今回の特別定額給付金オンライン申請システムの構造的な特徴を示します。
１．ぴったりサービス（Salesforce）と自治体との中継システム（LGWAN-ASP）、各自治体の住民記録システム・給付金管理システムが直列に位置づけられている。
２．各システムは、国やベンダー、自治体など、それぞれの責任範囲が分かれており、お互い他システムを知り得る状況にない。
３．申請データは常にぴったりサービス→中継システム→自治体システムの方向にしか流すことができない。つまり、申請データと同様に、申請そのもののステータスを前に戻すことができない。
先に言っておきますが、このような構造の情報システムはマルチベンダーという形で世の中に多数存在しますし、それら全てがトラブルメーカーでもありませんので、私自身はこれを克服可能な制約条件であると認識しています。したがって「国と自治体のシステムが密結合でなければならない。国・自治体の統一システムを開発するべきだ」という意見は、将来の課題としては面白いですが、一旦検討から外します。
工場のメタファー
さて、この構造をイメージしやすいように、たとえ話をしましょうか。今回のオンライン申請システムを何らかの機械の組み立て工場に例えます。（どうでもいい話ですが、私は大学院で工学マネジメントを学んだので、工場のたとえ話が多いです）
・工場ではお客様に納品するための機械を組み立てています。組み立てる部品は別の業者から納入しています。少し風変わりな点があるとすれば、製品の受注をこの部品納入業者が担っているということでしょうか。
・この工場では当初から困ったことがありました。検品が不十分なのか、生産設備がポンコツなのかは判りませんが、業者が納入する部品に不良品が多いのです。本来ならば不良品は業者に差し戻して良品を再納入させるのですが、この業者は自分達が納める部品には問題があるとは認識していない、と主張します。
・工場は業者に粘り強く交渉し、いくつかの不良箇所を認めさせましたが、すでに納品した部品は工場が受領したものなのだから、良品の再納入は行わないし、実は自分たちはお客様からの注文票を保管していないので、再納入を行うことができないと言います。あくまでも「今後納入する部品についてのみ改善する」という姿勢を崩しません。結果的に工場には再納入の見込みのない不良部品が累積し、その不良部品を莫大な手間をかけて修補しながら機械を組み立てなければならないので、製造現場は疲弊しています。
・時折、不良部品を修補する工具が業者から提供されますが、付け焼刃的な代物で、逆に組み立て手順を不合理に拘束するため、生産性がみるみる低下していきます。ただ、全く工具がないと組み立てが進まないので「こんなものなのかな」と思いながら工具を使っています。工場のメンバーも特にアイディアを持ち合わせているわけではないのです。
・一方、部品業者は「うちに発注すると納期が早いし、簡単だよ」と言いながら「納品が遅れてるのは工場の問題。うちは部品を納めているだけだからよくわからないので、直接工場に問い合わせてくれ」と調子のいいことだけを言っています。ますます工場は板挟みになって身動きが取れなくなります。
・長く苦しんだ上、ようやく自社で受注ルートや同じ部品を内製する体制が確立できる見込みが立ったので、工場はついにこの部品納入業者との取引をやめようと決意します。取引を停止した後、工場のメンバーはふと思います。「なぜ私達はあの業者と取引しなければならなかったのだ？」
…このぐらいにしておきましょうか。実際には「納品を心待ちにしているお客様」とか「お客様の声に耐えきれず、とにかく一刻も早く出荷しろという社長」とか「実はリコールになりそうな欠陥を隠し続けている部品納入業者」などのサイドストーリーがあるのですが、今回の本題ではないので省略します。
インテグラル型とモジュラー型
繰り返しますが、この工場のように工程や要素技術を分割して生産活動をすることは珍しくありません。また海外の生産拠点とサプライチェーンを構成する場合に、不良部品の差し戻しや良品交換が現実的に困難な場面もあります。
工学マネジメントでは、このように利害の対立する関係者の間をつなぐパターンは２つに大別されるとしています。
・インテグラル型（すり合わせ方式）
・モジュラー型（規格適合方式）
インテグラル型とは日本の自動車産業が代表的な存在で「系列会社」という受発注間の密接なつながりを根底として、互いの知見を活かしながらより良い製品を作っていく方式です。双方の接合面は試行錯誤を繰り返しながら差異を解消し（すり合わせを行い）、やがて密着する。というイメージでしょうか。ソフトウェア開発ではアジャイル型というのが似ていますね。
一方、モジュラー型とは、パソコンの組み立てを想像していただければ判るのですが、あらかじめ決まった規格の部品があり、規格に沿っている限りいかなる組み合わせも構成可能という方式です。合わせるべきは相手ではなく、共通の「規格」です。レゴブロックに例えられることも多いです。
今回はどちらのタイプ？
さて、今回の特別定額給付金オンライン申請システムにおける総務省と自治体の関係はどうなのでしょうか？
特別定額給付金の事務を行う自治体は全国で1741団体あります。特別定額給付金オンライン申請システムを提供する主体は一つだけ（総務省）ですので、交渉相手が多すぎて、1741団体の個別すり合わせができる能力はありません。必然的にインテグラル型は採用できず、モジュラー型で臨むことになります。
ところが、実は今回のオンライン申請システムは明確な規格（仕様）が存在しません。いや、有無の話になると互いの主観で「これが仕様だと言える」と水掛け論になるので、言い換えるならば「信頼に足る仕様が固定されていない」ということになりますか。機能改善の名のもとに、その内容も継続的に保証されているわけではないですし。だって、最近になっても「口座の桁数チェックを追加しました」とか「シリアル番号による突合をすること」などの運用の変更依頼が来るんですよ？
それ以前に、仕様が明らかでないが故に、意図しない挙動が果たしてシステムで内包している欠陥なのかの判別もできません（まぁ99.99％ぐらいは本当に欠陥で、それが自治体を今もなお苦しめているのですが）。したがって、その差異は人間の手作業（紙へ印刷して紙の申請書として処理）で補わなければなりません（一部の自治体は豪傑な方がいて、独自にシステムを解析して不完全な仕様を自分たちのシステム側で取り込みながらオールデジタルで処理したところもありますが、本当に例外的な存在です）。
総務省の言い分はこんな感じです。
今回は準備期間も短く、とにかくシステムを迅速に稼働させる必要があった。まず稼働させて、残りは走りながら考えていく
ふーん。もっともらしい話しぶりですが、実際はただの言い逃れでしょう。
交渉相手の数の面でインテグラル型を採用できないのもそうですが、今回の特別定額給付金申請は当事者にとって「一度きり」で、同じ市民が再び申請してくるわけではないので、その１回のタッチポイントが全てです。ネット広告のように繰り返しタッチポイントがあるわけではないので、走りながら考えて繰り返し改善しても、すでに申請されたバッドデータは負の遺産のままです。
したがって、初動が遅れても接合点の規格を決めたモジュラー型で臨むべきでした。彼らは賢いので当然それに気づいていたと思うのですが「面倒なことは自治体が被るんだから、いいや。オイラ知らない」と責任転嫁の姿勢を見せたのが根本的な誤りだったと考えています。
それでも、どうしても走りながら考えるというのならば、自治体側は「改善されたタッチポイントを実感させるために、これまでの不備のあるデータを全部捨てて再申請させるけど、総務省はそれでいいんだね？」という話になります。もちろん自治体は市民の顔を思い浮かべると、そんなこともできないし、そもそも申請者には申請が有効に成立したかのようにシステム上で見せている。申請者もそう理解している。総務省もそれを知っている。
百歩譲って、トライ＆エラーを繰り返したいのならば、自分たちがフォローできる規模でパイロット検証をすればよかったのに、それもやらないでいきなり実戦投入ですから、自治体を「捨て駒」だとでも思ってたのでしょうかね。
本当の課題はここなのです
総務省の振る舞いに注文をつけるだけでは不公平で、もちろん自治体にもわずかながら非はあります。
上述の工場のメタファーを引用すると、
本来ならば不良品は業者に差し戻して良品を再納入させるのですが、
この部分。つまり、受け入れ基準を満たしていない部品は納入させちゃダメでしょ。ということです。
さらに少し深堀りすると、今回はそもそも合意された受け入れ基準など存在していなかったという事実です。この受け入れ基準の合意事項の中に、UI上のエラーチェック、申請者の単位（個人か世帯か）、本人確認の基準、重複申請の取扱いなどが含まれるべきなのですが。30日のテーマがこれらの個別の是非やあり方などを議論するという内容になるのであれば、ハッキリ言えばどうでもいいことですので興味はありません。重要なのは事前に合意しておくことであり、合意事項が遵守できなかった場合は受け入れを行わないという自治体側の明確な意思表示です。
これらを決めずに、なし崩し的に既成事実化して、その場で解釈を変えて、言い逃れをして、負の遺産を押し付けて逃げられないようにして別の角度から成果を強いる。
自治体も毅然とした対応を取ればよかったのでしょうが、実際にはそれができない（なぜできないのかは、地方自治や地方分権の問題につながるので別の機会に）。これ、民間だと下請けイジメで犯罪です。
私自身もオンライン申請システムを一旦停止して、この問題解決を図らなければ被害が拡大すると主張していたのですが「順調に給付が進んでいる団体もあるので」という理由で一蹴されてしまいました。（スクリーンショットもありますが、ここには掲載しません）
その後、オンライン申請システムは役目を終えたとして利用停止する自治体が続々と出てくるのですが、当然、苦渋の決断ですし、それまでの苦労は並大抵ではなかったものと推察されます。
インテグラル型は、お互いの（最終成果に向けた）信頼関係がベースで成立するものです。もし総務省が「改善」の名のもとに、未だにインテグラル型を志向するのであれば、残念ながら手遅れですし、自治体が自分たちの命令に従うと考えているのならば、それは驕りでしょう。もはや本件に限って言えば、自治体との信頼関係は失われています。
蛇足：モジュラー型ならばどこが接合点になるのか
さて真面目な話をして、本稿を結びましょう。やや技術的な話ですし、本稿のテーマからみれば各論に過ぎませんが（自分で書いておきながら）。
仮にモジュラー型で構成するためには受け入れ基準を決める必要があります。今回のシステムは申請データと申請ステータスが元に戻せないという制約条件があるため、各工程内で完結する情報の範囲で申請の有効性を確認することが最低条件となります。
申請者→ぴったりサービス
具体的に言えば、ぴったりサービス（Salesforce）では、マイナンバーカードのICチップに格納された電子証明書の情報（氏名、住所、生年月日、性別）と申請フォームに記入させる情報が全てです。
口座確認用の添付書類（データ）は目視確認なので、システム上での整合性チェックはできませんが、ファイルの添付モレはチェック可能ですし、送信前に申請者にプレビューさせることができれば、エラーも格段に減ります。
また、住所が判っているので、申請先の自治体も自ずと決まります。
電子証明書に格納された情報と申請フォームに記入させた情報が一致していないのでチェックが必要、という話も聞きますが、そもそも申請フォームにそれらを記入させる必要はありません。電子証明書の情報を引っ張ってくるのなら入力項目は無くてもいい。つまり申請フォーム上では電子証明書によるデータの検証は行っていないことになります。なんで？ なりすましOK？
この段階で不備があれば、早々にエラーとして申請者に再入力を促しましょう。この工程におけるシステム投資は少額で済むはずです。そのためのPaaSだろうし。
ぴったりサービス→中継システム
次の中継システム（LGWAN-ASP）では、申請先自治体の振り分けと添付ファイルの無害化を行っているものと推測されます。
まず、受け入れ基準を満たしていないのならば、この段階で受け入れてはいけません。早々にエラーとしてぴったりサービスに通知を返す仕組みであるべきです。
ここでの受け入れ基準は添付ファイルに関するものが主になるでしょう。ファイルの拡張子を偽装していたり、そもそも規格外のファイル形式が送られてる場合には、受け入れ基準から外れます。
ファイルの無害化についても言いたいことがいろいろあるのですが、この無害化の機能は（私から言わせれば）不十分です。というか、別の攻撃の機会を与えてしまっているという意味で、リスクが残存しています（おそらく私程度でもクラックできるかも。やらないけど）。電子署名を付与して申請しているのだから悪意のある攻撃は行わないという前提なのかもしれませんが、攻撃者の心理までは想像できません。
どうせならば、ここで添付ファイルの正則化（サイズの変更、ファイル形式の統一）を行えばよかったのに。スマホで撮った写真やら、PDFやら、PowerPointやらが混在して来るのを見て、非常にもったいないと思うのは私だけ？ 画像をちゃんと処理すれば、中の証明書類を短形に切り出すこともできますし、切り取った証明書類が何なのか（通帳のコピーなのか、キャッシュカードのコピーなのか）を機械学習に基づいて判別することもできます。
もう少し頑張れるのならば、口座番号や口座名義を抽出することも可能でしょう。100％正確性は保証できないので、あくまでも下処理としての位置づけですが、私に1億円ぐらいくれるのならば、作りますよ。似たようなことをすでにやっていますし。
中継システム→自治体（住民記録システム・給付金管理システム）
その後、各自治体に申請データが来る（正確にはダウンロードできる状態になる）のですが、ダウンロードした状態だけでは「受け入れ」していないことにする取り決めは必要でしょう。
やはり受け入れ基準を満たしていなければ、早々に不備であるとして申請データを保留にし、申請者に再申請を促す方がお互いのためになります。電子申請に関する法的な整理は、実は20年前（e-Japan計画の頃）にも論点としてあったのですが、すっかり放置され、忘れ去られています。この20年はムダな時間だったのか。
行政手続法や昔のオンライン化三法からこの領域がどの程度変わったのかは私も勉強不足ですが、今回の特別定額給付金事務に行政手続法を適用するのならば、すでに法令違反です。
・申請がその事務所に到達したときは、遅滞なく審査を開始しなければならない（第7条）。そして、申請により求められた許認可等を拒否する処分をする場合には、原則として、同時にその理由も示さなければならない（第8条）。
・なお、行政庁は、申請により求められた許認可等をするかどうかをその法令の定めに従って判断するために必要とされる具体的基準（審査基準）を設定（第2条・第5条）し、原則として、公にしておかなければならない（第5条第2項）。また、行政庁は、申請がその事務所に到達してから当該申請に対する処分までに要する標準的な期間を定めるよう努め、定めた場合には公にしておかなければならない（第6条）。
一旦受理してしまうと行政側に審査権限が生じ、まず形式要件を満たしてなければ当然に拒否処分となるので、原則としてバッドデータはひたすら拒否、あるいは補正指示を出すべきなのですが、自治体は優しいのか法律を知らないのか、審査基準を定めていないのかの理由で、電話等の問い合わせによる事実確認をやっていたりします。受け入れ基準の合意がなされていないというのは、技術的な面だけでなく法的な面でも致命的だったということでしょう。
残念ながら自治体に申請データが到達した段階では、申請者が世帯主なのか、特別な配慮が必要な方なのかは判りませんので、各自治体の住民記録システムとの突合（審査）が必要になってきます。これは受け入れ基準では定められないものなので、ここは自治体の頑張りどころでしょう。少なくとも理想形はオールデジタルで処理することですので、信頼できるデータで突合ができれば問題は深刻化しないのです。
ー＊ー＊ー＊ー
えーっと、他になんか論点になるところはありますか？ 紙と電子の重複申請？ それは以前Facebookの投稿で書いたので、それを参照してください。要は期日を設定する運用しかないだろうという考えです。
申請を世帯単位にしたのが原因？ 確かにそうなのですが、総務省の言い分は「未成年者に申請させるのが現実的でない」とか、そんな話でした。
民法代理による代理申請のスキームを使って紙申請に誘導して、郵送も含めて申請を個人単位に統一するのもアリだったのかもしれないけど、今後、電子申請を汎用的に考えるのならば、権限が縦割りになっている組織の不完全情報で申請することを前提とした「ルールの整備」の方が必要だと私自身は考えています。
やっぱり、国と自治体の統合システムがいい？ 好みの問題だけど、統合すると保有データの責任分担が曖昧になるし、小さなカオスを解消するための大きなカオスがそれらを呑み込んで、しかも外から見えにくくなる分だけ、厄介な存在になるのでは？
マイナンバーと銀行口座を紐付ければこんなことはなかった？ 言っていることはわかるし、反対はしないけど、今回の問題はそこではないし、床屋談義は日を改めてやりましょう。
ー＊ー＊ー＊ー
細かなところで私自身も事実誤認があると思いますが、本稿のテーマはモジュラー型の関係における受け入れ基準の合意にあります。間違いがあれば訂正しますが、その前に、この問題に対して目をそらさないでください。
おしまい
この記事が気に入ったらサポートをしてみませんか？