ワクチンの配分スケジュールで起こり得ると予測した問題
西田圭嗣氏：2点目は、開発が運用を主導することです。
これはどういうことかというと、我々は、起こり得る問題を先読みをして対処することを意識して開発していました。
（当時）政府はワクチン接種記録システム（VRS）を使って国民の接種状況を管理したいと考えていました。それに基づいて各自治体がVRSに接種状況をどんどん登録していくので、政府がそれを見てワクチンの配分スケジュールを決定していました。
接種の予約はワクチンの配分スケジュールが決まってからでないと予約枠を作れないので、兎にも角にもワクチンを配分してもらうためには、このシステムに記録しなくてはいけない。ワクチンを打ったら、片っ端からそれをシステム上に記録していくオペレーションが必要でした。
ただ、そこで政府が推奨したやり方は、タブレットで接種券を1枚ずつ読み取るというものでした。当然これにはすごく読み取りには時間かかるし、ミスも発生します。我々は接種記録を登録する部分がボトルネックになってしまって、サイクルがうまく回せなくなるのではないかと最初に懸念というか、予期していました。
対処法として追加した接種履歴の出力機能
この問題を見つけた時に、我々は急遽予約システム上に接種履歴の出力機能を追加することで、この問題を解決しようと試みました。
接種履歴を我々の予約システム上で取り扱うというか、「この人は接種済みだよ」ということを管理できるので、それを一括でVRSに互換可能な形式であるCSVで出力して、（そうすると）接種結果一覧がCSVでズラーッと並ぶので、それを最終的にVRSにアップロードすることで、接種状況登録を一括で行って、ボトルネックを解消しました。
この試みで先手を打ったことで、なんとかサイクルが回らないとか、エラーが起こる問題を解決しました。
残念ながら弊社のシステムを使ってこなかった自治体さんは、けっこうこの問題に苦労したみたいです。というところで、端的にやっておいてよかったなと思っているところです。
開発の現場で起こるコミュニケーションの問題
最後に、コミュニケーションの基盤を整えることを言いたいと思います。
開発の現場において、往々にして起きる問題ですよね。仕様に関するコミュニケーションの齟齬というか、仕様策定をする時に十分に時間が取れなくて、運用者と開発者の間で情報を十分に共有できない。そういうことが開発の現場では多々起こっています。
例えば、ワクチンだったら、1回目の接種した人が2回目の接種を受けられる。接種後はその予約ができる仕様でないといけません。
この仕様策定やコミュニケーションを怠ると、開発側が「ワクチンを予約時刻に接種するということは、その予約時刻を過ぎたらもう全員接種したってことにしちゃえばいいんだな」と勝手に思い込んでしまい、その後その時刻が過ぎた人はすべて予約が取れるようになってしまいます。
そうすると、予約だけをして接種会場に来なかった人も2回目の予約が取れるので、「どうなっているんだ」とお叱りを受けることになります。ただ一方、開発側は、「そんなケースがあるなんて聞いていない」ということで、コミュニケーションの齟齬が起きて失敗してしまいます。
当然こんな問題は起きないので、これはすごく陳腐な例ですが、このバリエーションというか、多かれ少なかれこのようなケースが実は開発の現場では起きているのではないかなと思っています。
運用者と開発者の間で用語を正しく定義する重要性
我々がそれに対してどういう対処の仕方をしたかというと、とにかく最も重要なのは運用者と開発者の間で、用語を正しく定義することだと感じています。
（スライドを示して）例えば、1回目の摂取済みに対しては対象のユーザーがいて、そのユーザーに紐づく予約が1つであること。それから、予約時刻より現在時刻のほうが後であること。それに加えて、接種状況という人為的にいじるパタメータを作って、それを接種をしたら物理的に書き換えることによって接種済みになること。
この3つの条件です。この3つの条件が満たされた時に、ユーザーのステータスは1回目接種済みになると定義をして、それを開発と運用の間でしっかりと合意しておくことを心がけています。
例えば、ワークフローは運用側が主導権を持つもので、ビジネスロジックは開発側が主導権を持つものですが、スライドのような流れにすることで開発の中でのロジックやフローを、齟齬のないかたちで接続できます。それが非常に大きな利点です。
それがどういうふうに活きるか、ワクチンの事例でいうと、ワクチン（予約システム）はもう1年以上続いていて、長期運用をしているので、それに耐えられるシステムになっていなければいけません。
例えば、初期の段階ではファイザーとモデルナという2種類のワクチンしかありませんでした。
時を経てアストラゼネカが追加され、さらに時を経て、どのワクチンでもOKですが、3回目の接種のプロセスが追加されました。
運用の中でワークフローが追加あるいは変更されたとしても、きちんと「これは何か」という定義にさかのぼってデータと照らし合わせることで、そこに処理上論理的な矛盾がないかどうかを検証できます。
この検証を経ることによってシステムの安全な拡張が可能で、テストの設計や、さらにいえば自動化もしやすく、必要なテストケースも少なくて済むという利点が生まれます。
我々は運用の全容を把握するとか、開発の運用を主導するとか、コミュニケーションの基盤を整えるということをやってきましたが、このおかげで問題を起こしたりとか、接種計画を妨げることなくここまでこられているのではないかと思っています。
日本が抱える多重下請け構造という問題
今あらためて振り返ってみると、日本のワクチン接種は初動は遅かったのですが、比較的安定的な早い接種で、10月には世界のトップに立っていたので、すごくよかったのではないかなと思っています。
これに対して予約システムがそれほど貢献したとは思わないというか、どれほど貢献したのかはわかりませんが、それでもこれは我々と日本国にとって1つの成功体験で、誇れる出来事だったのではないのかなと思っています。
NHK「世界のワクチン接種状況」,ワクチン接種が完了した人（割合）
「ワクチン予約システムを国が開発すれば、もっと効率的だったんじゃないの？」という意見をもらいます。ワクチンではありませんが、デジタル庁が発足して、国のシステムを一括で管理をしていくようなことを国主導でやろうとしています。
しかし、日本はけっこう大きな問題を抱えています。それは何かというと、多重下請け構造という問題です。元請けから二次請け、二次請けから三次請けというように一方通行で流れていく構造と、それからその間には壁があって、開発からは顧客のことが何もわからないということです。
そういう状況がある限り、このコロナワクチンのような、機動性を求められるプロジェクトは難しかったのではないのかなと僕の観点からは思っています。
株式会社サイシード が提唱したいアンチテーゼ
（スライドを示して）それに対して、我々が提唱したいことはアンチテーゼです。多重下請けの構造の分断に甘んじず、運用と密に連携を取って、開発が運用を理解するとか開発が運用を主導するとか、コミュニケーションの基盤を整えるとか。そういうことをしっかり実践して、長期の運用にも耐えるシステムを開発することを目指しています。
これによって多重下請け構造の問題を克服して、日本のIT業界を変革していきたいと考えています。
（スライドを示して）これは最後のスライドです。冒頭になぜかスイスの話を始めて、「swiss made」というものがあるという話をしましたが、我々日本には、「MADE IN JAPAN」という表記があります。
30年という長い停滞の中で我々はもの作りに関する誇りを失いつつあるんじゃないかと、失ってしまったんじゃないかと。そういうふうに感じることも多々あります。
これには先ほど示したような構造的な問題がけっこう大きな要因になっていると考えていて、弊社はこの問題を解決したいと思っています。
事実、我々の手法によって、荒波に揉まれたワクチンの接種プロジェクトはある程度うまくいったわけです、なので、我々はこれから成功体験を積み重ねていって、日本がIT大国として、「MADE IN JAPAN」を誇れるようにしていきたいと考えています。以上で今回の話は終わります。
最後にちょっと話せといわれたので話します。（スライドを示して）弊社では今、プロジェクトマネージャーを絶賛募集しています。
先ほど「MADE IN JAPANを盛り上げていくんだ」という話をしたのですが、まさにデジタル庁がこれからやろうとしているような、行政向けのシステムにも我々が足を突っ込んでいきたいと考えています。
デジタル庁がガバメント・クラウド・プロジェクトをやろうとしています。自治体のIT基盤も一新するというプロジェクトなので、それを我々も一翼を担っていきたいと考えています。
ワクチン予約システムのようなスケジュールのハードなプロジェクトにはしたくないですし、我々も生活が重要ですし、健康も重要です。当然リーズナブルに進めていきますが、ガバメントクラウドみたいな自治体向けのプロジェクトをやることが、我々のその次の日本のITシステムを作るうえでとても重要だと思っています。
もしこういうものに興味がある方がいれば、ぜひお声がけください。きっとこの求人情報はどこかに貼られると思うので、ぜひそこから探して応募というか、お食事でもいいので声をかけてもらえれば幸いです。
以上です。みなさん、ご清聴どうもありがとうございました。
