Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

厚生労働省発表の調査と再発防止の検討について #35

Open
moonmile opened this issue Apr 22, 2021 · 36 comments
Open

厚生労働省発表の調査と再発防止の検討について #35

moonmile opened this issue Apr 22, 2021 · 36 comments

Comments

@moonmile
Copy link
Member

COCOA不具合調査・再発防止策検討チーム|厚生労働省

報道やツイッターの感想もいくつか出揃った感があるので、検討した後をどうするのか?を考えていきたいと思います。

image

概要の最初にある通り、目的が「再発防止策」を立てることなので、ここから実行しないと意味がありません。
で、そもそも

  • この「再発防止策」が再発に役立つのか?
  • 主原因はこの調査に書かれているものなのか?

等、疑問な点がいくつかあります。
特に、官庁系のITシステムには、ISO9001レベル(品質管理システム)が要求されるため、ある程度の管理文書や開発プロセスが決められています。その部分に対して、

  • ISO9001(品質管理システム)
  • PMBOK

の観点から再検討したいと考えています。以下、自由な議論の場として issue を置いておきます。議論が発散するようであれば、別途 issue を立ててしまって構いません。

@moonmile
Copy link
Member Author

資料として、品質マネジメントシステムの方。

JISQ9001:2015 品質マネジメントシステム-要求事項

@moonmile
Copy link
Member Author

改めて「5.再発防止策」を見ていると、何もできていないので PMBOK の手順をきちんと入れてください、としか言いようがなくなるので、具体的に示しておこう。

先の「4.評価」で述べたとおり、通知サーバー、HER-SYS、EN API 及びCOCOA のアプリはそれ
ぞれ、改修・アップデートが随時行われることを踏まえれば、理論上は、それぞれの改修・アップデート
の都度、システム上適切に接続・連携されていることについて、テスト環境において一連の動作検証
を行うことが適切である(また、品質管理を徹底する観点から、バージョンアップ以外のタイミングに
あっても定点観測的に動作確認を行うことも考えられる。)。

「品質管理を徹底」とあるので、品質管理システムのリリース手順に則るとよい。
製品リリース前の出荷検査にあたるものなので、

  • 出荷時の試験項目と試験結果
  • 出荷時の製品の確定(これは GitHub のバージョン管理でよいと思う)

出荷テストをするは受託側で試験項目と結果を提出、受け入れ検査(この場合は厚生労働省あるいは国?)は立ち合いで、
細かなところまではチェックしないが、おおむね試験結果のチェックを行う程度。

「テスト環境において一連の動作検証」というのは、出荷検査の前の通常の試験(運用試験とか結合試験とか)を
意味するだろうから、これはテスト環境とテスト項目の抽出とテスト結果を残す。

  • テスト環境については、環境構築の手順書を残す
  • テスト項目の抽出
  • テストの実施と結果

が、文書として残る。一般的に試験仕様書兼結果書が納品物件に含まれるので、これを国あるいは厚生労働省がチェック。
スクラム開発の場合は、明確な文書として残るかどうかわからないけど、少なくともバックログには項目が上がっている
だろう。

@moonmile
Copy link
Member Author

今後、デジタル化の進展を見据えれば、国が主導的にアプリ等を開発・運用保守を行う事業が
増加していくことが見込まれるが、今回の事案の反省も踏まえ、そうした事業においては、開発当初
より外部システムとの結合テストを実施するための環境を整備しておくことや、標準的なテストケースを
明確にしておくこと等が求められる(これらの点について仕様書に具体的に記載しておくことも重要)。

COCOA の場合は状況が特殊なので、結合試験等のテスト環境を国あるいは厚生労働省が用意すべきだったか
どうかは難しいところ。実際オリパラアプリは委託になるし、たぶん国側にテスト環境はない状態だと思う。

試験の実施については、受託開発の場合は納品時に試験項目と結果書の文書を求めればよいので、それを
以って試験の監査結果とする。なので、試験自体を実施していない、ということにはならない(という建前)。
開発工程については、委託時に ISO9001 に準じれば「プロジェクト計画書」の提出が求められるので、
開発時の設計書、試験項目や試験環境等は「プロジェクト計画書」に記述される。

「標準的なテストケース」については、受託側が責任を以って行うという契約なので、国あるいは厚生労働省側で
用意しなくても構わない。
ただし、受け入れ試験を行う場合は、要件定義書の要件を満たしているかを試験することになる。
受け入れ試験自体は、受託した会社でやることもあるし、顧客側のサーバーやマシンにインストールして後
動作確認をすることもあるので、これも試験環境自体を委託側(国あるいは厚生労働省)が用意しなければ
ならないという訳でもない。あれば望ましいが。

「これらの点について仕様書に具体的に記載しておくことも重要」の部分は、受入れ試験時の項目となる。
これは要件定義書から機能要件・機能外要件としてピックアップして実施する。

@moonmile
Copy link
Member Author

先の「評価」で述べたとおり、今回4か月にわたり不具合に気付くことができなかった原因の一つ
として、厚生労働省側にも事業者側にも、様々な「思い込み」があったことが挙げられるが、こうした
「思い込み」の発生を防止するためには、厚生労働省と事業者、及び事業者間のより継続的かつ
明確なコミュニケーションをより緊密に行っていくことはもちろんのこと、事業者側のプロジェクトマネジメ
ントの機能強化や、厚生労働省側における開発・運用保守を委託した立場として全体の進捗管理
や優先順位付けの見直し等を行うための体制・機能強化を講じていくことが必要である。

私的には、ここが最大の重大過失と思っています。体制的な問題と状況を加味しても一概「思い込み」で
済まされる問題ではなく、そもそも ISO9001 等に則っていない状態が良くない。
ゆえに、是正勧告レベルです。

現時点では、保守運用に移行しているので、

  • 運用体制(責任者、受託側も)を明確にすること
  • 瑕疵が発生した場合、どのようなフローで修正するのか(試験も込み)手順を明文化すること
  • 機能追加をするときに、有識者会議も含めて、手順を明文化すること

現在の運用体制の場合、「全体の進捗管理」が不明確でロードマップがありません。この部分がかなり問題です。
プロジェクト計画書とスケジュールが必須です。
とはいえ、重たい改修プロセスを踏んでも現状では重たいだけなので、せめてロードマップと修正するときの
優先度の明確化が必要ですね。

@rocaz
Copy link
Member

rocaz commented Apr 22, 2021

自明かも知れませんが、総務省から政府調達に関してこういう基本指針は出てますね。まあいつもやってられないと言えばそうかもですが。
分離調達原則とは…。

情報システムに係る政府調達の基本指針

「情報システムに係る政府調達の基本指針」実務手引書

@rocaz
Copy link
Member

rocaz commented Apr 22, 2021

@rocaz
Copy link
Member

rocaz commented Apr 22, 2021

@moonmile
Copy link
Member Author

@rocaz
Copy link
Member

rocaz commented Apr 22, 2021

独自にIT戦略室が策定したみたいですけど、前期末付けですね

アジャイル開発実践ガイドブック

@moonmile
Copy link
Member Author

moonmile commented Apr 22, 2021

そのガイドブック、知っている人が関与しているので、IPA の方を知らない訳はないハズですが。何故ダブって作ってたのかは不明です。監修しただけなのかもしれませんが。

@moonmile
Copy link
Member Author

政府CIOポータルでの標準ガイドライン集

https://cio.go.jp/guides

すでに調達関係はどれがメインなのか分からなくなってる…。
多分この辺。

デジタル・ガバメント推進標準ガイドライン解説書(第3編第6章 調達)
デジタル・ガバメント推進標準ガイドライン実践ガイドブック(第3編第6章 調達)

設計・開発・テストはこれ

デジタル・ガバメント推進標準ガイドライン解説書(第3編第7章 設計・開発)

デジタル・ガバメント推進標準ガイドライン実践ガイドブック(第3編第7章 設計・開発)

COCOAの調達仕様書はほぼこれらに沿っていますね(焼き直しとも言う)

不覚にも標準ガイドライン解説書の存在を知りませんでした。ありがとうございます。
この手のガイドラインは、2000年の e-Japan の頃に追っていて「情報システムに係る政府調達の基本指針」あたりまでは知ってたのですが、そのあたりから改版?されて、「デジタル・ガバメント推進標準ガイドライン」なんでしょうね、多分。

ちなみに

COCOAの調達仕様書はほぼこれらに沿っていますね(焼き直しとも言う)

のところですが、調達仕様書(要件定義書)を見たときに、きちんと PMBOK の沿っていてえらいなぁと
いう感想を持ったので、これもデジタルガバメント標準に沿ったものでしょう。

PMBOK や ISO9001 で出てくる要件定義書も標準のテンプレートに沿って各項目を穴埋めしていく指針なので、
焼き直しというより、きちんとテンプレートに沿った形で書かれていて実は「良い」要件定義書だったりします。

@moonmile
Copy link
Member Author

moonmile commented Apr 23, 2021

