東京都の新型コロナ対策サイトはなぜNuxtJSだったのか? ─ シビックテックのベストプラクティス

東京都が3月初旬に公開した新型コロナウィルス感染症対策サイトは、モダンなWeb技術を使いオープンソースの手法で開発されました。シビックテックの活動から生まれたベストプラクティスについて、開発者のお2人に聞きました。

東京都の新型コロナ対策サイトはなぜNuxtJSだったのか? ─ シビックテックのベストプラクティス

東京都が2020年3月3日深夜に公開した新型コロナウイルス感染症対策サイトは、都内の感染動向が見やすく整理されているだけでなく、NuxtJSベースのSSR(Server Side Rendering)で静的ホスティングにNetlifyを採用したサーバレスなSPA(Single Page Application)というモダンな技術選定がWebエンジニアの間で注目を集めました。

ソースコードはGitHub、UIデザインをFigmaで管理しているため、社会的な問題の解決に協力したいエンジニアが改善提案などをコントリビュートでき、開発環境ではCI/CDも整備されており、適切なオープンソースライセンスMIT Licenseが付与されているので各地方自治体向けの派生版を自由に作成できる──。

こういったオープンソースのマナーに則ったこの対策サイトは、元ヤフーCEOの宮坂学@miyasaka東京都副知事が組織した特別広報チームの委託を受け、関治之@hal_skさんが代表を務めるCode for Japanが開発しました。

1東京都新型コロナウイルス感染症対策サイトを開発|コード・フォー・ジャパン

Code for Japanは、行政ではなかなか手が届かない地域の課題をテクノロジーの力で手助けするシビックテックという活動をしている一般社団法人で、2011年の東日本大震災後直後に開発者コミュニティから立ち上がった支援の動きの中から生まれました。

急を要する対策サイトにおいてなぜこのようにモダンな技術要素が選定でき、実際にはどのように開発を進めたのか? サイトのローンチまで少数で開発にあたったコアチームのメンバーである小副川健さんと池田達哉さんに、今回のプロジェクトを支えた技術の背景から、シビックテックに携わるエンジニアのあり方までお話を伺いました。

小副川 健(おそえかわ・たけし) 2oso_ken 3osoken

4
株式会社ユーザベースでSPEEDA事業のチーフデータサイエンティストを務める。筑波大学大学院で数理物質科学研究科博士課程を修了後、富士通および富士通研究所でのデータサイエンティスト・研究員を経て、2018年から現職。データサイエンティストとしてコードを書くキャリアは現在9年目。

池田 達哉(いけだ・たつや) 5yokinist 6yokinist

7
文科系の学部に在籍しながらシビックテックに興味を持ち、関治之氏の「右腕インターン」として1年ほど関わる。その後いくつかのシビックテック活動やインターンシップを経て、株式会社almaの創業に参画。プロダクト開発をリードするかたわら、共同設立したCode for Youthなどでも活動する。学習院大学4年。

なぜNuxtJSだったのか? あるいはjQueryでなかったか?

── まず最初に、今回の技術的なバックグラウンドから聞かせてください。一見すると行政が関係した仕事とは思えない現代的な技術選定のWebサービスですが、この構成はどうやって決まったのでしょうか?

小副川 私が最初に話を振られた時点では、最終的にデータを静的なサイトに表示する仕組みが必要というだけで、特に技術的な決定事項はありませんでした。

ただ、Vue.jsのフレームワークであるNuxtJSを使うこと自体は、これまでCode for Japanで開発してきた経験からすんなりと決まった感じです。

── 詳しく教えてください。

小副川 2018年7月に西日本で発生した集中豪雨に伴う水害を機に開発された「紙マップ」というアプリケーションがあって、現在はNuxtJSで開発されています。

8- 紙マップ

このサイトでは、避難場所などの地図を紙に印刷するのに最適な状態でWebブラウザ上に表示できるのですが、当時はjQueryで書かれていました。地図を扱うのにLeafletというJavaScriptライブラリを使っていて、もちろんTypeScriptではありませんでした。

── 2018年にjQueryだと、すでに時代遅れ感がありますよね。

