#4477 コロナ接触アプリ「COCOA」の不具合の原因 Feb. ３, 2021

　コロナ接触アプリCOCOAの不具合が問題になっている。昨年9月にアンドロイドの改訂版を出したそうだが、それでも治っていなかった。田村憲久厚生労働大臣が今日（2/3）慌てて記者会見していた。

　クレームがいくつもあったのに放置していたのはどういうわけか。もっと問題なのは、有効なフィールドテストがなされずに稼働しているという事実だ。

　ソフトメーカに仕事を丸投げしたのだろう。外注先が作ったソフトはその企業がテストするのはあたりまえだが、発注元はフィールドテストしなければ、納品されたソフトの検収ができないはず。そういう基本的な作業をまったくやっていないということ。開発会社のシステム開発体制にも問題があるし、発注元である厚生労働省にも仕事の基本にかかわる大きな問題がある。

　どこに問題があるかというと、発注元の厚生労働省側にフィールドテストの実務デザイン能力がないということだろう。平井卓也デジタル改革担当大臣も本件では機能していない。屋上屋を重ねて担当大臣を次々に任命しているが、仕事をこなす能力が誰にもない。　

　システム開発をするときは、本稼働の状態でのテストデータも作成するし、テスト設計に従ってチェックをする。それがまるでできていないということ。誰が外注先企業を選んだのだろう？

　問題があって9月28日に改訂しているのになお不具合が続いて、5か月もして不具合のあることを認める発表を厚生労働大臣ががする。田村大臣、仕事の管理ができぬ。2月中旬に不具合を修正するというが、そんなに簡単なことならなぜ半年も放置していたのだろう？

　COCOAは一体どのメーカーに発注したのか？ネットで調べたら「人材サービス会社パーソルホールディングス」という会社。

　厚生労働大臣も大臣だが、厚生労働省の官僚機構もこの面ではまるでスキルがないことが露呈した。こんなに低レベルではデジタル改革なんて叫んで、予算を使えば使うほど、問題の山を築くことになりそうだ。
　首相官邸にもこのあたりの実務設計やシステムのチェックができるような人材がいないのだろう。デジタル改革を叫び担当大臣を任命するのか簡単だが、任せた担当大臣にそもそも必要なシステム開発マネジメントスキルがあるのか？
　経歴を見る限り、お二人ともこの分野での実務経験はないように見えるから、端から無理だったのだろう。
　ところで菅総理大臣、「実務遂行型内閣」って言ってなかったか？

＜余談-1：システム開発＞
　1984年に臨床検査最大手SRLに上場準備要員として入社して、予算編成と管理を任され、2か月後no

4月から上場要件を満たす経営統合システム開発を担当した。基本設計と外部設計仕様書作成に2か月、各システムとのインターフェイス設計に1週間、2か月の旧システムとの並行ランで合計8か月の開発期間を経て、本稼働した。
　テストデータは自分で作り、旧システムとの並行ランの前にチェックした。本稼働は実にスムーズ。当時国内では最先端の経営統合システムだった。
　大型のシステム開発の経験がなければ、このようなプロジェクトのマネジメントは無理だろう。テスト実務設計も、そのチェックだってできやしない。
　1997年ころだったと思うが、暗号ソフトを治験データ管理に採用する必要があって、暗号ソフトのベンチャー企業の英国人技術者二人と話をした。いくつか大きなメーカを当たったがどれも処理時間がかかりすぎ、こちらの仕様を満たさないことがすぐに知れたが、そのベンチャーの暗号ソフトは1秒で画像情報の暗号処理ができた。その技術者が言っていたが、日本の銀行システムでは「裸でデータが流れているので、いくらでも取り出すことができる、犯罪になるからしないだけ」だと言っていた。ハッカーの側から見たら、やりたいほうだいにできる、それほど日本の銀行システムは脆弱だったということ。デジタル回路が組み込まれたICカードになったのはヨーロッパに比べたら、ずいぶん遅れた。日本はセキュリティに関する意識が度外れて低いのである。そうした傾向はいまでもある。
　セブンイレブンの「セブンペイ」というカード決済システムの失敗例もそうしたセキュリテイの脆弱性、意識の低さ、スキルの低さの一つに挙げていいだろう。
　担当役員がいただろうが、仕事の基本がわかっていないのはとくにセブンイレブンに限らぬ日本の企業に普遍的な問題である。この分野で人材が育っていないのだ。

