先週が「土台はすでにある」という宣言だったなら、今週はその土台が機械の中にもあるという話だ。人だけが8割を握っているのではない。ベンチの上の装置も同じだ。そして人と機械から欠けた2割は、驚くほど同じ形をしている — 画面。
今週のSignal
機器はすでにすべて話せる。 今週のBuild記事の核心だ。ベンチの上の計測器一台を見よう。それはすでにSCPIという標準言語で自分の状態をはっきりと話す。測定値を差し出し、命令を受け入れ、設定を変える。欠けていたのは機能ではなく顔だった。人が覗き込んで操作する運用画面。その画面を、いまやファームウェアを焼き直さずに定義一枚で載せる。機械の8割(測定・通信・制御)はそのままに、欠けた2割(画面)だけを外部からきれいに埋めるのだ。
「専用SWがなくて」はもう言い訳ではない。 現場で最もよく聞く壁がある — 「この装置は専用プログラムがなくて使えません」。今週がまさにこの文をひっくり返す。専用SWがないことが本当の問題ではなかった。専用SWを機器ごとに別々に開発するモデルそのものが高すぎたのだ。定義で画面を載せれば、「専用SW」という概念そのものがそっと消える。装置が話すプロトコルに画面を合わせてやる定義一枚で十分だ。作る対象が「プログラム」から「一枚の定義」に変わる瞬間、コストの桁が変わる。
人と機械が同じ文の上に立つ。 ハン・ミジョンさんの採点基準であれ、計測器のSCPIであれ — どちらも「すでにある土台に画面一軸を載せる」という同じ動作だ。ドメインが教室であれ実験室であれ、載せる方式は一つだ。この一貫性が、今月が繰り返し指す地点だ。
ツール・パッケージメモ
今週のメモはプロトコルと画面の分離だ。古いやり方では、測定ロジックと表示画面が一塊でファームウェアに焼かれていた — 画面の文言一つ変えようとしても機器を丸ごと焼き直さねばならなかった。両者を分けると、機器はデータを話す仕事だけを、画面はそのデータを受けて描く仕事だけをする。同じ計測器に異なる画面を二つ載せることもできる — 初心者用一枚、熟練者用一枚。定義が二つなら画面も二つだ。土台は一つ、顔は複数。機器を変えずとも使い道が増える。
短い考え
値の張る装置が引き出しやキャビネットで眠っている理由は、たいてい性能ではなくアクセスだ。よく測れるのに覗く窓がなくて、だんだん使われなくなる。画面を載せるコストが0に近づくと、眠っていた土台が目覚める。新しい装置を買うのではなく、すでに持っていた装置をようやくきちんと使うことだ。資本支出ではなく発見に近い。
現場から
ハン・ミジョンさんの話を一マス進める。先週、彼女は採点基準を「書く」ことを始めた。今週はその書いたものが画面になって浮かび上がるのを初めて見た — 132名の名前と、自分が定めた評価項目が一画面の中にきちんと。「私が普段、頭の中でやっていたことをただ移しただけなのに画面になったんです。」計測器とまったく同じことが起きたのだ。土台はもともとあり、画面だけが載った。一方は人の12年、一方は機械のSCPI。出発点は違っても到着点は同じだった。
今週の問い・来週の予告
あなたの周りに、ちゃんと動くのに「専用画面がなくて」使われていない装置やシステムはあるか。一度リストにして書いてみてほしい。意外と長くなるかもしれない。来週は再び人の側に戻る — ハン・ミジョンさんの採点画面がどうやって4クラス132名を実際に回す道具になったのか、現場のど真ん中で直接見る。宣言と証明を過ぎて、一人の日常へ。
makemind.dev 「更新」— 毎週一度、一週のSignalを短くまとめます。