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