＜余談-2：HIVと厚生省エイズ・サーベイランス委員会＞
　1989年ころだったか、厚生省発表の国内のHIV感染者は百名前後だった。当時、SRLだけで毎日1-2の陽性検体が出ていた。スクリーニング検査した後、ウェスタンブロット法で確認検査していたので、100％確実である。年間500件ほど陽性が出ていたのである。1990年に学術開発本部へ異動したが、厚生省のエイズサーベイランス委員会がSRLへの問い合わせはなかった。医者が報告した数だけを集計していたのである。当時、SRLについでHIV検査が多かったのは江東微研と聞いていた。大手検査センター数社にデータ提供を要請したら、もっと実態を反映した検査結果を集計できたはず。数十分の一しかHIV検査陽性者数をつかまえていないから、先進国では日本が一番対策が遅れた。データの集計に関しては当時から厚生労働省は意識が低い。コンピュータシステムを使って、大手民間センターからデータ収集をするような構想がなかった。医療の専門家は厚生省にいたのだろうが、医療とシステム開発の両方の分野を渉猟できる人材がいなかったということ。そういう状態が30年たった今でも変わらない。あきれてものが言えぬ。

＜余談-3：臨床検査項目コード標準化プロジェクト＞
　入社2年目に「臨床診断システム開発及び事業化案」を書いて創業社長の藤田さんから200億円の投資予算を認めてもらった。PERTチャートを作成して添付してあったが、プロジェクトをさらに10個のプロジェクトに分割していた。そのなかに臨床検査項目コードの標準化プロジェクトとカルテの標準化プロジェクトがあった。大手六社の業界内の項目コード統一を議論しようということでBMLのシステム部長の北川さんと言ったかな、呼びかけがあったので、2回目に参加した。当時のわたしの肩書は「購買課員」である。話をもってきたシステム開発課長の栗原さんと話して臨床検査部の川尻部長を巻き込むことにした。臨床病理学会項目コード検討委員会の櫻林郁之助教授（当時自治医大助教授）がSRL顧問で臨床検査部の免疫電気泳動部門の指導に当たっていたからだ。
　2回目の会合で、「業界内でコードを決めても病院は使ってくれない、作業は大手六社がやり、公表は臨床病理学会項目コード検討委員会の櫻林先生にやってもらえば、日本標準になり、全国の病院が使うことになる、次回の会議に櫻林先生を連れてくるが、この方式に賛成してもらえるか？」と問うと、6社全員賛成だった。5回くらい出席したが、軌道に乗ったので手を引いた。川尻さんはその後学術情報部長になった。学術開発本部へ私が移動したので、六社のミーティングに2度ほど参加した。米軍との出生前診断や慶応大学病院ドクターとの出生前診断検査の日本人基準値のプロジェクトマネージャとして忙しくなったので、手を引いた。わたしが参加する必要はなかった。数年かかって日本標準になって、いま全国の病院が利用している。項目コード事務局はいまでもSRLにあるはず。櫻林先生には国際学会で世界標準にまでもっていくつもりだと話してあった。日本が国際標準規格を提案したことはほとんどない。ハリケーンの藤田スケールくらいなものだ。ところが日本標準ができたところでストップしてしまった。臨床病理学会にそういうニーズがなかった。お金もかかるから、資金面でのバックアップと、海外の専門家と共同作業も発生する。人材面でも補強しないといけなかった。学術開発本部にいれば資金面ではバックアップできた。入社2年目で検査試薬の価格交渉を提案し16億円のコストカットをしていた。当時の利益の半分はわたしが自分で提案し、検査試薬コストカット担当メンバーの一人として参加して予定通りの実績を上げていた。だから、数億円のお金なら経理部長も専務の谷口さんも異論のあるはずがない、了解もらえた。
　臨床検査項目コードの産学協同プロジェクトに当時の厚生労働省はかかわっていない。そういう問題意識やビジョンが厚生省にはなかった。だから声もかけなかった。不要だったのである。その厚生労働省がいま新型コロナ接触アプリのCOCOAを発注して大失敗をしているのはあたりまえだと感じる。いまだに医療とシステムの両方の分野を自在に歩ける人材が育っていないことが新型コロナ接触アプリCOCOAの不具合で露呈した。学卒の東大出身のキャリア官僚と難関大学医学部出身の医系技官のセット程度ではできないレベルの仕事である。

