COCOAの総括（オープンソースコミュニティとして） #1144
Comments
|
上から順とか言うといつまで経っても書き終わらなさそうなので、書けるものから書いていこう。 IssueやDiscussionの取り回し対応する人が居る（そう、ぼくです）という意味では、まったくノーリアクションと言うことはなくなったと理解しています（最低限、Labelはつけるので「見てるんだな」ということはわかるようにしています）。 ただ、ちゃんと応対できていたかというと大きな課題が残ります。ちゃんとできたかというと、ちゃんとできていなかった。 いただいているIssueの中には、エンジニアとして「もっともだ」と思うものも多くあります。 ただ「いいな」と思うものには、かなり大きな変更を伴うものもあります。 これはオープンソースプロジェクトあるあるだと思いますが、コントリビューターの方からもらう大きめのIssueに、最初から過不足無く情報が整っていることなんてほとんどありません。それ自体は当たり前のことです。ここで言いたいのは、Issueをもらった後、対話によって「なにがしたいのか」「どう変えるのか」を突き詰めていく課程が当然に必要になるということです。 しかし、取り込むかどうかわからないものの話を進めて、コントリビューターの時間を使ってもらって議論を深めて、やっぱり行政内で検討した結果駄目でした。というのは、ぼくとしては進められませんでした。 結果として大きめのIssueがほとんど処理できず、小さなIssueやPull Requestのみを取り込むという、言ってみればスケールの小さな活動に終始してしまったのが、ぼくの大きな反省です。 最近は、小さな変更であれば行政内での取り込みハードルは下がっていたと感じています。特に2021年11月のCOCOAのアップデート障害でオープンソースコミュニティの果たした役割の大きかったと考えています。 小さな変更や不具合に対する取り込みのハードルが下がった一方で、大きな機能の実現についてはぼくが入ってから今までの間一貫して消極的であると感じています。 それ自体は想定していたことなので、このまま小さな取り込みを増やして、少しずつIssueの規模を大きくしていく。行政内で「オープンソースコミュニティからの提案なら、考えてみてもいいんじゃないの」と言ってもらえるようにする。そんな風に考えていました。 しかし、行政内での人の入れ替わりが激しい。最長でも2年ほどで異動するのが普通だそうです。意思決定者と聞いているポジションで着任したと聞いてから、一度も挨拶しないまま離任した人も居ます。そのような状況ですから、引き継ぎがあるとは言え、オープンソースコミュニティへの信頼は定期的にリセットされた状態になっていると個人的には感じています。 接触確認アプリ「COCOA」は、もともと10年続かない（続いて欲しくない）プロジェクトとぼくは認識しています。 大きな会社（Googleとか、Microsoftとか）のオープンソースプロジェクトだって、結構人が入れ変わってるわけですよね。なのに破綻していない。担当者の数が多いので誰かが抜けても影響が小さい仕組みになっているのか、そもそもオープンソースコミュニティに対する力の入れ方が違うのか、おそらく両方だと思います。 なので、本当にオープンソースコミュニティを運営するなら十分な人員をなるべく長期に当てる。一人二人では場を持たせる（無視しない）ことが精一杯で、意思決定者の現状維持バイアスを突破することは難しいとぼくは感じています。 あと、もう少し物事を進める権限が欲しい。意思決定者と直接、話をさせてもらえる機会がちゃんと欲しい。意思決定者でなくてもいいから、どういう話し合いがあってそういう結論になったのか、経緯をきちんと教えて欲しい。 そういったことを行政内の統括には書き込めればいいなぁ。 |
開発状況の可視化これは少しうまくいった部類に入ると思います。 現在、COCOAの開発チーム（委託事業社に所属する開発者）は、コードに関してすべてGitHub上で作業をしています。 ぼくが関与を始めた当初、委託事業者の人たちはInternalなリポジトリで開発を進めていました。GitHubはリリース時にコードを公開する場所でした。MPL 2.0ライセンスを採用しているので、一般に配布するときにはコードの公開義務があります（コピーレフト）。 「（ライセンスの条件を守るため）リリース時にコードが公開されていればいい」と言う状態から、「2週間毎にInternalなリポジトリとGitHubをSyncする」ようになり、最終的には「GitHub上でPull Requestを出して、それを取り込む」と変遷しました。だいたい１年くらいかかったと思います。 現在、GitHubにあるコード、オープンソースになっているコードが（未リリースのものも含めて）最新のものです。 課題の１つとして、コードとしてはすべてGItHub上でやりとりしていますが、Issueに関してはやはりInternalなシステムを使っていることがあります。 Internalな課題管理は開発チームのスクラム開発と密接に関わっています。またInternalで管理しているチケットは、GitHubのIssueより小さな粒度で管理しているのでそれなりの数が動きます。行政側とのやり取りが記入されるので、そのままの形で外部に公開することが難しいなどなど。 代替案として、GitHubのIssueにInternalなチケット番号を付けてもらう運用にしました。この手法は、ドイツの接触確認アプリ「Corona Warn App」のリポジトリを参考にしています。ただ、前述の通りGitHubのIssueと開発チームのチケットは粒度が違いますから、必ず一致すると言うことは難しい。 この課題の一番の解決策は、「GitHubでオープンソースで運用するなら、最初からすべてをGitHubで運用する」ことです。 もちろん途中からオープンソース運用に変えようとなることも有ると思います。そのときには相応の工数がかかることを覚悟しなければなりません。「走りながら（開発しながら）変える」は至難です。 |
Pull Request取り込みのハンドリングIssueの投稿からPull Requestの取り込みの流れについては、今はある程度できるようになっています。 課題としては、取り込みが可能になったとは言え、実際の取り込みが実行されるまでの期間が長くなってしまうことです。 Pull Request取り込みにあたっては、委託事業者の開発チーム側と連携する必要があります。開発チームはスクラム開発をしていて一定期間を「1スプリント」として、スプリントの作業を計画しています。なのでPull Requestが来てから最長で1スプリント分のタイムラグが出るということがありました（今ではさらに短い期間でリファインメントが実施されています）。 COCOAはオープンソース開発なのだから、コラボレーターがレビューしてApproveするだけでいいのでは。と、言う意見があることも承知しています。ぼくも当初はそのように主張していました。 これは一般論ですが、請負契約においては納品物に対する契約不適合責任があります。 ぼくも受託でプログラムを書く仕事をしているので自分の事例の話ですが、一般的に、納品にした仕事に不具合が見つかれば、まずは受注者（ぼくです）宛てに問い合わせが来ると認識しています。 仮に、契約書に「第3者の著作物の不具合に起因する場合は責任を負わない」という条文があっても、実際に不具合の原因がオープンソース側から取り込まれたコードにあったとしても、不具合がある以上、ぼくはその不具合を調査して、自分の責任でないことを明確にしなければなりません（もしかしたら立証責任は顧客側にあるのかも知れませんが、たいてい受注者側がやっていると認識しています）。 オープンソースコミュニティからのPull Requestについて、自分たちのレビュー無しに取り込むことが難しいのは、ぼく自身が受注者の立場になって考えると理解できるところです。 この課題の解決策として、ぼくは、行政と委託事業者が締結する契約の形態を、もう少し柔軟にする選択肢を持つのが良いと考えています（行政内で内製という選択肢もあって、それは機会があれば別に書きたい）。 その上で、これは今後、行政内でさまざまなプロジェクトを立ち上げる上で、最初期の段階で立ち塞がる課題であると認識しています。解決するために模索する必要があると考えています。 |
HER-SYSオープンソースコミュニティとしての文脈で、リポジトリとしてのCOCOAの運用とHER-SYS（新型コロナウイルス感染者等情報把握・管理支援システム）との関係にも触れる必要があると思います。 本リポジトリはCOCOAに限定した場所です。COCOAとHER-SYSは別システムという取り扱いになっていて、別システムであるHER-SYSに関する事柄は、このリポジトリでは取り扱わないという整理になっています。 そして、これは改善すべき課題であるとぼくは認識しています。 COCOAとHER-SYSは密接に関わっています。 ここまで密接に関連したシステムなので、COCOAのリポジトリにHER-SYSに関連する話が来るのは当然のことです。 課題の解決策として、オープンソースソフトウェアと密接に関わるシステムについても意見を受け付けるようにする。連携するシステム側にも連絡を密にできる担当者を設定する。と定めておくのが良いと思います。 余談ですが、公開されている情報として「情報システムの整備及び管理の基本的な方針」と言うものがあります。 文書中、政府情報システムを3つに分類するとされています。
これは一般論になりますが、複数のシステムが密接に関わっている大きなシステムの中に異なる分類のシステムが混在することはプロジェクトの難易度を高めます。①と②の組み合わせであれば両方のシステムにデジタル庁の担当者が居て、相互に連絡もできるので、そこまでではないと思いますが、①|②と、③の各府省システムの組み合わせは大変に厳しいことになると思われます。 もちろん政府は大きいので、混在すること自体は仕方がないこととも思います。 |
省庁は、担当部局での［所掌］連続性と、審議会・研究会の［審議］連続性があると思われます。 COCOAも所掌は決まっておりますので、所掌部門で行政の判断やご活動について一定以上の連続性はあったかと思います。接触通知と行政検査との関係などは、時系列でみても説明可能なご判断の積み重ねだったかなと感謝しております。 一方、COCOAの要件、通知内容、通知された方への誘導・案内、接触通知のモデルやパラメータ、保健所や医療機関への周知、利用状況の把握、効果の検証等について、学識経験者や有識者に審議してもらう会議体はありませんでした。 委員資料や議事録が公開される会議体があると、経緯が文字になっていますので、行政の担当者が変化しても連続性が保たれます。立法などは国会への説明責任があり、法律毎に審議会・委員会が決まっています。 ［審議］連続性を保つ会議体は、所掌担当部局だけでなく、関係する部局のご担当者がオブザーバーで会議に出席してくれています。法律のみならず、ガイドライン策定などでも、会議体があれば、経済産業省と金融庁、法務省、内閣府と関連省庁など、様々な組み合わせで政府全体の整合性が保たれる仕掛けが動き始めます。 今後の課題を２点 国土地理院など内製力の高い部門のオープンソース活動から学べる他、 課題２ 複雑な主題と会議体の関係 他の事例を振り返って見ます。 B 現在サステナビリティ関連財務情報の開示と整合させながら人的資本の開示のガイドラインを定めるような課題と共通しています。 金融庁・日銀は、バーゼルでの審議自体に人を送り込むなど、省庁自体が評価モデルを理解しています。（COCOAはどうでしたでしょうか？）。 サステナビリティ関連財務情報Bについて、経済産業省は、海外動向を把握する研究会を立ち上げて、網羅的に情報収集し、他の部局等にとっても判りやすい資料に整理してくれました。 COCOAに関して、海外動向や、リスク評価モデルや、BLTの距離測定に関する技術動向に詳しい委員から情報を集めるような研究会は、ありませんでした。そこは、オープンソース側ではなく、開発主体のイニシアチブで行ってもらえていたら良かったなと感じます。 また、アドバイザリー・ボードにて、COCOAの効果を検証するような主題設定もなかったかと記憶します。効果の検証であれば、ENの複雑さを話題にせず、通知を受けたらどう振る舞って欲しいのかを、ご審議いただき、利用状況を把握するための良いアイデアや希望もいただけた可能性があるかと思います。 公式なシンポジウムのような形で情報共有することで品質を高めることも、行われなかった記憶です。 何か情報共有いただける機会があれば、遠距離の信号についてのissueも、無くてすんだように思います。 政府がオープンソースをより良く利活用するには、議事録がオープンな審議会の委員会や研究会があると良い、とご提案します。オープンソースのカウンターパートは事務連絡ではなく議事録オープンな会議体が良いです。 会議体、という仕組みで品質を高める他、シンポジウムを行って文書化や対話をしておく、など「プロセス」による品質向上も考えられます。オープンソースらしさのある協力関係に対して、シンポジウム等で、それなりの礼節で政府の立場から接してくださると、公共の担い手の裾野を広げていけるのでは無いかと想像します。 |
承りました。 前者については、全国民向けのアプリをいきなりオープンソースにして回す。というのではなく、最初は小さなアプリから、いっそ開発者しか使わないライブラリから始める。そこから行政内での回し方を確立していく。という流れが良いと思います。 所掌の連続性については、所掌が連続すること自体に違和感はありません。 後者については、これはぼくの意見を率直に言えば「パンデミックが起こってからやるのはリソース的にぜったい無理だから、次に備えて平時にやっておきましょう」になると考えています。 研究については技術的・科学的（医学的？）な側面に加えて、プライバシーとの関連など考えることは無限にあります。法律との整合も合わせて考えていく必要がある。 それがパンデミックの真っ最中にできますか。という話です。いや、行政としては「できません」とは言わないでしょうし、やらないといけない。というのが正解なんでしょうが、エンジニアとしてのぼくは「無理でしょ」と言います。 なので、もう少し世の中が落ち着いたら、次の感染症対策に向けて |
コード品質これも大きく改善できたものの一つだと考えています。 それまでServiceだけだったコンポーネント群にRepositoryのレイヤーを導入することで、データ処理のコードの見通しが良くなり、テストも書きやすくなりました。 バージョンごとのデータマイグレーション処理も可能な限り集約して、バージョン飛ばし（特定バージョンへのアップデートをスキップする）のケースでも確実に変更が適用できるように整備しました。 ただ、この処理の一部が2021年11月に発生したアップデート時の強制終了することがある障害の原因となったので、これは大きな反省点でもあります。 また、アプリが依存するライブラリ（NuGet）のバージョンは、当初は最初のリリース以来まったく更新されていませんでした。現在ではリリースごとになるべく最新になるようにアップデートしています。 「コードの静的解析」をしたいと言ったら、開発チームがSonarCloudを導入してくれました。 このIssueはオープンソースコミュニティに関するものという位置づけですが、「コードの品質」という切り口では、COCOA開発チームを抜きに語ることはできないので、ここではその話をさせてください。 COCOA開発チーム、つまり委託事業者に在籍している開発者の皆さんのことですが、ぼくから見た彼ら（Theyの意味）は、とても優秀なエンジニアであることを、きちんと記しておきたいと思います。 XamarinやPrismだけでなく、AndroidとiOS、Webサーバーについても、きちんと下地を持っています。 最近では慎重さに加えてパフォーマンスも向上しており、とても頼もしく思っています。 ぼくが解決できなかった課題として、彼らが自分の名前を出してGitHubにPull Requestしたり、Issueで受け答えできる環境・仕組みを作れなかったことです。 COCOAはいろいろな意味で注目されるアプリで、場合によっては関わっている個人にまで批判が及ぶこともあるので致し方ないことかもしれませんが。 これも、今後の課題にしたいと思います。 |
そもそも「接触確認アプリ」というジャンルで技術的な質問に絞るのは難しいのではないか率直に言えば、リポジトリを運用するにあたって「技術的な質問や提案に限定する」方針そのものは今でも妥当と、ぼく自身は考えています。一方「技術的な質問や提案に限定しなければならない理由」を、コントリビューターの皆さんにきちんと説明しなかった（できなかった）ことが、大きな反省点としてあります。 その上で、その理由をどこまでどうやって説明すれば合意が得られるのか。そもそもどこまで情報を出せるのか。ぼく自身、今でも皆目わからないというのも事実です。 たとえば「接触確認アプリ」の文脈として、接触の可能性があると判定する閾値の妥当性に関するDiscussionがありました。 デルタ株は感染性が高いので、閾値を下げるのが良い。その提案にぼくは「接触の可能性の閾値は、国立感染研究所の定めた基準に則っている。COCOAが独自の基準にすると保健所が対応できない」というようなことを説明して議論になりました。そしてぼくは、閾値は感染症対策の基準の話なので（アプリとしての）技術的な内容からは外れると言い、そうではないという反論もありました。 当時、連携チームが認識していた課題としては、陽性登録率が低いことでした。 SMSはどのような送り方をする？ 再送の頻度は？ 処理番号の送信はいつごろ実装できる？ COCOA側でやるべきことは？ SMSに記載するリンク（URL）の形式は？ AppLinks/UniversalLinksの仕様は？ www.mhlw.go.jp上にAppLinks/UniversalLinksの権限管理ファイルを配置する手続きは？ サーバーは？ cocoa.mhlw.go.jp は用意できる？ 「今は処理番号を陽性登録率を上げることに注力したい。陽性登録率を上げることで通知される機会が増えることを想定している。これは閾値を変えることよりも素早く実行できるのでまずはこちらを実行したい」 まず始めにそのように説明できれば良かったのですが、その説明をぼくはしませんでした。なぜなら、その時点で処理番号の自動発行はあくまで「調整」の段階、それを「実行」して良いという意思決定がなされていなかったからです。 オープンソースコミュニティと対話するには適切な情報開示が必要になります。 長々と書きましたが、このリポジトリの運用を「技術的な質問・提案」に限定しているのが妥当と思っている理由は、技術的でない質問や提案を受け付けても、行政として正式に決まって開示して良い状態になるまではぜったいに開示できないし、提案に対して「やりましょう」とも「やらない」とも言えない（決める権限がない）。 技術的な話であれば、ぼくはある程度自由に回答できます（そのためにぼくはいます）。 もっと真っ向から情報を開示するなら、ぼくのようなエンジニアだけでなく「行政官」の人も巻き込んでいく必要があると考えます。 どう言う状態になれば情報を明かして良いのか。情報を公開するまでに誰の了解を得ればいいのか。 エンジニアだけでなく、行政官の人たちも参加することを前提にしたオープンソースプロジェクト（たしか経済産業省でそういうプロジェクトがあった気もしますが）。 |
ベータ版の運用接触確認アプリのような制度とのつながりがあるソフトウェアで、無保証ベータ版の提供はそぐわないという課題です。 COCOA v2.0.0のリリースにあたっては、ベータ版の公開を実施しました。 一般的にベータ版のリリースをする目的は、次の2つに分けられると考えています。
COCOAも当初はこの2つの効果を狙って、ベータ版の準備を進めました。 しかしCOCOAの場合、プロダクト版と同等のコードベースでリリースすることが困難でした。
これらを実現するためには、画面遷移を変える必要もあり、かかる工数は決して小さくないものでした。 しかし、ベータ版をリリースできるようになれば、プロダクト版にすぐには載せられないような実験的な機能を搭載できます。 結果として、ベータ版とは言え、新機能をリリースするハードルは予想以上に高いものでした。 v2.0.0搭載予定だった「閾値未満の接触画面（※）」については、クローズドベータ版に搭載したものの、オープンベータへの搭載は認められませんでした。「多くても2000人程度、無保証であることを承知でインストールしてくれる人だけ見られる画面ですよ」と言いましたが、認められませんでした（その後廃案）。 ※ COCOAが通知する閾値に満たない接触を表示する。COCOAログチェッカーのような機能 さらに、ベータ版の運用（普及）を困難にしたのが「ベータ版で接触通知を受けても、公費負担の対象にしない」条件です。 COCOAは接触確認アプリです。ベータ版を使っている人たちだって陽性者と接触する可能性はありますし、体調が悪くなることだってあるでしょう。公費での検査を諦めてくれとは言えません。そのため、「ベータ版は普段使いの端末にはインストールしないでください。サブ端末にインストールしてください」と言わなければなりませんでした。 また、Google Playではベータ版はGoogleアカウントとして申し込むので、サブ端末は異なるGoogleアカウントで申し込む必要があり、利用者の負担が大きい。 ベータ版向けの実験的な機能もなければ動作保証もない。通知があっても公費での検査も受けられない。 ベータ版を実施した結果、COCOAのようなアプリで無保証ベータ版の運用は困難と言うのが、ぼくの中での結論です。 COCOAの通知を受けた人が公費負担で検査を受けられるのは、きちんと制度に裏打ちされています。 同様に、行政が出すアプリの多くは申請であるとか、証明書であるとか、アプリの枠を超えてさまざまな制度とつながっているので、無保証ベータ版の運用は難しいと考えています。 その上で、仮に、それでもベータ版をリリースするなら「ベータ版であるけれど保証を外さない」という取り扱いができないか。 保証付きベータ版は、プロダクトリリース前に不具合を見つけたいという目的には（表向きには）適いませんが、新機能を色々な人に試してもらってフィードバックを得たい。と言う目的で進められるのではないかと考えています。 |
|
@keiji 論点整理と深い考察、ありがとうございます。 私としては、今後、行政がある程度の規模のソフトウェアをオープンなプロセスでメンテナンスしていくには、下記の点が最も重要であると感じました。
まったくその通りだと思います。
というコメントに本質が現れていますね。私は東京都の新型コロナ感染症対策サイトにも関わっていますが、COCOAほどでは無いものの、同様の難しさはありました。 行政官を巻き込むには、ソフトウェア開発のプロセスを行政の意思決定プロセスに同期させていく必要があると思います。 私は、意思決定と実装の距離を縮めていく必要があると考えます。 ここまでだと、「そりゃそうでしょ」というだけなので、もう少し踏み込んでどう変えていくかという点で、アイデアを記載してみます。 組織文化へのアジャイル適用システム開発のみではなく、上流のプロジェクトマネジメント自体にアジャイルプロセスの考え方を導入することで、もっとなめらかな役割分担を行うチームができる可能性があります。 調達の仕組みの改善これは必須ですね。 簡単なものから始める他省庁がオーナーである案件よりも、デジタル庁内で意思決定ができるもの、そして複雑性の低いもの、または他国が公開しているオープンソースをForkしてくるものなど、比較的難易度の低い案件からオープンソースプロジェクトを立ち上げていき、成功体験を積んでいくことが必要にも思います。デザインシステムなど、他の国も公開しており、他省庁や自治体に取っても役に立ちそうなライブラリはオープンソース化に向いているのではないでしょうか。 Open Source Program Office の設置すべてのチームがGitHubの使い方やオープンな対話をできるようになるとは思っていませんが、オープンな案件が増えてくると、後方支援が必要になってくるはずです。ライセンスの議論などは専門家の知見も必要ですし、問題のある外部ライブラリを使っていないかなどの確認にはSCAツールなども必要です。利用されなくなったリポジトリをアーカイブするなどのメンテナンスも必要となります。 |
@halsk 素晴らしいアイデアですね。 ExposureNotificationでも、全世界、利用者向けの説明文、イラスト、動画などからして、実施地域（国、州）それぞれに、作成していました。世界で共有できたら良いだろうに、というコンテンツもありました。（ドイツの統計公開サイトや、イギリスの利用者向け説明動画など） COCOAも、Google や Apple のサンプルコードをForkするようなことが検討されたのか、何か難しかったか、総括できたら、未来に繋がりそうです。 省庁、都道府県、国家などの枠を超えて、知的成果物が共有されていって欲しいです。 |
COCOA公開WebミーティングまとめGitHubリポジトリ運営の課題（さらなる情報公開をGitHubリポジトリの運営に関しては、少なくともまったく反応がないという状態ではない。不具合報告時には短い時間で対応できる体制が整えられていることを評価する声があった。 一方、行政内の状況の公開に関しては課題が指摘された。 たとえばENv2移行に際して接触基準が変わることについて調整が必要となったこと。基準値未満の接触画面で検討が求められ、結果として搭載しないという結論になったことなど、結果が出てから結論を報告するのは情報開示としては十分ではない。 基準値未満の接触画面について（専門家の会議体の必要性COCOA v2.0.0には「ENv2移行」と「基準値未満の接触画面」の2つの大きな変更があったが、これらを同じバージョンに入れず、「ENv2移行」のあとに「基準値未満の接触画面」をリリースするようにすれば、少なくとも「ENv2」についての調整を終えた時点でリリースできるので、v2.0.0のリリース時期を早められた可能性がある。 「基準値未満の接触画面」について、利用者にどのように見せるか。情報を提示して利用者にどのような行動を期待するかを詰め切らないまま、実装を先行して進めている印象があったことが指摘された。 「接触通知アプリ」は一般のアプリとは性質が異なる。医療や感染症対策上の専門家会議などできちんと方向性を検討したものを実現することが重要で、それがない状態で「基準値未満の接触画面」をリリースしないという行政の判断を評価する意見があった。 COCOAのグランドデザインはどのようなものか。接触通知アプリの進め方を検討するにあたって、医療の専門家や会議体の関与が十分にあったのか。と言う指摘があった。 「基準値未満の接触画面」の反省として「技術的に可能であるから実装する」のではなく、なんのために作っているのか。COCOAの目的を（行政として）明確にすることがある。 ENv2移行について（Google/Appleとの交渉とデジタル・コンタクト・トレーシング研究の必要性ENv2移行については「移行しない」という選択肢を十分に検討したのかを問う声があった。 ENv2で接触基準そのものに変更があり、そのことが行政内で検討が必要になったのであれば、そもそもENv2移行がCOCOAの目的（グランドデザイン）達成に必要な機能かを検討する必要がある。 接触通知アプリは、多数の国がプラットフォーム事業者（Google/Apple）が提供する1つのAPIを用いて、同じ目的のアプリを開発する、これまでに類を見ない取り組みである。 世界中でさまざまな国が接触通知アプリを開発・運用する中で、同様の事例（ENが自国が定める基準に合致しない）はなかっただろうか。 日本としての課題で終わらせず、接触通知アプリ開発に取り組んだ各国が直面した技術面、行政面での課題を共有すること。それらの解決策を探り、必要に応じてGoogle/Appleとも連携して課題の解決手段を探ること。 ワクチン接種証明アプリとCOCOAの違い（プロジェクトとしての再現性について行政官を招いてワクチン接種証明アプリの話を伺う中で、ワクチン接種証明アプリの成功要因として、小林（前）デジタル副大臣の素早い意思決定と、高い調整力が挙げられた。また、同様の体制はすべてのプロジェクトで整えられるものではないという説明があった。 これは行政のみならずプロジェクト・マネージメント全般で言えることだが、個人の能力がプロジェクトの成否を決める状態は健全ではない。スーパープレイヤーの存在は否定しないが、プロジェクトとしては個人の力に大きく依存せず、一定の成功を納めることができる組織や仕組みを作ることが重要である。 外部ツールとの連携（行政と外部の開発者との連携を深める行政が提供するものではないが、COCOAログチェッカーなどの外部ツールは多くの利用者から支持されている。 COCOAログチェッカーは、ENv2移行後のCOCOA v2.0.0では接触通知API側が出力するファイルの仕様が変わったことで一時的に利用できなくなった。 「接触データのエクスポート機能」のリリース後、COCOAログチェッカーに加えて、COCOAログ.jpなど同様の機能のサイトがいくつか立ち上がった。 これまでのCOCOAのアップデートの中で「接触データのエクスポート機能」搭載については高く評価する声があった。 一方、行政内としては「接触データのエクスポート機能」は、外部ツールと連携することを目的として企画していない。あくまで「利用者のデータは利用者のもので、いつでも確認できることが透明性の観点から重要」という意図で搭載したものである。データが外部ツールで表示できることはあくまで副次的なものであって、意図しない効果という位置づけになっている。 データ（規格）の公開と、それを活用した外部ツールの充実は、オープンソースコミュニティとしては好ましいものであることは間違いない。しかし、あくまでも個々のプロジェクト独自の取り組みであって、行政として推奨・応援できていないことが課題としてある。 国土地理院の「地理院地図パートナーネットワーク」のように、継続的に外部の開発者と情報を交換する取り組みを続けることが望ましい。 外部の開発者との連携に関して、行政の開発・提供するソフトウェアは積極的にオープンソースすることが望ましい（"Public money, public code"）という意見があった。 「セキュリティのリスクがあるから」「個人情報を取り扱うシステムであるから」は、コードを秘匿する理由にはならない。 個人情報の保護は重要なテーマであることは理解できる。 |
|
作業メモ： |
|
遅ればせながら2月17日に総括の報告書が公表されています。 ここでのやりとりを元に要約した内容を報告書に含めました。また、要約を読んだ人が1次情報へ到達できるように当該ページにはこのIssueのURLを記載、さらにどの時点での情報をもとに報告書を作成したかを確定するため、参考資料集にはIssueの内容をすべて収載しています。 新型コロナウイルス接触確認アプリ（COCOA）の取組に関する総括報告書 |
その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?
報道にあるとおり、COCOAの総括については行政として進めていくのだけど、オープンソースコミュニティを担当している自分としても、きちんと総括したいですね。
ロードマップの提示これは「そもそも「接触確認アプリ」というジャンルで…」に書いたので個別の項目として書かなくてよさそうなどなど。
「できたこと」「できなかったこと」できなかったことを、今後できるようにするにはどうすればいいかも検討したい。
※ チーム境界の課題（COCOA以外のシステム、たとえばHER-SYSなどには言及しにくい）があるので、どこまでできるかはわからないけれど、それはそれで課題の1つとして行政側の総括に出す所存です。
解決策についてお書きください / Describe the solution you'd like
総括する。
あなたが考える代替案についてご説明ください / Describe alternatives you've considered
総括しない。
その他 / Additional context
本当はCOCOAの機能停止版をリリースしてからゆっくりやりたいところだけど、それだと行政側の総括に「オープンソースコミュニティからの課題として入れて」と言える時期を逸しそうなので進めます。
The text was updated successfully, but these errors were encountered: