ご視聴いただきありがとうございます。テストデータでタイプミスを発見する「Catching Typos with Test Data」です。Nathan Gamblesと申します。Frontgrade Technologiesのプリンシパル・プロダクト・エンジニアです。Frontgradeでの私の役割は、高信頼性集積回路の製造とテストを支援することです。当社の顧客は、医療、航空宇宙、軍事など、高い安全性を備えた電子機器が求められるあらゆる分野に注力しています。
今日は、私が参加した根本原因分析調査の話を皆さんにお話ししたいと思います。データに興味深い異常がいくつか見られ、テスト結果に問題を引き起こしているタイプミスがいくつかあることが判明しました。これらの状況を特定し、さらに調査するために使用したプロセスについてお話しします。
まず、私が具体的に何をしていたのか、少し背景からお話ししたいと思います。先ほども申し上げたように、集積回路を製造していました。画面には集積回路の例が表示されています。多くの人はこれをコンピュータチップと呼んでいます。集積回路には様々な形状、サイズ、ピン数があり、その多くは様々な機能を持つ非常に多くのピンを備えています。これらの部品をテストする際には、非常に多くの異なるピンに対して同じテストを行う必要があります。これは、後ほど説明するテストデータで確認できます。
集積回路についてもう一つ注目すべき点は、上部のマークです。一般的に、これらには製造元、製品名、ロット番号、あるいはロット日付コードが刻印されています。シリアル番号が付いている場合もあります。私が手がけている製品のほとんどにはシリアル番号が付いており、製造工程を通じてシリアル番号を追跡しています。このシリアル番号は、この話を進めていく上で重要になってきます。
私が働いている工場は、部品を製造する際に、多品種少量生産の工場です。ロットも多種多様です。一度にたくさんの部品を作ることはありませんが、ある日には様々な製品を製造していることもあります。
ロットを製造したら、それを整理します。テスト工程に入る時の作業について説明します。テスト工程に入ると、自動テスト装置にテストプログラムを読み込みます。テストプログラムが読み込まれた後、オペレーターが部品を取り、それを… すみません、部品を取り、それを見て、部品にあるマークを読み取り、その部品をテスト治具に置き、部品のシリアル番号を入力して、テストを実行します。テストが実行され、データが収集されます。完了すると、オペレーターは部品をテスト治具から取り出し、トレイに戻し、ロット内のすべての部品に対してこのプロセスを繰り返します。
少し話を戻しましょう。先ほど、テスト工程で行う一般的な作業について説明しました。私たちが行う大まかな流れは、まず部品を室温でテストすることです。次に部品を取り出し、負荷をかけます。そして再び室温でテストし、最後に冷温と高温でテストします。これが仕様書に記載されている最低動作温度と最高動作温度になります。
その後、部品を室温で再度テストし、さらに冷温と高温で再度テストします。この2回目のテストは品質チェックの一環として実施し、工程2と3で最初のスクリーニングを通過した不良品が過度に多くならないようにしています。私が関わった根本原因調査の話は、4と5のテスト工程で、それほど多くの不良品が出るとは予想していなかったにもかかわらず、想定よりも高い不良率が見られたことがきっかけでした。
調査は様々な方向に分岐しました。ここでは、私たちが行った調査の1つの分野に焦点を当てたいと思います。私たちは、これらのテスト段階で確認されたいくつかの不具合のデータを取得し、そのデータを少し詳しく調べました。通常、データで確認できるのは、特定の測定パラメータについてです。冷温時のデータを見ると、特定のデバイスが冷温時に分布の上限にある場合、室温でも分布の上限にあります。また、高温時も分布の上限にあります。同様に、特定のデバイスが下限にある場合も中間にある場合も、同じ状況になります。
工程の後半で故障したデバイスの中には、このパターンに従わないものもありました。あるデータでは上限値を示し、別のデータでは下限値を示し、そしてまた別のデータでは上限値を示すというパターンでした。これは全く意味をなさないものでした。半導体のデバイス物理学の観点から見ても、全く意味をなさないのです。
いくつかのブレインストーミングを行った結果、私たちが目にしていたこのデータの原因として最も可能性が高いのは、私たちが実際に見ていたのは予想していたデバイスからのデータではなく、データにタイプミスが混ざっていて混乱が生じているのではないかということだと判断されました。
この調査を進める中で、どの部品からでもデータを取得できる分析手法を特定したいと考えました。繰り返しになりますが、私たちは多種多様な部品を扱う環境でした。データを取得する際には、専門知識をあまり必要としないことを確認したかったのです。比較的簡単で、結果を簡単に確認できる手順を求めていました。それが、この調査を進める上での私たちの目標でした。
これが私たちが行っていることの背景、そしてその理由です。これから使用するサンプルデータは、こちらのJMPジャーナルから入手できます。ボタンをクリックするとデータセットが生成されます。私は既にこのデータセットを開いています。まずは、このデータについて理解した上で、その内容を簡単に説明したいと思います。
これはデータです。このデータテーブルには441行のデータがあります。各行には、テスト操作におけるロットのエントリが含まれています。これは先ほどご覧いただいたPowerPointと一致しています。テストが行われた温度と、テスト操作中にオペレーターがシリアル番号を入力した際に入力されたシリアル番号が示されています。このデータセットには、測定値の列が300列あります。このデータテーブルの各行は、基本的にテストプログラムの1回の実行に対応しています。300件という膨大な数のテストがあることがわかります。
複数の異なるピンがあることを先ほど述べました。テストAはピン1で測定されています。テストAはピン2でも測定されています。少しスクロールしてみると、多くの異なるピンに対して多くのテストを実行していることがわかります。ピンごとに実行されないテストもあります。ピンごとに実行されないテストもありますが、多くのテストではピンごとに実行されます。基本的に、ここにはアルファベット順のテストが300列も含まれており、測定値が示されています。
ここで一つ指摘しておきたいのは、データテーブルがあり、データが積み上げられているということです。行によっては室温のデータ、冷温のデータ、高温のデータがあります。これは、データ準備の際にJMPのグループ化機能を使って、計算する統計量にこれらの温度間の差異が考慮されないようにするためです。
いくつかのデータを簡単に確認してみましょう。グラフビルダーを開いて、このチャートを見てください。どの操作を行っているか、どの温度でデータを収集しているか、そしてテストされたすべてのシリアル番号が表示されています。Y軸には測定値が表示されており、室温でのデータはほぼこのくらいです。低温になると、値は下がります。高温になると、再び変化します。室温に戻り、再び低温に戻り、また高温に戻ります。
半導体では測定値のシフトはごく一般的です。すみません。半導体のデータ収集ではシフトはごく一般的です。これらのテストをスクロールしていくと、多くのペンで同じテストを行っていることがわかります。その結果、相関性の高いパラメーターが多数得られます。このままスクロールしていくと、これらのテストの多くは互いに非常によく似ています。少し下にスクロールして、見た目が異なる可能性のある他のテストを見てみると、データの見た目が異なるテストもあります。テストの中には、温度に対する応答が異なるものもあります。
例を挙げましょう。測定値の中には、かなり極端な外れ値を持つものがあります。半導体では、デバイスに欠陥があり故障すると、大きな故障につながることは珍しくありません。外れ値への対応は、私たちのプロセスにおいて絶対に必要なことです。温度の影響で測定値に変化が生じていることがわかります。繰り返しになりますが、データは列ごとにグループ化されているため、JMPのグループ化機能を使ってこれを処理する必要があります。
シリアル番号の分布をざっと見てみると、このデータセットには65個の異なる一意のシリアル番号エントリがあることがわかります。このサンプルデータセットには65個のシリアル番号があります。これでデータの調査は完了です。何を見ているのか、ある程度分かってきました。次に、データ内のタイプミスの特定に役立つことが確認できたプロセスを実行してみましょう。
最初のステップは、データの準備です。「外れ値探索」を使って外れ値を除去します。また、数式列を使って標準化Zスコアを計算します。そのためには、「分析」「スクリーニング」「外れ値探索」を使用します。300個の測定値すべてを取得し、温度別に分析を行います。
この分析では、分位範囲外れ値を使用することを考えています。このプレゼンテーション全体を通して注意点として、使用するすべてのプラットフォームでJMPのデフォルト設定を使用します。分位範囲外れ値はデフォルト設定のまま使用します。最後に、表内の外れ値を消去するために、「計算式列を作成」オプションを使用します。
設定はデフォルトのままにしておきます。部屋の設定に移ります。部屋についても同様に、数式列を作成します。暖房についても同様に、数式列を作成します。これで、テーブルにいくつかの数式列が生成されました。ここで少し整理すると、外れ値が削除された300個の新しいデータ列が作成されます。
次に、操作と温度をグループ化の基準として使用するように設定します。新しい数式列機能を使用するためですが、これを設定することで、外れ値パラメーター 300 個すべてについて温度別、操作別の統計が計算されるようにグループ化機能を取得したいと考えています。
外れ値を除去した300列すべてについて、新しい数式列の下にある「分布」の下にある「標準化」を右クリックすると、すべてのパラメータの標準化されたZスコアが計算されます。これで新しい列グループが作成されます。ここで少し整理すると、標準化されたデータが300列になります。
今行ったことを簡単に視覚的に確認するために、グラフビルダーを開いてテストE8を見てみましょう。以前は極端な外れ値があり、データが見えにくかったです。外れ値を除去した後はデータが見えましたが、異なる操作と異なる温度間で測定値に依然としてばらつきがありました。操作と温度で標準化した後、各分布の中心がゼロになり、標準偏差が1になりました。つまり、すべてのデータがほぼ±3の範囲に収まっているということです。
このスケールの位置が間違っていました。これで、これらの点は、その操作と温度において分布の上限に位置していたのか？それとも、その操作と温度において分布の下限に位置していたのか？それとも、その操作と温度において分布の中央に位置していたのか？といった疑問が湧いてきます。これがデータ準備のステップで行ったことです。
次に、これら300個のパラメータのうち、シリアル番号の予測に有効なものを特定します。そのために、予測因子スクリーニングを使用します。データから、互いに高い相関関係にあるパラメータが多数あることが分かっています。予測因子スクリーニングの結果、高い相関関係にあるパラメータがいくつか見つかるはずです。予測因子スクリーニングを行った後、クラスター変数を用いて、高い相関関係にあるパラメータの多くを取り除き、求めているテストの最も代表的なパラメータだけを残します。
そのために、スクリーニング、つまり予測変数スクリーニングを使用します。標準化された列をすべて入力し、シリアル番号を算出してもらいます。繰り返しますが、ここにいくつかのオプションがあります。このプレゼンテーションでは、デフォルト設定を使用しました。JMPはこのデータを処理し、デバイスのシリアル番号を最もよく表すパラメータを順位付けしたレポートを作成します。
ざっと見てみると、最初のパラメータが非常に良好で、その後もいくつか良好そうなパラメータが続いています。さらに下にスクロールしていくと、20個くらい経つと、新しいパラメータを追加してもあまりメリットがないように見えます。ここでは、データテーブルで既に選択された最適な20個のパラメータを選択します。次に、「クラスタリングの分析」で、クラスター変数を使用して、この20個のリストの中で相関の高い変数を特定します。
この20をY列に入れると、このレポートが得られます。ここでは、明るい赤と明るい青を探すのが一般的です。マス目を数えるゲームをします。1、2、3、4、5、6があるようです。この分析から、タイプミスチェックに使用できるパラメータが約6つ得られると予想しています。
先に進む前に、列の選択で何も選択されていないことを確認しておきます。そうすることで、このレポートで列を選択すると、その列も選択されます。このクラスタリングの下にあるクラスターサマリーを見ると、20個のパラメータすべてが取り込まれ、「これらを4つのグループに分け、各グループから最も代表的なものを表示できます」と表示されているようです。
それは素晴らしいですね。しかし、このプラットフォームは物事をクラスター化する傾向があることに気づきました。ここには、他の20個のパラメータのいずれとも相関関係がほとんどないパラメータが2つあります。それらは他のグループに追加されてしまっていますが、私はそうであってほしくありません。最も代表的なものを見るだけでなく、この列も確認して、パラメータがそのクラスターに含まれる場合、そのクラスター内で相関関係が良好であることを確認します。
下の方を見てみると、多くの値が1に非常に近いことがわかります。つまり、相関性が高いということです。しかし、この人物は0に非常に近いです。この人物は、自分が属するグループとの相関性が低く、次に近いクラスターとの相関性も低いです。どのクラスターとも相関性が低いのです。このパラメーターも考慮に入れておきたいと思います。さらに下の方を見てみると、グループとの相関性が低い人物がもう1人いるようです。この4つとこの2つを合わせると、図から予想していた6つになります。
これで、データテーブルから6つの列が選択されました。列を少し並べ替えて、グループ化を解除し、まとめてグループ化します。これで、手持ちのデータに基づいてシリアル番号を理解するための、私が「最良の予測因子」と呼んでいるもののリストが得られます。
これで重要なパラメータを特定できました。次は、シリアル番号の誤入力があるかどうかを判断するための分析を実際に行う準備が整いました。そのためには、階層的クラスタリング・プラットフォームを使用します。「クラスタリング分析」の「階層的クラスタリング」で、先ほど特定した6つの最適な予測変数を使用し、シリアル番号でラベル付けします。
他にもオプションがあります。私は全てJMPのデフォルト設定のままにしました。これで階層的クラスタリングのレポートが作成されます。ここでいくつか変更を加え、クラスターの色を設定して、異なるグループを少し見やすくしたいと思います。クラスターの数も制御できるようにしたいです。最初にデータを確認した際、このロットには65個の異なるシリアル番号がありました。この手順では、65個ではなく、ロットに含まれるデバイスの総数よりも少し少ない数に設定すると最も効果的であることがわかりました。この例では、65個ではなく、58個に設定します。
この分析を始めるために最後に必要なのは、データテーブルからデータフィルターを取得し、シリアル番号に設定します。これにより、例えばシリアル番号が1である行をすべて選択できるようになります。これを行うと、デンドログラムレポートで、シリアル番号1に関連するデータ行がすべて密集していることがわかります。すべて同じ色で、縦に並んでいます。
これは、ここで設定した6つのパラメータを用いて、クラスタリングアルゴリズムが成功したことを示しています。シリアル番号2もクラスタリングがうまくいっているように見えます。シリアル番号ごとにデータを見ていくと、これらのクラスタリングの精度がわかります。シリアル番号17に至ります。ほとんどのデータはここに収まっており、少なくとも1つのデータポイントはここに収まっているようです。
これらの点の間にはかなりの垂直距離があります。しかし、それらの間の垂直距離よりも重要なのは、これらの線に沿って線を引いて、見ている点を結んだ場合です。この線を引かなければならないように見えます。では、どれくらい右に見なければならなかったのかという疑問が生じます。このつながりを作るには、かなり右に見なければなりませんでした。右に見れば見るほど、これらのデータが実際にはこれらのデータと似ていない可能性が高くなります。
この樹形図の理解に基づくと、これらのデータはかなり異なっているように見えます。一見すると一見無関係に見えるこの点を拡大してみると、6つのパラメータに基づくと、テスト時に入力されたシリアル番号がほとんどの場合12であった例があるように見えます。ただし、電気テストデータに基づいてそのように見えるデバイスは、テスト時に入力されたシリアル番号が17だった1回を除いて、ほとんどの場合シリアル番号12でした。
これは部品のマークの読み間違いである可能性が高いです。フォントやマークのサイズによっては、2が7のように見える可能性が非常に高いようです。これは、データに誤字が現れる一般的な例の一つです。この方法で特定できました。はい、この方法を使用して、このデータセットの誤字を特定できました。
次に、シリアル番号18のデバイスで一致するすべてのポイントを選択します。ポイント間に少し距離があるようです。データを拡大して、同じゲームをプレイしてポイント間に線を引くと、そこを結べそうです。
では、どれくらい右に行かなければならなかったのかという疑問が生じます。実際には、それほど右に行く必要はありませんでした。このデータはすべて非常によく似ているようです。デバイス18とデバイス29はほぼ同じように見えるため、デバイス18のエントリが少し分離しているように見えます。これはタイプミスとは思えません。単に2つの部品がたまたま似ているだけのように思えます。これ以上調査する時間をかけるほどのものではありません。
シリアル番号をもう少し見ていきましょう。これらはよくまとまっていて、25に到達します。ここで分離が起こっているようです。ゲームをすると、かなり右に寄らなければならなかったようです。そのため、これらのデータはあまり似ていません。選択した1つのポイントを拡大してみましょう。さらに拡大してみましょう。テスト時にこのように見える部品は、ほとんどの場合、シリアル番号が26になりますが、25になった例が1つあります。
他の選択されたデータポイントを拡大すると、25は通常このように見えますが…26が入力されたインスタンスが1つあるようです。ここで選択されたデンドログラムに注目し、シリアル番号25と26の間を移動すると…これは、デバイス25と26の2つのデバイスが存在するインスタンスです。両方ともテストされていますが、デバイス25がテストされたときはシリアル番号26でテストされました。デバイス26がテストされたときは、入力されたシリアル番号は25でした。
これらについては、順序が乱れたか何かが原因で、テストデータにこのようなタイプミスが発生しました。これは、この方法論を用いて特定した別のタイプのタイプミスです。残りのシリアル番号についても引き続き調べることができます。もしこの手順を全て実行するのであれば、そうするでしょう。しかし、時間の関係で、今回はこれらだけを見ていきます。
プロセスとして、データを分析し、タイプミスがあるかどうかを調べるのに専門知識をあまり必要としない、シンプルな方法を見つけられるだろうかという疑問がありました。先ほど説明したプロセスは、実行しやすいプロセスを特定することにかなり成功したと感じています。これらのテストパラメータに関する専門知識はそれほどありませんが、それでもこのプロセスを実行し、少なくとも可能性のあるタイプミスの短いリストを作成し、それを専門家と議論することができました。
プロセスは非常にシンプルなので、経験豊富なエンジニアだけでなく、新人エンジニアにも使いこなせるという良い経験を得ています。JMPの組み込み機能をすべて使用し、デフォルトのパラメータもすべて使用しているため、自動化やスクリプト化が容易です。私たちの環境ではまさにそうでした。手動で行う必要はありませんが、エンジニア全員が今日ここで私が説明したプロセスを理解しています。
成功しました。洞察を得ることができました。テストデータ内のタイプミスを特定し、その洞察を用いて、体系的な「このタイプのタイプミスはよく起こる」という点を特定しました。原因は何でしょうか？これはかなり頻繁に起こります。原因は何でしょうか？プロセスシステムを改善することができました。トレーニングの改善にも役立ちました。また、テストオペレーターと議論し、私たちが目にしている点や抱えている問題についてフィードバックを提供するための非常に便利なツールとなっています。オペレーターがより多くの情報を得ることで、問題に常に注意を払い、変更点や改善を継続するためのアドバイスを提供できるようになります。そして、私たちの施設からより高品質な製品を継続的に生み出す方法も教えてくれます。
これが私たちが開発し、活用しているプロセスです。デバイスや製品を同じ条件、あるいはほぼ同じ条件で複数回テストした縦断的なデータをお持ちの場合は、これらの手法のいくつかが、データ内の潜在的な問題の特定にも役立つかもしれません。ご参加いただきありがとうございました。お役に立てていただければ幸いです。良い一日をお過ごしください。
