ミスできない状況下でのコロナワクチン予約システムの開発　仕様変更・追加のオンパレードも「運用の全貌把握」で乗り越えた

自己紹介

西田圭嗣氏：今日は「ワクチン予約システム開発戦記」ということで、我々はワクチン予約システムを提供している会社ですが、そのワクチン予約システムができるまでのストーリーをみなさんに話せればいいかなと思っています。

（スライドを示して）最初に自己紹介です。私は西田といいます。大学の頃からずっとコンピュータサイエンスを勉強してきて、大学院でスイスに行きました。スイスの大学院でコンピュータサイエンスの修士を取りましたが、その時の専門がコンピュータビジョンでした。

このコンピュータビジョンで、画像認識のエンジニアとしてスイスのスタートアップで勤務した後に、2015年に日本に戻ってきて、そこからサイシードのCTOとして開発部門を率いる仕事をしています。

（スライドを示して）Twitterは10年ぐらいやっていますが、最近5年はずっとROM専です。自分のバズったツイートの紹介で恐縮ですが、Twitterをやっていた中で最もバズったのが、左のスイスの物価に関するツイートでした。

ここに国民の平均年収が1,000万円と書かれています。少し話がそれますが、スイスはすごく豊かな国です。なぜかというと、観光資源もあるのですが、時計産業をはじめとした製造業がすごく発達している国だからです。時計だけではなくて、製造業のロシュやノバルティスも有名で、食品業界だとネスレもあります。

スイスは人口が900万人というすごく小さな国ですが、世界の時価総額ランキングでいうとトップ50に2社が入っている、製造業が強い国です。

それに対して日本は、1億2,000万人の人がいるにもかかわらず、入っているのはトヨタ1社です。スイスにはけっこう製造業が集中していて、スイス人は自国の製造業にすごく誇りを持っています。なので、自国の製品は「swiss made」というブランドを付けて売っています。

みなさんがロレックスなどの時計を持っている方がいるかどうかはわかりませんが、持っていたら下のほうに「swiss made」という文字が入っているので、それぐらいスイスの人たちは自分たちの国のことを、良質な製品を生産する国なのだと誇りに思っています。

コロナワクチン予約システム開発プロジェクトが始まった時の状況

（スライドを示して）それはさておき、今回はコロナワクチンの予約システムに関する話です。我々のコロナ用ワクチン予約システムは、人口のだいたい4分の1ぐらい。全国200の自治体・市区町村と3,000万人程度に使われている状況です。職域接種も100社以上が利用しています。

東京だと新宿区、渋谷区、世田谷区、杉並区などが利用していて、他ではさいたま市、福岡市、神戸市が利用しています。（スライドを示して）右下に住民用の画面を貼り付けました。もしかしたら該当の住民の方は使ったことがあるかもしれません。

（スライドを示して）このワクチンプロジェクトは、2021年2月から始まりました。その時の高齢者用の接種は5月から、一般の接種は8月からだったので、実は開発を始めてからあまり時間がありませんでした。

それに加え、欧米ですでに猛威を奮っていたアルファ株がすぐそこまで迫っていたのと、そのすぐ背後にはデルタ株も迫っていました。そのため、我々にとっては本当に時間との戦いでした。なんとかして強力な変異株がまん延する前に、高齢者にワクチンを接種したいというのが、我々が当時思っていたことです。

Yahoo!JAPAN ニュース「“第5波”はなぜ急激に減少したのか　尾身会長が語った5つの要素」

一方、当時の日本は感染者が比較的少なかったことと、ワクチンの製造拠点が欧米だったことから、ワクチンのそもそもの獲得に出遅れていました。だから、評論家には「このまま接種が遅れて、そのままグダグダになって進まないんじゃないか」と言われていたりしました。

それに輪をかけて、政府主導で開発した新型コロナの接触確認アプリのCOCOAが大コケしたので、ワクチンに関するシステムも「その先どうなの」と雲行きが怪しいような状況でした。

戦々恐々した状況で続いていたワクチンに関するトラブル

