ソフトウェアをハードウェアを作るノリで作るのはもう無理なんだよ

日本の会社の多くはハードウェアの作り方を発展してソフトウェアの作り方を模索してきた。僕はそれを根本から覆したいと日々模索しているのだが、今日面白い話があった。C言語における構造体である。

構造体とは、似通ったものをセットで管理できる仕組みである。例えば、

typedef struct {
のり
具
ご飯
} おにぎり

といった具合に。そしてそこにはアライメントというものが発生する。詳しい説明は避けるが、要は環境が勝手にいい感じに整列させる機構が働くというわけだ。
で、その勝手にいい感じに整列させるやり方が環境によって変わるので、セブンとファミマとローソンではこれらは同じように見えて中身は変わる。それを知らない人が時々罠にはまる。
で、だ。
小賢しい人はこのアライメントが分からない人が仕事をしても、その罠にひっかからないようにしたいと考える。これはハードウェアでもあるポカ避けである。例えば、機械と機械の接合部が物理的に異なれば、刺し間違いは絶対に発生しない。マイクロUSBの刺し口にUSBtypeCは絶対に刺さらない。ただし、アイシールド21の進を除く。
で、ポカ避けをするとこのようになる。組み込み開発経験者はどこかでみたことがあるコードだ。

typedef struct {
のり
具
dummy[3];
ご飯
} おにぎり

勝手に整列する方法を知ってる賢い人があらかじめこうやって書くと、アライメントは発生しない。だからそのあとアライメントを知らない人がいじっても罠にはまらなくなる。俺天才。これでおバカさんにも仕事をあげることができる。しかしそうは問屋が卸さないのがソフトウェアだ。
この手動アライメントには罠がある。まず、ファミマとローソンでは異なる。こう書いてしまうことで、ファミマで使っていたこの構造体をローソンに移植するとこの dummy によって意図しないアライメントが発生する。ポカ避けが逆に、より難解な罠に化けるケースである。
また、この dummy を手動でやるということは人間が頭で計算するということでそのものがミスるケースもある。賢い人でもミスはする、人間だもの。さらにさらに最悪なのは中途半端にそれを知っている人がこの dummy を見て「ああ、前任者が考えてくれてるからここは思考停止でもいいな」と思わせるケースだ。人間、人が考えたっぽいものを疑ってさらに考えることはなかなかしない。考えたっぽい形跡は罠になり得るのである。
さて、これに対する解決策は一つだ。このアライメントが分からない人がこのおにぎりをいじらないことだ。つまり、ちゃんとわかってるやつを連れて来いってことだ。マイクロUSBとUSBtypeCをわかってる人が刺さねばならない。
ここが、なかなかハードウェア出身の人には分かってもらえない。ならチェックシートでチェックすればいい、そう安直に考えてチェックシートを鰻のタレのように育てた結果、小学生が五分で作れるものを、一ヶ月かけることになった会社もあった。もちろん、うち一ヶ月は無限チェックリストをチェックして三人の上司に承認行脚する時間である。
ポイントは、この構造体というのは、プログラムにおけるとっても基本的な要素だということだ。しかしこの罠にかかるとメモリ不正アクセスという重大なルール違反になりやすく、環境側の配慮としてリセットがかかる。環境をコンビニの種類に例えた例を貫けば、おにぎり一つでセブンイレブンのブレイカーを落とすに等しい。暗くて買い物できなくなっちゃうね。超怖い。
という超不安定なものがソフトウェアである。これを触れる人は専門の訓練を受けた人であるべきで、その辺のバイトにノリで書かせては絶対になんともならない。雇用を生まねばならない日本社会はこれをなんとか素人でもミスらないように、考えて考えて、結果、セブンペイ事件が起こる。あれもセキュリティチェック受けたって言ってたわね。チェックでなんとかしようとするのハードウェアの悪い癖だ。チェックだけではなんともならない。プロが書いてプロが「レビュー」すべきで、プロの数が少ないならなおさら、そのプロが無限チェックリストを説いている有限の時間をもっと有意義に使わねばならないのだ。
ということを信じたくないと願って、早くも50年が経過した。今からでも、ソフトウェアの作り方は、一からきちんと考え直されるべきだ。それはソフトウェアを作るための仕組みとして定義されるべきで、ハードウェアの成功体験をベースに拡張されるものではない。だって、物理的に刺さらない、が通用しないのだから。
ソフトウェアをハードウェアを作るノリで作るのはもう無理なんだよ。いい加減。だから、全部ぶっ壊して作り直そうぜ。