(※)技術的助言等を受けたCIO 補佐官や外部のIT の専門家(順不同)
・ 政府CIO 補佐官 中井勘介 氏
・ 奈良先端科学技術大学院大学総合情報基盤センター 准教授 新井イスマイル 氏
・ 東京大学大学院工学系研究科 教授 川原圭博 氏
・ 名古屋大学大学院工学研究科 准教授 米澤拓郎 氏

中井勘介 氏
https://cio.go.jp/sites/default/files/uploads/documents/hosakan_ichiran_2021.pdf
新井イスマイル 氏
https://inet-lab.naist.jp/~ismail/index-j.html
川原圭博 氏
https://kawahara.akg.t.u-tokyo.ac.jp/home/profile_ja
米澤拓郎 氏
http://www.nuee.nagoya-u.ac.jp/communications/index.html

調査書に関わる CIO 補佐官としては、IT マネジメント(ISO9001, PMBOK等)に精通している人を
割り当てたほうが良かったのではないかと思うのですが、どうなのでしょうか。よくわからないです。
調査書自体が検証・監査の役割を占めているのか、原因調査に留めるのかによるんですが、
COCOA 開発の再発防止に関しては、内閣IT室に移管されたので、「デジタル・ガバメント標準に
則って保守なり改修なりを行う」という宣言で済んでしまうので。

@moonmile
Copy link
Member Author

そのガイドブック、知っている人が関与しているので、IPA の方を知らない訳はないハズですが。何故ダブって作ってたのかは不明です。監修しただけなのかもしれませんが。

名が入っていますね
https://cio.go.jp/sites/default/files/uploads/documents/hosakan_ichiran_2021.pdf
市谷聡啓 氏

@moonmile
Copy link
Member Author

標準ガイドライン群 | 政府CIOポータル

デジタル・ガバメント推進標準ガイドライン 説明会資料
https://cio.go.jp/sites/default/files/uploads/documents/hyoujun_guideline_setumei_PDF20190315.pdf

2019年3月に各府省、関連事業者向けに説明会をやっていました。当時、官庁系の受注をしていた会社ならば
既知の模様。変遷が書いてあります。

image

@moonmile
Copy link
Member Author

調査書の再発防止策に話を戻すと、

特に今回のCOCOA のような複雑な仕様のシステムについては、連携先のシステムやAPI 等の改
修・アップデートが別々の要因によって不定期に行われる可能性があり、事前の想定が難しい事態が
発生することをあらかじめ見込んだ上で、その都度、適時・適切な対策を講じる必要がある。

この部分が一番「再発防止策」的に不味い部分で、
「あらかじめ見込んだ上で、その都度、適時・適切な対策を講じる必要がある」とあるが、
どのような「適時・適切な対策」なのかが提示されていません。考えられなかったのかも
しれませんが、結構肝なところなので、案ぐらいは出さないと。

案としては、

  • アップデートが不定期に行われるため、継続的な契約を前提とする(保守契約)
  • アップデートが不定期に行われるため、アップデート単位で契約を継続する(単発の契約)
  • 「事前に想定の難しい」部分を明確にするため、想定できる範囲を定めておく(リスク管理要綱)
  • 「事前に想定の難しい」事象が発生した場合に、契約の破棄/修正を含めて条項を決めておく

というのはどうでしょう?
この部分、デジタルガバメント標準に沿うんでしょうが。

COCOA の EN API に関しては4,5月の時点で API 更新が明らかだったので、契約の変更/継続に
動いていなかった(動けなかった?)ことが問題だと思うのですが、その指摘があるかどうかは
確認していません。

@moonmile
Copy link
Member Author

moonmile commented Apr 23, 2021

このため、GitHub 等の外部からの指摘や、利用者からの声などを適時・適切に把握する13 ととも
に、その重要性や緊急性について、技術的対応の可能性等の専門的視点も含めて判断し、確実に
プロジェクトチーム内へのエスカレーションを行うことができる体制の整備が求められるとともに、いかな
る事態が発生した場合でも、緊急度や重要度、事業全体における優先順位等を俯瞰的に検討・
判断することができる人員を配置することが求められる。また、事業全体における優先順位は、その
時々の状況に応じて変化し得るものであり、優先順位の見直しが必要ではないかという視点を常に
持っておくことも重要である。

現状(見掛け上は)、2名の補佐官+技術関与1名で GitHub が対応されています。しかし、
「緊急度や重要度、事業全体における優先順位等を俯瞰的に検討・判断することができる人員」が
配置されているかどうかの問題が残ります。とりあえず「誰が優先度を決定しているのか」が
3名の合意制っぽい感じなのですが、意思決定プロセスが明文化されていません。

