部品が製造中止になる。ディスコン（製造中止。部品が生産終了になること）の報せが届く。あるいは供給が逼迫する、コストを下げたい、新しい要求仕様に合わせて変えなければならない——理由はさまざまですが、どれも「いま載っている部品を、別の部品へ載せ替える」という同じ結論に行き着きます。

このとき、部品ベンダはこう言います。「互換品です。大丈夫です」。

その一言に頷いた瞬間、あなたは見えないリスクを肩代わりさせられています。本稿では、なぜそうなるのか、そして本来は何をすべきなのかを、実際にやることを見せながら説明します。

1. 「互換」はベンダの主張であって、あなたの保証ではない

「互換です」は、ベンダの立場からの言葉です。ベンダにとってこの一言は、自社製品を売り、移行を後押しし、そして同時に、互換性の細目を仕様書の奥に置いたまま、責任の重心をこちら側へ移す言葉でもあります。

一方で、生産ロットに判を押すのは誰か。顧客に出荷するのは誰か。市場で不具合が出たとき、市場デバッグ（出荷後に市場で不具合が発覚し、現地で対応に追われること）の費用と賠償を負うのは誰か。——製造者であるあなたです。

ここに、ソフトウェア開発の文化と、機器開発の文化の決定的な差があります。ソフトウェアの世界では、「互換」と分かれば、たいてい載せ替えて先へ進みます。変更は安く、可逆で、問題が出ても更新で戻せるからです。しかし機器の世界では、「互換です」は作業の終点ではなく、起点です。「同じである」は、相手の言葉を信じて済ませるものではなく、自分の設計で証明するものなのです。

そもそも、この「互換」という言葉は、誰の目から発せられたものでしょうか。部品を作って売る側か。その部品を製品に組み込む側か。それとも、できあがった製品を手に取る利用者か。——発しているのは、部品を作る側です。「互換」とは、部品メーカが自社のカタログの上で「前の品の代わりに使えます」と言う言葉であって、あなたの製品の上で「まったく同じに振る舞います」と保証する言葉ではありません。立っている場所が、そもそも違うのです。

そして、言葉そのものが手がかりを残しています。もし本当に「違いはない」という意味なら、人は「互換」とは言いません。「同一品」と言うはずです。互換、同等、代替、相当——部品の世界には“ほぼ同じ”を指す言葉がいくつもありますが、そのどれ一つとして「同じ」だとは言っていない。互換 ≠ 同一。ほぼ一緒、とは、違いがある、ということなのです。

2. 過ぎたるは及ばざるが如し — 変えた理由と無関係な差分を、丸ごと引き受ける

昔の人は、過ぎたるは及ばざるが如し、と言いました。部品の世界も、ご多分に漏れません。

部品を替えるとき、あなたはたいてい「一つの理由」で替えます。これしか手に入らないから。こちらのほうが安いから。要求が変わったから。ところが新しい部品は、その一つの理由に関わる点だけが違うのではありません。あなたが頼んでもいない、ほかのすべての点でも、静かに違っています。

「互換品」「上位互換」という言葉は、安心の根拠のように聞こえます。足りないものは何もない、むしろ良くなっている、と。しかし「従来品とまったく同じに振る舞ってほしい」という文脈では、その「良くなっている」こそが罠になります。新しい世代の部品は、製造プロセスが新しく、内部構成が違い、初期状態やタイミングや単位が違う。あなたの製品は、従来品の挙動に合わせて作られている。つまり、「足りない」ことだけが危険なのではなく、何かが“違うやり方で”行われることこそが、従来品との等価性を静かに壊すのです。

同一を求める設計において、変えた理由は一つでも、引き受ける差分はすべて。そして差分は、すべてリスクです。

——こう書き連ねると、なんと悲観的で、なんと批判的な人間か、と思われるかもしれません。違いばかりを数え上げて、と。これは、そういう性格の問題なのでしょうか。

いいえ。責任を持つ製造者だからです。採用責任——一度その部品を自社製品に採用すると決めた瞬間から、その部品の振る舞いがもたらす結果は、ベンダが何と言おうと、あなたのものになります。だから、違いにこだわる。これは性格ではなく、職責なのです。

3. 実際にやること — 「単純な部品ほど危ない」と、全比較

では、「互換です」を信じない、とは具体的に何をすることなのか。一つ、わかりやすい例で見せます（※これは説明のための一例です。実際には、ここに当時いちばんヒヤリとした差分が入ります）。