＜2/6朝追記＞
　「新型コロナウイルス感染者等情報把握・管理支援システム(HER－SYS)」というシステムもつくったが、ほとんど稼働していない。関連企業に相談もせずに勝手な仕様でつくって、それに従えなんて通達出しても、民間企業は動かない。臨床検査項目コードの標準化プロジェクトを大手6社と臨床病理学会（臨床検査医学会）で組織し、数年かけて実務に耐えうる綿密な検討作業をしたわたしたちとはまるでやり方が違う。唯我独尊。
　ではどうやればよかったのか。民間検査センターとのインターフェイスは大手6社のシステム部門と学術部門へ「急ぎなので２週間でインターフェイス仕様を決めて厚生労働省へ通知を願いたい」と文書で連絡すればよかったのである。検査会社から来た仕様書を見てから、HER-SYSの基本設計をすべきであった。逆をやるとアウト。李油はお考えいただきたい。
　大手民間検査会社の自動化やシステムは世界最先端のレベルにある。そこでどのようなデータ処理がなされているかも知らずに、勝手なインターフェイスを公表されても困惑するだけ。
「COCOA」だけじゃない。厚労省コロナ対策関連システムの惨状」

------------------------------------

　…「HER－SYS」の利用が進まないのは、現場だけではない。厚労省本省すら、「HER－SYS」を利用している節がないのだ。
　厚労省によると、いまだに陽性者数の集計は「各都道府県のホームページを、担当者が目視確認する」手法で行われているという。「HER－SYS」の正式名称は「新型コロナウイルス感染者等情報把握・管理支援システム」。この名称からもわかるように、「HER－SYS」には集計作業の自動化と迅速化も機能として実装されている。しかし厚労省本省の集計作業が担当者による各都道府県のホームページの目視確認で行われているのならば、「HER－SYS」は一向に活用されていない事になる。厚労省からすれば、現場における「HER－SYS」の利用が進まない以上、ファックスや電話による報告を受けた各都道府県の「ホームページ」に頼らざるをえないのだろうが、このオペレーションでは本末転倒の感は拭えない。
　このように、検査の現場でも厚労省本省における最終的な集計作業でも、「HER－SYS」が設計通りに利用されている形跡は一切ない。厚労省が「HER－SYS」改修のために獲得した二十数億円の予算は、ドブに捨てられたのも同然だ。
------------------------------------

にほんブログ村　
　

コメント 14

ちゃお！？

コロナ接触アプリCOCOAは新規開発アプリじゃないですね。
台湾？香港？だったかの流用アプリで開発期間が異常に短いスケジュールでテスト不十分のなか公務員の剛健判断で導入したアプリ。
聞いた話では、アプリ流用開発の下請けは毎日残業だったようですよ。

公務員の検証なんてザルです。
その場を乗り切るための動作であれば問題ない人の集まりで、経過して問題が起きれば開発元を叩く。
いくら当時の要求仕様どおりに開発してもです。
これが何時ものことです。

私も20年前とある企業の住基等の共通部品を開発したことがありますが、ここまで酷い話はあまり聞いたことがありません。
えっ今ですか？
今はメディア関係の仕事ですよ。
by 石動惣一 (2021-02-04 08:10) 

石動惣一さん
おはようございます。
COCOAは核の部分は外部仕入アプリですか。開発期間を短縮するためにそうしたのですか。そこの動きがわからないということのようですね。そりゃあたいへんだ。新規開発よりもっとたいへんです。
そもそも納入されたシステムをチェックする方は作り手よりもスキルが上でなければ有効なチェックは出来ないものです。
発注元の厚生省の担当者にそんなスキルがあるわけがない。あれば、仕様書が書ける。その仕様書を見ればプログラミング可能なレベルの詳細な仕様書です。
それが書けないから、おおざっぱな仕様で発注する。そしてチェックのスキルがないから、納品されてもテスト設計ができずにチェックができない。小規模なフィールドテストすらできない。

1984年にSRLへ転職して経営統合システムを担当したときには、仕様書の書ける担当は一人もいませんでした。だからサブシステム単位に分けられたプロジェクトは1年たつのにほとんど進んでいませんでした。
ユーザー部門に外注先のソフトハウスのシステムエンジニアよりもスキルが上の人材がいなかった。いやシステム設計経験のある人がいなかった。普通のことです。仕様を固めるのに２年かかったのが販売会計システムでした。このサブシステムは本稼働まで3年かかってしまいました。
SRLにはユーザ部門の専門知識や実務知識をもったシステムエンジニアが一人もいなかった。だから、無駄を繰り返して時間をかけて育てるしかなかった。
上場準備要員で、簿記の専門家で会計システムの専門家、在庫管理システムの専門家、売上債権管理の経験者、原価計算の専門家そして統合システム開発の経験者はわたし一人だけでした。
だから、会計システムと支払い（買掛金）管理システム、投資・固定資産管理システムの三つの仕様書（すぐにプログラミングができるようなレベルの外部設計仕様書）を書くのに2か月かかったかな。購買在庫管理システムが滞っていたので、それが動かないと、支払い管理システムが稼働できないので、実務デザインをして帳票の半分以上を設計し、プログラミング仕様書をわたしました。
他に、原価計算システムと販売会計システムがありましたが、インターフェイス仕様が決まらないで会議を繰り返していたようなので、初めてミーティングに出たときに、どこもやれないようなので、次回のミーティングにインターフェイス仕様書を作って持って来る旨宣言、1週間で仕様書を書いて、次の週のミーティングで決定。
システムはあれから4度ほど変わったでしょうが、システム間インターフェイスはほとんどそのままだと思います。

テストデータも自分で作りました。こちらの仕様書通りになっているか、あるいはわたしが設計した実務の通りに動くのか、自分でチェックしたかったからです。2か月間、旧システムと並行ランをしてデータ確認をしてます。それで1985年1月1日から本稼働。ノートラブルでした。
この仕事を担当する前にシステム開発専門書を20冊は読んでました。もちろん、統合システム開発経験もありました。だから必要なスキルが揃っていた。
必要な範囲の複数の専門知識と経験をベースに、基本に忠実に仕事したからノートラブル。

そういう目で見ると、厚生労働省は穴だらけ。お粗末の極みです。東大法学部出身の官僚と難関大学卒の医療系技官だけではとてもやれる仕事ではありません。もっとスケールの大きな人材が必要です。三十数年たちますが、いまでもなかなかいないのでしょうね。（笑）
by ebisu (2021-02-04 10:32) 

今の日本のSE,PGはカッコだけです。

優秀なSE,PGは1割もいません。優秀な人は既に国外や大手の主要に抑えられています。

今のSEはPG経験がなくてもなれるとんでもない状態です。少し前はPG最低でも５年経験、その後SEへという流れでしたが、今は未経験でSEになる人がいる。
その下請けのPG開発は地獄らしい（哀）。

一昔前はこの人に任せればどうにかしてくれるというSEなどが多くいましたが、今はごく僅かです。

あと公務員は勝手な仕様と概念を押し付けるから
by 石動惣一 (2021-02-04 12:07) 

　記事の論旨は真っ当だと私も思いますが、とても難しい問題を孕んでいると私は思います。

　中村洋四郎師匠はロケットの打ち上げソフトをバグひとつ無く完成させて見せました。今の日本のロケット打ち上げの失敗率の低さにその遺伝子が綿々と繋がっています。

　私は凡人ですので、テスト重視はよく理解できます。でもテストし易い作り方と開発体制の維持がとても難問です。

　医学部卒の先生は頭が良い。法学部出身の官僚は頭が良い。でも実践経験はありません。

　システム開発は改善が一番難しい。校正は新しく文章を書くより誤字脱字を生む。ゼロから作る、書く方が誤りが減り、早くできます。

　銀行のシステム開発者は6年以内に移動。システムの更新は6年ごとでした。今も変わらないと思います。日本人が劣化したから移動させます。

　頭に依らず、確率2割程度で悪事をする奴がいる。システム開発の担当者も同じ。日本人が出来損ないになったのが私は全ての根本的な理由だと思います。

