かになべ

ノンジャンル

接触確認アプリ「COCOA」不具合、結局誰が悪いの？の話と今日日のシステム開発における請負契約について【2/17追記】

社会制度 COVID-19 IT技術

いつもの自分用メモ（免責）。

厚生労働省は2021年2月3日、新型コロナウイルス感染拡大防止策として導入した接触確認アプリ「COCOA（ココア）」で、陽性登録したアプリ利用者と接触しても検知・通知されない障害が判明したと発表した。

接触確認アプリ「COCOA」Android版で不具合、20年9月から検知・通知されず | 日経クロステック（xTECH）

COCOAでは、陽性登録したアプリ利用者の1メートル以内に15分以上いると、陽性登録者と接触があったことを検知・通知する。今回明らかになったのは、この条件を満たしても接触があったことを検知・通知しないという不具合になる。2020年9月28日のバージョンアップ以降、Android版アプリで発生していた。


アプリの目的である新型コロナウイルスの持つ社会的インパクト、また不具合が9月28日からと４ヶ月以上修正されていなかったたことから、TV、新聞、ネット各方面で話題になっていた。

厚労省は今年１月まで把握できず「対応は開発業者に委託している」としている。障害を洗い出す動作試験ではミス部分をチェックしていなかった。

　ミスが投稿されたのは、大量のプログラム情報がやりとりされ、多くの技術者が閲覧するサイト「ＧｉｔＨｕｂ」（ギットハブ）。厚労省は「アプリ機能の改善を図るため公開している」と説明している。

　このサイトで昨年１１月末「（ココア）アンドロイド版では接触が検知されることはないと思われます」と匿名の投稿があり、１２月にはミスの分析も掲載された。

コロナ接触アプリ「COCOA」障害、ネットでミス指摘 厚労省は情報把握せず - SankeiBiz（サンケイビズ）：自分を磨く経済情報サイト


情報開示請求で明かされたこと

また、むぐらさんという方がこのアプリについて厚労省へ情報開示請求を行っており、自身のnoteに開示された文書を公開されていた。

note.com

この記事では、有志の作成したオープンソースソフトウェア「Covid-19 Radar JAPAN」の「Covid-19 Radar」及び「一般社団法人コード・フォー・ジャパン」の「まもりあいJAPAN」から厚労省発注の請負契約に至った経緯について、判明している情報と疑問点等が整理されている。

また、変更契約を含めた開発契約についての情報（金額：2億9448万9147円、元請：パーソルP&T）が明らかになった。

f:id:russENG:20210214105256p:plain
結果として、2億9448万円のゆくえはおおよそ、こうなりました。


指摘された多重下請け構造は、しばらくTwitterでプチバズと承認を得たいアカウントの格好の"材料"になってしまっていた。

いくつかの事実誤認や決めつけが見られるが、この多重下請け構造と、今回の「不具合の放置」を関連付けて問題を指摘する声が多数見受けられた。


今回の開発契約が、多重下請けがもたらす悪（中抜きと責任の所在が曖昧になること）として指摘できるほどの悪と言えるのか、私にはわからない。*1
次の中見出し以降では、本当に多重下請け構造が、今回の不具合放置の問題の原因だったのだろうか？という話をする。


不具合を発見する義務があったのは誰？

むぐらさんがnoteで公開した開発契約の仕様書を読むと、変更後においても、契約期間は「令和2年7月31日まで」となっている。

この情報開示請求は、9月14日以前に行われたもののようだが、この時点で運用保守に関する契約に関する文書はない。

（そうすると、今回の開示請求の範囲に対して、開示された文書が適切なのか、とも思うが・・・。）

運用保守に関する契約に関する文書はないため、その契約がパーソルP&Tと結んでいるものなのか、それが多重下請け構造を持つものだったのか、はたまた運用保守契約は結んでおらず、厚労省やIT室が自前で運用保守を行う考えだったのかについて、現時点のソースでは「よくわからない」ということになる。


結局のところ、開示された文書以外に運用保守契約を結んでいないのであれば、この開発契約のSLA契約で定められた範囲を紐解くしか、責任の所在は明らかにならない。

私が発注者なら、API仕様変更に伴うシステムの改修作業は含めないまでも、本件の特性から、何らかのテスト手法による機能の継続的な監視とその報告はSLA契約に含めるだろうな、という気もする。


