バグを見つけるテストがバグってるは、開発をやったことのある人なら、必ず1回は経験したことがあるに違いない。1回というより、何度も経験しているだろう。
　これを回避することはできない。バグのないソフトウエアが存在しないように、バグのないテスト存在しない。テストの開始は、まずテストがバグっていないことの確認から始まる。

　テスト工数を削減したいというのは、ソフトウエア開発で大きなニーズの1つだとおもう。その手段の1つがテスト自動化ということで、ソフトウェアテスト自動化の教科書 〜現場の失敗から学ぶ設計プロセスという本を読んでみた。
　内容は基本的なもので、この本を読んだから、すぐに自動化にとりかかれるかというとそうはいかない。それは、当たり前で、自動化というのは、手動でやっていたソフトウエアテストを単に自動化するだけのものだからだ。そもそものテストのバリエーションが広いのでそれを自動化する方法は、それぞれの現場で工夫するしかない、
　この本を読んで最も参考になったのは、自動化の最大の目的は、デグレの防止である、ということだ。デグレ防止のためのテストを自動化することで、結果的に、新しいリリースごとにデグレが防止され、品質は上がる。でも、新しい機能は、やっぱり最初は、手動でやるしかない。その手動テストの中で、自動化でき、自動化することで工数削減できる部分だけ自動化する、という当たり前のことを、あらためて認識した。
　もう1つは、テストをスクリプトで書けないと、結果的には、自動化できないという指摘である。プログラミングなしで使えるテストツールは結局は使いものにならない。確かに。
　テスト項目を整理して、自動化できるものをピックアップして、PYTHONでテストスクリプトを作るところから始めようとおもった。

　健康保険証 「誤り3万件」が映すマイナンバーの不思議は、マイナンバーカードの運用に関する矛盾点がよくわかる記事である。
　せっかくのデジタルシステムなのに、手作業が混じってしまう。過渡期ゆえの一過性の問題であればいいのだが、この記事を読む限りでは、どうも制度設計そのもの問題で、根深い問題になりそうに思える。

　マイナカード保険証利用、本格運用先送り　トラブルで。相変わらず官公庁がらみのITはうまくいかない。そもそものスタートがまず間違えている。マイナンバーカードの普及率が低いから、何か用途を、という思いつきで保険証ということになったとしか思えない。そして、それを実装する稚拙さ。官公庁というのは、実務をさせると最低の組織である。何か考えて、予算をつけることに徹するべきなんだろうと思う。

　「マスター」「スレーブ」は”死語”に　技術による偏見への向き合い方という記事に、「マスター」「スレーブ」が死語になるということが書いてあった。差別用語として、「リーダー」「フォロワー」という用語へ変更するようになってきているらしい。
　英語圏だと、マスタースレーブという言葉が、そのまま奴隷と主人という語感になるのだろう。非英語圏の技術者である私にとっては、マスタースレーブは単なる技術用語である。だから、逆にいえば、「リーダー」「フォロワー」に変えてもらっても、それで通用するならかまわない。でも、切り替えるのは大変だろうなあ。

　「小さく始める」が「小さいまま終わり」に、SAPが第4次産業革命で訴える危機感という記事の題名を見て笑ってしまった。よくある話だからである。新しいことをするには、スモールスタートではじめるのがいい。それは、その通りである。でも、どこかで、大きくするか、やめるかの決心が必要になる。でも、えてして、その決心がつかずに、いつまでも小さいままで、そのうち忘れ去られて終わってしまう、というパターンがよくある。

　インテル　世界で最も重要な会社の産業史を読んだ。本の感想は、別のブログに書いた。これを読みながら思ったのは、かつては、マイコンの仕様が最も重要「だった」時代があったということである。
　昔は、何かやろうとすると、外部のインターフェース回路を接続しなけらばならなかった。シリアル通信ですら内蔵していなかった。ソフトウエアはアセンブラであった。そんな時に、使いたいチップとのインターフェース回路の設計が簡単で、アセンブラソフトを素直に書けるマイコンを選択したい、というのが開発の要望だった。
　今は・・・。正直言って、マイコンの仕様は、どんな通信インターエースを搭載しているか、ROM・RAMの容量は、という程度である。それさえ満足していれば、後は最も重要なのは開発環境になっている。
　というのは、実は実態と違っていて、開発環境重視は、もう既に終わっている。AI等の最先端なら今でも重要かもしれないが、私がやっているLANとRS485の通信という程度の機器であれば、どんな開発環境でも、立派なライブラリーが無料でついていて、開発環境もJTAGデバッガの治具以外は無料である。
　なので、今では、一度使ったマイコンの環境に不満がなければ、他の開発環境へ移るのがイヤなので、使い続けるという状況である。
　時代は、どんどん変わっている。開発者は、追従しなければならない。

　汎用性はキーボード入力に匹敵、なぞって伝える三菱電機の「しゃべり描き」は、実際に作ってみて、使ってみて、その経験から知見を得るということの重要性がよくわかる話である。
　ものは、スマートフォンやタブレット端末の画面を「なぞる」ことで、ユーザーが話した言葉をテキスト化して表示するという技術だ。これが、専門家から「認識精度が高い」「レスポンスが早い」という評価を受けている。でも、使っている音声認識エンジンは、普通のサードパーティー製のエンジンらしい。でも、「認識精度が高い」「レスポンスが早い」というのは、「なぞる」という独特のUI方式にあるらしい。これには、驚いた。やってみないと絶対にわからない知見である。

　IntelがArmコア集積ストラクチャードASIC、FPGAからの移行が容易には、いい取り組みだと思う。製品はASIC化が前提だが、いきなりASICを作るのはリスクが大きすぎるので、一旦FPGAで作って回路検証してからASIC化するというのは、現場ではよくある話である。私も何度か経験している。でも、FPGAで検証しているから、その後のASIC化が簡単かというと、そうはいかない。いろんな違いがあって、結構大変なのである。その苦労が少しでも少なくなるというのは、現場の技術者にとってうれしいことだ。

　東証でサーバーのハードウエア障害が発生したときに、システムが切り替えられなかったという事例で象徴されるように、設計段階でいろんな障害を想定して手を打っていても、それがうまく動くとは限らない。
　実行中のワークロードに対してさまざまな障害を人為的/実験的に発生させ，障害に対するシステムの挙動を観察し，障害対策を強化していくというケイオスエンジニアリングという考え方があって、Netflixでは実際に数年前から取り組んでいるという。（すべてのユーザにケイオスエンジニアリングを ―AWS Fault Injection Simulatorが実現するマネージドな障害”実験”）
　すごいの一言である。でも、実際の運用で、障害がないなどということがあり得ないということを考えると、こういう方法は実際的なのだと思う。でも、そこまで費用をかけられるのか、というのが課題であろう。そして、それは、そのビジネスにとって、信頼性がどれだけ重要で、かつ、障害対策に費用をかけられるだけ儲かるビジネスなのか、ということになる。日本でこれができるところは、ほとんどないだろうなあ。