　無理ですよ。どんなに叫んでも、変わるやつも同じ穴のムジナになる。

　要するに幼児教育の劣化。家庭の教育の崩壊で日本国は崩壊する運命だと私は思います。

　急がば回れ、コロナだろうと、デジタル革命だろうと幼児教育を抜本的に変えなければダメでしょう。だから改善には30年かかると私は諦めているのです。

　その内、私は嫌いな中国の属国になるでしょう。仕方ない。

by tsuguo-kodera (2021-02-04 12:09) 

石動惣一さん

35年でそんなに劣化するものですかね、驚きです。
なんでそんなことになるんやろ。
by ebisu (2021-02-04 22:08) 

koderaさん
こんばんわ。
倫理という点では幼児教育の大切さがよくわかります。
躾と言ってもいい。
そこが劣化したのはなぜなのか。
その一方で、大学教育が文型と理系で整然と別れすぎていると思います。総合大学なら、両方の単位がとり放題というシステムになっていれば、文型と理系の両方の分野を自由に行き来できる人材が育てられるのではないでしょうか。米国の大学はそういうシステムになっています。

改善の余地があるのでしょう。大学院もそうあってほしい。経済学でユークリッド『原論』を読む必要がある時代です。数理論理学も必要です。システム関係の科目も。
時代のニーズに合うようにチューニングしてもらいたいと思います。
30年単位で考えると、いくらでも必要な人材を供給できるはずです。
小さな私塾ですが、そういう方向で授業しています。言うだけでなくやって見せなければわからない。
by ebisu (2021-02-04 22:19) 

ちゃお！

劣化の答えは簡単。

コンピュータが普及し開発仕事が増えたが人員不足。
解決するため有名大学文系卒でもSEにしたて、開発を下請けに投げたため、自社開発レベルが下がった。
あとIT土方といって知識や経験ない人を導入したため。
そのためシステムの完成度より稼働性重視に比重を置いたためバグの割合が増えた
プログラム言語への理解度が低下、他分野に対する知識が理解度がない。
最後に世の中が指示待ち人間が増えたこと

人間の「進化」いや「劣化」です。

今小学生でもプログラミング学習があるが、正直現場意見から見ると意味がないと感じてると聞く
学習内容が「ゲーム向け」らしい
興味を持たせる学習なので問題ないが、このレベルが業務系のSEやPGになると今以上に厄介になる
企業では理想と現実のギャップですぐに辞めることを予想。


人間の生き方は4とおりしかない。
最初に楽をして、後で苦労するか。
最初に楽をし、後も楽をするか。
最初に苦労して、後で楽をするか。
最初に苦労し、後も苦労するか。

ちなみに私の生き方は4番目です
by 石動惣一 (2021-02-05 08:02) 

忘れ
企業では業務中にネット閲覧で調査可能な時代。
しかし今の現代人はネット情報のみを信じたり、困ったらすぐにネット検索する。
手法は間違えではないがなせか情報を覚えない。メモしない。
理由を聞くと「ネットをまた見れば解決する」かららしい。

「内部資料や秘匿情報すらネット検索して情報無いです」という人もいる
「内部資料や秘匿情報」がネットに公開されたら一大事だろうに。
それすらも判らないのが今の現代人。

ネット普及で便利になったが、なんでもネット頼りで大丈夫？
それとも既にその考えが古いものなのか？
by 石動惣一 (2021-02-05 10:42) 

石動惣一さん

ノリで「ちゃお！」って返事したくなります。（笑）
おはようございます。

劣化は昨今のSEとPGの育成事情と開発案件の増加のアンバランスが産み出したものですか。いまその業界で仕事をしている人の意見、なるほどと思います。

他分野あるいは実際のアプリケーションの分野への理解のないSEは35年前も事情は一緒でしたね。
経営統合システム開発はプログラミング経験がなければ、たとえば設計した帳票にソート順位を記入することができませんし、プログラミング工数の少なくなるような帳票設計ができません。当時はメモリー媒体が高くてプリントアウトがあたりまでした。
在庫管理や売上債権管理業務に何らかの形でタッチしたことがなかれば仕様書が書けないし実務設計ができません。コンピュータシステムを前提に新たな実務設計がなされますが、そういう実務を経験した人は誰もいません。まったく新しい実務を創造することになります。実際に稼働したときにはスムーズに動く、それまでベテランの作業が必要だった部分が消滅してしまいます。アルバイトでできる仕事に代わるだけでなく、仕事の量自体が著しく減少します。仕事によってはゼロになるものが出てきます。生産性と仕事の精度が一桁くらい違ってきます。
原価計算システムは、既存の原価計算理論を知っていることはもちろんですが、業種でかなり違ってきますから、例えば、臨床検査業なら臨床検査の業務に関する自動化やシステム化についてもかなりの程度知っていなければなりません。原価計算のシステム関係の本が書ける学者は日本にはいないのです。アカデミズムは無力。この分野の大学の先生たち何やっているんでしょうね。大御所は一ツ橋大学が代々引き継いでました。
固定資産管理システムも実地棚卸のやり方から実務設計の必要がありました。上場審査基準をクリアするために減価償却費の予算制度を一桁アップするひつようがありました。そのために投資案件を予算管理して固定資産管理システムへ組み込まなければなりませんでしたね。当時は誰もやったことがないものでした。固定資産ラベル、固定資産分類コードの設計、購入協議書の書き方も含めて改善が必要でした。
月次・四半期・半期・年次決算の予算・実績対比表はあたりまえ。25項目・5群の指標をもった経営分析レーダーチャートへ決算データや人員データを取り込み、レーダーチャートを出力します。それも当時はやっているところがなかった。試行錯誤です。統計学や経営分析のスキルが要求されます。もちろん分析に経験がなければ、レーダーチャートと、総合偏差値による経営分析諸表は宝の持ち腐れ。それらの出力帳票をベースにさらに分析を加え、子会社を含めて評価します。評価結果は翌年度以降の予算や中期計画へ反映され、目標総合偏差値に沿った経営改革の具体案が求められます。
経営統合システムだけでも35年前ですら、2000人社員がいてもそういうことができるのは一人だけ。
オービック、日本電気情報サービス、NCDなど、それぞれの会社のトップレベルのSEと合計で四年間ほど一緒に仕事させてもらいました。業界内にもそういう仕事のできるSEは一人もいませんでしたね。SEというよりもKE、ナレッジエンジニアです。

ゲーム業界が莫大な利益を上げるので、そちらへPGが大量にシフトしたようですね。ブラックな仕事も企業も増えたのでしょう。
金融関係では、とくに証券投資分野では高度な数学的なバックグラウンドを持ったPGへの需要が急増しています。ネットワークビジネス分野でも需要は急増。AI分野でも医療分野でも、あらゆる業界へコンピュータシステムが浸透してしまい、いわば企業経営のインフラ化してしまいました。新規開発だけでなく、膨大に膨れ上がったアプリ資産はコンピュータの性能や通信速度がアップする都度、膨大な更新作業が生まれています。単純なソフト開発やメンテナンスはAIに移行していくのでしょうね。20年後にはかなり複雑なアプリケーションも、その中核部分はAIがプログらミングすることになりそうです。
PGへの需要がこの35年間で百倍どころではない増え方をしているのでしょう。
だから、それぞれのアプリケーション分野を覗いたら、SEやPGの平均的な質が落ちて見えてしまう。
その一方で、KEレベルのSEが35年たってもほとんど育っていない。必要な専門分野が多くて、要求水準が高いからでしょう。

システム関係の仕事を見てきて、最悪なのは、スキルがないのに、あるいは著しく低いのに、能力を超えたシステムに手を出したがるパソコン小僧がしばしば出てくることです。惨憺たる結果を招いて、自滅してしまいます。だから、人材劣化に関する石動さんの次の意見に私もうなずきました。

「このレベルが業務系のSEやPGになると今以上に厄介になる
企業では理想と現実のギャップですぐに辞めることを予想。」

人生の生き方についてはわたしはリストにない五番目の行きかたをしてきました。

〇好奇心の赴くまま、やりたい仕事をする

