結局『COCOA』とは何だったのか…失敗の原因を考察してみる

2021年8月6日

新型コロナウイルス接触確認アプリとして厚生労働省が担当しパーソル社が開発したCOCOA(ココア)。コロナ感染者と濃厚接触したことを感知するとそれをプッシュ通知で知らせ、利用者は医療機関の受診を自主的に検討出来るというスマホアプリでした。

国家主導で作られたアプリでしたが、結果は大失敗。アンドロイド版のCOCOAが濃厚接触者と遭遇してもプッシュ通知を出さないという不具合が4か月もの間放置されていたのです。

アプリが起動しない、動かないという不具合ならまだしも、きちんと動いているように見えて、濃厚接触しても『大丈夫でした』としてしまうのですから、むしろ害悪にしかなりませんよね。

一体何故こんなことになってしまったのか、IT業15年の私が分析してみました。(大した経歴じゃないですけど)

Contents

1. アプリはどう開発するのか
2. COCOAが失敗している点
3. まとめ

アプリはどう開発するのか

そもそもスマホアプリってどういう流れで開発するんでしょうか。システムの仕事に携わったことがない人でもひょっとしたら知っているかもしれませんが、大体以下のような流れです。

FRP(提案依頼書)の作成
『こういうアプリが作りたい』というのをボンヤリと資料にまとめ、いろんなシステム会社に見せます。システム会社はその骨子を見て肉付けをし、『ウチならこんな感じに作れますがどうですか』という提案を発注元(アプリを作りたい人)に行います。いわゆるセリとかオークションみたいなもんです。発注元はクオリティや値段を見比べて『今回はこのシステム会社にお願いしよう』と意思決定します。
要件定義書の作成
開発をお願いする会社が決まったら、システム会社が詳細に『どんなアプリを作りたいのか』を細かく聞いて、要件定義書というのを作ります。要件定義書というのは『あんたが作りたいのはこういうアプリってことで合ってる？』って文書に残して合意するものです。IT白書によればアプリの不具合の80%はこの要件定義の段階で防げると言われています。言い換えれば、ここでしっかり要件を確定させておかないと開発が始まってから『ごめんやっぱここ変えてくれる？』とか『やっぱ追加でこういう機能つけてくれる？』といった不測の要件が発生してしまい、不具合の原因になります。
設計書の作成
要件が決まったら次は設計書を作ります。設計書はシステム会社の人が作る社内用の資料です。成果物として発注元に見せる場合もあります。システム会社も大体は営業さん、マネージャーさん、プログラマーさんと役割が分かれており、設計書を作るのはマネージャーさんです。それをプログラマーに見せて、『この設計書の通りに作って下さいね』と指示します。この時はマネージャーの管理統括能力が問われる部分で、プログラマーとのコミュニケーションが不十分だとやはり不具合の原因になります。私もマネージャーの仕事をしています。
テスト計画書の作成
設計書と一緒に作る場合もありますが、作成するアプリに合わせてテスト計画を作成します。これも作るのはシステム会社です。テスト計画も単体テスト、結合テスト、シナリオテストなど、その目的によって種類が色々あります。テスト計画も発注元に成果物として提出することが多いです。成果物というのは簡単に言えば、『ちゃんと仕事してますよ』と発注元に伝える為の資料でもあります。
開発とリリース
多少順序が前後することもありますが、ここまで作ったらあとは開発とテストを行い、リリース(アプリの公開)を行います。これがおおまかなアプリ開発の流れです。今回紹介しているのはウォーターフォール型という手順で、他にも色々と手順があるのですが、私の経験だとやっぱウォーターフォール型が圧倒的に多いですね。

これらの開発工程は何も暗黙の了解ということではなく、JIS規格(国の定めた規格)とか共通フレームというもので標準化されています。細かい違いはあれど、会社ごとにやり方が全然違うと社会全体が混乱しますからね。

COCOAが失敗している点

COCOAは厚生労働省が不具合調査チームを立ち上げ、こちらのページで報告書を公開しています。内容を見て失敗の原因を分析してみました。

無理があるスケジュール

まず見て思うのは、スケジュールにかなり無理があるということです。2020年5月8日に日本のコロナ対策室や厚生労働省の関係者が会合を開き、それぞれの役割分担を決めています。いわばこれが『スタート』ということになります。

これに対し同月の25日に安倍総理が『6月中旬にアプリを導入する』と発表。その翌々日の27日にシステム会社であるパーソルプロセス＆テクノロジー株式会社に厚生労働省が開発を委託しています。その後、COCOAは6月19日に公開されました。

私からするとこの開発期間は余りにも短すぎるように思います。元々、Apple社とGoogle社が世界規模でアプリの元ネタを各国へ公開していたので、完全にイチから作るというワケではなかったみたいですが、人海戦術で作っても一カ月やそこらでこの規模のアプリを作るのは無理があります。