そもそもこういった開発契約を請負契約でやるべきなのか問題

ここからはITエンジニアではない自分*2にはいよいよわからない領域になっていくが（息を吐くように免責していく。）

接触監視アプリCOCOAで報道では伝えきれてない要素

  • GoogleとAppleの技術者が話し合って技術的仕様を頻繁に更新している
  • 毎日とか毎週の単位で話し合いを追いかけて、その仕様変更に追随してアプリを修正するのが最低限必要な作業
  • 官公庁が発注している業者は通常はそういう開発手法をしていない

医療ITに関する情報メディアMed IT編集部による、今回の問題の解説。

f:id:russENG:20210214114740p:plain
Med ITによる今回の問題の解説

【編集部コラム】接触確認アプリ「COCOA」の開発体制が確認できないのはなぜ？ | Med IT Tech

ハードウェア寄りなネットワーク基盤とソフトウェア寄りのSDNの両方をやってる立場からすると今のソフトウェアって「運用保守」ではなく「継続的な開発」って呼ぶぐらいの心構えで取り組んでいかないと厳しみがあるなと感じる


そもそもこういった継続的な仕様変更への対応が求められる案件においては、請負契約という契約形態は適切なのだろうか？


請負契約には、「計画時に問題は予見できる前提がある」「成果物は買い切りが原則」といった性質があり、本件とは馴染まない点が多いように感じる。


以前、ITエンジニアの方達とのクローズドな飲み会でこの議題が上がったことがあり、色々教えてもらったのだが、開発における不確実性をマネジメントしていく発想であるアジャイルと、請負契約とは本質的に馴染まないものであるらしい。

だいたいにおいて、「開発をアジャイルでやりたい」とか言い出す輩ほど、アジャイルのことを何も分かってないケースが多いです。
　そもそも「アジャイル開発」などと言うものは存在しません。「アジャイル(agile)」は「俊敏な」「素早い」「小回りのきく」といった意味を示す形容詞であり、「アジャイルな開発」というものはあっても「アジャイル開発」という開発手法や開発プロセスがこの世にあるわけではないです。アジャイルソフトウェア開発宣言(アジャイルマニフェスト)とその背後にある12の原則に沿う開発プラクティスがいくつも存在し、それらを総じて「アジャイル」と呼ばれているのに過ぎないのです。
　前述のように「アジャイル＝スクラム」のイメージを持っていてくれているならまだマシですが、そんなレベルにさえないことが残念ながら大半のようです。

「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？ - ミッションたぶんPossible

それでも請負契約の商慣習がなくならないのはなぜか？　私論ではそれは予算制度・決算制度とのロジックの相性による、と考えているのだが、それはまた別の記事で。


ちなみに、今回の仕様書にもアジャイル・スクラムを使用する、と書いてあって以下のように色々とえ？と思ってしまった。

  • 前述の通り請負契約であればアジャイルではないのでは？
  • アジャイルでなければ成果物の品質が満たせないとする根拠があるのか？

（つまり、ウォーターフォールかアジャイルかは受注者が自らの責任で定めるものであって、発注者が定める理由がよくわからない。）

  • 仕様に規定したものは成果物の検査（検収）時に確認する必要があるが、どうやって確認するのか（本当に確認した？）
f:id:russENG:20210214131501p:plain
仕様書一部


逆に発注側からの視点のみから見るのであれば、今回はオープンソースソフトウェアが既にあり、そこからの移行時に、政府のテックチームとコード・フォー・ジャパンが接触し、かなり細部にわたって「まもりあいJAPAN」を元にした議論が行われていた。それに関してはアジャイルの一部と解釈できなくもないのではないか。


末尾で全く違う話をすると、私は今回の件を厚労省が発注しシステムを買い上げ国民に供したことについては全く悪いことだとは思っていない。このシステムの性質上、公共サービスを提供する政府が予算を執行するべき性質のもの、責任を追うべき性質のものだと思う。


2021/2/17 追記

