HP Directplus -HP公式オンラインストア-
ウイルスバスター公式トレンドマイクロ・オンラインショップ
毎日の生活に役立つ!面白い!『こんな便利な商品があったのか!!』特集
本ページはプロモーションが含まれています。
  
 

コロナウィルス接触確認アプリ COCOAの不具合放置問題報告書を斬る

 

スポンサーリンク

 
コロナウィルス接触確認アプリ COCOAの不具合放置問題報告書を斬る

数か月前に日本中を震撼させ、政府への信頼を失墜させたあのダメアプリの原因調査報告が公開された。COCOAというコロナウィルス患者との接触確認アプリの不具合の件だ。
ネット環境が提供するサービスについてのまとめはこちら。

  

COCOA不具合問題の概要

あきれる
開いた口が塞がらない

この問題ほどこれらの言葉が似合うものはない。1年以上も日本中がコロナウィルスで大騒ぎになっている中で期待を背負ってリリースされたアプリだ。多額の税金が投入されている。
なのに。なぜこういう問題が起きるのか???
問題の内容は以前書いたので、覚えていない方は参照を。

問題発覚から2ヶ月経って調査報告が公開された。

概要と書かれている報告書を見て、思ったことを書く。

COCOA不具合報告

COCOA不具合報告

出典:厚労省 報告書(上記リンク先参照)

結合テスト未実施

結合テストとは使う会社、プロジェクトで定義が異なると思うが、単体テストと総合テスト・システムテストの中間のテストだ。総合テスト・システムテストはユーザの視点でテストを行う。マニュアルがあればそれを見ながら開発者ではないエンジニア(QAと呼ばれる)がテストを実施する。開発者とは違って思い込みが少ないし、弱点を考慮した回避もしないので潜在的なバグをたたき出すことができる。
単体テストはその真逆で、エンジニアが作ったプログラムの機能が果たせているかの確認を行う。例えば100以上になったらエラーを返す、というようなプログラムのパーツの仕様が満たせているかの確認をエンジニアの手で行う。
結合テストはその中間で、自分の定義では単体テストを終えたパーツを組み合わせてある程度のまとまった機能(プログラム、プロセス、アプリ)でエンジニアがテストを行う。当然そのテストは作ったエンジニアが絡むので思い込みや弱点の回避をしてしまいがちだが、正常なルートのチェックと思いつく異常ルートの確認をすることができる。

テストは通常こういう階層的、代表例では3階層で順番に単体、結合、総合テストを行って、ユーザにわたる。総合テストで発見されたバグは究明されて場合によってはプログラムの大幅な作り直しになる。その場合は単体テストからやり直しだ。つまり総合テストのように後工程になるほど、発見されたバグによるが対策する時間がかかる。昨今のソフトウェア開発では前工程をしっかりすることが重視され、もう何年も前から単体テストの自動化を進めている。
単体テストを無人で行うことができれば、バグによりプログラムを少々変更したとしても影響範囲を極小化することができ、コストを最小限に抑えて修正が可能になる。これにより大胆なプログラムの修正が可能になった。(20世紀の頃は全て人手でやっていた)

前置きが長くなったが、報告書ではその結合テストがバージョン1.1.4のリリース時点では実施しなかったという。ここでいう結合テストはおそらく上記の結合テストと総合テストを兼ねているのではないだろうか。つまり単体テストを実施しただけでアプリをリリースしたという事だろう。
なぜそうなったか?言い訳がいろいろ書かれているが、「テスト環境がなかったから」テストできなかったという。

まあ、それはそうだわな。環境がなければテストはできない。

じゃあ、テストしないアプリにバグがないと厚労省もベンダも胸を張って言えたのだろうか。その後もテストが必要ないと思うなんて、君らはエスパーか。
今どきテストをしなければまともに使えるソフトウェアがないことは、よく知られていると考えている。もしかしたら、頑張れば完璧なソフトウェアを作れると厚労省の担当者は考えていたのだろうか。

その下にも言い訳がいっぱい書かれているので引用する。

一連の流れに係るテストを行わずにリリースするリスクを、厚生労働省も CIO補佐官や事業者と同程度に認識していれば、テスト環境が整備された後に事後的に当該テストを行うことが優先的な課題として位置付けられた可能性もあった。

んー人の命がかかわる事態に緊急で作られたアプリなんだよね?他人事なのかな、厚労省は。
可能性があった、って。必須じゃねえの。誰がリリースしてよいって判断したんだろ。大臣じゃないの?品質責任者はいったい誰なのさ。

結果として、一連の流れに係るテストの実施を優先的課題として位置づけることが、明示的に検討されることもなかった。関係者間でテスト環境の整備の目的自体が認識共有されていなかった点も問題であった。

厚労省はIT音痴しかいないって宣言なのかな。あるいはプロジェクト管理ができない宣言なのかな。そうであれば厚労省は今後一切アプリやマイナポイントなどは手を出さないで、そろばんと紙ですべて作業しますって宣言したほうがいいのではないか。

致命的なのは下記ではないか。

事業者側の問題点として、各作業項目に係る最終的な品質管理の実施主体について厚生労働省と具体的かつ明確な認識共有が図れていなかったこと、関係者間の打ち合わせは頻度として相当数行われていたが、丁寧なコミュニケーションが行われていたとは必ずしもいえないこと、テスト環境の整備後において標準的なテストケース等の検討・提案などが行われなかったこと等が挙げられる。

ソフトウェアの開発をしているというのに、これはお粗末だ。命に係わるソフトウェアはいろいろあるがここまで手を抜いた開発は聞いたことがない。ソフトウェア開発を舐めているのか、あるいは仕事をする能力がないのか。
その両方だろうか。厚労省もベンダも相応の処罰があってしかるべきだ。

更にお粗末な話が続く。

昨年 9 月頃に厚生労働省は GitHub の Issue についての管理を追加で依頼したが、事業者側は、誰がいつどのように行うか具体的な業務フローがあいまいであった。その原因は、明確な役割分担が行われなかったこと、事業者間の丁寧なコミュニケーションが不足しており、各々が「他がやっているだろう」という思い込みを持っていたこと等が考えられる。

ソフトウェア開発ではよく聞く話だ。他がやってくれている(だろう)、他にお願いした(つもりだ)
皆が同じように思っていて、くっつけたときから修羅場が始まる。

お粗末すぎる開発体制

これ以上読んでも得られるものは何もないし、教訓とすべき高尚な物語も見当たらない。

当たり前のことをやらず、なるべくしてなった

一言で言えばそういう事だ。

発注側は丸投げ。
受注側は右往左往する中で言われたことしかやらない。

国難といえる疫病の対策ソフトウェアであり相応の税金が投入されているのに、厚労省の役人は3月末に送別会を開催して感染者を出すような意識の低さ。受注側はわずかな金額だけ返金するといった中途半端な対応。全額返したほうがいいのじゃないの?

このアプリを信じていたのに感染した人、もしかしたらこのアプリが正しく動いていれば亡くならずに済んだ人。いろんな人の想いをどこまで理解しているのだろうか。役人もベンダもあまりにもお粗末であり、これが日本の現状と思うと泣けてくる。

どこまでも他人事、と考えているように透けて見える役人とベンダに未来はないだろう。ほかの役所やベンダはそうではないと信じたい。

(Visited 133 times, 1 visits today)

PR

   
著者プロフィール
irvine
 ソフトウェア設計、ストレージ設計を経てクラウドにかかわる仕事をしている、東京郊外在住のエンジニア。
 仕事でUS,UK,SGなどの国とかかわる。
 自作PC、スマホ、タブレット、AV機器好き。ドラクエウォークはルーチンワーク。Linuxやストレージ、IT業界の動向は興味を持っている。
 新しい機器、サービスに興味あり。年数回のレビュー(自腹購入、ご依頼)と発表されて興味があるものの新製品机上レビューをやっている。
 2022年はJAPANNEXT様のアンバサダーを務めました。
 

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です