これをあなたが見ているということは、筆者は無事に前回の続きを書き上げられたようだ。大変喜ばしい。

TL;DR

• やはり接触確認アプリ COCOA開発とCOVID-19Radar オープンソースプロジェクトは不可分一体だった
• 接触確認アプリ COCOAはマイクロソフトのためのショールームだったのではないか
• 現在のXamarin + Azureプラットフォームは調達仕様を満たしていないのではないか
• 我々は接触確認アプリ COCOA開発を今後どうすべきか

前回同様、本稿では開発者個人へあったとされる人格攻撃やバグ騒ぎなどの話題については扱いません

COVID-19Radar オープンソースプロジェクトのGitHubレポジトリを可視化してみる

裁判判決に伴い削除

今回はまずCOVID-19Radar オープンソースプロジェクトがどのように開発されていたかを見てみよう。

Covid-19Radar/Covid19Radar

COVID-19Radarオープンソースプロジェクトはマイクロソフト自身が買収した世界最大のGitプロバイダーサービスであるGitHub上で行われている。
パブリックなオープンソースであるので、誰もが自由にソースコードを参照しまたその開発履歴を確認することもできる。

上記に示したのはContributor(開発者)一覧の画面だ(6/28現在)。グラフは最初に開発が始まってからの全体と開発者ごとのコミット数の推移を示している。大雑把に言うと各開発者が開発したソースコードをまとめていく推移だと思っていいだろう。
この画面で確認できる開発者はざっと87人だ。

前回も述べたが、恐らく廣瀬氏が開発を開始してしばらくは純粋に個人によるオープンソースプロジェクトであったろうと考えている。しかしどこからかマイクロソフト自身のプロジェクトと化したタイミングがあったはずだ。

グラフを一見して気付くのは山が2つあることだ。
最初の山の頂点は4/18頃、そこから4月末へ向けてピークは下がっていく。
そして5月以降大きく山は再び登りだし6/7頃に二度目の最大のピークを迎えている。

おそらく最初の山が純粋なオープンソースプロジェクトとしての山で、以降がマイクロソフト社員としての接触確認アプリ COCOAの開発であったのだろう。

また全体割合からは接触確認アプリ COCOAの開発時においても廣瀬氏を筆頭にせいぜい4名程度がメインの開発者だったらしいことが分かる。
これはメディアで彼らがインタビューに答えていた内容とも符合する。

ここで簡単なプログラムを用いてこれらのコミットログから特に廣瀬氏に関して、彼がどのような時間帯でコミットを行っていたか、3−6月まで月ごとに時間帯別のコミット回数を算出してみた。(あくまで回数であって作業時間を示しているわけでは無いことには注意して欲しい)

$ python ./aggregateGithubCommits.py --author=kazumihirose
Repository: git://github.com/Covid-19Radar/Covid19Radar.git
Total:      9492
  Author:     kazumihirose
    Period:     2020-06-01 - 2020-06-30
       Hour      00        01        02        03        04        05        06        07        08        09        10        11        12        13        14        15        16        17        18        19        20        21        22        23
      Count        94       121        80       129       138        66        36        54        24        56        41        53       139        71       118        99       117        42        85       112       149       116       150       165
      SubTotal:  2255
    Period:     2020-05-01 - 2020-05-31
       Hour      00        01        02        03        04        05        06        07        08        09        10        11        12        13        14        15        16        17        18        19        20        21        22        23
      Count        90        42        60        52        56        24         4                   4        16        40        58        42       114        60        24        40        53        48        20         8        24        44        58
      SubTotal:   981
    Period:     2020-04-01 - 2020-04-30
       Hour      00        01        02        03        04        05        06        07        08        09        10        11        12        13        14        15        16        17        18        19        20        21        22        23
      Count        68        38        34         4        12        24                                                14        10         9        31        32        24         6        28        28        18        14        50        38        78
      SubTotal:   560
    Period:     2020-03-01 - 2020-03-31
       Hour      00        01        02        03        04        05        06        07        08        09        10        11        12        13        14        15        16        17        18        19        20        21        22        23
      Count         1                                       2                                                                     2         1         1
      SubTotal:     7
   AuthorTotal:  3803
