「データシートに書いてあるから大丈夫です」。現場でこの言葉を聞くたびに、少しだけ身構える。データシートは最も重要な一次情報の一つである。しかし、同じRds(on)やQgという文字を見ていても、各人が頭の中で想定している条件が違えば、議論が噛み合わなくなる。
結論だけが先に決まり、後から「温度条件が違った」「測定方法が違った」「定義が違った」と判明して手戻りになる。データはあるのに進まない。その入口は、多くの場合「読む力（Read）」の不足にある。
以下は、ECU開発業界における開発担当・検証担当・品質担当間のよくある状況である。ポイントは、誰も嘘はついていないのに、前提がずれるだけで意思決定を誤ることである。
開発担当：「このMOSFETは低損失が見込めます。Rds(on)も良好です」
検証担当：「シミュレーションモデルでも損失は小さかったです。波形もきれいでした」
品質担当：「そのRds(on)は温度条件が何℃ですか。代表値ですか、最大値ですか。測定電流とパルス条件は揃っていますか？」
開発担当：「項目名は同じなので、比較できると思いますが」
品質担当：「同じ項目名でも、前提条件が違うと別物です。脚注と測定条件を確認してから比較しないと危ないですよ！」
検証担当：「モデルの版や測定条件も合わせないと、結果が再現できませんね……」
このやり取りは極端に見えるが、実際の現場ではもっと静かに起きる。誰も嘘はついていないのに、「項目名」と「数値」だけが先に共有され、条件や定義が置き去りにされる。その結果、比較できたつもりで意思決定し、後工程で覆る。
Readとは、丁寧に読むことではない。比較や判断に必要な前提条件を、短時間で抜き出して揃える技能である。
データシートは「数字の一覧」ではなく「条件付きの契約書」である
Readで最初に押さえるべき結論はこれである。データシートは、条件付きで成立する情報の集合であり、数字単体に意味はない。たとえばRds(on)は、少なくともVgs、Id（測定電流）、温度、測定方法（連続かパルスか）、実装や配線の影響を受ける。Qgなら、Vds、Id、Vgsの掃引条件、ゲート抵抗、測定回路の定義によって値の見え方が変わる。trrやQrrはさらに厄介で、di/dt、測定回路、温度で大きく変動する。
つまり、項目名が同じでも同じ条件・同じ定義の値でなければ、比較できない。にもかかわらず、現場では比較表や社内資料で「項目名＋数値」だけが並びやすい。脚注や測定条件は欄外に追いやられ、ページをまたぐことも多い。結果として、条件が見えないまま議論が進む。
これは個人の注意不足というより、情報の見せ方の構造的な問題である。だからこそ、読む側に「前提を拾い、揃える」という型が必要になる。
典型的な落とし穴：条件・定義・脚注
データシート読解で事故が起きやすい落とし穴は大きく3つある。
1) 条件が揃っていないのに比較してしまう
同じ項目名でも、メーカーや品種が違えば条件が違うことがある。Rds(on)の測定電流が違う、温度条件が違う、Vgsが10Vと4.5Vで混在する、連続通電とパルス測定が混ざる。こうなると、比較表は比較できているように見えるだけの表になる。
対策はシンプルで、比較する前に条件欄を揃えることである。「項目名＋数値」ではなく、「項目名＋条件＋数値」で並べ直す。すると、比較できるものと比較できないものが自然に分離される。
2) 定義が違うのに同じ言葉だと思ってしまう
用語の定義がメーカーや測定手法で微妙に異なることがある。Qgの定義（どこまでをQgとするか）、スイッチング時間の定義（10％～90％か別のしきい値か）、熱抵抗の条件（実装条件や銅箔面積）などが典型である。このとき、数字を比べても意味がない。
必要なのは「定義を確認した」という事実である。定義が違うなら、同じ名前でも別の指標として扱うべきである。
3) 脚注に結論があるのに読まれない
脚注には、測定回路、測定機器、統計条件（Typ・Max・Min）、保証条件、適用範囲など判断に直結する情報が書かれている。ところが脚注は小さく、比較表にも転記されない。結果として良い数字だけが一人歩きする。
Readの第一歩は、脚注を末尾扱いせず、本文として読むことである。脚注を読めば、議論の前提の多くが揃う。
「読む」とは、前提を揃えて比較可能にすること
現場で使えるReadの最小手順を提示する。時間がないときほど役に立つ。
- 比較したい指標を3つに絞る（例：Rds(on)、Qg、熱抵抗）
- 各指標について、データシートから条件4点セットを抜く（温度／駆動条件／測定方法／統計条件）
- 条件が揃わないものは同じ表に並べない（比較対象から外すか、注記して別枠にする）
この手順を踏むと、「数字の大小」ではなく「条件が一致しているか」で会話が始まる。すると議論が速くなるだけでなく、あとから覆りにくくなる。これはDX以前の話として、意思決定の品質を上げる基本動作である。
ミニ事例：部品（MOSFET）の採用が量産で覆る
ある案件で、比較表ではA社品が最も低いRds(on)を示していた。開発担当は「損失が減る」と判断し、採用が進みかけた。しかし品質担当が脚注を確認すると、A社は25℃の代表値で、測定電流も低め、かつパルス測定であった。
一方、B社は高温条件での最大値に近い記載で、測定条件も厳しかった。さらに、量産ではロットばらつきや実装差が避けられない。結局、量産環境を前提にするとA社が優位に見えたのは、比較条件が緩かったためで、採用判断は保留となった。
もし脚注確認が後工程まで遅れていたら、評価のやり直し、調達交渉のやり直し、スケジュールの遅延が発生していたはずである。Readは、こうした後工程でコストが膨らむ事態を防ぐ。
実務テンプレ：データシートReadチェック
最後に、現場で回せる最小テンプレを置く。比較表の各項目の横に、次の5行を付けるだけでよい。
- 定義：何を測っている指標か（閾値・範囲）
- 条件：温度、Vgs・Id・Vds、測定方法
- 統計：Typ・Max・Min、保証の有無
- 出典：ページ番号・図表番号（脚注含む）
- メモ：比較可否（○・△・×）
この5行が埋まらない数字は、まだ比較に耐えない。逆に言えば、この5行が揃えば会議の質は確実に上がる。
データシートは「読んだつもり」になりやすい。だからこそ、読むべきは数字ではなく前提である。データシートは条件付きの契約書であり、Readとは契約条件を揃える技能である。
次回はRead②として、数値の前にデータの正体（生データ・加工・推定、粒度、欠損、誤差）を見抜く方法を扱う。あなたの手元のデータは、どの工程を経てその数字になっているだろうか？