ルーチン業務を抱えて、好奇心のままにプロジェクトを立ち上げて仕事をしてました。もちろん、だれにもできないので、特定のプロジェクトを任されることの方が多かった。臨床検査項目コード標準化プロジェクトや米軍との出生前診断検査や慶応大学との出生前診断検査の日本人基準値研究プロジェクトのような先端分野だったり、帝人との臨床治験データ管理合弁会社のような複合分野のスキルが必要なプロジェクトでしたから、その都度愉しかった。老人医療に関してシームレスな介護と治療を事業化したくて療養型病院の建て替えや経営にも携わりました。外食産業の上場関連の仕事にもタッチしました。
紳士服の製造卸、産業用＆軍事用エレクトロニクス専門輸入商社、帝人とSRLの治験合弁企業、病院経営、外食産業の上場、業種はさまざまですが、ずっと仕事を愉しんできた気がします。もちろんいまも。ふるさとで、子どもたちの育成＝教育にかかわっています。

好きなことをやる代わりに、報酬も出世も度外視。正直に言うと、短い期間でしたが高額の報酬をいただいた時期はあります。もちろん、報酬の数十倍の利益はだしてます。
きっと、仕事が好きなのでしょう。
身体を壊すような仕事のやり方はしませんでしたね。お小遣いが多かったので、結構遊んでました。仕事ができるととくなことがいっぱいあります。（笑）
若い人たちはいい仕事いっぱいしてください。楽しい生活が待ってます。
by ebisu (2021-02-05 11:02) 

石動惣一
仮面ライダービルド
喫茶店のマスター
https://dic.pixiv.net/a/%E7%9F%B3%E5%8B%95%E6%83%A3%E4%B8%80
by ebisu (2021-02-05 16:02) 

動作確認もしないで世に出していたなんて信じられないですね。防げた感染をどれだけ見過ごしたかを考えれば不作為の罪で担当者は解雇ではすまないところだけれど。
by もやしサンマ (2021-02-06 17:22) 

もやしサンマさん
お久しぶりです。
東大法学部出身のキャリア官僚と難関大学医学部出身の医系技官が揃っていても、この分野の経験はゼロに等しいのですから、起こるべくして起きたとしか言いようがないです。
人の採用の仕方がまずいのでしょうね。
だから10年後でも状況はほとんど変わらないと思います。35年前も同じでしたから、厚生労働省はぜんぜん変わっていません。
by ebisu (2021-02-06 18:09) 

私は先月から海外で活躍している日本人ITエンジニアさん達と週1回、日本時間のAM4時からAM10時までZOOMでITエンジニア勉強会に参加しています。参加していらっしゃる方はどの方も優秀で、参加当初はITエンジニアの実力不足を痛感していました。新型コロナウイルスによる影響で、テレワークが推進されて、日本在住のITエンジニアにとっては参加しやすい環境になっているのをもっと日本で勤務するITエンジニアが利用して欲しいと思います。来年からアメリカのTopCoder社主催のコンテストとSingateのdataScienceCompensionに参加すべく、日々勉強の毎日です。お題が経営工学的な題材、統計学を駆使した題材が多いので、現在は専門的な業務知識を勉強しつつ、開発力の向上と、プログラムを教える際に利用できそうな題材をレベルを下げてプログラミング作成課題に考えています。最近、BMI値から厚生労働省の基準に沿った肥満度を計算して、メッセージを画面表示するプログラムをJavaで作成して、わざと不完全な状態のものを修整してオブジェクト指向にふさわしい、プログラム課題を出題しました。

石動惣一さんの意見には賛成です。日本のIT系の企業は優秀なエンジニアには大量のプロジェクトを同時に抱えることが多く、病気やメンタル疾患に罹るリスクを察知して、海外に進出するのだろうと思います。私は脳梗塞を患うまでリスク察知ができなかった、リスクを察知して海外での就業準備が不十分だったので、私は二流のITエンジニアなだなと実感しています。
by hattori (2021-02-10 20:23) 

hattoriさん

企業の枠を超えて海外に在住の日本人ITエンジニアとZOOMで6時間も勉強会ですか。便利になりましたね。
空間の壁はもう乗り越えられます。
SNSで分野を超えた方とお付き合いが始まると、ZOOＭでのお誘いもあります。異分野へは並行して学習が必要になります。
好奇心が旺盛なら、やれることは多い。いい時代です。
たいへん参考になりました、ありがとうございます。

体力と相談しながら、身体に気をつけて交流してください。
by ebisu (2021-02-10 22:02)