今回のヤシオリ作戦遂行に際し、放射線流の直撃や急性被曝の危険性があります。
ここにいる者の生命の保証は出来ません。
だが、どうか実行してほしい！
我が国の最大の力はこの現場にあり、自衛隊はこの国を守る力が与えられている、最後の砦です！
日本の未来を、君たちに託します。

内閣官房副長官・政務担当の矢口蘭堂議員（衆院・山口県第3区選出）の発言です。

ここで言及される通称ヤシオリ作戦とは「ゴジラの細胞活動を停止させるための血液凝固剤」を民間の化学プラントなどの設備を総動員して生産し、民間からかき集めた特殊車両を使って自衛隊がゴジラに経口投与するという、米軍の有志まで参加して実行された日米官民協同プロジェクトです。

と、ここまでは2016年公開の映画の話ですが、今になって見返してもなお細部に発見があって面白くてやっぱりこの映画は庵野監督の、ということを書きたいわけではなくてですね、まさか自分が現実でこのような事態に遭遇するとは思わなかった、そしてそれが割とシン・ゴジラだった、しかも現在進行形でその渦中にいる、という奇妙な立場において何かその記録を残したいと思ったのが、超久しぶりに文章を書くモチベーションとなりました。

is 誰

この文章を書いてるのはファッション→WEB制作→アプリ制作という経歴のデザイナーです。企画、デザイン、設計、エンジニアリング、ビジネスという異なるチーム間を行き来しながら、採用、見積もり交渉、顧客対応まで担当しながらその全てを「デザイン」としてやっています。
（なので、申し訳ありませんがシステムチックな単語とかも登場します）

そんな理由で新しい案件の話が出ると、要件定義や仕様策定、メンバーのアサイン、スケジューリングと費用見積もり、請求額の提案などをやるわけですが、今回の話も最初はいつもと同じような、大きな話ではないというと語弊がありますが、数週間〜1ヶ月程度の話かなと思っていました。最初は。最初はね。

1月13日 『自治体向けワクチン接種ソリューションの共有』

ことの始まりは、新年開けて間もない1月13日。まさにこのタイトル通りのスケジュールが入った通知を受け取り、最初は「何か新しいことやるんだな」くらいに思ってました。
ウチは前から自治体さんと何かに取り組むことがあったし、共有って書いてあるので新しい案件の頭出し（こういうことやるよ、エンジニアチームも認識しておいてね、という伝達メインのミーティング）かなと思ってたのです。

そこで明かされたのが、新型コロナウィルスのワクチン接種に関する予約受付システムの開発、という内容でした。ビジネスチームはそれを、LINEベースのチャットボットの機能を軸に専用機能を追加開発して1ヶ月くらいで実装して2月末にリリース必須の予定でいる、ということが共有され、アサインするエンジニアは別のチームから連れてくるから現状の開発には影響しないと、そういう話でした。

ちゃんと検討してみると

ミーティングはその場で解散しましたが、ほんとにそれでいいのかな？と思って後日エンジニアチームで見積もってみたんです。新型コロナウィルスのワクチンなんてそれこそたくさんの人が接種するだろうし、そもそもLINEのMessaging APIは1秒あたり2000リクエストという上限があるので、アクセスが殺到した時点で捌くのが無理になってしまう可能性が出てきてしまうんですね。

2000の壁問題

もちろんそれはAPIアクセス前に秒間2000を超えたらちょっとwaitさせる的な制御を入れればいいとは思うのですが、それにしても前段のAWS（Cloudfront）でも暖機申請とか必要になるんじゃないか、そもそも予想される同時アクセス量はどれくらいなのか見積もるためには接種の見込みスケジュールが必要なのに、国からは明確な数字がない状態で、それどころかワクチンの確保とスケジュールも確定していない状況でした。

これはささっとボットに機能追加して捌ける話ではなく、専用のシステムを開発する必要があるというのがエンジニアチームの出した結論でした。
その上で既存システムとはAPIで疎結合に連携させて、インフラは相当なスパイクを見越してエラスティックな設計にする必要がある、それがないと、予想されるアクセスの集中に耐えきれず、結果として多くの人がワクチン接種の機会を逸失してしまうことになります。

ざっくり見積もっても最短で3ヶ月程度は必要な規模のシステムです。共有された時点が1月13日なので、3ヶ月としても4月中旬リリースってなります。しかし、この時点でビジネスチームが取りまとめた内容が2末リリース。見積もり時点で2ヶ月半の乖離というのは、早くも大波乱な予感しかない状態。。
これをどう進めるのか、まずビジネスチームに共有すべきかどうか、共有したとしてもう契約が進んでたらどう進めたらいいのか、、悩ましいところですが一人で考えても仕方ないので、まずは素直にエンジニアチームの見積もりとざっくり設計を伝えることにしました。

2ヶ月の壁問題

これはITあるあるだと思ってるんですが、受注を優先してクライアントと現実的ではない内容を握ってしまう、ということが起こります。
かなりシステムを理解している営業でも、実際の仕組みや工数まではなかなか見えないので仕方ないんですが、そうなると生まれるのが契約後に見積もりスケジュールと現実スケジュールの乖離が判明するという悲劇で、往々にしてそれは巨大なシワとなってエンジニアチームに押し寄せてというか襲いかかります。
今回も既に2ヶ月の解離が生まれてしまっているので、まずはこの壁をどうするかを考えないといけません。

そこでエンジニアチームであれこれ検討した結果、段階的リリースをするしかないという話でまとまりました。クライアントの要望を叶えつつ必要な機能に優先順位を付けて、機能を段階的に足していく方法です。
開発的にはあまり望ましくないんですけど、無茶なスケジュール最優先だったり既に契約してしまっているのに無理な内容だったり、つまりピンチの時に発動する最終手段の一つです。
（最終手段の割に登場回数が多い気がする）

今回の件でいうと、最も必要なのが ワクチン接種を受けたい人の予約を全て受けられること と 自治体側が会場や予約枠を管理できること の2点。でもそれを全て画面から操作できるようにするにはそれなりに時間が必要です。
そこで、まずはその予約と管理だけに機能を絞って、スケジュール的に実装可能な方法で作ってリリースすることで、最初の壁を乗り越えようという提案を行いました。

1月29日『ワクチン接種プロジェクト キックオフ』

自分は立場上エンジニアチームだけでなくビジネスチームや事業部長とも何かとコミュニケーションが生まれやすく、ランチのことから副業の節税方法まで色々話すのですが、今回のことはあまりに乖離が大きいので別途ミーティングを設定して説明することにしました。

ポイントはシンプルで、今のビジネスチームの想定だとシステム的に耐え切れないので仕組みを変えよう、ということ。伝えれば分かってくれるとは思っていましたが、2ヶ月の解離が大きいという認識を共有して合意を得ておかないと、今の小さな火種が巨大な烈火になるのは目に見えています。
言いにくい気持ちをポイッと捨てて、リリースは早くても3月末を超える見込みであることを伝えました。

もちろんそれはクライアントである自治体さんまで提案して合意を得ないといけないのですが、これなら大丈夫っていう確信を持っていただけるように設計して資料を作り、心苦しいけどビジネスチームに伝えてもらい、無事に許容してもらえることになりました。

くすぶる火種があちこちに

他にその時点では、接種券というものを自治体が配布するらしい、それには番号が振られてるらしい、それによって誰がいつ予約したか分かるようにするらしい、でも住民側は個人情報を入力せずに接種券の番号と生年月日だけで予約できるようにする必要があるらしい、ということが伝えられていました。この時はまだ幸か不幸か未確定要素が多かったのです。

未確定なことは多いけど、それでも光り輝く売上額というものが積み上がっていくことになり、段階リリース作戦を取り入れた予約システムの開発がスタートすることが決まったのでした。
そう、まさか自分が内閣官房とミーティングしてそこに大臣も登場することになるとは微塵も予想しないままに。

つづく。