在宅勤務で、せっせと次の新製品の回路設計をしていた。部品表を再確認していると、軒並み部品が欠品している。これでは、せっかく設計したのに試作できそうもない。ソフトを先に作るか・・・。

　CentOS終了へ――移行先として注目の「Alma Linux」「Rocky Linux」を試してみようという記事で、CentOSがなくなるのを初めて知った。
　私自身は、CentOSを使ったことはないが、いろんなプロジェクトでCentOSが使われてきた実績を知っているので、現場は大変だろうなあと思う。

　日本のIT業界は「文系技術者」の巣窟、早くリスキリングしないと用済みだぞという記事であるエピソードを紹介していた。少し引用する。

大手企業の研究所での話だが、ソフトウエア関連の研究者は仕様書をつくるまでが仕事で、プログラミングは出入りのITベンダー任せだったという。この研究所に入った若手がプログラムを自分で書こうとすると「そんなことは業者の仕事だ」と怒られたそうだ。

　私の前職は大手電機メーカーだったが、確かにそういう部署が存在していた。ソフトウエア関連の研究者といいながら、ひたすら仕様書を書いているのである。うそのような本当の話だ。

　“Windows 11のすごさ”より重要な「『Windows 10』はいつまで続くのか？」問題という記事を読んだ。全く同感だ。プライベートのPCはWindows11にするつもりだ。でも、仕事で使っているPCは、ツールが動かなくなるとイヤなので、できる限りWindows10を使い続けたい。

　最近、ルネサスの評価基板が変化してきたと感じていた。昔は、独自仕様の高価な基板が多く、この点で、安価でArduinoシールドなどを使えるSTマイクロにかなり負けているというのが印象だった。
　それが、少しづつ変わってきている。
　「ルネサスは宝の山」、ウイニングコンボの仕掛け人が放つ新たな戦略とはに、最近、同社が投入したクイックコネクトIoTについて書かれていたが、かなり本気のようだ。チップ自体はいいものが多いので、評価基板をうまく活用できるようにしてくれれば、と思う。

　完璧なDRは存在しない、「議論の基本」で改善し続けるべしを読んで、基本ほど難しいモノはないと実感した。
　すぐにアクションプランを議論したがる人が多い。基本ができてないのだ。そもそも問題点がわかっていないのに、議論しているのである。
　私は、問題点を明確にするのに必要なことがあると思っている。それは、ありたい姿を明確にすることである。それと現実との差分が問題点だ。ありたい姿を言葉にできる人は、実は少ない。先日も、アクションプランから始まる改善計画を、あるマネージャーが発表していて、途中で聞くのがいやになった。全く何もわかっていないことが明白だったからだ。

　トヨタグループはソフト開発体制を1万8000人に、「幅広い分野の人材が必要」という記事を読んで、トヨタのソフト開発の本気度がわかった。1桁違うのでは、というような規模である。
　記事の中で、ソフトウェアエンジニアの立場の弱さ、という話があって、少し苦笑いした。以前、電機メーカーに勤務していたが、そこでもハード屋がソフト屋よりも偉いという暗黙のルールのようなものがあった。たぶん、今でもあるのではないか。

　みずほ銀行でシステム障害https://www3.nhk.or.jp/news/html/20210820/k10013213351000.htmlというニュースを読んで、ちょっとあきれた。
　いくらなんでも、多すぎないのか？まあ、これだけ大規模なシステムなのだから、大変なのはわかるが。
　このシステムとは比べものにならないほど小さな1万行程度の組み込みアプリでも障害は起きる。原因がわからず、連続して障害を起こしてしまうこともある。でも、みずほ銀行のシステムのように、優秀な技術者を集め、長期間のテストをして、こういうことになるのは、根本設計がどこか間違っているとしか思えない。これだけ障害を起こすと、現場は、対症療法に精一杯で、根本原因をさぐるという仕事ができていないのだろう。

　1700年代から建築記録が存在、竹中工務店の驚くべき「竣工建物データベース」https://xtech.nikkei.com/atcl/nxt/column/18/00933/072400079/?n_cid=nbpnxt_mled_kmは、題名通り驚くべき話である。竹中工務店が施工した建物の図面が1700年代から残っているのだという。
　業種は異なるが、メーカーで製品の設計資料が50年とか残っている会社はほとんどないのではないか？ソフトのソースコードになると10年前のコードも見つけられないとかあるような気がする。そもそも、転職後の会社では、設計資料そのものはほとんど作られていない。ソフトの設計資料もほとんど作らず、いきなりコードを書いている。私にとっては、それも驚くべき話だ。驚く次元が全く異なるが。

　「なぜなぜ分析」の狙い　不具合対策は仕組みの改善までは、前職なら納得の内容である。でも、転職して今の職場では、こういう議論ができる職場がうらやましい。今の職場は、開発の仕組みすらないからだ。開発は、全て、属人的である。回路図と部品表しか残っておらず、設計ドキュメントは何もない。流動の激しい職場なので、設計者は残っていない。何とか、まともなドキュメントを残そうよ、と言っているのだが、忙しいから、で終わりである。