防衛省のワクチン予約システムを考察

防衛省のワクチン予約システムの作りがひどいと話題です

急拵えで、バタバタして作ったものを内情もわからない人があとから叩く構図、多いですよね。ほんと、あとから安全地帯から石投げるのって楽で卑怯なので好きじゃないです。技術者って、そんなことも知らないの？だめだなって言ってから自分が上に立ったつもりになって安心するパターンが多くて怖いです。（自分も含めて）

出来上がったサイトに、SQLインジェクション試すとか、テロだと思います。頼まれてもいないのにわざわざやってみるとか、気持ち悪いです。

なので、自分が現場のいちプログラマーになったつもりで、予約システムが不備だった理由を弁護してみようかなと思います。SIer時代ににお蔵に入った政府向けシステム作ったことあるし。ただし、全て想像なので、全部嘘です。文章の最後に「知らんけど」をつけて読んで下さい。

接種券番号や年月日が適当でも予約できる

元請けのマネージャーが受けてきた絶対の条件が、サーバーがダウンすることがないようにしたい。というのが絶対条件だった。マイナンバーカード発行の時にサーバーがダウンして散々叩かれたので、絶対に落ちないようにしたいというのが第一の要望だった。

ならば、サーバーをAWSにしてロードバランサーつけて負荷分散すればだいぶ違うのかなと思うんだけど、サーバーは国が使ってるどっかのオンプレサーバー？で決定しててこちらから指定することなんか無理だった。ソフトウェア側から提案できるのはDBのアクセスを極力減らすぐらいしかなかった。

本来ならば、接種券番号を入れた時点で存在するかどうかのチェックをしてからエラーにするのが普通だけど、ここでDBへのアクセスが発生してしまう。サーバーへの負荷を無くすために番号のチェックは最後の予約決定時にだけ実施することにした。接種券番号は自治体が出してたし、Web作成者側からチェックできないし。どうしようもなかった。

チェックデジット(※1)入れろって外野には散々言われたけど、自治体が作ったものなのでこちらではどうにもならない部分だ。住所と名前を持ってて住民にハガキを出せるのは自治体なんだから、接種券番号はそちら任せだった。接種券番号はこちらの管轄ではない。

最後に接種券番号をチェックするので、実在するかどうかわからない。とりあえずDBは接種券番号で更新するようにした。後のを残しておけばいいだろう。自治体が変わると重複してしまうから、同じ番号で２度予約できてしまい、先に予約していた情報で上書きされてしまうっていう問題も、接種券番号がユニークでなかったからで。Webの作り手としては聞いてないと言いたい。あとのが残ってれば接種には問題ないと思われる。むしろサーバー落ちずに残してるんだからいいんじゃ。

はっきりしてきたことは

要は、各家庭にハガキを出すことができる自治体と、アプリを作る防衛省側の連携がうまくいってない。プロジェクトの頂点にいるSEの想像力次第ですが、大手SIerで優れた想像力を持つSEをみたことはありません。大手は経験足りない人材をSEとかPMに回すからしかたないのでしょうが。SEとかPMとかの方がお客さまから単価高くとれるからね。あと、プロジェクトの人数が無駄に多くて横の連携もできてないのが推測できます。あ、結局石投げてるのか？

※1 チェックデジット(意訳) ：会員番号など重複してはいけない番号を決める時00000001,00000002みたいに連番にしてしまうと00000003があることが容易に想像できてしまうのでそのような番号の振り方はしない。ならば、ランダムでつければいいのではと思うけど、それだとどんな番号でも入力できる可能性があることになってしまうので一定のルールを持つ桁を作って（簡単にいうと全部足した時の下一桁を持つ桁を作るとか）番号が間違ってるかどうかをDBの存在チェック前にロジックで見つけることができるようにする方法。