あなたのスキルは社会に役立つ

あなたのスキルは社会に役立つ
エンジニアだからできる社会貢献

エンジニアだからできる社会貢献

東日本大震災の発生直後に発足したHack For Japanや「市民が主体となって自分たちの街の課題を技術で解決するコミュニティ作り支援」を掲げるCode for Japanのメンバーを始めとして、日本各地で技術を活用した社会貢献活動が行われています。本連載では、防災や減災、地域の活性化や課題解決、そして人材育成など、「エンジニアだからできる社会貢献」の取り組みをお届けします。

第 117 回

接触確認アプリ「COCOA」OSSコミュニティの現状と課題● COCOA コラボレーター 有山 圭二（ありやま けいじ） Twitter @keiji_ariyama

本稿の中で示される見解や方針は筆者である有山圭二個人のものであり、厚生労働省および内閣官房 情報通信技術（IT）総合戦略室を代表するものではありません。あらかじめご了承ください。

はじめに接触確認アプリ「COCOA」が登場して 1 年が経ちました。
筆者は 2021 年 3 月から GitHub の COCOA リポジ
トリ注 1 のコラボレーターをしています。筆者の役
割は、GitHub のコントリビューターのみなさんとCOCOA 開発チームの間の橋渡しをすることです。
Issue や Pull Request を整理したり、活動しやすいAPI の取り扱いにおいても経験を積んだメンバーがそろっています。情報を公開するための調整にしても、内閣官房 IT 総合戦略室や厚生労働省の方々がいなければ、筆者 1 人の力ではどうにもならないことばかりです。コラボレーター就任から 4 ヵ月、筆者自身はまだ何も成し遂げていない、というのが正直な感想です。とはいえ、ここまで「前に進んできた」
確信はあります。また、COCOA の OSS コミュニティが今どうなっているかを広く伝えることの必要性も強く感じています。これが今回、本稿の執筆を引き受けることになった理由です。

COCOA についてように情報を公開したりするために、厚生労働省なまずはじめに接触確認アプリ「COCOA」についらびに内閣官房 IT 総合戦略室とともに調整していて 解 説 し ま す。COCOA は、 ス マ ー ト フ ォ ン のます。

Bluetooth 機能を利用して利用者同士の接触を検知・本連載は「エンジニアだからできる社会貢献」を記録（図 1）するアプリです。ある利用者が新型コロテーマにしています。実を言えば、寄稿のお話をいただいたとき、はたして自分は社会貢献ができてい◆図 1 Bluetooth により接触を記録るのだろうかと考え込んでしまいました。筆者がコラボレーターになったことで COCOA が突然良くなった、などという都合の良いことは起きていません。COCOA の開発自体は開発チームが担当しています。開発チームは優秀で、COCOA の開発に用いられている Xamarin はもちろんのこと、接触確認
注 1 https://github.com/cocoa-mhlw/cocoa

176 - Software Design

後日、陽性が判明

第 117 回
接触確認アプリ「COCOA」OSS コミュニティの現状と課題

ナウイルス感染症（COVID-19）の陽性判定を受けたに 選 ん だ の が 経 緯 の よ う で す。 ま た、COVID-

ときに、感染力があるとされる期間に接触をしたほ

19Radar が採用するライセンス（MPL 2.0）の関係かの利用者に匿名で通知できます（図 2）。COCOA

で、リリースバージョンについてはソースコードがは、厚生労働省からリリースされており、本稿執筆入手可能になっている必要があることから、GitHub

時点で約 2,800 万回、ダウンロードされています。

リポジトリをコード公開の場所としていました。

COCOA は、 オ ー プ ン ソ ー ス プ ロ ジ ェ ク ト「COVID-19Radar」をベースに開発しています。また、COVID-19Radar のライセンス Mozilla Public
License 2.0 に従って、GitHub でソースコードを公開しています。

これまでのおもな取り組み
これまで、課題解決のために取り組んできたことを紹介します。個別の項目に分けてはいますが、実際には複雑に絡み合っています。また筆者だけで取課題り組んでいるわけでもありません。銀の弾丸はどこにもなく、関係者全員で Yak Shaving 注 2 しながら取COCOA リポジトリを運営するうえでの大きな課り組みを続けているというのが現状です。

題が、OSS コミュニティと COCOA の開発チーム、Issue の取り扱い両者間のスループットをどのようにして高めるかです。COCOA の開発チームは、GitHub とは別に非公コントリビューターが GitHub に投稿した Issue

開のインターナル・リポジトリでコードや課題を管は、まず内部の課題管理システムへ転記されます。

理しています。だいたい 2 週間の単位で作業内容を当初は、転記済みであることは内部の課題管理シス決めている開発チームからすれば、個々のコントリテムを確認しないとわからなかったため、Issue の件ビューターから散発的に Issue や Pull Request が提数が増えるにつれて徐々に取りこぼしが発生しまし出される GitHub への対応は、都度割り込み作業とた。

なり、分量によっては計画した作業を圧迫します。

そこで、内部の課題管理システム上の ID を Issue

一方、コントリビューターの立場では、開発チーの Description に記載することで、Issue が転記済み

ムがインターナル・リポジトリで開発と課題管理をか、内部の課題管理システム上のどのアイテムにひしているため、最新の開発状況がわからないことも付いているかを確認できるようにしました（現在や、コードが公開されるのは新しいバージョンがリでは補助的にラベルも付けて管理しています）。開

リースされたタイミングで、かつ、すべての変更が1 つのコミットにまとめられているので、変更内容

注 2 ある問題を解決しようとすると、別の問題が出てくるような状態が延々と続くことを指します。

を追うのが難しいことなどの課題がありました。