小副川 はい。しかし、そのときはむしろ「jQueryでうまくいったね」という認識だったんです。そのプロジェクトで集まったのは、私を含めて「jQueryなら書ける」という30代のエンジニアが多かったので、メンバーに合わせた技術が採用できました。

── このサイトをどこかのタイミングでNuxtJSに置き換えたわけですね。

小副川 去年(2019年)の台風19号です。千葉県を中心とする被害の情報公開で、西日本豪雨のプロジェクトを再利用しようと改めて複数人で開発を始めたんですが、jQueryだとどうしてもコンフリクトが多発してしまう。

これはコンポーネントベースの仕組みに移行しないとまずいということで、Vue.jsで書き直しました。

── ということは、東京都のサイトもわざわざモダンな仕組みを狙ったのではなく、これまでの開発経験からの選択だったんですね。

小副川 はい。全員が触りやすく、コンポーネントベースで、複数人で開発してもコンフリクトが起きにくいものを選んだら、自然とNuxtJSになりました。選択肢としてはReactもあったのですが、紙マップの経験があったのでVue.jsを選んだわけです。

── 結果的には、その選択が功を奏して、「この技術だったら参加したい」という形でコントリビューターが一気に増えた面もありそうですね。

池田 確かに、これがjQueryと最小限のHTMLで作ったサイトだったら、これほどエンジニアから注目されることはなかったかもしれないですね。

小副川 もちろんエンジニアの反応を見越して技術を選定したわけではありませんが、後になってから「Vueにしておいてよかった」という話を関さんとした覚えはあります。

池田 フロントエンドにおいて、日本ではVue.jsやNuxtJSの技術コミュニティが発展していることもある気がします。

偶然に決まったNetlifyは開発にとても役立った

── ソースコードをGitHubで公開することは最初から決まっていたと思うんですが、ホスティングでNetlifyを採用したのはなぜでしょう?

小副川 静的コンテンツなので、最初はGitHub Pagesでよいのではという話になっていました。それがNetlifyになったのは、聞いた話ですが、SSLサーバ証明書の関係で要件を満たせるサービスとして選択肢に上がってきたようです。

── ちなみに、Netlifyは新型コロナウイルスに関する情報提供でのサービス利用については無料期間を延長することを3月22日に発表していますが、東京都のサイトのリリースはその前でしたね。

小副川 はい。最初は無料プランで登録していて、途中からビルド回数か何かの制限に達して有料プランに移行したようです。

池田 Netlifyにしたおかげで、レビューがものすごく楽になったんですよ。

GitHub Pagesに書き出していたときは、各自に撮ってもらったスクリーンショットをもとに判断したり、細部を確認するにはビルド結果を毎回自分たちで生成する必要があったんですが、Netlifyだとビルド結果をもとにステージング環境を勝手に作ってくれるんです。

小副川 公開後にコントリビューターが増えたときにも、Netlifyにしていたおかげでプルリクエストのレビューがしやすくて助かった面もあります。CIを適切に設定すれば「このプルリクエストをビルドしてデプロイした結果」のURLを教えてくれるんです。

これがなかったら、プルリクエストをローカルに取り込んでビルドしてから確認することになっていたと思うので……。

── ちょうど話に出たCIなどの自動化も話題になっていましたが、工夫されたことはありますか。

池田 CIではGitHub Actionsも使っていて、マージ前に必ず一回はESLintが走るようにしたりとか……。

小副川 ESLintはありがたかったです。

池田 エディタによって自動整形されて、本来の差分が分かりづらくなるという問題があったんです。また、レビューの際に打ち間違えやインデントなど細かいことで時間が取られるともったいないので、開発の初期段階から、コミット前にlintをかけたりインデントの自動修正をしたりする設定を導入していました。

小副川 GitHub Actionsはデータの取り込みなどでも使っていますね。自動化では池田さんが手を動かしてくれました。

池田 最初は人手が足りない状況でマンパワーが求められたので、ひたすらコンポーネントを作って、ページを組み立てていきました。開発環境については特に指定していなかったのですが、コントリビューターの数が増えていくとさまざまなケースを考慮する必要がありました。

Dockerで開発している場合など、開発環境によってはコミット前のフックがうまく動かずにlintをスキップしてしまう事例もあったので、GitHub Actions経由でもreviewdogでESLintを回して二重チェックし、lintが通らないとマージできないような設定にすることで、ある程度のコード品質を保てるようにしていました。