サイコロ転がすだけのゲームとか、現在地表示するだけのアプリだったら1～2日あれば十分です。しかしこれは国家規模の、人命が関わるアプリですからね。

結合テストしていない

スケジュールが短すぎることで色んなところが破綻していますが、まず一番の原因はテスト工程がグダグダ過ぎるところですね。開発から保守までの工程は報告書によると大体こんな感じです。

バージョン	問題	日付
1.10	初リリース。プッシュ通知が多すぎて保健所の業務が逼迫するという問題を抱えていた。	2020/6/19
1.14	上記の問題を解消したバージョン。急いで開発したのでアンドロイド版に限り『濃厚接触者と接触しても感知しない』という不具合を抱えていた。	2020/9/24
–	開発環境が整い、きちんとしたテストが出来るようになる。	2020/10/12
–	GitHub(誰でもソースを見られる仕組み)で1.14に第三者から不具合の指摘が発生。	2020/11/25
–	上記の件を含めて事業者がテストを開始。	2021/1/8
1.22	不具合を修正したバージョンを配布。	2021/2/18

まず濃厚接触者と接触しても感知しないという不具合を抱えていたバージョン1.14 ですが、初リリースから大体3か月後に公開されています。この間に十分なテストをしていれば気づけた問題かもしれません。しかしきちんとしたテスト環境が整ったのは2020年の11月。

もちろん全くテストをしていなかったという訳ではなく、文節からするとこの『テスト環境』というのは実機の動きを再現したシナリオテスト用の環境だと思うんですが、どっちにしろ本来の工程としては逆ですね。

もっと言えば、バージョン1.14 の公開を急いだのは初期バージョンの1.10 にプッシュ通知が多すぎるという不具合を抱えていたからであって、やはり1.10 をきっちりテスト/評価してから公開していれば後続の作業にもゆとりが出来たんじゃないかと思います。

○ （１）の表にあるとおり、昨年10 月 12 日にテスト環境（通知サーバー、HER-SYS 等の外部シ
ステムとの結合テストを実施するための環境）が整備されており、それまでのバージョンアップに当たっ
ては、いわば「できる範囲でのテスト」を実施していた（具体的には、以下のようなテストを実施）。
・ COCOA がインストールされている実際の携帯端末を操作し、アプリ起動や画面遷移を確認
・通知サーバーから診断鍵がダウンロードされ、接触符号の突合処理が行われていることについて、
携帯端末を PC につないでデバッグモードで動作を確認

○ テスト環境の整備前は、HER-SYS に陽性者の処理番号を照会・確認し、通知サーバーから陽性
者に係る診断鍵等の情報を取得し、接触情報の突合や接触リスクの算出を行い、通知するという
一連の動作を確認するための、いわば「接触通知までの一連の流れに係る結合テスト」については、
（テスト環境がなかったため）行うことができなかった。
引用元：接触確認アプリ「COCOA」の不具合の発生経緯の調査と
再発防止の検討について

責任分界点が曖昧

もう一つの要因として、責任分界点が曖昧だったのではないかと推測します。今回の不具合も結局『どこの企業が原因だったかわからない』といった結果になっており、報告書を読むとなんだか責任の押し付け合いみたいな感じに見えます。

事業者の体制
○ 管理職級 B は、委託事業者と話したところ、HER-SYS については品質管理を行うと認識して
いたが、COCOA についての品質管理は再委託事業者 C がやると考えていたという回答であった
旨、本来は委託事業者が不具合に気付くべきだったのではないかと思う旨を述べている。

○ 担当者 C は、COCOA の品質管理については、委託事業者が行うものと認識している旨、履
行体制図を作って事業者側にも確認をしている旨を述べている。

○ CIO 補佐官B は、契約主体として委託事業者に品質管理の責任はあったが、実態としては行
われていない旨を述べている。

○ CIO 補佐官 C は、アプリ開発が Xamarin という技術を使い、プラットフォーム側が Azure とい
うものを使っている関係で、今回のチームは割と必然性があって集められたと思う旨を指摘している。
また、分かっている範囲では、委託事業者との契約を拡大する、追加することによってでしか、期
間的な実現性はなかったのではないかと理解している旨を述べている。

○ 委託事業者は、昨年 5 月 27 日の変更契約時点で各社の業務分担はできており、委託事
業者は COCOA の開発は一切やらないとなっていた旨、プロジェクト管理の一部や工程管理の
一部を担うことになっていた旨、厚生労働省側がその役割分担を理解していたかは分からない旨
を述べている。

○ 再委託事業者 C は、各業務タスクと、それらの実行者、承認者、情報共有者の役割の定義
をしており、厚生労働省に説明をしている旨を説明している。また、再委託事業者 C は、再委託
事業者 A のプロジェクトマネジメントがタイムリーに重要な事項をフィードバックしてくれて、間に入っ
てくれていたおかげで開発業務に集中できた恩恵が大きかった旨を述べている。