これ、内部資料的には意思決定プロセスなので「プロジェクト計画書」に記載されるはずなんですが、
そのあたりは内部資料なので非公開なのかもしれませんが、どうなのでしょう?
なお、意思決定プロセスの責任者としては既に上がっているの明確化されています。
それは以前はなかったので。

@b-wind
Copy link

b-wind commented Apr 24, 2021

2名の補佐官+技術関与1名で GitHub が対応されています

細かい事ですが、主たる対応は「2名のIT室所属政府CIO補佐官+厚生労働省の技術参与1名」ですね。

一応厚生労働省 GitHub リポジトリは「内閣官房情報通信技術(IT)総合戦略室」によって運用されていると明記されています。

https://github.com/cocoa-mhlw/cocoa/blob/v1.2.3/OPERATION_POLICY.md

とりあえず「誰が優先度を決定しているのか」

「開発チーム」の意向・方針 として示されるケースは有りますが、「開発チーム」のメンバーが明示されたことはありません。

(これらはすべての Issue/PR に目を通した状況での発言であり、私自身は利害関係者ではない事を明記しておきます)

@moonmile
Copy link
Member Author

2名の補佐官+技術関与1名で GitHub が対応されています

細かい事ですが、主たる対応は「2名のIT室所属政府CIO補佐官+厚生労働省の技術参与1名」ですね。

一応厚生労働省 GitHub リポジトリは「内閣官房情報通信技術(IT)総合戦略室」によって運用されていると明記されています。

https://github.com/cocoa-mhlw/cocoa/blob/v1.2.3/OPERATION_POLICY.md

YES. 私もその認識です。
有山さんは「厚生労働省の」なんですね。

@b-wind
Copy link

b-wind commented Apr 24, 2021

有山さんは「厚生労働省の」なんですね。

はい。ソースは当人の着任時のブログです。
https://blog.keiji.dev/2021/03/cocoa.html

@moonmile
Copy link
Member Author

意思決定プロセスについては、民間の場合は、

  • PMBOK におけるプロジェクト計画書に「コミュニケーション・マネジメント」として明記
  • ISO 9001 の場合は「7.4 コミュニケーション」として明記、大抵は議事録の記述と、定例会の開催日程を記述。
  • 内部統制(JSOX)により明文化と外部監査

があります。
デジタルガバメント標準にも「プロジェクト計画書」があるので、PMBOK のコミュニケーション・マネジメントと
似たものがあると思うのですが、まだ未チェック。

この「コミュニケーション・マネジメント」不足も大きな要因です。
なので、これも具体的な再発防止策の立案が必須になるところです。

@moonmile
Copy link
Member Author

PMBOK についは、正式なのはあの高い教科書を買わないと駄目なんですが、さらっと知識エリアだけ知っておくと便利です。
内部統制は会社法/上場企業が対象になります。

内部統制がデジタルガバメント標準の対象範囲になるかどうかは官庁なので会社法の外にあるのですが、情報統制という形では民間の内部統制に対応するものはあると思います。これも未確認。

参考まで、

@moonmile
Copy link
Member Author

moonmile commented Apr 24, 2021

cocoa 自身のコミュニケーションマネジメントとしては、以下のように定例は10月までに週1回、10月以降に週2回となっています。

image

ですが、その前のヒアリングとの齟齬があります。

image

image

このあたりは議事録を見ればわかるでしょう。
ちなみに調査書に「議事録」という文言はでてきません。

まあ、齟齬があってもいいんですが、議事録は残っているのかなぁ。

@b-wind
Copy link

b-wind commented Apr 24, 2021

そう言えば、

「緊急度や重要度、事業全体における優先順位等を俯瞰的に検討・判断することができる人員」が配置されているかどうかの問題が残ります。

の部分ですが、基本的に優先順位の高い物を GitHub コミュニティー側で扱うことは無さそうです。
その辺りの発言はこちらを参照。
cocoa-mhlw/cocoa#102 (comment)

GitHub コミュニティー側で発案・実装された物の中から開発チームが取り込む価値があると判断した物だけCOCOAに取り込まれる…… 様には見えます。

「開発チーム」もしくはIT室でそのような人員を配置しているかは不明です。

@moonmile
Copy link
Member Author

意思決定プロセスが明確になっていないのは、そのままなのですが、プロジェクトボードは作った模様です。

Projects · cocoa-mhlw/cocoa

@b-wind
Copy link

b-wind commented Apr 25, 2021

そのプロジェクトボード、基本的に開発チームがリリースに組み込む予定の物が記載されるだけなんです。

@moonmile
Copy link
Member Author

なるほど。そうなると、ロードマップがない状態なんですね。