後でコンポーネントを変更改善できるよう小さく作る

── 小副川さんは、主にどういった開発を担当されたのでしょうか?

小副川 nuxt initコマンドを実行した初期状態からテーマを差し替えたり不要なコンポーネントを整理したりして、それを最初に東京都のリポジトリにプッシュしました。

それから対策サイトでは、カード形式の四角い枠がいくつか並んで表示されるのが基本構成で、その枠の中に棒グラフやテーブルが表示されるようになっています。これは、例えばDataViewなどのVueのコンポーネントとして作り、そのSlotに中身を差し込むことで実現しています。

そういったコンポーネントをそれぞれ作り込みながら、いろいろなデータで使える共通の部品にする作業をしていました。私が雑に作った棒グラフやテーブルに、Cookpadの藤井謙士朗@kenshir0fさんがデザインを当てていたり。

── UIデザインでは藤井さんと宇野雄@saladdaysさんが参加されていたんですね。

9東京都の新型コロナサイト誕生秘話、行政らしくない爆速開発はDXのシンボル | 日経クロステック(xTECH)

小副川 その後もいろいろな人が改良を加えてくれているので、私が書いたコードが今も残っているかは分かりませんが……。

── どんなライブラリを使うかなどは、実際に手を動かすエンジニアの裁量で進めていたのでしょうか?

小副川 大前提としては「使える人が多い」ことで、ある程度の軽さがあるものをみんなで考えました。

例えば、グラフを描画するJavaScriptライブラリではd3.jsが大好きなのですが、これは学習コストが比較的高い。そのため、どちらかといえば使える人が多く、変なグラフが作られにくい構造のchart.jsを選択しました。

もちろん導入した後で「こっちの方がいい」と指摘されて直すこともありました。時間表示のライブラリで、最初はmoment.jsを使っていたのですが、チームで「day.jsの方が軽い」という会話があって途中から変更しています。

── 四角い枠のカードは、サイトが公開された時点ではコールセンターの相談件数など4つくらいでしたよね。

小副川 はい。あとは、感染者数の推移、検査人数、感染者の年齢や性別の一覧表あたりだったと思います。

10

開設当初に提供されていた「都内の最新幹線動向」のカードは4つ

── それが今では13枚になっています(2020年5月15日現在1。公開後に情報が増えることを見越して共通の部品を作っていったわけですね。

小副川 最初はとにかく急いでいたので、きちんと作り切れていないと自覚していた部分もありますが、見た目をそろえようといったことは意識していました。

── サイトに掲載できる情報は東京都が用意できるかどうかに依存するわけですから、勝手に考えておくことは難しいですよね?

小副川 具体的には分かりませんが、後で追加される準備中のデータがあるといった話は間接的に聞いていました。

いずれにせよ、まったくサイトがない時点では誰にも正解が分からないので、いったんミニマムなものを作ろうという方針にしてよかったと思います。

── 宮坂学副知事が組織した東京都の特別広報チームでも、そういった方針だったとインタビューで答えられていますね。開発期間もかなり短かったようですが……。

11東京都の新型コロナ対策サイト“爆速開発”の舞台裏 オープンソース化に踏み切った特別広報チームの正体 (1/4) - ITmedia NEWS

小副川 感染状況を独自にまとめているWebサイトは報道機関のものを含めてすでにいくつかありましたし、個人的にも「早くリリースしないと都民のためにならない」という思いでやっていましたから、開発スケジュールがタイトであることに違和感はありませんでした。

── 開発初期に意識されていたことは他にありますか?

小副川 ちょっと違いますが、感染者数などの数字に3桁ごとのカンマをいれるフォーマッターを修正しているときに「このフィルターが使われないといいですね」と話していたことが印象に残っています。つまり、数字が1,000に届かないことを願っていたのですが……。

── リリースした日はまだ新規感染者数が4人でしたね……。

小副川 棒グラフの横幅も固定長のままだったんです。エンジニアリング的には長く使えるよう可変長にするんですが、長期化する前提でコードを書くことにちょっとした抵抗がありました。半ば「祈り」と言ってよいかもしれません。

ベストエフォートでの開発体制

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く