三要素分析法に依拠して開発されたX-TEA Modelerには、他のモデリングツールにはない独特な機能があります。そのひとつが、関連の深いテーブルやアプリを「サブシステム」としてまとめる機能です。三要素分析法では「サブシステムに含まれるテーブルは、同じサブシステムに含まれるアプリによってのみ更新される。含まれないテーブルについては参照のみを許す」と考えます。これはサブシステム間を疎結合に保つためのルールで、当該サブシステムに含まれるテーブル（内部テーブル）は水色に、他のサブシステムに含まれるテーブル（外部テーブル）は灰色で示されます。水色がそのサブシステムにおける「主役」で、灰色は「脇役」と考えてください。

　ちなみに、1.「予防接種データ管理サブシステム」で示されている灰色の「自治体」や「世帯」は、前回の「給付金管理システム」のモデルにおける「基本データ管理サブシステム」に含まれる外部テーブルです。同様に「ワクチン」のテーブルは、2.「ワクチン在庫データ管理サブシステム」に含まれる外部テーブルであるゆえに、灰色で示されています。（この表記法に慣れていない方のために、一般的なIE記法でのER図も併記してあります。）

　なお、以下の説明で「UI（ページや帳票のデザイン）」が問題にされていない点に注意してください。多くの技術者は「UIが明確でなければデータモデルも明らかにならない」と考えています。実態は真逆で、「扱いたいデータの構造」が明らかになることで、UIや業務手順を検討するための基礎が固まります。UI先行でシステム設計するほうが簡単そうに思えますが、整合的なデータを保持するためのDB構造がいつまでたってもまとまらないリスクを抱えることになります。とくに今回のようにデータ構造が複雑な案件では致命的です。

　また、このモデルを組み立てるために「予防接種管理に関するエキスパート」が必要だと思われたかもしれませんが、必ずしもそうではありません。在庫管理や生産管理といった一般的な業務システムの設計経験があれば、新型ワクチン接種管理システムがどのようなものであるかについては、ある程度予想できるものです。

　むしろ、自分以外のいわゆるドメインエキスパートに頼ることにはリスクがあります。彼らはシステム開発のプロではないので、システム仕様に関する革新的なアイデアを持っているわけではありません。ようするに開発者自身が「業務システムという社会領域（ドメイン）」のエキスパートであればいいだけのことです。クライアントの要望に合わせて、経験にもとづく本来的、あるいは革新的なシステム仕様を提示できるでしょう。この意味で、「ドメインエキスパートの考えを理解して、端正なコードに落とし込むこと」を自分の役割とするドメイン駆動設計の考え方には危うさがあります。

１．予防接種データ管理サブシステム

　データモデルから予想される業務の流れに沿って説明します。まず、各自治体は事前に「ワクチン拠点」を複数定義します。これはワクチンを在庫、または接種できる場所を意味し、学校や公民館といった公共施設の他に、民間の病院やクリニックも含まれます。イオンのような大型商業施設を接種拠点とする構想もあるようです。

　次に各自治体は、感染状況に応じて予防接種プログラムを企画し、議会承認を経て「予防接種」とこれに付随する複数の「接種条件」を登録します。接種条件には"医療従事者"、"６５歳以上、または既往症あり"、"一般"といった値が接種開始日とともに登録されます。それらは自治体毎に異なる可能性があります。場合によっては３グループに分けずに、住民全員に同じ優先順位が与えられるかもしれません。

　続いて、予防接種プログラムに協力してくれる拠点毎に「接種日程」毎の必要派遣要員数、および「接種時程」毎の接種可能数を登録します。いっぽう「派遣要員」が作業可能な日程を登録することで、それぞれの接種日程での要員手当数が自動集計されて過不足が示されます。

　以上がひととおり完了した時点で、自治体はその時点での住民毎に「接種申請見出し」とその子である「接種申請明細」をバッチ処理にて自動生成します。その内容は接種通知書として郵送されます。「接種申請明細」には、次数（１回目、２回目）毎の接種予定の拠点と時間帯が含まれますが、それらの初期値は生成時に設定されると考えてもいいし、接種者がWEBで予約登録するまではブランクのままと考えてもいいでしょう。いずれにせよ接種予定が変更された場合、「接種日程」および「接種時程」上の接種予定数が自動更新されるとともに、拠点在庫の在庫推移（次項参照）が変化します。

　接種予定日時・拠点を変更する手段はもうひとつあります。各拠点の接種日程の管理者が、接種者の接種管理番号を直接入力することでも予定が更新されます。病院勤務のスタッフに対する優先接種、あるいは６５歳以下でも既往症を持つと医師に認められた場合に、そのような操作がなされます。

