接触確認アプリ「まもりあいJapan」プロジェクト参画を経てーー社員5名による知見の共有と振り返り
6月19日に実施された社内会議で、新型コロナウイルスの接触確認アプリ「まもりあいJapan」プロジェクトの弊社参画メンバーが登壇し、活動内容を報告しました。
「まもりあいJapan」は、一般社団法人 コード・フォー・ジャパンが独自に開発を進めてきたアプリおよびプロジェクトチームの名称。アプリは、スマートフォンに搭載されているBluetoothを使い、新型コロナウイルス感染者と濃厚接触した可能性を通知するものです。
モンスター・ラボからは12名が参画し、主にバックエンドの開発に携わりました。本記事では、参画メンバーが発表した開発の成果・知見を抜粋してお届けします。
※5月8日、厚生労働省が接触確認アプリ「COCOA」を一元的に開発することを決定。
目次
「まもりあいJapan」の概要と経緯（御供 翔豪／バックエンドエンジニア）
「まもりあいJapan」は、モンスター・ラボのミッションにも含まれる「テクノロジーで世界を変える」を体現するようなプロジェクトだったのではと思っています。
そのなかで、普段のプロジェクトではなかなか難しい進行や、開発における新しい取り組みがあったので、私からはそのような知見をシェアできればと思っています。
まず「まもりあいJapan」は何かというと、新型コロナウイルス接触確認アプリのいち実装の名称です。同時に、アプリの開発を中心としたプロジェクト活動や、活動を行ってきたチームの名前でもあります。
「まもりあいJapan」の画面。メッセージやビジュアルからも行動変容を促すものに
次に、接触確認アプリとは何なのかという話をします。接触確認アプリは現在、世界各国で開発が進められていますが、国によって状況や社会的背景が異なり、それゆえにその設計思想も異なります。「まもりあいJapan」アプリが持つ主な機能は以下の2つです。
1つめは、BLE（Bluetooth Low Energy）通信を利用し、スマートフォン端末同士の「濃厚接触の可能性」を記録する機能。
2つめは、陽性判定を受けたユーザーとの「過去の濃厚接触の可能性」を通知する機能。
この2つの機能とデザイン・メッセージを通じ、ユーザーに行動変容を促すことで、新型コロナウイルスの感染拡大予防を目指していました。
本アプリでは、電話番号や氏名などの個人情報、GPSなどの位置情報を取得しません。接触者の情報は各スマートフォンの端末のみに保存され、プライバシー保護に寄った仕様になっています。詳しくはコード・フォー・ジャパンの勉強会でご確認いただけます。
[youtube]
[/youtube]
コード・フォー・ジャパンは、行政機関のテクノロジー活用やシビックテックの啓蒙を推進する非営利組織です。シビックテックは「civic（市民）」と「technology（テクノロジー）」を組み合わせた造語で、市民がテクノロジーを使って社会・地域の課題を解決することを指します。今回の「まもりあいJapan」プロジェクトも、有志によるシビックテックの一環でした。
プロジェクトに参画した有志には、主にUI・UXを担当したGoodpatch Anywhereさん、主に開発を担当したモンスター・ラボのように企業協力として参画したメンバーのほか、参加公表はしていませんが、協力してくださった医師や専門家なども含まれています。その全員が「接触確認アプリ」という手段を用いて、日本におけるコロナの感染拡大を予防しようという取り組みだったのです。
「まもりあいJapan」プロジェクトの体制図。緑色のマーカーがモンスター・ラボ社員
次に、モンスター・ラボが「まもりあいJapan」に参画するまでの経緯をお話しします。
まず、社内に案件を持ってきたのは本村（美絵／プロダクト企画担当者）さん。それに対して宇野（智之／開発管理責任者）さん、平田（大祐／開発テック責任者）さんが社員をアサインしたのですが、ボランタリーな参加ではなく、他のプロジェクトと同様、業務として参加・貢献できるように計画しました。そのため、参加した社員は思う存分、それぞれの能力を発揮できたのではないかと思います。
このあたりの経緯は、本村さんがnote「まもりあいJapanの6つの奇跡」に詳しく書いているので、ぜひご覧ください。
ここからは、各担当者による現場レポートをお届けします。
「まもりあいJapan」の技術レッスン（Yash Murty／バックエンドエンジニア）
「まもりあいJapan」では、バックエンドシステム開発のためのNode.jsフレームワークとして非常に人気のある「NestJS」を使用しました。
モンスター・ラボのNode.jsプロジェクトでは当初、とても整った仕組みでプロジェクトを進めてきたのですが、たくさんのエンジニアが携わるなかで、いつしか煩雑なものになっていたのです。
そこで、今回はその問題を解決するためにNestJSを採用しました。NestJSで構築された「まもりあいJapan」は、そのアーキテクチャの原則に沿って非常にすっきりしたものになったと実感しています。
これは将来的にも安心して使えるものだと思っているので、今後のNode.jsプロジェクトではNestJSのフレームワークを使っていきたいと考えています。また、これを機にグローバルレベルでNode.jsの取り組みを始めており、バングラデシュやEMEAのメンバーと一緒に活動しています。
開発の詳細は私のブログ「Backend for Japan’s Contact Tracing App」にも掲載しているので、ぜひご覧ください。
「まもりあいJapan」のBLE通信・負荷テスト（橋本 亮佑／テストエンジニア）
私はアプリのBLE通信テスト、APIの負荷テストを担当しました。
BLEには、電波の受信信号強度情報 (RSSI:Recieved Signal Strength Indicator)というものがあり、距離によってRSSIの差異が確認できれば、アプリ側の調整により、精度の高い濃厚接触の判定が可能になります（※濃厚接触の定義は「1m以内かつ15分以上」）。
テストでは、実際にメジャーで1mごとに端末を置いて、アプリで接触を検知するかどうかを確認しました。エンジニアがデバッグ用に作成した画面に、通信のたびにランダムな文字列の交換用デバイスIDが流れてくるので、目視での確認には非常に苦労しました。結果的には距離によるRSSIの差異が見られることがなく、調整のヒントが得られず残念でした。
負荷テストには、Pythonで簡単に書ける「LOCUST」というツールを使いました。テストコードは簡単にかけるのですが、負荷をかけるためのサーバの準備をする上でAWSの設定などにてこずったので、今後このようなケースでは、インフラエンジニアのサポートを仰ぐことができればよりスムーズに進むだろうと感じました。
セキュリティテストはDaniel（Eddy／テストエンジニア）さんが担当しました。今後はもっとテストエンジニアができる人材を増やしていければと考えています。
「まもりあいJapan」の品質テスト（山下 加代子／テストリーダー）
先日公開したnote「『まもりあいJapan』の品質をまもるためにやったこと」に、テストの進め方の詳細はもちろん、私たちがどのようなスタンスで品質保証にあたっているかを書かせていただいたので、ここでは主に、プロジェクトに参画した所感をお伝えできればと思います。
最初に御供さんからのご説明にもあったように、「まもりあいJapan」にはさまざまな企業の方や専門家、ステークホルダーが関わっていました。
テストチームの参加は、ある程度開発が進んだタイミングだったのですが、チームの雰囲気がとても良く、メンバーが互いにリスペクトし合える環境が印象的でした。
また、このプロジェクトを通じ、モンスター・ラボがもつ技術・専門性や普段の業務の進め方は、このような社会貢献のプロダクトにも応用できるのだと体感しました。間違っていなかったというか、正しいやり方だったんだなと。社員のみなさんには自信を持ってほしいと思います。
最後に、4〜5月の忙しい時期にプロジェクトに関わったメンバーはもちろんですが、メンバー達の業務のカバー・フォローをしてくださった社員の方々にも感謝申し上げます。
「まもりあいJapan」を1.5ヵ月で開発できた理由（石村 渉／開発マネージャー）
モンスター・ラボの社員が関わった開発チームでは、技術調査に始まり、要件定義、実装、結合テスト、負荷テスト、ペンテストまでを行いました。驚くべきは、1.5ヵ月でリリースに耐えられる品質のものが出来上がったということです。
とはいえ、普段の案件では「1.5ヵ月でできます！」とはなかなか言えません。そこで、どのような条件によって実現できたのかを考えてみました。
1つめは能動的に動けるメンバーがそろっていたこと。「この仕様書がないとできない」というようなメンバーはおらず、みんなが自走できるチームでした。マイクロマネジメントをする必要はなく、私自身は全体のマイルストーンの整理、抜け漏れの調整などに取り組みました。
2つめはミニマムな機能にしぼったこと。普段の案件では、最初に「リーンスタートアップでやろう」と話していたとしても、途中から「あれもこれも」と希望が出てくることも。「まもりあいJapan」の場合は、第一に社会貢献の思いがあったので、ミニマムな機能にしぼることができたのかなと思います。
3つめは細かい仕様決定を開発チームに任せてもらえたこと。平田さんのnote「『まもりあいJapan』 開発試行錯誤の裏話 後編」でも書かれているように、開発中にさまざまな仕様変更があったのですが、細かいところを任せてもらえたのは大きかったかなと思います。
4つめは必要最低限のドキュメントで進めたこと。ドキュメントの完成を待って実装を始めると時間がかかってしまうので、設計と実装を同時に進め、ドキュメントは全体の設計やデータモデル、API仕様書など必要最低限のものを作りました。その結果、スピード感をもって効率的に進めることができたと感じています。
その一方で、管理画面を誰がどのように使うかなど、最後まで想定するのが難しい項目があり、ドキュメントレスで進めざるをえなかったという実情も。もう少しドキュメント化するべきだったという反省もあります。
結果的には、このような複合的な要因とメンバーのモチベーションの高さによって、1.5ヵ月という短期間でリリース可能な品質を実現することができました。これは、本当の意味でのアジャイル開発だったのではないかと思います。
また、メンバーが仕様の漏れなどにすぐに気付いて提案するなど、コミュニケーションも盛んに行われ、本当の意味でのスクラムチームに近いものを経験できました。
これを1つの実績として捉えることで、今後、我々の開発も変わっていくのではと思います。
「まもりあいJapan」の成果は以下からもご確認いただけます。ぜひご覧ください。
- note：まもりあいnote
- ソースコード：まもりあいJapan · GitHub
- デザインデータ：App Design – Figma
- アーキテクチャ：まもりあいJapan – Architecture
- 負荷テストレポート：負荷テスト設計書
- ペネトレーションテストレポート：ペンテストレポート-英語版
最後に、「まもりあいJapan」は、関わった個人やチームの貴重な経験になっただけでなく、実際に目に見えるアウトプットができ、モンスター・ラボとしても意味のある資産が生み出せたプロジェクトだったと感じています。
直近のイベント
記事の作成者・監修者
関連記事
