コロナワクチン予約システムベンダーが明かす、365日奮闘の舞台裏②
こんにちは、サイシードCOOの叶です。こちらのnoteは、弊社サイシードがコロナワクチン予約システムの最大手ベンダーとして、コロナウィルスと共に怒涛の1年間を過ごしてきた舞台裏を3部作で紹介している第2部です。
エピソード1をご覧になっていない方は、そちらから読んで頂くことをおすすめします！
サイシードがコロナワクチン予約システムを成功に導いた7つのポイント
今回の記事は主に、開発者向けにシステム設計面での工夫について紹介していますが、開発以外の部分も含めて重要なポイントがあるので、1つずつ紹介していきます！
①迅速な組織変更の意思決定
LINE社の村井さんからのワクチン予約システムへの参画打診が年末にあったため、年末年始に説明会資料と組織体制の変更案作成を行いました。
弊社は開発メンバーを中心とした小さな会社なので、「組織変更」とは既存事業の切り捨てを意味します。
既存サービスの研究開発を中断し、クライアント企業への大幅な納期延長交渉（当然失注も少なくない）を行って、売上が見込めるかもわからない事業に参画するのは、かなり難しい意思決定でした。
ここで決め手になったのは、CTOの西田が「これは単なるシステム開発ではない、国民の生命がかかった重要なプロジェクトだ。コロナの感染が広がるスピードとワクチン接種スピード、どちらが早いかが問われている。自治体へのワクチンの配分、住民への接種をいかに効率的にできるか、その鍵を握るのが接種予約管理システムだ。これを短期間で作り切れるのは、我々をおいて他にはいない。」
と反対メンバーを粘り強く説得したことです。
ご存知の通り、西田は「田舎で一人暮らしがしたい」という理由で東北大に進み、情報学部を主席かつ飛び級で卒業し、スイス連邦工科大学の大学院を修了した後、現地ABBでインターン→テックスタートアップでAIエンジニアとして勤務し複数の特許を取得したが、なぜかホームシックになって日本に戻ってきた本物の天才です。
そんな西田ですが、国家公務員になろうかと迷っていたほど、日本に対して強い愛着を持っております。その西田の熱意と「お前ら税金で国立大に通ったんだから、その借りを返す千載一遇の好機だ！」という喝に押されて、我々は覚悟を決めました。
ワクチンに関わらないメンバーにも、納期の延長を受け入れていただいたクライアント企業にも、心から感謝しております。
②自治体向けマーケティング
弊社はこれまで積極的に自治体向けのマーケティングをしていなかったので、繋がりは多くはありませんでした。
そこで新規に開発するシステムを紹介するために、2つのサービスを利用しました。「ジチタイワークス」と「リスティング広告」です。
●自治体向けマーケティング支援の「ジチタイワークス」
自治体向けマーケティングといえば、ほぼ一択で「ジチタイワークス社」になります。
・適切な部署への郵送DMの発送、メールの配信
・ターゲット自治体へのアウトバウンドテレマーケティング
・導入事例冊子「ジチタイワークス」への掲載
など、超タイトなスケジュールの中でいくつもの施策を迅速に実施していただきました。
担当してくださった吉原さんには非常に感謝しております。
●Web広告運用代理店の「キーワードマーケティング」
リスティング広告は一般的な手法ですが、新しいサービスで競合が存在しない中では非常に効果的でした。
弊社には専門担当がいないので、キーワードマーケティング社に依頼をしておりました。
コロナ関連については、Googleの掲載基準で掲載されなかったり、ワクチンを巡るルールが目まぐるしく変わる中で、広告文言変更や運用を当日・翌日に行っていただくなど、迅速に対応いただきました。
担当いただいた川手さんにも、非常に感謝しております。
③直販はせず、BPOパートナーとの協業
説明会や個別の打ち合わせを経て、実際に自治体で利用いただけることが見えてくると、営業体制・サポート体制・法務体制が課題になりました。
自治体との契約も含めてすべてを自社で行うことは現実的ではなかったので、10社ほどの企業とパートナー契約を行い、弊社のシステムを利用頂く自治体のサポートを切り分けました。
一方でパートナー企業側も、自治体から事務局業務を受注している場合、独自でシステムを探す必要があり、ここでわかりやすいWin×Winの関係を作れたと考えています。
④業務オペレーション設計から始めることの重要性
上記の内容は弊社がベンチャーゆえに必要だった工夫ですが、この項目以降は会社規模に関係なくシステム開発において非常に重要なノウハウだと思っているので、発注する側も受託する側も知っておいて損はないと思います！
弊社が、業務効率化のためのシステムを開発する上で最も重要視しているのは、システム以前に業務オペレーションの設計です。
実は、事務局業務においてはコールセンターや書類確認に必要な人件費が数億円・数十億円になることは珍しくありません。
一方で、システムの費用は事務局予算の5-10%程度（あくまでも金額感のイメージ）なので検討が後回しにされがちです。
しかし、UI上の分かりやすさ、目的の操作までのクリック数、定期で発生する作業の支援機能など「システムの配慮」は人件費に対して相当なインパクトを与えます。
したがって弊社では、システムに直接的に関係しない部分も含め業務全体のプロセスを洗い出し、業務フローを想定します。
そして、業務フローに合わせて各業務の発生頻度も踏まえてシステムの機能を考えていきます。コロナワクチン接種においては、類似の事務局の経験が豊富なパートナー企業や、細部まで運用を想定されている自治体の優秀な担当者などと早期からディスカッションを繰り返してきました。
「システムの配慮」は仕様書には現れてこないですが、例えば10億円の人件費の30％を効率化できれば3億円の税金が節約できます。
システム単体で数十万・数百万円のコストを削減することよりも、全体を最適化する観点の方が、税金が関わるプロジェクトにおいては特に重要だと思います。
⑤大量アクセスを前提としたシステム構成
コロナワクチン予約システムにおいては、最初から「日本の全国民がサイシードの予約システムを同時に利用しても耐えられる」という視座で考えていました。
従って、ネットワーク構成は下記のように構成していて、工夫したのは主に4点です。
・SPA（Single Page Application）
SPAにすることで、ページを切り替える際にサーバーとの通信を行わないため、サーバーへのリクエスト数を最小限に抑えられます。
一般的な構成のWebサイトで、予約を取得するまでに10ページの遷移が必要だとしたら、それに比べてリクエスト数が1/3程度になるイメージです。
・キャッシュ
一度表示した結果を一定期間保持(キャッシュ)し、再度同じ問い合わせが来た時に、同じものを表示することで、サーバーへの直接のリクエストを抑える仕組みです。
例えば、10秒間保持されるとして、その10秒間に数万人のアクセスがあったしたとしても、最初にアクセスした1人と、あとからアクセスした残りの数万人は、同じ結果を見ることになります。
・バックエンドサーバ
サーバ面は、シンプルにEC2を使う構成にしました。理由としては、パフォーマンスやランニングコストの調整がしやすいためです。サーバレス化に関しては、予約や住民情報の登録ロジックが複雑になることが予想されるため、難しいと考えました。
詳細は伏せますが、かなり大きめのサイズのEC2インスタンスを最大16台という構成にし、システムが落ちることがないよう、増強・増設して挑みました。
また、冗長性に関しては、ALBを採用するなど、スケーリングの機構などは、もちろん入れました。しかし、オートスケーリングが発動するタイミングは、どうしても問題が起こってからの後出し対応になってしまうことが多いため、負荷が高くなると分かっている時間は、あらかじめ、スケーリングされた状態にしておくなど、そもそもオートスケーリングが発動しないような仕組みを採用しました。
・DBサーバ
DBは、予約枠の参照が一番使われるという仮定のもと、リードサーバを複数台建てることのできるAurora RDSを採用しました。これにより、負荷耐性の高いシステムにすることができました。
また、各自治体には予約アクセスのピークが集中する時間帯にCSVのアップロードをしないなど、サーバやDBに負荷をかけぬよう、運用面でのご協力をいただきました。
⑥エゴサーチからのアジャイル開発
開発手法は、スピードと変化への対応が必要なのでアジャイル開発で行いました。機能のアップデートとしては、下記のような例がわかりやすいと思います。
当然、様々な機能リクエストやバグ対応が出てくる中で優先度をつけて対応する必要があります。
パートナー企業経由で伝えられる自治体のリクエストはもちろんですが、積極的にTwitterで情報収集しておりました。
具体的には2つの観点でウォッチしています。
1,自治体職員、コールセンター担当者のアカウント
自治体担当者等は匿名で「コロナワクチン担当」というようなアカウントを作成して、Twitter上で情報交換や交流を行っている場合が多く、積極的に発信されている方をフォローしたり、Twitter上で非公式に交流させていただいています。
その目的は、担当職員の方がオペレーションで困っている点をシステムに反映させることです。
例えば、「1回目接種を広く普及させるという当初の政府の方針に対し、自治体では2回接種を完了させることの方が優先度が高い」という実情から、飛行機の往復チケットを取得するような「セット予約」の概念を導入しました。
初期の頃から交流させていただいていた方々は個人的には勝手に「同志」だと思わせてもらっています笑
2, 「サイシード」に関するエゴサーチ
予約システムを利用する住民がどこで躓いているかを把握するために有効なのが、自社名やサービス名でのエゴサーチです。
利用者は開発期間や政府のルールなど知らないので、サービス提供者としては反論したくなることもありますが、一般ユーザーの不満をダイレクトにキャッチできます。
例えば「会場はどこでもいいから、日付から探したい！」という、多くのユーザーが呟いている内容を参考に「日付検索機能」を前倒したりしていました。
⑦サービスに対する一貫した哲学
最後のポイントはあまり語られませんが、非常に重要な観点です。
アジャイル開発の落とし穴として、後から何でも変更できると思われてしまう点があります。
しかし、システムの改修と保守性（安定運用）はトレードオフの関係にならざるを得ません。社会インフラ同等の「サービス」として絶対に止めてはいけないという前提で、情勢に合わせて柔軟にアップデートを行っていくためには、システムの根幹（不変なもの）と枝葉（可変なもの）を明確に意識して設計し、根幹は何があっても改修しないという信念が必要です。
設計段階で将来的に、「接種間隔が変わるかもしれない」「接種券に対して、年齢という変数が増えるかもしれない」「何回も予約を取るかもしれない」と変数を想定できれば、状況に応じて改修を行うことができます。
逆に、「接種券ではなくメールアドレスで管理を行う」という根幹の改修は避けるべきと判断でき、代替手段として「仮接種券発行」でメールアドレスと接種券番号を対応させるという発想が生まれます。
これは一見簡単に思えるのですが、システムは概して運用期間が長くなると当初の哲学が忘れ去られ、根幹を含めた魔改造が行われがちです。
そうすると保守性が非常に悪くなり、バグが頻発しその原因もわからないという地獄に陥ります。一度こうなったシステムを立て直すのはほぼ不可能です。
自治体やパートナーからは根幹の改修要望が来ることもありますが、我々はITサービスのプロフェッショナルとして哲学を貫く必要がありました。
特に、顧客対応のフロントに立つメンバーは苦しい立場になりますが、開発チームを守ってあげるスタンスが求められます。
まとめと採用告知
今回のエピソード2では、戦略面や開発面での工夫について具体的に紹介させていただきました。
とはいえ、どんなに優れた開発戦略・哲学があっても、それを実現できるか否かは、最終的にはそれを実現する開発力にかかっています。
プロジェクトマネジメント、システム設計、インフラ構築、アプリケーション開発、テスト、デバッグのそれぞれの役割におけるプロフェッショナル達が会社にいてくれたからこそ実現できたと自負しています。
しかし、これまでの歩みは決して100点満点ではなく「もっとうまくやれたのに！」と思うことばかりです。弊社が更にレベルアップしてよりよいサービスを提供していくには、仲間が必要です。
様々な職種で全方位的に採用強化中なので、サイシードに興味を持って頂いた方は、ぜひお気軽にTwitterのDMからご連絡ください！
エピソード3では、公共領域のデジタル化とベンチャー企業にとってのビジネスチャンスについて紹介していきます。
同業界のIT企業や、自治体向けに事業を行っている企業にとっては有益な情報だと思うので、引き続きお付き合いください！
この記事が気に入ったらサポートをしてみませんか？