「この世のあらゆる困難が詰まっていた」新型コロナワクチン予約システムはこうつくられた【開発PM勉強会レポート】

• keyboard_arrow_down 留学先のスイスで知った「ものづくり」への誇り
• keyboard_arrow_down いかなるミスも許されない。当時はまさに「黒ひげ危機一髪」
• keyboard_arrow_down 「それでも、やらねば」開発の軸となった3つのポイント
• keyboard_arrow_down 多重下請け構造を乗り越え 日本は「ものづくり大国」に返り咲けるか

大学ではコンピュータサイエンスを専攻し、スイスの大学院へ進学したという西田氏。卒業後はスイスのスタートアップ企業に就職したが、2015年に帰国したのを機に株式会社サイシードのCTOとして開発部門を率いることとなった。

西田氏の学んだスイスでは時計産業をはじめとした製造業が発達している。その影響か、スイスは人口900万人という比較的小さな規模の国にもかかわらず、国民の平均年収は約1000万円にもなる。国民は製品の品質に自信を持っており、「スイスメイド」と誇る風潮もあるという。

では、対する日本の（システム開発を含む）ものづくりはどうなのか？

そのような問題提起がなされた上で、本論である「コロナワクチン予約システム開発秘話」がスタートした。

サイシード社のコロナワクチン予約システムは現在、全国200以上の市区町村で導入されており、利用対象人口は約3000万人にも及ぶという。同システムは職域接種にも使われており、100社以上が導入済み。最速で申し込みの翌日から利用開始できるのが大きな特徴である。

このプロジェクトがスタートしたのは、2021年の2月のことであった。当時はちょうど高齢者に向けたワクチン接種（5月スタート）を控えた時期で、欧米で流行していたアルファ株だけでなく、デルタ株も迫っていた。開発は時間との「厳しい戦いになる」と覚悟したという。

サイシード社としては、これらの強力な変異株が襲いくる前に高齢者の接種を終わらせたい思いがあった。しかし、当時は日本へのワクチン供給が遅れていただけでなく、新型コロナ接触確認アプリ「COCOA」に瑕疵が見つかるなど、開発には逆風が吹き続けていた。

それに畳み掛けるように、ワクチン関連のインシデントが度々社会問題になっていた。事業所の保管不手際でワクチンが破棄処分になったり、余ったワクチンを医療従事者に接種したことが発覚して謝罪騒動になったりと、流行の終息が見えない中、新システムに対する世間の目は非常に厳しかった。西田氏は当時を振り返り、さながら『黒ひげ危機一髪』のような状況であったと表現した。

このような状況でシステムを提供するには、通常のシステム開発よりも数段上の気配りが求められた。実際に、他社の開発したシステムにトラブルがあった際は「重大欠陥」と報じられ連日取り上げられるなど、状況の厳しさを実感させられる出来事もあった。

そんな中、3000万人が使用するシステムに求められる要件は多岐に及んだ。まずは何より、短期間で開発すること。その上で、大量のアクセスを問題なく処理できること。もちろん、予約と個人情報を守る堅牢なセキュリティも欠かせない。しかも開発要件は、時勢に応じて頻繁に変わる。そのうえ「高齢者でも使いやすいUIを」と求められるなど、極めて難易度の高い開発であった。

それでも、誰かがやらねばならない。西田氏率いるサイシード社は、以下の3つを軸に開発を推し進めていった。

1. 1. 運用の全容を把握する
2. 2. 開発が運用を主導する
3. 3. コミュニケーションの基盤を整える

1. 運用の全容を把握する

開発に入る前に自治体側に開発要件をヒアリングした際はごくシンプルな要望が寄せられた。つまり、「接種券を市民に送り、市民がその情報をもとに接種会場を予約できるシステム」「予約はオンラインか電話で、2種類のワクチンから自由に選べるようにしてほしい」といったことである。

しかしこれは氷山の一角にすぎなかった。ヒアリングを重ねていくうちに、実際には

• ・自治体・医療機関の職員用アカウント管理機能
• ・接種の予約枠を作成・設定する予約枠管理機能
• ・予約状況の管理、予約一覧を出力（CSV）するための機能
• ・政府のワクチン接種履歴管理システム（VRS）と連携する機能
• ・1回目予約の日付に基づいて2回目を自動予約する機能

など、さまざまな要件が求められたのである。しかも、これらを管理する医療スタッフや自治体職員への権限付与も、職責によって細かく分けなければならない。認識のすれ違いはさながら、「小さな家を求められていたはずが、難攻不落の城塞を建てる必要があった」状況だったという。

こうしたすれ違いに気がつかないまま放置すると、開発工数の見積りに大きな影響を与えてしまう。

そこで同社は自治体と積極的にコミュニケーションを取り、「そのような運用をするのであれば、こうした仕様も必要になるのでは」と提案するのはもちろん、将来的に必要になるのであろう機能も初期から盛り込んだ。

システムの全体像をつかんだ上で、ときには開発側が運用側へ積極的な提案もする。西田氏によると、自治体向けのシステム開発においては、言われた仕様をただ実装するだけでは足りず、全体像を明らかにするためのコミュニケーションを密にとることが成功のカギを握るという。

