-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
資料として、品質マネジメントシステムの方。 |
改めて「5.再発防止策」を見ていると、何もできていないので PMBOK の手順をきちんと入れてください、としか言いようがなくなるので、具体的に示しておこう。
「品質管理を徹底」とあるので、品質管理システムのリリース手順に則るとよい。
出荷テストをするは受託側で試験項目と結果を提出、受け入れ検査(この場合は厚生労働省あるいは国?)は立ち合いで、 「テスト環境において一連の動作検証」というのは、出荷検査の前の通常の試験(運用試験とか結合試験とか)を
が、文書として残る。一般的に試験仕様書兼結果書が納品物件に含まれるので、これを国あるいは厚生労働省がチェック。 |
COCOA の場合は状況が特殊なので、結合試験等のテスト環境を国あるいは厚生労働省が用意すべきだったか 試験の実施については、受託開発の場合は納品時に試験項目と結果書の文書を求めればよいので、それを 「標準的なテストケース」については、受託側が責任を以って行うという契約なので、国あるいは厚生労働省側で 「これらの点について仕様書に具体的に記載しておくことも重要」の部分は、受入れ試験時の項目となる。 |
私的には、ここが最大の重大過失と思っています。体制的な問題と状況を加味しても一概「思い込み」で 現時点では、保守運用に移行しているので、
現在の運用体制の場合、「全体の進捗管理」が不明確でロードマップがありません。この部分がかなり問題です。 |
自明かも知れませんが、総務省から政府調達に関してこういう基本指針は出てますね。まあいつもやってられないと言えばそうかもですが。 |
おっと、上記は廃止されてました 政府情報システムの整備及び管理に関する標準ガイドライン 事業者向け説明会資料 現行はこちらみたいですね |
政府CIOポータルでの標準ガイドライン集 すでに調達関係はどれがメインなのか分からなくなってる…。 デジタル・ガバメント推進標準ガイドライン解説書(第3編第6章 調達) 設計・開発・テストはこれ デジタル・ガバメント推進標準ガイドライン解説書(第3編第7章 設計・開発) デジタル・ガバメント推進標準ガイドライン実践ガイドブック(第3編第7章 設計・開発) COCOAの調達仕様書はほぼこれらに沿っていますね(焼き直しとも言う) |
アジャイル開発版「情報システム・モデル取引・契約書」 アジャイル開発なんだから、IPA のこれに準拠して欲しかったですよねぇ、と。 |
独自にIT戦略室が策定したみたいですけど、前期末付けですね |
そのガイドブック、知っている人が関与しているので、IPA の方を知らない訳はないハズですが。何故ダブって作ってたのかは不明です。監修しただけなのかもしれませんが。 |
不覚にも標準ガイドライン解説書の存在を知りませんでした。ありがとうございます。 ちなみに
のところですが、調達仕様書(要件定義書)を見たときに、きちんと PMBOK の沿っていてえらいなぁと PMBOK や ISO9001 で出てくる要件定義書も標準のテンプレートに沿って各項目を穴埋めしていく指針なので、 |
中井勘介 氏 調査書に関わる CIO 補佐官としては、IT マネジメント(ISO9001, PMBOK等)に精通している人を |
名が入っていますね |
デジタル・ガバメント推進標準ガイドライン 説明会資料 2019年3月に各府省、関連事業者向けに説明会をやっていました。当時、官庁系の受注をしていた会社ならば |
調査書の再発防止策に話を戻すと、
この部分が一番「再発防止策」的に不味い部分で、 案としては、
というのはどうでしょう? COCOA の EN API に関しては4,5月の時点で API 更新が明らかだったので、契約の変更/継続に |
現状(見掛け上は)、2名の補佐官+技術関与1名で GitHub が対応されています。しかし、 これ、内部資料的には意思決定プロセスなので「プロジェクト計画書」に記載されるはずなんですが、 |
細かい事ですが、主たる対応は「2名のIT室所属政府CIO補佐官+厚生労働省の技術参与1名」ですね。 一応厚生労働省 GitHub リポジトリは「内閣官房情報通信技術(IT)総合戦略室」によって運用されていると明記されています。 https://github.com/cocoa-mhlw/cocoa/blob/v1.2.3/OPERATION_POLICY.md
「開発チーム」の意向・方針 として示されるケースは有りますが、「開発チーム」のメンバーが明示されたことはありません。 (これらはすべての Issue/PR に目を通した状況での発言であり、私自身は利害関係者ではない事を明記しておきます) |
YES. 私もその認識です。 |
はい。ソースは当人の着任時のブログです。 |
意思決定プロセスについては、民間の場合は、
があります。 この「コミュニケーション・マネジメント」不足も大きな要因です。 |
PMBOK についは、正式なのはあの高い教科書を買わないと駄目なんですが、さらっと知識エリアだけ知っておくと便利です。 内部統制がデジタルガバメント標準の対象範囲になるかどうかは官庁なので会社法の外にあるのですが、情報統制という形では民間の内部統制に対応するものはあると思います。これも未確認。 参考まで、 |
そう言えば、
の部分ですが、基本的に優先順位の高い物を GitHub コミュニティー側で扱うことは無さそうです。 GitHub コミュニティー側で発案・実装された物の中から開発チームが取り込む価値があると判断した物だけCOCOAに取り込まれる…… 様には見えます。 「開発チーム」もしくはIT室でそのような人員を配置しているかは不明です。 |
意思決定プロセスが明確になっていないのは、そのままなのですが、プロジェクトボードは作った模様です。 |
そのプロジェクトボード、基本的に開発チームがリリースに組み込む予定の物が記載されるだけなんです。 |
ここから類推すると、
となるので、COCOA の PJMO は厚生労働省内の COCOA 開発チームのままで、委託先含めて WBS を作成することになりそうです。PJMO は組織(チーム全体)を示すので、責任者名が明確になっていないような気も。 PMOは厚生労働省そのものなので、厚生労働大臣が責任者と思われます。 |
まあ、COCOA 開発が「深刻な問題があるプロジェクト」にあたるかどうかが争点になるわけですが、これは「接触確認アプリ「COCOA」の不具合の発生経緯の調査と再発防止の検討について」には明記されていません。 名称が「COCOA 不具合調査・再発防止策検討チーム」となっているので、デジタル・ガバメント標準の「検証」あたらないのかもしれないし。 |
COCOA の「目標設定」自体が曖昧な気がしますが、どこかに記述されていたりするのでしょうか。 |
目的は結構明確で 接触確認アプリに関する仕様書等の公表 | 政府CIOポータル 「接触確認アプリ及び関連システム仕様書」の「1.目的」 「~その陽性者と一定期間内に接触が確認された者に対し通知を行う。」のが最優先かつ、 |
なるほど。目標自体は確かに明確ですね。 |
確か、有識者会議で COCOA の目標ダウンロード数を試算していたと思います。それに伴って、システム仕様書の処理最大数が決められています。 おそらく、厚生労働省が発表しているダウンロード数 接触確認アプリ「COCOA」のダウンロード数が2,000万件に到達しました|厚生労働省 は、広報の意味もあるでしょうが、そのあたりに基づいているのかなと。 モニタリングに関しては、首相が「把握できていない」と言っているので、把握できていないのでしょう。 菅首相、「COCOA」による陽性判明数は「把握できていない」 登録陽性者も全体の2.6%に過ぎず: J-CAST ニュース【全文表示】 本来は有識者会議が定期でモニタリングするはずなのですが、有識者会議自体が去年の夏で止まっていますからね。。。 |
ダウンロード数やCOCOAからの陽性登録数などは間違いなく指標の一部ですが、それだけでは何とも言い難いですね。 |
もともと、科学的根拠をもった政策立案と実施後の検証プロセスが日本の場合弱いので、「現在の COCOA が当初の目的を達成っしているかどうか?」の検証自体もできないのかな、と思っています。 感染対策も EBPM のひとつだとは思うのですが。 |
COCOA不具合調査・再発防止策検討チーム|厚生労働省
報道やツイッターの感想もいくつか出揃った感があるので、検討した後をどうするのか?を考えていきたいと思います。
概要の最初にある通り、目的が「再発防止策」を立てることなので、ここから実行しないと意味がありません。
で、そもそも
等、疑問な点がいくつかあります。
特に、官庁系のITシステムには、ISO9001レベル(品質管理システム)が要求されるため、ある程度の管理文書や開発プロセスが決められています。その部分に対して、
の観点から再検討したいと考えています。以下、自由な議論の場として issue を置いておきます。議論が発散するようであれば、別途 issue を立ててしまって構いません。
The text was updated successfully, but these errors were encountered: