2021年3月から本格化したワクチン接種は当初は順調に進むかのように見えたが、7月に入って突然、一部の都道府県へのワクチン供給を削減する方針が示された。その根拠となったのが、都道府県別に算出された「余剰在庫」だった。ところが、その数値が実態とずれていることが各方面から指摘され、けっきょく政府は発表2週間後に供給削減の方針を撤回した。何が起こっていたのか。私は詳細を知る立場にはないが、在庫管理システムを数多く手がけた開発者としていくつかの問題を指摘できる。
未接種分が引き当てされていない
まず驚かされたのが、都道府県別の余剰在庫の数字に「1回目は接種したが2回目はまだ」のための引き当てが考慮されていなかったことだ。なんとも初歩的なミスではあるが、これは本来ひとつにまとまっているべき接種管理システムが、配送管理用のワクチン接種円滑化システム(V-SYS)と、接種実績管理用のワクチン接種記録システム(VRS)に分割されているためでもある。それぞれが提供するデータにもとづいて都道府県別の「余剰」は次のように算出されたようだ。
余剰数量 ＝ 配送済数量(V-SYS) - 接種済数量(VRS)
素人にも発想できそうな計算手順だが、これで得られた数字にほとんど意味はない。１回目接種と２回目接種の合計を接種済として差し引いているからだ。未接種分の２回目向けの「引き当て」が考慮されていないのだから、まともな数字にはならない（図１の余剰ａ）。多めに示されるこの余剰を基準に供給削減されては、都道府県はさすがに腑に落ちないだろう。削減方針を発表した時点での全国への発送済が8800万回分で、接種済が4800万回だったので、政府は合計4000万回分もの余剰が全国津々浦々にあると考えたわけだ。
不思議なのは、VRS上の接種記録には「何回目の接種であるか」を示す項目が載っているのに生かされていない点だ。それを手掛かりにすれば「1回目は接種したが2回目はまだ」の数量がわかる。それを引き当てることで、より正確な余剰在庫が得られる（余剰ｂ）。そういった初歩的な考慮さえされていないのはなぜだろう。
ただし、2回目未接種分を引き当てたとしても問題は残る。各都道府県が既に抱えている大量の「1回目も2回目も未接種の予約」が控えているからだ。それらを引き当てなければ本当の余剰在庫はわからない（余剰ｃ）。じっさい一部の都道府県では供給削減の方針を受けて、いったん受け付けた予約を取り消す事態になった。平謝りするしかない担当者の気苦労はどれほどであったか。
引当方式から在庫推移監視方式へ
じつは、「未接種分の予約」まで引き当てても問題は残る。引当方式では「時間軸」が考慮されないからだ。接種予約による消費予定であれ、配送指示による入荷予定であれ、在庫を増減させる取引予定は常に将来の異なるタイミングで起こる。つまり、各拠点における在庫の有効在庫（余剰や不足）は「時間の関数」に他ならない（図２）。
実際問題として、未来の消費予定を合算して現在庫に引き当てた図１の余剰Cは少なめに示される（時にはマイナスになる）。この値にしたがって管理者は現在庫を余分に抱えようとするだろうが、それは困る。とくに今回のワクチンを保管するための専用冷凍庫が必要なので、必要以上の在庫を抱えるわけにはいかない。消費予定と入庫予定を時間軸上で並べて現在庫からの増減推移として捉え、安全在庫を考慮したギリギリの余剰を維持できるように需給管理できたほうがいい。
現在庫を起点にした先々の在庫推移を適宜眺められるようにして、必要なアクションを取る。このやり方を筆者は「在庫推移監視方式」と呼んで、MRP（資材所要量計算）に代わる在庫管理方針として推奨している。現在の実装技術やマシンパワーを前提にすれば実現は容易だが、拠点、製品、拠点別在庫、接種予約、配送指示といったさまざまな要素が総合されたデータモデルが欠かせない（このブログでの参考記事「新型コロナワクチン接種管理システムのデータモデル公開」）。
さて、今回の業務課題を「政府から各都道府県へのワクチン配送計画の立案」とみなした場合、求められるものは「自治体内の各拠点別の在庫推移」ではなく「都道府県別の在庫推移」である。これならば手持ちデータから得られないわけではない。今春からの配送指示はすべてV-SYSに記録されているし、接種予約は各自治体の予約管理システムに記録されている。それらをすべてVRSに渡してしまえばよい。個々の接種予約に｛自治体コード＋予約番号＋接種次数｝の複合主キーを与え、そのうえで自治体の予約管理システムで予約登録された時点で即座に連係し、適宜に"未接種"から"接種済"にステータス更新されるようにしておく。これらを都道府県別の配送指示といっしょに時間軸上に並べることで、在庫推移が得られる。
ところがここで「大規模接種・職域接種」が邪魔をする。自衛隊が協力している大規模接種や職域接種での接種実績はVRSにアップされているようだが、各自治体内拠点向けの予約と大規模接種・職域接種向けの予約がダブっている可能性がある。つまり接種にともなって「予約者が居住している都道府県のワクチン在庫が消費される」とは限らないとういことだ。大規模接種・職域接種は必要な施策ではあったが、残念ながらデータ管理が別であったためにシステム的な混乱をもたらしてしまった。
統一自治体システムの欠如とMSAの弊害
それにしてもこういった混乱の最大の原因は、やはり「統一自治体システム」が存在していなかった点に尽きる。そのため、接種予約機能について各自治体が自前で用意しなければならなかったし、VRSと手作業で連係させられる羽目になった。大規模会場で接種した場合には、接種者自身が自治体向けの予約を忘れずに取り消す手間も要る。
本来であれば、統一自治体システムに含まれる接種管理機能で配送指示、予約登録、接種登録、要員派遣といったひととおりの業務要求を賄えたはずだ。大規模接種会場については「複数自治体の出張拠点が同居する大会場」とみなし、職域接種会場は「越境予約を認める自治体内拠点」とみなせば、通常の枠組みの中で扱える。2020年になされた一律給付であっても、統一自治体システムの特別給付機能を使ってより正確かつ迅速に実施できただろう。2000年にe-Japan構想を打ち出して以来、政府は未だに統一自治体システムを実現できていない。莫大な費用と時間を投じて何をしていたのかと思う。
私が懸念しているもうひとつの原因が、多くのIT技術者が心を寄せている「マイクロサービス(MSA)」の悪影響だ。今回は、厚労省によるV-SYS、官邸によるVRS、各自治体の接種予約管理システム、大規模接種・職域接種向けの管理システム、といった多くのシステムが連係する形態になったことで、いろいろな問題が生じた。統一自治体システムが存在していなかったためとはいえ、もっとスマートなやり方があったような気がしてならない。もしかしたら関係者には「小さめのサービスをアジャイルに作ってAPIで連係させたらいい」というMSA的な発想があったのではないか。「MSA的な甘え」といってもいい。
限定された機能を担う小さめのサービス（独立したDBを扱う）を生み出せば、それらを連係させることでさまざまな要望に応えられる――と考える癖をつけてはいけない。今回の混乱を見ればわかるように、カジュアルに生み出されたサービス群を後付けで連係させるやり方には明確な限界がある。MSAおよびSOAはシステム設計のヒントのひとつではあるが、適用に際していろいろな制約や課題があることは知っておいたほうがいい(*1)。
少なくともMSAを、広域のデータモデルを構想しない（できない）ことの言い訳にすべきではない。それを確立しないままでは、企業や行政といった複雑な社会活動を支援する情報管理システムは完成しない。システム開発者は、まずは広域のデータモデルを構想できるようになるべきだ。最初からMSAに慣れてしまうと、部分最適化しか担えない小ぶりな開発者として成熟しかねない。システム設計スキルに関しては「大は小を兼ねる」、つまり、「広域向け設計スキルは局所向け設計スキルを兼ねる。その逆ではない」と考えてほしい。
*1.MSA/SOAの課題に関する参考記事
ThinkIT「Istioがマイクロサービスからモノリシックなアプリに変化。その背景とは」
日経クロステック「SOAなのにトラブルが連鎖、みずほ銀行システム障害の謎」