そのため、最初に「サイシードさん、ワクチン予約システムを作れませんか」と言われた時には、けっこう迷いました。我々としてもやはりかなり厳しい戦いになると予想はしていたのですが、一大事だし「これはもうやるしかない」と覚悟を決めました。

当時の日本社会の空気感はけっこうすさまじかったです。とりわけ次々と強力な変異株が現れていて、とにかくみなさんが早くワクチンを接種することを望んでいました。接種したい人で街が溢れかえっていたような状況で、「早くワクチンを打たせろ」という高齢者や、「1本でも無駄にしたら許さん」と言っている人がけっこういました。

そういう戦々恐々とした状況下で、全国でワクチンに関するトラブルが多発していました。例えば配送業者が間違ってワクチンを常温保存してしまい廃棄処分することになって、自治体の人が謝罪をしたり、ワクチンを保管している冷蔵庫に不具合があってワクチンが廃棄になり、冷蔵庫の製造会社が謝罪させられたりしました。

あるいは若い町長が、医療従事者枠で先行接種をしてなぜか晒されたり、別の町長が高齢者用のワクチンの余りを「来なかった人の分だからいいだろう」と自分で接種をしたら、それが晒されてしまったりしました。

今考えると、「別にそんな晒すこともないんじゃないの」ということでしたが、それでもバシバシ叩かれて、今考えればとんでもない状況だったんだなと思います。

「黒ひげ危機一髪」のようなミスできない状況でのリリース

そんな中、我々は予約システムをリリースしましたが、ミスできないというプレッシャーが我々の中には当然ありました。その当時の我々の様子を端的に表した画像が、黒ひげ危機一髪（の画像）ということで。どんなミスを引いても、一発アウトで即メディアとTwitterで晒されるような状況でした。

例えば、システムによくある問題です。システムがアクセスの負荷に耐えきれなくてダウンするとか、バグがあって予約画面から先に進めないとか、オーバーブッキングするとか。個人情報が漏れるとか、予約データが他人と入れ替わってしまうとか、接種期間の条件を満たさなくても接種できてしまうとか。そういう一つひとつの問題を、何を引いても一発アウトという状況で、我々はとにかく戦々恐々としていました。

我々だけではなくて同業者も同様の危機一髪をやっていて、実際にトラブルを引いてしまった会社もたくさんありました。よくあった事例は、アクセスが集中していた時の負荷に耐えきれなくて予約サイトにつながらなくなってしまったり、ちょっとした仕様の説明不足を揚げ足を取られてというか、けっこう大きめに書かれて、重大欠陥と呼ばれてしまったり。外部から攻撃を喰らってサーバーがダウンしたりという問題が多発していました。それら一つひとつが、軒並みニュースになっていました。

横浜市「市役所トップページ（総合案内）」毎日新聞「大規模接種予約始まる　アクセス集中で一時つながりにくく」

AREA.dot 「【独自】「誰でも何度でも予約可能」ワクチン大規模接種東京センターの予約システムに重大欠陥」Yahoo!JAPAN ニュース「不正アクセス受けコロナワクチン予約サイトが停止　千葉・君津市」

プロジェクトに求められていた大きなこと

振り返ればこのワクチンプロジェクトは、けっこう大きなものを求められたプロジェクトだったのではないかなと思っています。（スライドを示して）そもそも開発期間が2021年1月末〜4月末の3ヶ月で、（その期間で）ある程度かたちにしなければいけないことです。そして、開発後にいきなり数千万人規模の利用者がつくことと、みなさんがワクチンの予約に殺到して大量のアクセスが予約開始時に集中していたので、それらをさばかなければならなかったことです。

また、これらは住民向けのサイトの問題も当然ありましたが、それとは別に、コールセンター側の管理機能も提供しなければいけなかったので、その分実装すべきものが膨れあがっていたことです。

あとは、ご存じだと思うのですが、ワクチンの一連の流れはすごく変化に富んでいたので、システム的には仕様変更と追加のオンパレードでした。

自治体が提供するものだから、予約や個人情報を守る堅牢なセキュリティがどうしても必要だったのと、極めつけはWebを使ったことのない高齢者が突然この予約システムを使うということで、「使いやすいUIにしてくれ」という要望を受けていました。