2. 開発が運用を主導する

2つ目の「開発が運用を主導する」というのもこれに通じる話である。同社はシステムを開発するにあたり、起こりうる問題を先読みして対処しておくことを心がけていた。

例えば、国がワクチンを配分するにあたっては、ワクチン接種記録システム（VRS）に登録された接種状況を参考にしていた。一方で接種予約の受付は、ワクチンの供給が決まって初めて可能になる。こういった背景を踏まえると、「ワクチンを接種した端からシステムに記録していく」オペレーションが必要となる。

しかし肝心の記録手順はというと、タブレットで接種券を1枚ずつ読み込むという人力に頼ったシステムに頼っていた。これが登録のボトルネックとなり、うまくサイクルが回らないリスクがあるのではないかという懸念が浮上した。

そこで同社は、接種履歴を管理画面上で一括管理するシステムを構築。接種実績をVRS互換形式のCSVで出力することで、最大10万件の一括登録を可能にした。

3. コミュニケーションの基盤を整える

コミュニケーションの基盤を整えることは、「運用者と開発者の間で用語を正しく定義すること」という。

例えば、ワクチンを予約するにあたり、運用側から「1回目接種した人のみ2回目の予約を取ることができるような仕様がほしい」という要件を受け、開発側は「予定時刻を過ぎた人は、すべて『接種済み』ステータスにすれば良い」と考えたとする。

しかし実際には、予約はしたものの来場しなかったケースも存在し、全員に「1回目接種済み」ステータスを付与すると、実際には1度も接種していないにも関わらず2回目の予約ができてしまうといったトラブルが起こる。

当然、運用側からのクレームが届くわけだが、開発側は「そんなケースがあるとは聞いていない」と感じ、衝突が起きるといった事例である。

これを防ぐには、運用側のワークフローと開発側のビジネスロジックが齟齬のない形で噛み合っている必要がある。

例えば、「1回目接種済み（であり、2回目の予約を取ろうとしている状況）」であれば、ワークフロー側は左図のような流れを想定する。

つまり、2種類のうちからワクチンを選択し＞1回目接種済みかどうかを判定し＞接種済みである場合、前回から3週間経過しているかどうかを判定し＞すべてが「YES」の場合、最初に選んだワクチンと同じ種類で予約が可能、というワークフローになるというわけである。

一見するとシンプルなワークフローに見えるが、問題は「1回目接種済み」をどう定義するか、である。

そこで開発側のビジネスロジックとしては、「1回目接種済み」を右図のように定義した。

つまり、①1ユーザーあたりにつき予約は1つしか取れない②予約時刻よりも現在時刻のほうが後である③ワクチンを接種次第、接種状況を接種済みに書き換える。この3つの条件がいずれも満たされた場合のみ、「1回目接種済み」のステータスに変更される、というロジックとなっている。

このようにワークフローとビジネスロジックを噛み合わせておけば、誤った予約を防ぐことになり、市民にとって安全なシステムとなる。自治体向けのシステム開発においてもっとも重視される「安全」が守られるというわけだ。

さらにこのように噛み合わせておくことによって「運用側の（予期せぬ）ワークフローの追加に柔軟に対応できて、システムの長期運用と安全な拡張ができる」と西田氏は語る。

例えばコロナワクチンは当初ファイザー社・モデルナ社による2種類しか提供されていなかったし、２回の接種までしか想定されていなかった。しかし現在では、アストラゼネカ社製のものも加わっているほか、3回目接種も進んでいる。

ワークフローとビジネスロジックをきちんと詰めておけば、このようにワークフローが拡張しても、論理的に矛盾のない方法でシステムの拡張を設計でき、精密な検証を行える。なおかつ、自動化なども行いやすい。

西田氏は「これまで接種計画を妨げることなくシステム運用を続けて来られたのは、このように丁寧なコミュニケーションを続けてきたためだ」と語っている。

西田氏は開発当時を振り返った上で、日本のワクチン状況について「比較的早い段階で、安定的に接種が進んだ。世界的に見て、成功事例と言ってもいい」と評価した。

しかし一方で、日本のシステム開発については問題を投げかけた。その問題とは、日本特有の「多重下請け構造」である。

2021年9月にはデジタル庁が発足し、国主導でのDXを推し進めようとしている。しかし仮に、今回のようなシステム開発を国が主導した場合、元請け・二次請け・三次請け……と下請けに委託する多重下請け構造になったことは想像に難くない。

西田氏によると、多重下請け構造は、最終的な作業者へ渡る賃金が不当に安くなってしまう上に、機動力が損なわれる問題があり、今回のようなシステム開発は難しかったのではという。

「コロナワクチン予約システムの開発は、日本式のシステム開発へのアンチテーゼだと思います。多重下請け構造を乗り越え、『スイスメイド』ならぬ『メイドインジャパン』の誇りを取り戻したい」と西田氏は語り、セッションを締めくくった。

文・夏野かおる