別に誰から反論が来たわけでもないが、色々と考え直してみた。
上段の、末尾２段を書いた時点で、私の思っていた意図を整理した。
オープンソースコミュニティーによって作成されたソフトウェアをそのまま国民が使うといった場合、２つ問題点が発生しそうだな、と思った。

  1. 然るべき報酬が開発者に支払われない点
  2. 責任の所在がさらに不明瞭になってしまう事態が発生する「かもしれない」点
  • 不具合が起きた時に、善意で開発を行った有志に責任を求めてしまうのはいかがなものか。
  • また逆に、例えば今回のような開示請求がある場合、オープンソースコミュニティーに請求に応じる法的な責任はないわけで。

１個目に関しては、現在の厚労省発注パターンでも最初のオープンソースソフトウェアには支払われていない可能性が高いが（もしかしたら顧問料等の形で会議への出席に関しては払われているかもしれない）、それでも残りの開発・リリース・調整について、全く支払われないであるとか、国が「作ってくれたんだ、ありがとう、じゃあ使わせてもらうね」といった態度ではイカンでしょ、と思った。

しかし、上述のコードフォージャパン代表の関さんが以下のようなnoteを書いておられた。
シビックテックに関してまだまだ知らないことが多いため、文意を掴めているとは言い難いが。

良く言われているメリットである「ベンダーロックインが防げる」という話だけではないのです。税金を使って構築したシステムが特定のベンダーの知的財産としてブラックボックス化されるのではなく、社会の誰もが使える知的資産となり、長い目で見ればコストが下がるだけでなく、人材育成や共有財の蓄積に繋がるのです。

自治体には、このように他の自治体向けにソースコードを公開してほしいし、その逆も期待します。これから公共サービスやまちづくりに関わる企業は、青い部分で活躍していただくことを望みます。
Code for Japan としてリリースに至らなかった接触確認アプリのソースコードや知見をオープンに公開するのも、それが知的資本として社会に残ると信じているからです。

EUでは、公共部門のコスト削減、国内のソフトウェア業界の活性化、プロプライエタリなソフトの制約のない相互接続性の促進のために、第5次フレームワークプログラム(1998-2002)以降戦略的にオープンソース振興策を取ってきました。オープンソースプロジェクトへの研究資金の提供を始め、EU域内の地図・空間情報の統合・共有化を目指すINSPIRE指令(2006)や、加盟国間でオープンソースソフトウェアのベストプラクティスを共有するための Open Source Observatory and Repository（OSOR）の立ち上げ(2006)、総額3億ユーロ（約390億円）を投資し、オープンな情報共有基盤であるFIWAREを生み出したプロジェクト、 FI-PPP（2011-2016）など、積極的な投資を続けています。

行政がオープンソースに投資すべき理由｜Hal Seki｜note


素晴らしい理念だ。私がまだ心配するのは、この記事で取り上げてきた、現在の請負契約が持つ「対価と責任分界点のシステム」をこういった新しいスキームに「翻訳」というのはいかにしてできるものなのだろうか。

するとしたら何から始めて、行政に何を返させ、どんなものを作れば理想が実現できるのか。自分用メモで書き始めたが、この方向に何か良いものがありそうな気がする。

2021/2/17 追記終わり

以下、取りこぼした議論。

泥のcocoaがまともに動いてなかったのは社会的意義を考えるとごめんで済まない系問題だと言うのはそうなんだけど、この国はとにかく何かやらかすとそれがせっかく芽吹き始めた貴重な芽であろうとも地面ごとえぐる勢いで叩き潰す風習があるのでという意味であまり過熱しないで欲しいみたいな気持ちある




官公庁系の”絶対”失敗しない。問題が発生しないという姿勢がある限り、COCOAみたいなのは計画しちゃダメという結論やろ。もし、それでもやる場合は、NTTデータクラスの超巨大組織のSIerがやる今までの方式以外ないべ。
ただ、この問題の根源は、日本人のゼロリスク教の狂信者が多いことに由来する。






COCOAの不具合、厚労省の問題が凝縮している。民間システムをチェックできるIT人材がほぼ皆無、業務量膨大で回ってないなど。ハインリッヒの法則では、重大な1件ミスの裏には、軽微なミスが29件、ヒヤリハットが300件あるという。表面的に厚労省を叩くだけでなく、組織構造を改善しないと再発する。

*1:ちなみに総額の３億円自体は、SIerに勤める友人に聞いたところ、今回の調整の人件費等々加味すればまあまあ妥当な値段だろう、とのこと。

*2:発注、仕様書作成経験は何個か。ただ契約書類作成くらいの話。