　接種者は予約日時に拠点に出向き、接種通知書を提示して接種します。その際には「接種申請明細」の「ワクチンロット№」が更新されます。特定ロットに問題が生じた場合に接種者を一覧できるようにするためで、この要件を「ロット・トレーサビリティ」といいます。

２．ワクチン在庫データ管理サブシステム

　接種予定データを管理するだけでは、接種プログラムは執行できません。各拠点でのワクチン在庫が接種予定に応じて確保されていなければいけません。そのためにシステムは、ワクチンおよびワクチン在庫を管理する必要があります。そのためのDB構造です。

　テーブル「ワクチン」の子が「接種用量」で、孫が「接種回数」です。「接種用量」の主キーからわかるとおり、月齢で用量（１回あたりの接種量）や回数が決まります。「接種用量」と「接種申請明細」との参照関係における参照キー（外部キー）は何でしょう。関連する「接種日程」毎に決まるワクチンC（コード）と、接種時の月齢から算定され動的に探索された「接種用量」上の「上限月齢」が複合されたものです。これは「動的参照関係」と私が呼ぶもので、業務システムではしばしば登場します。

　統一自治体システムにおいて、ワクチンのこれらの情報は各自治体とは異なる主体（厚労省？）によって登録され、全自治体がそれを参照することになります。定義されているワクチンを各自治体は、登録されたワクチンを１個か複数組み合わせて、予防接種プログラムを執行します。

　「ワクチン」と「ワクチン拠点」の子が「拠点別在庫」です。その主キーが｛自治体C＋拠点行番＋ワクチンC｝であることに注意してください。これはこのシステムにおいて、日本全国津々浦々にある拠点のワクチン在庫が把握されていることを意味します。拠点間、自治体間の在庫の融通も「ワクチン取引」を用いて簡単に指示できます。また、細かい説明は省きますが、このモデルでは居住自治体以外での接種予約も可能です。統一自治体システムの意義がおわかりでしょうか。

　拠点別のワクチン在庫については現在庫だけでなく、時間的変化も把握されます。「在庫取引予定」は、「ワクチン取引明細」と「接種時程」を抽象化したもので、それらの変化に応じて自動更新されます。このように在庫の入出庫テーブルを在庫取引予定として抽象化することで、そのうえで現在庫にもとづく未来の在庫推移がリアルタイムで計算され、欠品や余剰の予定が見える化されます。このような枠組みを私は「在庫推移監視法」と呼んでいるのですが、時間軸上の在庫を予約する「在庫引当方式」より柔軟であるし、「所要量計算方式(MRP)」よりもお手軽です。

　「拠点別在庫」に含まれる「最早欠品日」は在庫推移監視法の意義を表す象徴的な項目です。これが各種入出庫予定の変化にもとづいてオンデマンドで計算・提示され、ユーザによって対処されることになります。とくに新型コロナワクチンの場合、解凍すると５日間しかもちません。超低温で保管するための設備のない拠点では、接種予定数に対して「多すぎず少なすぎない量」の在庫を維持する必要があります。そのためには、在庫推移監視機能、在庫推移にもとづく取引指示機能、および接種予約機能が欠かせません。

　実際の在庫管理オペレーションはこのようになされるでしょう。まず自治体毎に、拠点在庫を監視する役割を持つユーザ（在庫管理者）が数人あてがわれます。彼らは１日に数回、自治体内の全拠点の在庫について最早欠品日を問い合わせます。近い未来（たとえば１週間以内）に欠品が予想されるような拠点には、欠品をカバーする「ワクチン取引」を未来日付で登録すれば、その時点で欠品予定は解消します。

　仕入予定や輸送に何らかの障害が生じた場合、偶発的な欠品が生じる可能性がありますが、その際には接種者にメールで通知するか、WEBページで当日の状況を確認できるようにしたほうがよさそうです。いずれにせよ、入出庫予定の攪乱があればシステム上の入出庫予定をすかさず更新することが、「現実世界の入出庫予定のセンサー」である在庫管理者の役割です。

　なお、上述したように「接種日程」毎にワクチンCが決まっている、つまり、日付と拠点の組み合わせにワクチンCが関数従属している点にも注意が必要です。地味な制約に思えますが重要です。その制約のおかげで、接種者が２回目の日程を選ぶだけで１回目のワクチンと異なることに気づけます。その場合、予約受付アプリは「１回目のワクチンと異なるので別の拠点・日程を選んでください」とエラー表示します。同じ接種日程でワクチンも選択可能なほうがいいと思われるかもしれませんが、おそらくそれは接種者に裁量を与え過ぎです。特定メーカーのワクチンに風評が生じた場合、それを避けるような接種予約が許されてしまうからです。そもそも接種現場を考えた場合、ひとつの接種日程で複数のワクチンを扱っていては無用な混乱を招くでしょう。