題材は、あえて一番“単純”に見える部品にします。EEPROM（電気的に消去・書き込みができる不揮発性メモリ。電源を切っても内容が消えない、小さな記憶素子）です。

EEPROMの仕様書は、数十ページしかありません。「ただのメモリでしょ」と思える。——この油断こそが、最大の落とし穴です。仕様書が薄いほど、人は比較をせず「同じだろう」と先へ進む。つまり、部品が単純に見えるほど、思い込みが強くなり、罠にかかりやすくなる。

従来品は、内部で一度に書き込む単位（ページ）が32バイトでした。ところが容量を増やした“互換”品では、このページが64バイトに変わっていました。従来品向けに書かれた、ページをまたぐ複数バイトの書き込みは、新しい部品ではページの境界が異なるため、従来とは違う場所（アドレス）へデータを書き込みます。——データが静かに壊れる。書き込みのソースコードは、一文字も違っていません。

ここで見落としてはいけないのは、読み書きのコードはまったく同じだったことです。差分は、部品内部のページ構成に潜んでいた。ソースを眺めても、コードレビューをしても、見えません。新旧両方の仕様書を読み、しかも「ページ構成が違えば書き込みが壊れる」とわかっている人間にしか見えない。書き込み完了までの時間の差（固定の待ち時間で済ませていると、新しい部品が遅ければ書き込みを取りこぼす）も、書き換え可能回数の差（寿命が短ければ、市場で何年か経ってから一斉に壊れる）も、すべて同じ構造を持っています。

だからやることは、薄い仕様書であっても全比較する。差分を一つずつ取り出し、「自社製品の振る舞いに影響するか、しないか」を、根拠なく“同じ側”へ丸めることなく分類する。そして影響し得る差分には、新しい部品の挙動を従来品へ戻す制御を設計する（書き込みをページ境界にそろえる、固定待ちではなく完了を確認する、など）。これが、徹底した客観性と思い込みの排除を、実作業に落とした姿です。地味で、そして——ごまかしが効きません。

4. なぜこれは「誰にでもできる作業」ではないのか

ここまで読んで、「そんなの、全部比較すればいいだけでは。誰でも思いつく」と感じたかもしれません。

そう感じたなら、それはあなたが、すでに痛い目を見たことがある人だからです。多くのチームは、これをやりません。「互換」というベンダの言葉を信じ、しかも部品が単純に見えるほど、比較を省きます。そして本当に難しいのは、「比較すること」そのものではありません。どの差分が爆発し、どの差分が無害かを判定することです。ページ構成か、書き込み時間か、寿命か、電圧か——どれが、自社の使い方で牙をむくか。

その判定には、ハードウェアの挙動と、ソフトウェアの制御と、システム全体の要求を、同時に読める必要があります。この「境界を読む」能力は、職務記述書（求人で求めるスキルを定義する文書）にうまく書けません。だから募集しにくく、採用しにくい。結果として多くの会社は、ハードウェアの専門家とソフトウェアの専門家を別々に揃え、そのあいだの差分判定を——誰も担当しないまま——出荷してしまいます。

そして、これを暗黙にこなしてきたのは、勘の鋭いベテランでした。「この差分は危ない」と嗅ぎ分ける勘。その勘は文書化されないまま、いま定年で現場を去っていきます。DRBFM（Design Review Based on Failure Mode。変化点に着目して故障モードを洗い出す設計審査手法）という仕組みはありますが、変化点を「どこまで深く見るか」を決めていたのは、結局その勘でした。仕組みだけが残り、勘が抜け落ちたとき、審査は様式になります。

5. では、どうするか

変化点の影響を、思い込みを排して層をまたいで追える人を、社内に常駐で雇うのは難しい——求人票すら書けないからです。また、育成するにも時間はかかる。だからこそ、必要なときに借りる、という選択肢が現実的になります。

スライドで「ありがたい正論」を置いて去っていくのでは意味がありません。チームの横で、実際に手を動かし、「従来品と同じである」を設計上証明してみせる。プロダクト開発チームの、頼れる補機（主機が頼る、不可欠な補助機関）として伴走する——そういう関わり方ができる人材が必要です。

今回は、製品開発の落とし穴の1つである「変更」の話をしました。

より深い落とし穴は、もっと上流にあります。

製品が「どう振る舞うべきか」——ソフトウェアへの要求が、上位文書や機構や電子回路やシステム構成から、正しく抽出されていたか。次回は、ソフトウェア工程における最上流工程である、ソフトウェア要求定義を扱います。（プロセス名はESPR v.2:IPAに準じます）