シリーズ全体を読む
この記事は、Quilterの物理法則に基づくレイアウト自動化を使い、NXP i.MX 8M Mini搭載コンピューターを再現した過程を詳しく紹介するシリーズの一部です。
テストエンジニアリングは、信頼性設計（DFR）と製造性設計（DFM）をつなぐ架け橋です。ハードウェアが最初の一回だけでなく、千回目でも動くかどうかを決める分野なのです。
世の中には2種類のエンジニアがいます。
一方は、派手なプロトタイプや概念実証をつくり、デモの観客を沸かせ、投資家に小切手を切らせるエンジニアです。
そしてもう一方は、それが千回目でも本当に動くことを確かめるエンジニアです。
Paul McDonaldは後者です。そして、彼のような人がいてくれることに心から感謝しています。
テストエンジニアが称賛されることはめったにありません。テストリグが15のインターフェースをエラーなく黙々と検証しても、誰も拍手はしません。Cessnaが認証マトリクスを通して自律飛行できるよう準備を整えても、TechCrunchの見出しにはなりません。
しかしPaulの世界では、そこにこそ本物のエンジニアリングがあるのです。
ハードウェアエンジニアのインタビューをメールで受け取る
ベン図の真ん中へようこそ
Paulに言わせれば、テストエンジニアリングはあらゆるものの真ん中にあります。設計と納品が出会い、ソフトウェアとハードウェアが出会い、洗練されたアイデアがスケジュールやツール、ダクトテープといった現実世界の厄介な制約と出会う場所です。
もちろん、これは私なりの言い換えです。Paul本人なら、トレーサビリティや製造準備、そして規格の活用の話だと言うでしょう。しかし同時に、テストシステムは多くの場合、製品と非常に高くつく故障との間に立ちはだかる最後の砦だとも言うはずです。
彼はかつて私にこう言いました。「テストエンジニアリングは、アイデアを現実のものにし、それで利益を上げるための入り口なんです。」
短い一文ですが、多くのことを物語っています。優れたテストエンジニアは、ただ測定をしているだけではありません。チームの他のメンバーが強いられたあらゆる妥協の上に橋を架けているのです。
片付いたデスクという神話
Paulは「純粋にデジタル」な流派のエンジニアではありません。学士号を2つ取得した後、ものをつくる方法を学びたくてコミュニティカレッジに入り直しました。CADの中だけでもなく、シミュレーションの中だけでもなく、工具を使い、自分の手でつくる方法をです。
そのことについて尋ねたとき、彼はこう答えました。「実際に作業をする人たちと同じように話を聞き、同じように訓練を受ける必要があったんです。」これは単なる謙虚さではありません。システム思考です。
彼の世界では、優れたテストシステムとは美しいUIを持つものではありません。インターンがケーブルを強く引っ張りすぎても壊れないものです。あるいは、スケジュールが変わり、半年前に別の前提で設計したブレイクアウトボックスで新しいDUTリビジョンをテストすることになっても、壊れないものです。
彼はあるとき、カスタムPCBを避け、きちんとラベル付けされたケーブル配線に徹するだけで、テストシステムの構築期間を丸1か月短縮できることに気づきました。「テストリグの回路基板のほとんどは不要なんです」と彼は言います。「DUTが変われば、新しい基板を待つしかなくなりますから。」
ケーブルは待ちません。差し替えればいいのです。そして飛行機は空を飛び続けます。
長く使え、スケールできる製品をつくる
本当に際立つ製品をつくりたいなら、長期にわたってどう機能するか、そしてどれだけ効率的に生産できるかの両方を考える必要があります。テストエンジニアリングは、信頼性設計（DFR）と製造性設計（DFM）を結びつける結合組織です。厳密で意図的なテストを通じてこそ、設計上の前提が検証され、潜在的な故障箇所が洗い出され、製造プロセスが微調整されます。強固なテスト戦略があれば、製品は性能を発揮するように設計されているだけでなく、現実の条件下で実際にそれを発揮できることが証明され、さらに生産ラインで効率的かつ安定して製造できることも確認できます。
信頼性設計（DFR）とは、製品がライフサイクル全体を通じて問題なく動作することを保証するためのものです。単に発売されるだけの製品と、長く使い続けられる製品との違いはここにあります。エンジニアは、故障モード影響解析（FMEA）、高加速寿命試験（HALT）、統計モデリングなどのツールを使い、故障を事前に予測して防ぎます。DFRとは、材料、熱ストレス、耐久性、さらには製品が直面しうる想定外の条件まで、あらゆる変数を考慮することです。そうすることで、顧客は性能について一切心配せずに済みます。
製造性設計（DFM）は、この方程式の実践的な側面です。品質を損なうことなく、効率的かつ大規模に製造できる製品を設計することです。製造上の制約を早い段階で考慮することで、チームは組立を簡素化し、部品点数を減らし、高くつく再設計を避けられます。DFMがあるからこそ、企業はコストのかかるボトルネックにはまることなく、プロトタイプから量産へと進めるのです。
DFRとDFMを組み合わせれば、信頼性が高いだけでなく、現実の製造にも最適化された製品が生まれます。この整合によって品質が向上し、生産コストが下がり、市場投入までの時間が短縮されます。
自動車、航空宇宙、民生用電子機器といった業界の企業にとって、この組み合わせはもはや選択肢ではありません。顧客の信頼を築き、競争力を保つための前提条件です。勝ち残るのは、信頼性と製造性を初日から設計原則として扱うチームです。
ソフトウェアは素晴らしい、でも……
Paulはソフトウェアプラットフォームに対して愛憎入り混じった感情を抱いています。過去にとらわれているからではありません。むしろその逆で、彼は自動化スタック全体を構築し、エアギャップされたテストシステムを分散環境に統合する手助けもしてきました。
しかし同時に、誰かがアジャイルをペンキローラーのように見当違いの問題へ塗りたくったときに何が起こるかも見てきました。
「まだ構築されてもいないテストシステムに2週間のスプリントを割り当てることはできません」と彼はかつて語りました。「優先事項は6つもあって、ラックは自分で組み立てていて、ケーブルはまだできていないのに、それでも毎週デモをしろと言われたんです。」
彼はアジャイルに反対しているわけではありません。ただ現実を重視しているのです。そこには違いがあります。
静かな勝利と、サブアセンブリ単位で考えることの価値
Paulのアプローチにはどこか詩的なものがあります。彼はレイヤーで考え、モジュール性で考えます。ピンが壊れたりケーブルが見つからなかったりしても全体が止まってしまわないよう、何を再利用し、何を交換し、何を事前に在庫しておけるかを考えるのです。
こうした考え方は、たいてい教科書からは生まれません。フラストレーションから生まれます。深夜作業から生まれます。6フィートのハーネスが調達に間に合わなかったせいで生産ラインが止まっているのを目の当たりにした経験から生まれるのです。
そして、思いやりから生まれます。設計に対してだけでなく、それと付き合っていかなければならない人々に対する思いやりです。
Paulと話していると、彼がただシステムをつくっているのではないと感じます。他の人が苦労せずに済むシステムをつくっているのです。それは静かなリーダーシップであり、めったに見られないものです。
それこそが肝心なのかもしれません
私はイノベーションについて声高に語るエンジニアたちと多くの時間を過ごしてきました。Paulはそういう声の大きさを持つ人ではありません。あなたの大胆なアイデアが間違ったタイミングで爆発しないよう、静かに確かめてくれるタイプのエンジニアです。
前のシフトのテストログを確認しながら、インターンにコネクタの圧着方法を教えるようなエンジニアです。
数多くの誤った前提を目にし、事後に責任をなすりつけるのではなく、それを回避する設計の仕方を身につけてきたエンジニアです。
より堅牢なハードウェアを求めるなら、テストを後回しにするのをやめなければなりません。もっと多くのPaul McDonaldが必要です。最初から正しく仕上げることは華やかではないけれど、それこそがすべてだと理解している、静かな推進者がもっと必要なのです。
Hardware Rich Developmentは、変化の速い世界で高い完全性を備えたハードウェアをつくるとはどういうことかを探る、Quilter.aiのシリーズです。エンジニアリングチームを率いている方、あるいは組織で技術的な意思決定を担っている方で、ご自身の知見を共有したい方は、ぜひご連絡ください。
私たちは、より良いハードウェア思考をめぐるコミュニティを築いています。
