このメモの目的
COCOAアプリの成り立ちを深く知ることで、COCOAアプリの失敗の原因を探りたい。
立ち入らないこと
- セキュリティ周りの話
- Exposure Notification APIの挙動
失敗の定義
- 精神的に苦しい思いをした人が居る
- アプリの目的が達成できていない・・・アプリ開発の失敗
- アプリ利用者数が少ない・・・広報の失敗
- 全体のプロセスにおいて、透明性が確保されていない・・・プロジェクト統治の失敗
いろいろ挙げてみたが、私の中では１つ目が大きな動機になっている。
何があったか
現場（厚労省結核感染症課）目線
現場目線は「仕方ない」の連鎖だったように思う。
以下、報道に対して、独断と偏見をスパイスして流れを妄想した。
- そもそも接触確認アプリは民間主導の予定だった
- Google,AppleからのAPI提供と仕様（1国（公衆衛生当局主幹で）1アプリ）の強制
- 政府トップのリリースへのコミット宣言
- 厚生労働省において、新規調達では2020/6/19のリリースには間に合わないという状況、さらに当局自体に余力もない状況
- 新規調達も困難な状況であったため、HER-SYSの追加契約でパーソルから調達
- パーソルもリソースがなく、再委託比率94%の問題を孕みながら保守体制構築
- 6-7月の厚労省不在、OSS Community依存の開発
- 現HER-SYSとの親和性を考慮し、ベンダーロックインを許容する問題を孕みながら、AzureでCOCOAもシステムを構成
- 試行版という立て付けでリリースを達成するも理解されず、炎上
- 依存していたOSS Communityの崩壊
- 苦しい状況での引き継ぎ、8月からの厚労省体制での保守・運用の開始
- Google,AppleそれぞれのAPI仕様差異による被害
- しかし、OSS開発の基礎が一切なく、Issueをガン無視。不具合に次ぐ不具合
統治目線
こちらは以下の記事が非常にまとまりがよく、正鵠を射ていると思う。
接触確認アプリCOCOA失敗の本質
より上位から見たCOCOA開発の是非に踏み込んでいる。上で書いた「仕方ない」の連鎖は、本来は断ち切れるべきものであった。政府としての意思決定が不在（統治の欠落）という主張だと受け止めた。
Google,Appleを横串しとする仕様策定組織の構築などを政府が提案・交渉すべきと論じている。
政府CIO補佐官楠氏も問題山積の接触確認アプリ、政府CIO補佐官が語る3つの要改善点で、政府主導のガバナンスの確保、Google,Appleへの交渉（1国1アプリの制限解除）をすべきと論じている。
ポイント
一覧
- 厚労省の優先順位・人員不足
- 94％の再委託率の許容
- Covid-19 Radarの採用とまもりあいJapanの不採用
- 厳しすぎるスケジュール
- Covid-19 Radar依存の開発
- Covid-19 Radarの疲弊
- 広報の失敗
厚労省の優先順位・人員不足
もともと厚労省にアプリ開発の予定はなかった。民間の取り組みによって接触確認アプリは提供されるという予定であった。
しかし、Google, AppleのOSへのExposure Notification API提供と制約の周知があり、1国1アプリかつ公衆衛生当局への提供のみとする、という規定から厚労省主幹でアプリ開発することが決定した。
Exposure Notification API利用の決定経緯は政府CIO補佐官楠氏の説明が詳しい。1
当初（Covid-19 Radar, まもりあいJapan)で開発されていた独自方式では、Exposure Notification APIにおけるプライバシー水準に達していなかったために、独自方式を持つアプリは採用しなかったということのようだ。
厚労省の結核感染症課に開発の話が入ったようだが、IT人材不足、結核感染症課の人材不足があったと省みられている。
開発が決まっても、本来の業務が優先であり、COCOAは省内では重視されていなかったことが厚労省の振り返りでは見受けられる。
CIO 補佐官A：厚生労働省がちょっと気の毒だと思った旨、そもそも結核感染症課は IT を所掌する部局でもないので、capability としてどうなのだろうという疑問を持っていた旨を述べている。また、厚生労働省に移管する理由は大きく２つあると当時認識していて、１つは HER-SYS とのつなぎ込みを円滑に実施できることが重要であること、もう１つは陽性患者の診断鍵を配信する主体がデータコントローラーとして厚生労働省であるべきということは間違いないと思う旨を述べている。2
指定職級Ｋ（厚労省）：全体の中で COCOA はそれほど大きな位置づけを占めていなかった旨、順にいくと、検疫、水際があって、医療があって、保健所問題があって、ワクチンがあって、治療薬があって、もちろん生活支援とか雇用対策とかは別にあったが、その中で COCOA は確か、当面の関心が設計といったものではなく、これは非常にいいものだからどんどん入れていかなければいけない、むしろ広めるのが大事なので、ダウンロード数をとにかく早く上げるということで進捗状況を報告してもらっていた旨を述べている。2
指定職級Ｎ（厚労省）：HER-SYS は保健所の業務の効率化のために重要だと思っていたが、COCOAにはそこまでの認識がなかった旨、国民の期待感や関心は高いという認識はあったが、保健所の積極的疫学調査の補完的役割だと認識していた旨を述べている。また、指定職級G は、COCOA は効果が分かりにくいと思う旨を述べている。2
私見
政府トップにはそれなりのモチベーションがあったように思えるが、厚労省やその配下組織におけるCOCOA開発のリソースも無ければ、インセンティブも無かったと思われる。厚労省からすれば、実務が先で、COCOAは補助ツールに過ぎないという見方があったように思える。
94％の再委託率の許容
2020/5/27 パーソルプロセス＆テクノロジー（以降、パーソル）へCOCOA開発を委託した。
パーソルからは再委託をMicrosoft(委託費：8416万円）,MTI（委託費1億9093万円）,フィクサー（委託費9333万円）へ行った。
これにより再委託率は94％となった。
流れとしては、HER-SYSの体制として、パーソル、MTI、フィクサーが参画していた。HER-SYSのクラウド基盤がAzureであったこと、COCOAの前身となった民間の取り組みのうち、OSSのCovid-19 Radarも同様にAzureであったこともあり、Microsoftに声が掛かった。
この体制が実際にスタートしたのは、2020年8月以降とのこと。3
管理職級A（厚労省）：当時、HER-SYS の追加改修が必要になるだろうと考え、HER-SYS は再委託事業者A と再委託事業者B がやっていると聞いたことから、再委託事業者A とコンタクトをとった旨を述べている。また、再委託事業者A は、厚生労働省から問合せがあった際、再委託事業者A の提供するクラウドサービスの基盤を使っているため、オープンソースコミュニティーA が開発しているものを紹介したが、会社としてオープンソースコミュニティーA の品質を確認したり保証したりはしていない旨、昨年のゴールデンウィーク明け頃に委託事業者と再委託事業者C に声をかけた旨を述べている。2
パーソルは厚労省の調査報告書の中でこう述べている。管理も一部のみということで、実質のPJ管理はMicrosoftが進めていたように思われる。
委託事業者：昨年 5 月 27 日の変更契約時点で各社の業務分担はできており、委託事業者は COCOA の開発は一切やらないとなっていた旨、プロジェクト管理の一部や工程管理の一部を担うことになっていた旨、厚生労働省側がその役割分担を理解していたかは分からない旨を述べている。2
「委託事業者はCOCOAの開発は一切やらない」「プロジェクト管理の一部や工程管理の一部」と元請けの立場とは思えないコメントが登場する。
パーソル自身が受け取った金額が低かったが、PJにおける役割（PJ管理、受入確認等）を全うしていたかと言うと疑問が残る。
担当者C（厚労省）：昨年６、７月は優先順位付けなどについて、定期的な打ち合わせができる状態ではなかった旨、８月以降はスプリント・プランニングが行われるようになり、優先順位付けができるようになった旨、優先順位の指示とリリースの判断は CIO 補佐官が行うというところは班内でも共通認識であったと思う旨を述べている。2
CIO 補佐官B：定期的な打ち合わせの中で課題を事業者から聞き、技術的な立場として、優先順位を決める上で判断すべきことを提案し、業務的な立場で厚生労働省から意見をもらいながら最終的に調整していく形で業務を進めていた旨を述べている。2
再委託事業者C(MTI)：自分たちの役割は表を作るところまでであって、優先順位をつけるのは別のところでやるとの認識であった旨、エンジニアがシステムの改善作業に集中できるよう、エンジニアではないメンバーが単純作業として表に載せる作業を行っていた旨、エンジニアがすぐ目につくフローでなかったことが課題であり、エンジニアが正式な業務フロー上として見るべき対象がバックログに一元化されていたが、その手前のところでエンジニアがそのイシューを検知していれば、異常に気づけた可能性はゼロではないと思う旨を述べている。2
※最後のMTIのコメントは、「昨年 11 月 25 日に GitHub 上に指摘が掲載され、12 月 4 日に当該指摘が検討リストに掲載されていたこと、その対応の検討が行われなかったこと等についての認識」におけるコメントだが、2020年8月からの体制でも概ね意思決定に関しては、MTIは関与は薄かったのではないか。
このあたりからは、タスクの優先順位付けは、CIO補佐官を主として、厚労省、委託業者（パーソル）の間で決定していたように思われる。
私見
パーソルは、ほぼ開発に関与していないと思われる。
上記に対して、中抜き、という批判があるが、あまり的を得ていないと思われる。パーソルにとっても、望んだ展開ではなかったと思う。大手の企業において、定められたルールを違反する、というのは相当な抵抗があるもの。厚労省とパーソルの間で委託比率が94％となることは致し方なし、という結論が妥当と認識するような状況であったはず。
簡単に思いつくのは、
・新たな取引先を定義し、契約するハードルが高すぎた
・パーソルでは、HER-SYSへの人員で手一杯になっており、追加の体制が組める状況に無かった
再委託先のMTIからモバイルに対応できるメンバーの調達、MSからはPJ管理、タスクの優先順位付けなどの役割を設定した。
実際、政府CIO補佐官楠氏のnoteによると、
COCOAの開発をHER-SYSに含めるための契約変更にあたっては，数事業者が手を挙げていた事情を踏まえるならば，再委託先の選定にあたって，条件を揃えて相見積もりを取るといった方法も考えられた．主契約事業者が再委託先を選定することは広く一般に行われており，決して珍しいことではない．
接触確認アプリCOCOAに限らず，各府省の新型コロナ感染症対策のシステム調達では開発着手までの時間的猶予がなく，WTOルールで定められた国際競争入札の手続きを踏むことが難しい．どうしても緊急随契，特命随契，既存契約の変更などで対応せざるを得なかった．
新規調達に要する期間と事務量が大きいために，既存案件の契約変更として新規の開発が行われ，結果として追加調達分の業者選定にあたって十分な競争性が担保されにくいことは，COCOAに限らず広く政府のIT調達が抱えている課題であり，今後の改善が望まれる．
4
とあり、やはり新規調達の対応コストよりアプリリリースを優先した決断があったように思われる。
ただ、その代償として、
結果として追加調達分の業者選定にあたって十分な競争性が担保されにくいことは，COCOAに限らず広く政府のIT調達が抱えている課題であり，今後の改善が望まれる．
ということになったのであり、業者選定の不透明さを指摘する意見も挙がっている（後述：Microsoft Azureのクラウドベンダーロックインへの批判）。
既存で出来ていたHER-SYSで採用していたクラウド基盤（Microsoft Azure）へのCOCOAからの連携も予定されていることから、Microsoftに技術支援、PMOとしての参画も取り付けた。
フィクサーは運用監視ということで開発の場には登場していない。
Covid-19 Radarの採用とまもりあいJapanの不採用
まもりあいJapanについて
まもりあいJapanは、Code for Japanによって、およそ1ヶ月〜1ヶ月半の間に作成されたアプリだが、完成度は非常に高かったと思われる。5
この組織の代表は、政府CIO補佐官でもある関 治之氏だ。noteによれば20年10月から政府CIO補佐官にもなられたようだ。
「まもりあいJapan Overview」5では、Google, Appleから提供されるExposure Notification APIの利用にも対応可能と読める記載がある。「まもりあいJapan Overview」5は第３回 新型コロナウイルス感染症対策 テックチーム Anti-Covid-19 Tech Teamで提供。この会合自体は5/8開催。
「まもりあいJapan Overview」5でも積極的に語られているが政府への提供姿勢が示されているし、そもそもCode for Japan自体、シビックテックと呼ばれる活動に意欲的な組織である。一般社団法人であり、利益を追求する組織ではない。
参考
フロントはiOSはSwift、AndroidはKotlinベース。
なお、バックエンドはGoogle firebaseをベースとしている。
Covid-19 Radarについて
Microsoftのデプロイ王子こと廣瀬一海氏筆頭にMS社員がOSS活動として参画した開発を進めていた。
フロントは、Xamarin。
バックエンドは、Azureをベースとしている。
私見
仮にパーソルからの再委託先として、Code for Japanの選択したとしても、運用時にHER-SYSはAzure、COCOAはfirebaseとなるため、運用負荷は相当高くなったことは予想できる。
単純に、HER-SYSがAzureなら、COCOAもAzureに寄せたいと考えるのは自然かな、とは思う。
橋本福大臣の
実際に開発で手を動かすのはおもにCovid-19 Radar Japan〜6
という発言はあまり理解出来なかった。
OSS Communityに実質的に納期を課してしまったということについては、どう捉えれば良いのだろうか。
厳しすぎるスケジュール
2020/5/26 にテックチームがまとめた仕様に基づいてCOCOAは開発する。
初回リリースは6/19。
私見
無理ゲー。
Covid-19 Radar依存の開発
私見
公にはできないだろうが、2020年5-7月の間は、Covid-19 Radar に依存していたと考えるのが妥当だと思われる。
厚労省の資料でも、例のベンダーの体制は「保守体制」と記載されており、COCOAの開発・構築体制ではない。このあたりからも君ら作ってないでしょ感がにじみ出ている。
政府CIO楠氏のTwitterで関与が示されているが、実働はCovid-19 Radarだったというところか。
GitHubのContributorsを見ると、ほぼ4人で作ったものと分かる。
後述の「Covid-19 Radarの疲弊」で書いているが、2020/6〜7のコミット数とその時間帯は、鬼気迫るものがある。OSS Communityの開発のイメージとは掛け離れている。これは炎上プロジェクトのコミット履歴と言われた方がしっくりくる。
2020/6/19の加藤大臣の発言7では、
とあるが、この6/19リリースまでに掛かった費用が4500万、7月末までには5000万程度を見込んでいるということだった。この4500万はCOCOA本体というよりは、厚労省の広報・リリース費用、運用費用などに投じられているように思える。7月末までの費用は、＋引き継ぎ費用といったところだろうか。
Covid-19 Radarの疲弊
2020/4-2020/7の単月ごとのコミット数
| 年月 | Commit | 参考 廣瀬さんCommit |
|---|---|---|
| 2020/4 | 1299 | 368 |
| 2020/5 | 1965 | 573 |
| 2020/6 | 3277 | 1391 |
| 2020/7 | 37 | 13 |
6月は常軌を逸したコミット数と感じる。
6/19リリースしたのはプレビュー版という立て付けだったが、うまく伝わらなかったし、出来についても良くなかったため、それはもう地獄の業火のように燃え上がってしまった。
私見
諸説あるが、Covid-19 Radarは、純粋な動機から始まったように思う。8
たまたま、既存システム（HER-SYS）がAzureで動いていたことや新規調達が出来ない、リリース期限がある、という状況で、Covid-19 Radarベースに倒れたのだと思う。実態はベース、ではなくCovid-19 Radarそのものだったようだが・・・。
内部でどういう調整があったのかはわからないが、Covid-19 Radarも走り切る方向に倒れたのだろうと思う。このあたりは、色々な思惑が錯綜していただろうし、これだ、という一つの原因に収まるものではないと思う。
広報の失敗
2020年6月19日加藤大臣会見概要
会見の初っ端で「プレビュー版」であることを強調されているが、うまく広まったとは思えない。
プロジェクト
ここではフェーズを独断で分けて分析する。
企画フェーズ
ここではCOCOAに限らず、コロナ禍における政府IT戦略の活動も含めた。境界があいまいだった。
体制
仕様検討フェーズ
体制
新型コロナウイルス感染症対策 テックチーム
保守・運用フェーズ
体制
時系列
厚労省のCOCOA不具合調査・再発防止策検討チームの概要の最後に時系列で政府・COCOAのイベントがまとめられている。
以下、私の方でまとめた補完版（完成度低し）
補完版
事実ベースの問題点
再委託比率94%
こちらの記事で、厚労省とパーソルの間で了承済みとのこと。
Azureロックイン
接触確認アプリに関する仕様書等の公表>接触確認アプリ及び関連システム仕様書
第２章 非機能要件の定義 8.中立性に関する事項は守られていない
このあたりはROCAさんの記事が痛烈に批判している。9,10,11,12
厚労省の調査報告書
この報告書の位置づけは、あくまで
とあるとおり、2020/9月以降に発生していた不具合に対する真因調査、再発防止策の検討となっている。
残念ながら、COCOAの構築全体としての問題点を総ざらいするような位置づけの資料ではない。
私見
厚労省の反省できる範囲はそこまで。ということ。結局、政府トップが落としてきた「アプリを作る」「リリースは6月中旬目処に」に対しては問題とする範疇の外ということ。
この活動の中に、積極的に情報発信してきた政府CIO補佐官の楠氏、まもりあいJapanの関氏（2020/10から政府CIO補佐官に就任13）が参加している。
Code for Japanの関氏が参加しているのは皮肉めいているようにも感じてしまう。
引用元:COCOAの不具合、内閣官房内に検証チーム メンバーにCode for Japanの関代表ら
批判
以下のような批判が見られた。
- 政府の統治への批判
- 「まもりあいJapan」を採用しなかったことに対する批判
- 中抜きに対する批判
- リリース体制に対する批判
- デプロイ王子に対する批判
- Microsoft Azureのクラウドベンダーロックインへの批判
- 運用体制への批判
現在の状況
安定してきている。※気力尽きた
調べてみての感想
この件は、ずっと対岸の火事だった。
去年は、Twitterで燃えているのを見て、うわぁー誰かやらかしたのかなーと今からすると浅すぎる受け取り方をしていた。
先日、あるCOCOAの失敗に対する意見を目にして、個人的にはそう思わなかった。だが、じゃあ本当のところはなんなんだ、というところが明確ではなかった。自分の中では何も見つからなかったため、色々と調べてみることにした。
なし崩し的に決定した色々な事柄のすべてが悪く受け取りようのある余地を残してしまったのではないかと思う。
実際に明確に悪かった点もあるが・・・。
一言で誰が悪いと言えるか？Twitterでよく見るような「政府が悪い」になってしまうのかもしれないが、そんな一言では表しきれない物事が連なっている。
自分も表層だけを見て、分かりやすい犯人を見つけて、思考せず叩く、というような行為をしたことは、恥ずかしいことだったと反省した。
個人的な学びとしては、自分の目で納得行くまで調べてみる、という基本的なことを改めて認識したということ。
まとめベタでとても疲れた・・・。
資料
厚労省
- 新型コロナウイルス接触確認アプリ（COCOA) COVID-19 Contact-Confirming Application
- [GitHub]cocoa
- COCOA不具合調査・再発防止策検討チーム
- 接触確認アプリCOCOAの現状と課題
- [Code for Japan]接触確認アプリのソースコード公開
- 加藤大臣会見概要 2020/6/19
- 再委託に係る変更承認申請書 2020/5/27
政府CIO関連
楠氏
関氏
まもりあいJapan
Covid-19 Radar
Public Meets Innovation
- 【PublicNotes特集】COCOAはなぜ機能しないのか（前編）～パーソルとの契約を「変更」した経緯～ 2021/2/26
- 【PublicNotes特集】COCOAはなぜ機能しないのか（中編）～開発体制にひそんでいた３つの落とし穴～ 2021/2/26
- 【PublicNotes特集】COCOAはなぜ機能しないのか（後編）～「失敗」に終わらせないために 社会制度にテクノロジーを位置づける～ 2021/2/26
こちらも取材されており、納得感の高い内容。
xtech
IT media
- COCOA、“多重下請け構造”解消へ 最新API対応も「重要なテーマ」 2021/3/16
- COCOAの不具合、内閣官房内に検証チーム メンバーにCode for Japanの関代表ら 2021/2/19
- 「iOS 13.7」リリース 新型コロナ接触通知、アプリなしで可能に【追記あり】 2020/9/2
- 開発コミュニティー破綻？ 接触確認アプリの問題点と批判の在り方で激論 2020/6/23
日経メディカル
ROCAさん
- #接触確認アプリ #COCOA の無償ボランティア開発美談は本当か？
- #接触確認アプリ #COCOA はマイクロソフトの夢を見せられているのだろうか？
- #接触確認アプリ #COCOA とオープンソースの危うい関係
- #接触確認アプリ #COCOA は令和時代の新たなベンダー囲い込みか
読み応えあり、説得力あり。ただ、私はなし崩し派で居たい。
石橋秀仁さん
個人的には一番刺さった。
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="360" height="360"><rect fill-opacity="0"/></svg>){kind=small}
コメント