ちなみにデジタルガバメント標準では、PJMOがWBSを書くことになています。

image

工程管理については、「PMOや府省CIO補佐官等の支援や助言」と書いてあるので、PJMOって補佐官とは違うみたいです。
COCOA の場合 PJMO って誰なんだろう?

image

@moonmile
Copy link
Member Author

moonmile commented Apr 25, 2021

デジタル・ガバメントへの取組 : 財務省

ここから類推すると、

  • 厚生労働省全体管理組織(PMO)
  • プロジェクト推進組織(PJMO)

となるので、COCOA の PJMO は厚生労働省内の COCOA 開発チームのままで、委託先含めて WBS を作成することになりそうです。PJMO は組織(チーム全体)を示すので、責任者名が明確になっていないような気も。

PMOは厚生労働省そのものなので、厚生労働大臣が責任者と思われます。

@moonmile
Copy link
Member Author

深刻な問題があるプロジェクトについては、「プロジェクトの検証」の対象となります。
ここにある「プロジェクトの検証」が、今回の「接触確認アプリ「COCOA」の不具合の発生経緯の調査と再発防止の検討について」にあたると考えられる。

image

何故、ぽつんと WEB で発表されていたのかと言えば、「3.検証結果の公表」に「検証結果を各府省のWebサイトに公表する」と定めているからでしょう。各府省となっているので、この場合は厚生労働省のサイト内になる。

@moonmile
Copy link
Member Author

改善処置(ISO9001でいう是正処置)は、3.2.4.3 プロジェクトモニタリング及び停止・改善となる。

image

COCOA の場合、b) プロジェクトの抜本改善が必要な状況 と考えられるので「「プロジェクト検証委員会」が定期的にモニタリングの結果を把握する」ことになっています。

「モニタリング」自体は、3.2.2.1 にあります。

image

モニタリングの項目は

  • 工程管理
  • 指標管理
  • 品質管理

になりますね。

@moonmile
Copy link
Member Author

まあ、COCOA 開発が「深刻な問題があるプロジェクト」にあたるかどうかが争点になるわけですが、これは「接触確認アプリ「COCOA」の不具合の発生経緯の調査と再発防止の検討について」には明記されていません。

名称が「COCOA 不具合調査・再発防止策検討チーム」となっているので、デジタル・ガバメント標準の「検証」あたらないのかもしれないし。

@b-wind
Copy link

b-wind commented Apr 26, 2021

COCOA の「目標設定」自体が曖昧な気がしますが、どこかに記述されていたりするのでしょうか。

@moonmile
Copy link
Member Author

目的は結構明確で

接触確認アプリに関する仕様書等の公表 | 政府CIOポータル

「接触確認アプリ及び関連システム仕様書」の「1.目的」

image

「~その陽性者と一定期間内に接触が確認された者に対し通知を行う。」のが最優先かつ、
これが唯一の目的なのです。

@b-wind
Copy link

b-wind commented Apr 28, 2021

なるほど。目標自体は確かに明確ですね。
問題はモニタリングの方でしょうか。目標を達成できた件数とかわりと不明ですし。

@moonmile
Copy link
Member Author

確か、有識者会議で COCOA の目標ダウンロード数を試算していたと思います。それに伴って、システム仕様書の処理最大数が決められています。

おそらく、厚生労働省が発表しているダウンロード数 接触確認アプリ「COCOA」のダウンロード数が2,000万件に到達しました|厚生労働省 は、広報の意味もあるでしょうが、そのあたりに基づいているのかなと。

モニタリングに関しては、首相が「把握できていない」と言っているので、把握できていないのでしょう。

菅首相、「COCOA」による陽性判明数は「把握できていない」 登録陽性者も全体の2.6%に過ぎず: J-CAST ニュース【全文表示】

本来は有識者会議が定期でモニタリングするはずなのですが、有識者会議自体が去年の夏で止まっていますからね。。。

@b-wind
Copy link

b-wind commented Apr 30, 2021

ダウンロード数やCOCOAからの陽性登録数などは間違いなく指標の一部ですが、それだけでは何とも言い難いですね。

@moonmile
Copy link
Member Author

もともと、科学的根拠をもった政策立案と実施後の検証プロセスが日本の場合弱いので、「現在の COCOA が当初の目的を達成っしているかどうか?」の検証自体もできないのかな、と思っています。

エビデンスに基づく政策立案 - 科学技術政策 - 内閣府

感染対策も EBPM のひとつだとは思うのですが。
多分、内部的には「COCOA をリリースした」ことによって、一応の成功を収めているという形なんじゃないかなと思います。活用されているかどうかは別という感じ。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants