列車ダイヤについて -- ３−３１ 「ＣＯＣＯＡ」の不具合について
２０２１年３月１０日
３−３１ ＣＯＣＯＡの不具合について
新型コロナウイルス接触確認アプリ「ＣＯＣＯＡ」に不具合がありましたが、２月に修正版がリリースされました。
ＩＴの分野では、どんどん新しい技術が開発されるので、日本が得意だった、改善活動や失敗に学ぶの考え方は、通用しない。
プロアクティブに対応する、「将来を適切に予測し、必要にせまられる前に行動をとること」が重要であると言われることがあります。
プロアクティブに対応することは、重要です。しかし、実際に、将来を適切に予測することはそれほど簡単ではありません。
少なくとも、過去の失敗に学ばなけらばならないのではないかというのが、今回のコラムです。
修正版をリリースするのは当たり前ですが、それで対策完了ではないということです。
２０１７年１２月、新幹線の台車に亀裂がはいるというトラブルがありました。
アプリの修正版をリリースするというのは、台車に亀裂がはいるというトラブルに例えるなら、
亀裂がはいった台車を取り除いて、正常な台車に取り替えたというようなものです。
トラブルを起こした台車は、製造過程に問題があったので、今後問題を起こさないようにすれば良いというのでは、
過去の失敗から何も学んでいないと言えます。
新幹線の台車は、１２０万キロ走行すると、念入りな検査を行って、まったく亀裂がないことを確認していました。
鉄道を構成する部品には高い信頼性が要求されます。しかし、まったく故障しない部品は実際には存在しません。
そこで、モーターのように、一台故障しても、正常に走行でき、車庫に戻ってきてから、修理する。
あるいは、信号のように、故障したら、停止「赤」を表示する。停止すべき時に、進行「緑」を表示することは
限りなくゼロというものもあります。台車の場合、一台故障しても、重大なインシデントになります。
そこで、金属製の部品には、金属疲労などにより亀裂が発生するが、１２０万キロ走行ごとに、まったく亀裂が
無い状態であることを確認しておけば、次の１２０万キロ走行の間に、亀裂ができても、インシデントにつながるほどの
大きさになることは無いという前提でした。
トラブルを起こした台車の場合、一応正常に走行できる状態から、台車が破壊して事故に直結する状態まで、
２−３日のうちに亀裂が拡大しました。長い間の前提を覆すようなインシデントでした。
同種のトラブルの再発を防止するため、走行中に、台車をはじめ車両の各種の状況を継続的にモニターして、
運行指令所にも通報するという対策が、新幹線に限らず、鉄道全体で広く取り入れられるようになりました。
鉄道のように長い歴史があるものでも、部品の亀裂が急速に拡大することがあるということは、トラブルがあるまで
予測できなかったのです。
飛行機でも、着陸の時に車輪が出なくなるとか、飛行中に燃料が無くなるなど、まったく予期していなかったトラブル
が起きたことがあります。
少なくとも、過去の失敗から学ぶという観点で見た時、「ＣＯＣＯＡ」の不具合から、
次の２つの点は学ぶ必要があると思います。
１つ目は、なぜ４ヶ月間トラブルに気づかなかったということです。
以前、Ｇｏｏｇｌｅ Ｍａｐのアプリが劣化した時、２４時間以内に話題になりました。
「ＣＯＣＯＡ」の場合、利用者本人が直接気付くことはまれです。家族が感染したのに通知がこない、「おかしいな」
と思った人はいたそうです。しかし、積極的疫学調査で濃厚接触者を見つけることを各地で熱心に行っていたのに、
その際に、「ＣＯＣＯＡ」から通知があったかどうかなぜ聞き取りをしなかったのでしょうか。
行政機関のなかで縦割りの弊害があったのかもしれません。
「ＣＯＣＯＡ」の有効性の確認をどのように行うつもりだったのでしょうか。
「ＣＯＣＯＡ」の開発には、４億円位かかったそうですが、投資対効果を把握するつもりが初めからなかったとしたら、
大きな問題です。
特別定額給付金の給付の際にトラブルが発生したので、マイナンバーと個人の口座番号を紐付けるというのも、
間違えた対応です。 まず、特別定額給付金の給付の処理のうち、振込口座の確認が出来なかったものの、割合を公表すべきです。
それから、マイナンバーカードを持っていない人で、自分のマイナンバーは正確に記憶しているという人はほとんど居ないと思います。
２０１８年８月の時点で、すでに株や投資信託などを行うために証券会社と取引する場合には、マイナンバーが必要となっており、
銀行の、普通口座に関してはマイナンバーの提出は義務ではありませんでしたが、銀行口座を新たに開設する際には必ずマイナンバーの提出をお願いされる
状況でした。 これらの施策により、どこの省庁がマイナンバーにかかわる情報を収集し、
その情報は、何に利用していたのか、特別定額給付金の給付に際し利用したのか
利用しなかったのかをまず公開し、話題になっているマイナンバーと個人の口座番号を紐付けでどの部分がどのように
改善されるかを公開すべきです。利用者に対して、行政システムは何をおこない、どのような利便を提供し、
投資対効果は、どのようなパラメーターで測定しどのように公表するのか、明らかにするのが、第一歩です。
２つ目は、厚生労働省から、開発業務を随意契約で受託した会社は、契約金額の９４％で事業を再委託していたそうです。
１９９０年代にも、国税総合管理システムの開発で、それまで国税庁の事務器具を受注していた、ほとんどＩＴ分野と関係ない、
会社が開発業務を受託し、事業の大半を再委託していました。プロジェクトの管理能力が著しく不足しており、
開発費がどんどん膨らみ、５，０００億円投資した時点でも完成の目処を立てることができず、大問題になりました。
「ＣＯＣＯＡ」は、４億円だから、まあ良かったと思う人はほとんどいないでしょう。
３０年経ってもなにも学んでいないのはあきれるばかりです。
ＩＴ分野と関係ない、会社が開発業務を受託し、事業の大半を再委託することで、お金の流れがわかりにくくなるという問題があります。
もっと大きな問題が、システムの機能仕様書などの決定にあって、行政の業務の内容も、システムに関する技術的知識もない人が
間にはいることで、プロジェクトを俯瞰的に見て管理出来る人が誰もいなくなり、
関係者が誰も納得していないような機能仕様書が出来上がることです。
厚生労働省のＨＥＲＳＹＳのシステムへの保健所での情報入力に抜けがありました。
もし、感染した本人が、自分のデーターを確認できる仕様になっていれば、もっと早く問題に気づいたと思います。
一般的に「個人情報の保護が重要だ」というと、システムのデーターを閲覧できる人を制限しよういうことになります。
しかし、自分のデーターが正しいかどうかを確認する能力は、他の多くの手段に勝ることが多いです。
名前に使われる特殊な漢字も、本人は間違えません。
１０年程前に大問題になった、消えた年金問題も、発端は、社会保険庁が電子計算機を導入するにあたり、
データーの入力を外注した時の、入力ミスが原因のものが多くありました。
データーの入力を外注した際の、処理のミスや、データーの漏洩は繰り返し起きています。
過去の失敗に学ばなければならない、典型的な問題です。どのようなコーディングをするか以前に、
はんこの廃止に続いて、紙の書類を受け取ってシステムに入力するのも例外処理として、
基本は、本人が入力して、処理状況もオンラインで確認するなど、行政手続きそのものの見直しも行わなければなりません。
２０２１年２月１３日に福島県沖で地震が起きました。
茨城県に住んでいるので、ものすごく揺れました。揺れは長いこと続きました。
翌朝になって、家屋の倒壊などの被害がほとんどないので、ある意味驚きました。
震源が深くて、地震の周期が短かったと聞いて、ある程度納得できました。
阪神淡路大震災のような、１秒～２秒周期の地震動はキラーパルスと呼ばれ、中層階のビルや家屋は特にこの周期の揺れに弱いです。
それより短い周期の場合、低層のがっちり造られた、鉄道や、空港の建物などには被害がでます。
東日本大震災の際も、茨城空港や、鹿島サッカースタジアムは、人が居なかったので人的被害がでなかったものの、
大きな被害がでました。最初、東北新幹線が、翌日にも運転を開始すると言ったのには驚きました。
すぐに、復旧までに、１０日程かかるというニュースを聞いて、なるほどと思いました。
９００箇所以上の被害ヶ所があるというニュースを聞いたので、２０２１年２月２４日には、全線で運転を再開したのにも、
驚きました。新幹線の地震対策は、何度も話題になっていますが、地震の周期が異なるだけで、
予期せぬことがいくつも起きます。それでも、過去の失敗に学んで、災害復旧に関しては、工事発注に際しての
入札などの手続きを大幅に加速化して、とにかく運転を再開することに集中するという手続きが確立しています。
「ＣＯＣＯＡ」の不具合の場合、２月の初めに、不具合が広く認知されてから、修正版がリリース（２月１８日）されるまで、
２０日近くかかっています。
そもそも、なくてはならない物だという認識が、広まっていないということが原因だと思います。
まず、行政のデジタル化は、試しにやってみると話題になるものではなくて、
当然に毎日利用できなければならないものだという認識を広めることが重要だと思います。
行政システムの開発において、難しいことのひとつが、どの範囲をひとつのシステムにするかということです。
縦割りも横割りも良くないが、すべてをひとつの袋に詰め込んで丸く収まる状況でもないということです。
新型コロナワクチン接種を管理するシステムを考えてみます。
一つの自治体のワクチン接種の通知と予約だけを管理するシステムを作れば、比較的簡単で、不具合の発生は最小にできそうです。
しかし、接種を受ける人が引っ越しする場合などを考えると、全国的なシステムにしたほうが良さそうです。
それでも、ワクチンの輸入のスケジュールがわからないと、接種予定が根底から変わってしまうおそれがあります。
接種後の副反応や、接種を受ける人の生活習慣病の内容さらには、接種を担う医療関係者の、シフトの管理や人件費の管理
なども含めて、総合的に管理するするシステムを作ったほうが、業務がスムーズに進むかもしれません。
しかし、関係する人が多すぎて、機能仕様書を決めることが出来ないとか、稼働後の不具合の発生につながるおそれがあります。
会計システムの開発でも、類似の問題があります。
航空会社を例に考えてみます。航空機の整備を管理する、「基幹系情報システム」（ＥＲＰ）で評判の良い日本の会社があります。
部品の信頼性、故障発生率や、交換にかかる時間、人件費、運行の障害になるインシデントの発生確率と会計情報を
総合的に管理するシステムで、管理会計の分野の有用な情報も得られます。
運行管理システムや座席予約システムも取り入れて、どの機体をいつ使うかというデーターと整備を管理するシステムも
連携させたほうが良い場合があります。しかし、座席予約システムは、コードシェアなどの関係で、
他の会社のシステムと連携させる必要があります。
世界中のあらゆるものをひとつのデーターベースにいれてしまうというのは現実的ではありません。
財務会計のことだけを考えるなら、社内にＥＲＰを導入するより、クラウド会計システムを契約して利用するほうが
業務をスムーズに行うことができる場合があります。
しかし、クラウド会計システムに、航空機の整備に関わる情報や、すべての管理会計の情報と業務にかかわる情報を
記録するというのは現実的ではありません。
２０００年頃、連結財務諸表の作成が始まったころ、日本でＥＲＰの導入も広まったので、
複数の総勘定元帳を持つことができる、（マルチプルレッジャーをサポートする）と言って、
ＥＲＰを導入すると、連結財務諸表がすぐに作成できるといわれたことがありますが、
ＥＲＰが得意なのは、社内の業務情報と会計情報をひとつのデーターベースに記録して分析することで、
複数の会社の会計情報をひとつのデーターベースに記録して管理することではありません。
このような話になると、各種の業務と複数の会社をマトリックス的に描いて、すべての管理を容易に
行うことが出来るという人がいますが、実際、けっして容易に行うことはできません。
日本で導入実績が多い、連結会計専用のシステムがあります。連結財務諸表を作成するなら、
このようなシステムを導入したほうが良いと思います。
ひとつのクラウドデーターベースで世界中に分散したデーターを管理できるようになりました。
それは、論理的にひとつのデーターベースのなかのデーターの話です。
複数のデーターベースのなかのデーターを、それほど厳格に管理できるわけではありません。
あらゆるデーターをひとつのデーターベースに収納しようとすると、
テーブルの名前が重複するのを避けるためのカストマイズが膨大になる、
逆に、複数のデーターベースのなかのデーターを、連携してして処理しようとすると、
データーの更新などについて、厳格なデーター完全性を確保するのは容易ではありません。
銀行の預金は、自分が口座を持っている銀行のシステムのデーターベースに記録されています。
それでは、他の銀行に振込をおこなって、なぜ口座残高に矛盾が起きるなどの問題が起きないかというと、
各銀行が、全銀協標準通信プロトコル（全銀手順）で接続されているからです。
現金の残高を管理するだけで、あれほどの規模のシステムが必要になります。
行政システムにおいても、ひとつの自治体のなかの、住民基本台帳の情報、社会保障関連の情報を関連させることが
必要になる場面と、複数の自治体間の、社会保障関連の情報を関連させることが必要になる場面があります。
マトリックス的にすべての情報を管理するというようなイメージ図で議論していて、解決するような問題ではありません。
コンビニで、ＰＯＳシステム（販売時点情報管理システム）が使われています。
５０年程前、日本のコンビニに勤務していた人が、限られた大きさの店で、いかに商品の種類を増やして、便利な店にするかを
考えて、販売時点で商品在庫をリアルタイムに管理し、仕入れ発注を行う、一連の業務フローを、ノートに書いて考え、
コンピューターメーカーにシステム開発を依頼しました。
最初は、実現不可能と言われましたが、コンピューターメーカーと検討を続け、最終的にシステムが完成したという話は、
ＮＨＫのプロジェクトＸでも紹介された有名な話です。
行政システムのデジタル化においても、行政手続きを知り尽くした人が、どのようにデジタル化を進めるかを
考えるというのが、基本になると思います。
２０世紀には、アカウントＳＥという制度が、広く存在しました。
コンピューターメーカーに入社したＳＥは、最初、お客様のシステム室に常駐するというのが一般的でした。
ＳＥがお客様のシステムや会社全体の状況を広く理解できるのが、利点でした。
ただ、欠点もあって、どこのお客様のところへいくかの当たりはずれが大きかったです。
さらに、日本経済のバブルがはじけたころから、自社の従業員には命令できないブラックな勤務を要求されるＳＥも増えて、
アカウントＳＥという制度はなくなりました。
ただ、現在、日本では、ＳＥが、システム・インテグレーションの会社に雇用され、お客様の業務を理解する機会が無いのに対し、
米国などでは、システムを導入する側の事業会社に雇用されるＳＥが多いということが話題になっています。
けっして２０世紀のやり方に戻すのが良いとは思いません。
しかし、過去の成功と失敗に学ぶことは積極的におこなうべきです。
現在のＳＥのなかには、プログラミングの能力はすばらしいけれど、
自分がコーディングしているシステムにはまったく関心がなくて、自分が使っている
ＩＤＥ(統合開発環境)にものすごく関心をもっている人が居ます。
行政システムのデジタル化においては、行政手続きを知り尽くした人が、どのようにデジタル化を進めるかを
考えるというのが、基本になるとともに、
自分が開発している、行政システムにものすごく関心を持っているＳＥと、
自分自身が利用するシステムとして、システムを利用することと、
システムの使い勝手にものすごく関心を持っている政治家と、
主権者として、政治家や行政機関の発表を、鵜呑みにせず、
重要な虚偽の表示が存在する虞に常に注意を払い、
誤謬又は不正による虚偽表示の可能性を示す状態に常に注意し、
懐疑心をもって批判的に評価する姿勢をもった一般ユーザーの存在が鍵になると思います。