JSON:
{"kazumihirose": {"2020-06-01 - 2020-06-30": {"20": 149, "16": 117, "14": 118, "12": 139, "21": 116, "13": 71, "11": 53, "10": 41, "09": 56, "23": 165, "19": 112, "18": 85, "03": 129, "00": 94, "22": 150, "15": 99, "02": 80, "01": 121, "04": 138, "05": 66, "17": 42, "06": 36, "08": 24, "07": 54}, "2020-05-01 - 2020-05-31": {"20": 8, "14": 60, "13": 114, "12": 42, "11": 58, "05": 24, "00": 90, "23": 58, "17": 53, "15": 24, "01": 42, "03": 52, "21": 24, "19": 20, "18": 48, "10": 40, "16": 40, "09": 16, "04": 56, "02": 60, "08": 4, "22": 44, "06": 4}, "2020-04-01 - 2020-04-30": {"15": 24, "00": 68, "20": 14, "01": 38, "21": 50, "18": 28, "02": 34, "23": 78, "14": 32, "12": 9, "05": 24, "03": 4, "22": 38, "17": 28, "13": 31, "11": 10, "10": 14, "19": 18, "04": 12, "16": 6}, "2020-03-01 - 2020-03-31": {"12": 1, "00": 1, "11": 2, "13": 1, "04": 2}}}
CSV:
"Author","Period","00","01","02","03","04","05","06","07","08","09","10","11","12","13","14","15","16","17","18","19","20","21","22","23"
"kazumihirose","2020-06-01 - 2020-06-30","94","121","80","129","138","66","36","54","24","56","41","53","139","71","118","99","117","42","85","112","149","116","150","165"
"kazumihirose","2020-05-01 - 2020-05-31","90","42","60","52","56","24","4","","4","16","40","58","42","114","60","24","40","53","48","20","8","24","44","58"
"kazumihirose","2020-04-01 - 2020-04-30","68","38","34","4","12","24","","","","","14","10","9","31","32","24","6","28","28","18","14","50","38","78"
"kazumihirose","2020-03-01 - 2020-03-31","1","","","","2","","","","","","","2","1","1","","","","","","","","","",""

一見してわかるのは5月までに比べて6月は昼夜関係なくどの時間帯においても非常に多くのコミットが行われていたと言うことだ。
話としてはずれるが、まさに過酷な労働状態であったろう。これには心から同情する。ワークバランスや労基法などどこ吹く風状態、確か日本マイクロソフトは週休3日制導入を喧伝していたと思うが、その話はどこへいったのだろう。どのような労務管理を行っているのだろう。

裁判判決に伴い削除

Apple/Google APIへの対応は5/5から開始されていた

ではどの時点からCOVID-19Radar オープンソースプロジェクトは接触確認アプリ COCOAへと作り替え始めたのか。コミット履歴を追ってみる。

Apple/Google APIは「Exposure Notification API」と呼ばれている。
例えば以下はマイクロソフトがXamarin向けにこのAPIへ対応したことをアナウンスしている、5/6付けのブログ記事だ。

Exposure Notification API Support for Xamarin Apps

接触確認アプリの根本機能はこのExposure Notification APIへの対応なので、恐らくこれに対応した時期が、マイクロソフトが関与して接触確認アプリを提供すると決定されて程なくであるはずだ。

確認してみると、下記のように5/5から5/6へかけて先の記事にもあるXamarin向けExposure Notification APIへ対応しているようだ。

関連するのは以下のコミットとなるだろうか。

• Add xamarin.exposurenotification
• Install Exposure Notification beta
• add platfrom Cross Platform Exposure Notification for Xamarin

ここで時系列を整理してみよう。

5/8の会合で議論され合意したわけでは無くそれ以前に当然根回しや水面下での決着が行われていたはずで、また4/28にドイツでの採用がわかり厚労省所管へと方針が変わったとも聞くが、5/5ｰ5/6頃からマイクロソフトにて接触確認アプリ開発が(オープンソースプロジェクトという建前で)始まったとすると非常に納得できる時系列だ。

具体的に水面下で厚労省内でまた各ベンダーとどのような折衝が行われていたかはもちろん分からない。しかし4/28の前後で厚労省所管が決まりパーソルプロセス＆テクノロジーを元請けにマイクロソフト・ファミリーが接触確認アプリ開発含めて、5/5以前に決定されたと考えるのが自然だろう。
そう考えると、マイクロソフトがXamarin向けにExposure Notification APIへ対応したことをアナウンスした、または対応自体もこの決定に間に合わせたのではないだろうか。

いずれにせよ、マイクロソフト・ファミリーによるAzureクラウドとXamarinアプリという全面的なマイクロソフト製品の採用はこの時点には既に決定されていたのだということがわかる。

更には、COVID-19Radar オープンソースプロジェクトと厚労省公式接触確認アプリ COCOAは建前上別物であるはずだが、COVID-19Radar オープンソースプロジェクトにはしっかりと厚労省のシンボルマーク画像が含まれている。

以下のようなIssueでも指摘されているが、特に本日までに何ら反応は無い。「どうしようもない」ということだろうか。

これらからも、実際にはCOVID-19Radar オープンソースプロジェクトは今や建前で、5月以降は実質的な厚労省公式接触確認アプリであったことは明白であろう。

マイクロソフトの深謀遠慮

1つの大きな疑問を抱く方もいるだろう。
マイクロソフト(およびファミリー)は自社社員のオープンソースプロジェクトを「無理に」活用してまでこの接触確認アプリ開発に何故入れ込んだのかということだ。

もちろんこれはビジネスであり旨みが多いと言われる官庁仕事(根拠は筆者は現実に接したことが無いのでよくわからない)なので、と言われればそれだけかも知れない。目の前にぶら下がった案件を確実に取りに行くのは営利企業としては当然の行動だ。

しかし筆者は実際には、接触確認のモバイルアプリ開発でのメリットではなく、官公庁案件でのAzureクラウドの採用こそが、マイクロソフトが自身では慣れないはずのモバイルアプリ開発を無理に押してまで手に入れたかったことでは無いかと思える。

実はあまり知られていないのではないかと感じているのだが、COCOA(もうCOVID-19Radar オープンソースプロジェクトと呼ぶ必要も無いだろう)のGitHubレポジトリには、モバイルアプリのソースコードだけで無く、サーバーサイドのアプリケーションもしっかり含まれている。
つまりモバイルアプリとサーバーアプリケーション全て実際に各自が構築してみることも可能と思われる。
但し、サーバーアプリケーションのためにはAzureクラウドでアカウントを用意する必要がある。これはサーバーアプリケーションはAzureクラウドを前提としているためだ。

まずinfrastructure以下はAzureクラウドへAzure Functions(サーバレスアプリケーション)やCosmosDBなどを作成するためのTerraform構成ファイルだ。
Azure Functionsで動作するサーバーアプリケーションのソースコードはsrc以下にある。

モバイルアプリをビルドしている人はよく見かけるが、興味があるならばAzureクラウドのアカウントを作成してサーバーサイドの環境を立ち上げてみても良いかも知れない。

しかし確かにマイナーなプラットフォームばかりではある。
Xamarinはまだしも(それでも大勢はiOSならSwift、AndroidならJavaだろう)、Azure FunctionsとCosmosDBの組み合わせでの開発案件などどの程度あるだろうか。
だがそここそが、マイクロソフトがなんとしても食い込みたかった理由ではないのか。

Azureがクラウド分野でAmazon AWSに大きく水をあけられつつも熾烈な競争を世界中で繰り広げているのは皆さんもご存じだろう。

また昨年には日本政府が政府共通プラットフォームとしてAWSを採用し、国内でも手痛い敗北をしている。
今後地方自治体などでもクラウドの採用は進むだろうが、政府がAWSを採用しているという事実はマイクロソフト/Azureにはマイナス材料であることは間違いない。

これは完全に想像だが、基本ベンダーであるマイクロソフトがアプリケーションを開発してまで手に入れたかったものは、この国内で大きく注目されることとなる接触確認アプリでのAzureクラウドの採用という実績ではなかったか。
言うなればAzureクラウドのためのショールームとして接触確認アプリを活用したいのではないか。

だが個人的にはそれは諸刃の剣では無かったかとも思っている。

この接触確認アプリシステムはシステム仕様の要求を満たせていない可能性

接触確認アプリに関する仕様書等の公表

5/26に公開された接触確認アプリ及び関連システム仕様書では次のような非機能要件がある

8. 中立性に関する事項
– いわゆるベンダーロックインの解消等による調達コストの削減、透明性向上等を図るため、市場において容易に取得できるオープンな標準的技術又は製品を用い、特定のハードウェア又はソフトウェアに依存しない仕様とする。
– 本アプリへの信頼を高めるため、開発ドキュメント等の透明性の確保に配慮する。

https://cio.go.jp/sites/default/files/uploads/documents/techteam_20200526_01.pdf

XamarinやあるいはAzure FunctionsとCosmosDBなど、Azureクラウドであってももっとより市場が開かれ開発者も多い、よりオープンな製品もあったろうに、何故このようなマイナーで、言ってしまえばプロプライエタリなマイクロソフト製品を選択しているのか、ということだ。

これは上記の中立性に関する事項に反しているのではないか。

手前味噌で恐縮なのだが、先日筆者はこのようなツイートをした。

またこういう記事もある。ベンダーロックインというよりスイッチングコストの問題という視点には筆者も賛成だ。

クラウドサービス利用者につきまとう「ベンダーロックイン」問題にはどう対処するべきなのか？

今回に限らず政府調達は基本的に委託業務となる。更に今回のように受託側から再委託がなされていると、細かな指示は発注側からは法律上出せない。
そのため納品時または検収時に上記のような事前に示した調達仕様を満たしているか技官らが念入りに確認を行うこととなる。

今回も当然そうなると思うが、現時点ではプレビュー版という位置付けであり、受け入れテスト(や検収？)は今後予定されるのだという。

その時これだけプロプライエタリなシステムがどのような評価を受けるか？
我々はしっかりと見届けなければならない。

我々は接触確認アプリ COCOA開発を今後どうすべきか？

まだ何も終わっていないし始まってもいない、プレビュー版がリリースされただけ。それが接触確認アプリ COCOAの現状である。

我々が上記のような厚労省での検収までに考えるべきは、まずはこれまで述べてきた数々の「深謀遠慮」はあったのかどうか、何故マイクロソフトなのか、明確にすべきだ。
すでに指摘されているように、政府は発注先のことはわからないでは無く、国の重要な大変注目される事業であるのだから、発注先にプラットフォームとアプリケーション選択の経緯をはっきりさせるべきだ。

特に何故オープンソースプロジェクトでなくてはならなかったか。
一旦仕切り直すのであれば、新たに作られる接触確認アプリのコード自体をオープンソースとするだけで良かったのではないか。何故マイクロソフト社員のオープンソースプロジェクトの流用だったのか。
これは何故Code for Japanでなかったか、という問いと同じだ。

最後にそこに関して報じられた記事の内容を引用しておこう。

「政府委託を少人数の組織に任せられるのか」「何か問題が起きた時に対応できるのか」。政府が主体となって民間に開発を委託する形に方針転換したため、政府内にこんな声があがるなど、CFJへの見方が変わったと関係者は明かす。「大企業でもないCFJには荷が重い」との判断だ。開発は普段から政府発注事業を手掛けている大企業が担うとみられている

コロナ接触確認アプリ、導入1カ月遅れの曲折(2020年6月1日付け)

私は政府と会話をしたいと思っている。政府の回答を聞きたいと思っている。
日々私たちがGitHubのIssueで交わしているのと同じようにディスカッションをしたいのである。