我々はけっこう厳しい状況に追い込まれていました。まさに危機一髪ということで、我々の立場としてはトラに追われる鳥のような気分で、逃げ回るわけではありませんが、常に開発に追われていました。

ともあれやらなければいけなかったので、我々はその中でもできる限りのことをしようと努力してきました。特にこういう状況にあったので、仕様面に関してだけは致命的な考慮漏れやミスがないことを保証しようと、全力を注ぎました。

自治体からの要求は簡素だったが、蓋を開けたらそれは氷山の一角だった

（スライドを示して）特に我々が行ったのはこの3つです。1つ目は運用の全容を把握する。2つ目は開発が運用を主導する。3つ目はコミュニケーションの基盤を整える。この3つを、集中して行いました。

1つ目の運用の全容を把握するというのは、最初、自治体側から我々に寄せられた要求がすごく簡素でした。コロナワクチンの接種は、接種券を市役所から市民に送って、市民がその接種券を持って接種会場に行って、ワクチンを接種します。その時に接種会場に人が溢れてはいけないから、まずは必ず予約するようにしましょうと。

その予約をオンラインでやるか、もしくは電話でコールセンターに問い合わせてコールセンターの人が代行してやるか、いずれにしてもその2通りの予約に対しての予約システムを作ってほしいというのが、我々に対する最初の要求でした。

（スライドを示して）ところが、このシンプルな予約システムは、実は蓋を開けてみると氷山の一角で、実際に求められていたのにはこれだけの機能が必要でした。

例えば、まず自治体や医療機関がこのシステムにアクセスしなければいけないので、そのアカウントを作成して管理する。特に権限周りは当然このシステムには重要で、管理者の人にしか触れない機能や、その接種会場の中でも偉い人にしか触れない機能を細かく分けていかなければいけませんでした。

それから、接種会場の情報を細かく管理するための会場の管理機能です。ワクチン接種は予約制なので、予約枠を作成してそれを編集する、あるいはその予約の状況を管理する、あるいは出力するような予約枠の管理機能が必要でした。

さらに、政府が別にワクチンを記録するシステムである「ワクチン接種履歴管理システム（VRS）」を持っていたので、それと弊社の予約システムを連携するための機能を実装しなければなりませんでした。

これらの管理機能と同時に住民用機能があり、ここではワクチンの種別に応じて、予約の制御ができるとか、1回目の予約をしたその日付に基づいて2回目を自動的に予約するとか、そういう機能を搭載した予約システムを我々は作成しなければなりませんでした。

そうなると、最初に言われていた簡単な予約システムの要件から比べて、結局我々が実装したのは非常に巨大なものでした。

よくある話で、顧客が最初に説明した要件と実際にできあがったものがぜんぜん違うということです。別セッションでは例えば開発時の伝達ミスによって起こるようなことが明示されていましたが、我々のケースはその中でもこんな感じでした。

最初に提示された要件は「シンプルな家を作ってくれ」ということでしたが、最終的には、まるで熊本城のような難攻不落の要塞を作る必要性がありました。

密にコミュニケーションを取り、運用の全容を把握できたことがよかった

私たちは最初の段階でこの事実に気づくことができました。仕様のところに積極的に介入していって「あれ？　これって、この運用だったらこういうのが必要なんじゃないの？」ということを、顧客というか自治体の方々やコールセンターの方々と密にコミュニケーションを取ることによって深掘りしていきました。

最初の段階から、ある程度は「これとこれとこれは将来的に必要になるな」ということがわかっていて、そのための基礎を初期の設計に組み込んでおきました。

このおかげで後々の拡張に対応できて、それ以降に起こっていく変更にうまく追従できたので、これが1つすごくよかったポイントなのではないかなと思っています。

1点目で我々がどうしても言いたいことは、初期にいかにプロジェクトの全体像をつかむかが重要だということです。あるいはそれを顧客なり、運用側の人たちに突っ込んでいって、全部を把握するまできちんと話を聞くことが、非常に重要なのではないかと感じています。

（次回に続く）