原因は予想外の場所に潜む！――修理は“気付き”が大切は古い記事だが、たぶん、似たような話は、組み込みの現場では、今でも繰り返されている。
　つい最近でも、端子の被覆から電線が出てしまって、筐体に接触してしまう。いわゆる地絡による障害に出くわしている。

　前回、今でも現場ではRS485などのシリアル通信が使われているということを書いた。ところが、そのシリアル通信の技術をきっちり理解するための教科書がない。LANが普及する前は、シリアル通信が組み込み機器の中心だったので、いろんな本が出ていたのだが、今では絶滅である。Interface誌とかトランジスタ技術誌とかでも、AIの特集はあっても、今さらシリアル通信の特集はしないだろう。
　でも、当然、シリアル通信がレガシー技術だからと言って、簡単な技術であるわけはない。

　横浜の花火台船火災、システム操作も打ち上げ停止せずは、一歩間違えば大惨事になるような事故だった。最近の花火は高度化していて、打ち上げをコンピュータ制御しているらしい。当然、異常時には打ち上げを停止させる緊急スイッチがあっただろうと推測するが、それがうまくいかなかったらしい。
　打ち上げ停止をコンピュータ制御でやっていたとしたら、問題だろう。危険度が高いシステムの停止は、単純で故障しない、万が一故障しても、打ち上げ停止側になるような設計が重要なはずである。

　国内製造業でSBOM導入済みは7％にとどまる、79％は導入予定なしという記事を読んだ。まあ、そんなものかもしれない。そもそも製造業というのは、ソフトウエアに対する理解がない。そんな状況で、SBOMという話をしても、導入しようという気にはならないだろう。最もやりたくないのは、たぶん、開発者自身だ。ただでさえ、納期に追われているのに、SBOMなんていう余分な仕事までやってられない、と思っているに違いない。

　イチから全部作ってみよう（21）ソフトウェア開発の見積もりは「KKD」がカギには、本当にその通りだ。ソフトウエア開発の見積もりほど難しいものはない。
　KKDは、勘と経験と度胸の頭文字からきた言葉で、開発ではよく使われる言葉である。根拠のある数字があればいいが、そうはいかない。結局はKKDである。そういうものだ。

　まだマイコンがなかった、50年前の回路設計の記憶は、マイコン登場前からマイコン登場直後の回路設計に関して書かれている。この記事にMDSという開発装置の名前がある。今でこそ、組み込みマイコンの開発は、JTAGデバッガがあればよく、個人でも買える範囲のものになった。しかし当時は、本当に高価な機器だった。ただ、マイコンによる回路設計の簡素化の効果は大きく、製品コストを下げたり、今までの回路ではできないことができるということで、数が出る製品開発では使われていた。

　初心者向けサンプルコードはなぜつまらないか、諸悪の根源は「黒い画面」はその通りと思う。初心者向けのプログラミング参考書では、必ずコマンドラインでのプログラミングになる。私のように、MS-DOS全盛時代からの世代は、違和感はないが、Windowsやスマホに慣れた世代には、何だろう、ということになるんだろう。
　プログラミングの基本を学ぶためだから仕方ないとはいえ、あまりにつまらないので、そこで挫折することも多いのかもしれない。

　時代に合わない「情報システム」という言葉を使い続ける企業は衰退するという記事の中で、面白い話があった。少し引用する。

「もうかるのか」「できるのか」「事例はあるのか」は亦賀氏がかねて批判してきた、「なのかを問う人」の口癖である。「なのか」を問うのではなく、「自分で戦略を描き、『実行する』『勉強する』『調べる』など、自分ですることが重要」と言う。

「もうかるのか」「事例はあるのか」は、前職でさんざん言われてきたことである。前職は研究開発部門であった。
「事例はあるのか」と聞かれて、NOというテーマをやるのが本来の研究開発部門の仕事であるはずである。でも前職ではそうではなかった。事例があって、その事例を少し改良したものでないと、「もうかるのか」という問いに答えられないからである。

　次世代TRONの「T-Engine」が死しても今なお息づく「μT-Kernel」と「μITRON」の結びに、「国内の半導体メーカーのICをターゲットとし、全て日本語で完結するμITRONやμT-KernelというRTOSは、実に貴重な存在ともいえるだろう。」とある。それは、その通りである。だが逆に、英語のドキュメントや技術資料は少ない。海外の会社にμITRONで、となると、大きな弊害になる。
　ソフトウエア開発は、詳細な技術文書がないと、開発効率が悪い。ソースが公開されているのだから読めばいいだろう、というのは乱暴な話である。このあたりは、AIによる翻訳精度が上がっているので今後は何とかなるのかもしれないが。

　設計部門にはびこるOJTという名の無教育という記事を読んだ。設計者をどう育てるのか、というのは、本当に難しい課題である。結局OJTしかない、といいながら、満足なOJTもできず、無教育のままになっている。
　それは、その通りである。でも、この記事のように、スキル項目とスキルマップを用意し、それに対するOFF-JTの機会を与えるということが、教育なのだろうか？
　OFF-JTで学べるのは知識である。知識なしには、設計はできない。でも、知識があっても設計はできない。知識は、設計の必要条件でしかないからだ。