○ 再委託事業者 A は、PMO 支援や技術的なアドバイスといったものが役割となっている旨につ
いて、厚生労働省に役割分担を説明している旨を説明している。
引用元：接触確認アプリ「COCOA」の不具合の発生経緯の調査と
再発防止の検討について

これはたくさんのシステム会社を投入して行うプロジェクトではよくあることです。そこで混乱しないよう、プロジェクトのリーダーやオーナーをしっかり決めて、責任の所在をはっきりさせて開発を進めるものですが、今回はそこの定義が各社毎に判断が違う(報告書では思い込みがあったと表現)のも問題の根幹でしょう。

Github上で9月の時点で問題を指摘する投稿があったが、事業者側は「誰がいつどのように行なうか具体的な業務フローがあいまい」で、事業者間のコミュニケーション不足により「各々が『他がやっているだろう』という思い込みを持っていた」とする。
引用元：https://www.watch.impress.co.jp/docs/news/1319229.html

中抜き体制

前述のように責任分界点がいい加減な要因として、日本独自の中抜き体制も遠因になっているのではないかと思います。COCOAの業務の流れは図にすると以下のようになっています。

引用元：東京新聞

当初は3億9036万円で発注されたCOCOAアプリ。予算規模としては相当デカいです。システム会社に仕事を発注する場合、かかる費用を通常は人工(にんく)という単位で計算します。人日(にんにち)とも言いますね。1人/日であれば『うちの会社の社員を一人、一日自由に使えますよ』という意味です。

人工の相場は企業規模や属性によってマチマチですが、小さい会社で5～6万くらい。東証一部上場の大企業でもせいぜい10万くらいじゃないでしょうか。少なくとも私の周りではそうです。(自分の経験が全日本に当てはまるとは思いませんが)

とりあえず一番高くて1人/日 10万円としてザックリ計算すると、3億9000万という金額は『1人の人間を10年くらい自由に使えますよ』という金額です。『3900人の人間を1日自由に使えますよ』とも言い換えられます。

まあプロジェクト開発はサーバを建てたりインフラを整備したり、ヒト以外にもお金を使うので全部人工に予算投入は出来ませんが、感覚的にはやはり大規模ということです。

これを厚生労働省から競合他社の比較なし(つまり"セリ"をしていない。ここも問題)で受注したパーソル社は2200万円ほどを抜いて日本マイクロソフト、エムティーアイ、フィクサーという3社に再委託しています。この時の再委託比率は94%。規定の50%を大幅に超えています。

そもそも何故再委託比率に50%というリミットが設けられているかというと『再委託先に丸投げ』を防ぐ為です。今回のケースでは恐らく、パーソル自身はほとんど何もせず、業者に丸投げして2200万抜いてるだけなんじゃないかと思います。少ししかお金もらってないからウチは見てるだけでいいよね！って感覚。後に今回の不具合騒動の発覚後、自主的に1200万円を厚生労働省に返金していますが、どっちにしろ『何もしないで1000万もらった』ということになります。まあ、何もしないどころか逆にやらかしてるんですけどね。

更にこの後、エムティーアイという企業が1億5000万円ほどを抜いて更にイー・ガーディアン、ディアイザードという企業に再々委託しています。このエムティーアイという企業がプロジェクトの中でどの程度活躍したのかは分かりませんが、ディアイザード社なんかには400万しか渡ってません。これだと40人/日ですから2人の人間を2カ月動かせる程度ですね。

またプロジェクトオーナーである厚生労働省も責任感は薄かったみたいです。報告書を読むと担当者が短期の間にコロコロ変わっており、良く分からんことになってます。

① 厚生労働省の体制等
○ 昨年 4 月時点では、テックチーム主導でアプリの検討が行われており、厚生労働省にも関係省庁
として声がかけられていたが、基本的には必要に応じて連絡を受け、関与する程度であった。

○ 昨年 5 月 8 日のテックチーム第３回会合において、厚生労働省が「テックチームから提供された仕様
書案を用いてアプリ開発・実装・運用」することが確認された。その前後から、6 月 19 日のバージョン
「1.1.0」版のリリースに至るまで、コロナ本部の担当参事官が主となってアプリ開発に関する業務を行
っていた。また、民間企業から厚労省への出向者（以後１、２か月単位で交代）が当該業務を
補助していた。

○ 昨年6 月11 日に担当の課長補佐が着任。

○ 昨年7 月13 日に COCOA 担当の CIO 補佐官が着任。

○ 昨年 8 月 1 日に、コロナ本部の組織再編により設置された疫学・データ班が COCOA の業務を
引き継ぎ、班長及び技術参与が着任。また、他部局の室長級職員１名が COCOA の担当を兼務。

○ 昨年11 月1 日に担当の CIO 補佐官が交代（同月は引継ぎ期間）。
引用元：接触確認アプリ「COCOA」の不具合の発生経緯の調査と
再発防止の検討について