統一自治体システムを基礎として
10万円の一律給付が話題になった頃に「給付管理システム」のデータモデルとプロトタイプを公開したが、それに「ワクチン接種管理システム」の機能を組み込んだ（ダウンロードはこちら）。前回の「給付管理システム」は、日本に１基あれば済む「統一自治体システム」に含まれるサブシステムとして組み立てたものだったが、今回もそこに２つのサブシステムとして追加されている。含まれる機能はサブシステム別に以下のとおり。
＜接種データ管理サブシステム＞
・保管・接種用拠点管理 ・接種日程管理
・接種予約管理 ・要員派遣管理
＜ワクチン在庫データ管理サブシステム＞
・ワクチンデータ管理
・ワクチン在庫管理
・ワクチン取引管理
単純な機能一覧からは想像しにくいが、さまざまな制約が交錯する情報管理システムである。接種可能な人数は拠点別や日付別、時間帯別に異なるし、接種に必要な要員構成も異なる。年齢や既往症の有無によって接種の優先度が異なる。ワクチン在庫のひっ迫が予想されるので、適切なタイミングで拠点に在庫を配送しなければいけない。さらに、越境接種や自治体間でのワクチン在庫や派遣要員の融通にも対応しなければいけない。そのためには、統一自治体システムを基礎とする質の良い情報管理システムが必要だ。
システム開発者も納税者として声をあげよう
そのシステムがあれば、将来に別の感染症が起こった場合にも対応できる――しかしこれは情けないほど当たり前の話だ。そもそも、今回の新型コロナ向けにあわててワクチン接種管理システムを開発している時点で、すでに「デジタル敗戦」である。
何かコトが起こるたびに、全国に1500以上ある市区町村がそれぞれ、住民給付管理システムやワクチン接種管理システムやホニャララ管理システムの開発に右往左往している。それがどれだけ税金の無駄づかいや混乱を生み出しているかわからない。納税者の一人でもあるシステム開発者は、もっと声をあげていいと思う。
ただし、技術者の意見は具体的であってほしいものだ。「仕様化できるIT人材が発注側にいない」とか「実績偏重でベンダーロックインが是正されない」といった体制上の批判は技術者でなくてもできる。プロのシステム開発者ならば「専門家として適切と思われるシステム仕様」を添えるくらいはしていい。様式は自由。人気の高い「ドメイン駆動設計(DDD)」によるドメインモデルでもぜんぜんかまわない（というか、ほんとお願いします）。
とにかく、国や自治体のデジタル化に関して「自分たちの暮らしを支えるインフラの問題」という意識を持ちたい。「有償で責任をとるのがプロ」なんてケチくさいことは言いっこなし。家の近くの橋が設計ミスのために危険な状態になっていて、それに気づいた橋梁設計者が「お金をもらっていないので、プロとして黙っている」としたらどうだろう。お金を受け取るかどうかは別として、社会貢献もまた専門家に期待される役割のひとつだ。また、女性蔑視の問題で指摘されたように、この種の問題は「黙っていれば現状に賛成」とみなされてもしかたない。
DOA版のデータモデルと実装
ではさっそく、私がまとめた「データ指向アプローチ(DOA)版」のモデルと実装について見ていこう。工数はモデリングと実装を合わせて延べ4～5人日。データモデルに連動する合理化された実装手段があれば実装に時間はかからない。
なお、ワクチン接種管理システムの仕様などこれまで考えたことはなかったが、業務システム開発の経験を重ねた技術者であれば、それがどんなものであるべきかはおおよそ想像できるものだ。そこらへんに関してドメインエキスパートだのプロダクトオーナーといった他人の知見をアテにしていては、いつまでたっても一人前のシステム開発者にはなれない。このブログで何度も強調しているように、システム開発におけるボトルネックは、今も昔も「実装スキル」ではなく「仕様の構想スキル」である。実装スキルがボトルネックになっているように思えるとしたら、実装方法に関して合理化の余地が大きいと考えたほうがいい。
最初にプロトタイプのスクリーンショットを見てほしい（図１）。このように、実際にシステムを動かしながらデータモデルを確認できることの意義は大きい。モデルを基礎として組み上げられた「動作するシステム」こそが、モデルの有効性を事前評価するための最強エビデンスだ。言い換えると、要件定義フェーズでデータモデルとこれにもとづいて動作するプロトタイプを用意できなければ、開発プロジェクトがデスマーチ化するリスクは従来どおり高止まりし続けるだろう。
▼図１．「接種管理システム」のスクリーンショット（一部） 
上述したように接種管理システムの役割は多岐にわたるが、それらのために追加されたテーブルはそれほど多くない。自治体、世帯、住民といった基礎テーブルを除けば、16個で済んでいる。それらを含むデータモデルを見ていこう（図２）。まずは、拠点、予防接種、接種条件、接種申請（接種予約）、派遣要員を含むモデルだ。
▼図２．「予防接種データ管理サブシステム」のデータモデル 
｛予防接種№｝を主キーとして持つ「予防接種」のテーブルには、各自治体の議会で承認された予防接種プログラムが登録される。プログラムには”札幌市新型コロナワクチン接種2021”といった名称が与えられる。この「予防接種」を親とするテーブルが、「接種条件」、「派遣要員」、「接種日程」、「接種申請（接種予約）」で、それらの主キーがどのようなものであるかをじっくり観察してほしい。主キーこそがテーブルの存在意義を端的に示すものであるからだ。
たとえば「接種申請」は｛予防接種№＋住民ID｝の複合主キーになっている。つまり、「予防接種プログラムと住民の組み合わせで決まる諸問題」が接種申請として情報管理されるということだ。それらの主キーをすべて{id}のようなサロゲートキーにしてしまえば、DB構造として表現される精妙なデータ要件をアプリ側のコードとして組み込まねばならない（そもそも組み込むべき関数従属性をとりこぼしやすい）。そんなやり方ではデータの整合性を維持できないし、システムの可読性や保守性の低下も避けられない。
「接種申請」は見出し／明細テーブルの２階層を成している。明細は接種次数で展開されていて、新型コロナであれば１回目と２回目の接種予定が保持される。接種対象住民の全員がいちいち予約登録していては、回線がひっ迫することが目に見えている。そこで各自治体はあらかじめ「接種条件」にもとづく優先順位を細かく定義しておけばよい。そのうえで、それぞれ毎の対象者の接種予定日時・拠点をあらかじめ設定した形でデータを用意し、その内容にもとづく接種券を印刷・送付するのである。これで、指定された日時の都合が悪い住民だけがWEBや電話を介して予約変更すればいいことになる。ドタキャンされたらワクチンが無駄になるので、その場合には接種順序は最後尾になります、くらいの警告はしておいてよい。
続いて、ワクチン在庫を管理するためのモデルを見よう（図３）。接種拠点によっては専用冷凍庫を用意できないので、余分な在庫を大量に抱えるわけにいかない。そこで、各拠点の「接種日程（正確には接種時程）」毎に集計された”接種にともなう消費予定数（バイアル数）”にもとづく将来の在庫推移が、リアルタイムで監視できるようになっている。
▼図３．「ワクチン在庫データ管理サブシステム」のデータモデル 
このように拠点別の在庫推移を眺めながら、適宜に未来のワクチン在庫取引を指示しておけば、在庫の欠品が起こらないように準備できる。なんらかの事情での配送遅れ、あるいは足腰の弱っている住民が予約なしで接種に訪れた場合等のために、拠点毎の「安全在庫」も定義できるようになっている。接種予約に対してワクチン在庫が足りなくなる心配をせず、枕を高くして眠れる。
在庫更新のようすも見ておこう。拠点間の配送等を担う「ワクチン在庫取引見出し／明細」を登録したときに、取引がすでに完了した旨を指定すれば、即時に在庫更新される。未来の予定として登録した場合には、その指示に対してあらためて完了報告がなされたときに在庫更新される。
いっぽう接種拠点においては、住民が接種する都度に在庫更新が起こるわけではない。各拠点で１日の最後に、パネル上で「接種日程」の実際消費数(*1)を入力する形で在庫が引き落とされる。接種都度の実際の在庫減少量は小数付きのミリリットルだが、在庫はバイアル数で捕捉されているためだ。日々の残余分はバイアル単位で廃棄されるだろうから、そのほうが都合がよいのである。
これら以外にもさまざまな工夫がほどこされたモデルなので、ぜひダウンロードしてアナライズしてみてほしい。タイムリーなネタを扱ったDB設計の教材としてもお勧めできるので、職場での勉強会で活用してほしい。なお、このモデルにもとづいてローコード基盤で実装されたシステムの競演イベントが、ローコード開発コミュニティ主催で来月に開催される。そちらにも参加して理解を深めてほしい。
2021年03月05日(金) ローコード開発された "新型コロナワクチン接種管理システム"６社大競演 解説動画もあります（60分あるので1.5倍速での視聴をお勧めします）。 IT勉強宴会での解説
*1.パネル上で入力する値は「実際消費数」ではなく、その時点での実棚数のほうが使いやすいだろう。入力時点の帳簿在庫数と実棚数との差が実際消費数として記録されることになる。ちなみに、接種実績（接種申請明細）の合計から換算される消費数と実際消費数との差が大きすぎる場合には盗難が疑われる。そのような仕組みを周知して関係者に「出来ごころ」を起こさせないこともまた、情報管理システムの大切な役割だ。