◆図 2 接触通知サーバのしくみ

インターナル・リポジトリについては、存在自体が秘密というわけではありませんでした。COCOA の陽性登録サーバ

接触通知サーバ

診断キーサーバ

ベースになったプロジェクト「COVID-19Radar」が G i t H u b と陽性情報登録

診断キーを配布陽性者

濃厚接触の可能性を匿名で通知

Azure DevOps の 2 つのリポジトリを同期しながら開発を進めていて、その後、開発チームが自分たちの使……

い慣れている DevOps 環境をメイン

Sep. 2021 - 177あなたのスキルは社会に役立つ

エンジニアだからできる社会貢献

発チーム向けの情報を GitHub に掲載することにつターナル・リポジトリで作業をしていることはすでいては不安の声がありましたが、筆者の知る限り、に述べました。これまで GitHub 側には、インターオープンソースプロジェクトで非公開のリポジトリナル・リポジトリ側の変更をリリースごとに 1 つのや、課題管理システムが別に存在するケースはとくコミットとして追加してきました。同じブランチでに珍しくはありません。何より、Issue の取りこぼしあっても GitHub とインターナル・リポジトリでまっを防ぐことが重要という点で全員の意見が一致しまたく異なる歴史をたどっています。

した。

また、GitHub リポジトリがリリースコードの公開

また、コントリビューターからの提案で「プロ場所である以上、GitHub リポジトリの master にリジェクトボード」も整備しています（図 3）。作業のリースされない変更を取り込んでしまうと、リリー進捗を見渡せるいわゆるカンバンとは違いますが、スに含まれない変更を取り除いたブランチを作成す

過去のバージョンでどのような Issue が解決されたる必要があります。とはいえ、大きな変更をオープか確認したり、次のバージョンでの作業候補を整理

ンソースコミュニティで手がけるときに、1 つのしたりするのが目的です。Issue を通じて積極的に情Pull Request でリリースコードの準備を整えたうえ報収集する取り組みも始めています。新しい画面デで、その機能をリリースすることが決定するまでザインを公開して意見を募集したり、アプリのアクPull Request が取り込まれないというのも、動きがセシビリティについて聞いたりしています。アプリ非常に遅くなります。のレビューで寄せられた不具合報告について、筆者

そこでまず、インターナル・リポジトリに合わせの手元で再現できなかったので情報提供を求めるて GitHub 側のブランチ構成を変更することにしまIssue を立てたところ、数時間の内に不具合が発生した（図 4）。それまで master だけだったブランチする機種と原因、解決策の特定にまで至ったこともを、リリースコードを公開する main と、開発用のあります。

コードを公開する develop に分けました。コントリ

Pull Request の取り込みビューターは develop に向けて Pull Request（図 5）を送ることになります。次に、開発チームが変更しオープンソースコミュニティからの Pull Request

たコードについて、これまでのリリースタイミングを取り込むうえで行ったことは、GitHub からインに加えて、だいたい 2 週間に 1 回の頻度で develop

ターナル・リポジトリにコードを取り込むしくみ作ブランチへ反映するようにしました。

りです。筆者がコラボレーターになってから数回、大きな変更については feature ブランチを用意しGitHub 主導で Pull Request を取り込んだところ、て、そこで作業をすることにしました。コントリ

開発チーム側の負担が予想以上に大きいことがわかビ ュ ー タ ー に は、 ま ず feature ブ ラ ン チ に Pullりました。開発チームが GitHub とは別にあるインRequest を送ってもらいます。そして、ある程度ま◆図 3 COCOA リポジトリのプロジェクトボード

178 - Software Design

第 117 回
接触確認アプリ「COCOA」OSS コミュニティの現状と課題◆図 5 Pull Request のコードレビュー◆図 4 ブランチ構成変更の Issue

ど、提供する情報を増やしていきたいと個人的には考えています。プロジェクトとして、どの機能を重視しているかが明確に伝わることで、コントリビューターのみなさんの力を COCOA に効率的に反映できます。
開発チームから公開するコードについては、頻度とまった段階で develop ブランチに Pull Request をこそ増えたものの、変更が 1 つにまとめられているするという流れを想定しています。さらに、これま点で改善の余地があると筆者は考えています。今後で GitHub側では手つかずだった CI 環境も GitHubはもっとわかりやすく、細かい粒度で公開していくActionsを用いて整備しました。これはPull Requestように働きかけをしていきます。また、Issue や Pullを最初にチェックする筆者の負担を減らすためです

Request などを通じてコントリビュートしてくだが、1 ヵ月ほどかけて試行錯誤しながらビルドとテさっているみなさんの名前を記録することも必要だ

ストを整備したところ、通りすがりのコントリと考えています。コミットログだけでなくドキュメビューターが一晩で高速化してくれました（図 6）。

ントとして記録して、可能であれば COCOA のアプ

これは実にオープンソースコミュニティ的な出来事

リや Web サイトから見られるような形になるようだったと思います。に提案したいと考えています。
以上、接触確認アプリ「COCOA」のオープンソー

今後の取り組み

スコミュニティの現在についてをお届けしました。

ここまで、COCOA リポジトリの取り組みを紹介

トリを覗いてみてください。それではまたの機会読者のみなさんも、これを機会に COCOA のリポジしました。まとめてみるとあっさりしたものだなと思いますが、これらを実現するために調整を続けた日々をに、ご報告できる日を楽しみにしています。s◆図 6 GitHub Actions の高速化前後

思い出すと、やはり感慨深いものがあります。
今後は、引き続きIssueの活用やPull Requestの取り込み促進、そしてコントリビューターを増やす取り組みを続けていきます。たとえば今後のリリース予定や機能のロードマップなSep. 2021 - 179