とにかく出荷せよ：Paul Robinsonのハードウェア遍歴に学ぶ、粘り強さ・テスト・チームの教訓

役職：

Apple 製造ソフトウェア&テスト担当ディレクター、Amazon ハードウェアテストリード 注力分野：製造テスト、製品デリバリー、チームマネジメント、設計のレジリエンス

主なポイント

• テスト時間はお金。工場でのテスト時間には1秒ごとにコストがかかります。賢いチームは、いつ投資し、いつ節約すべきかを学びます。
• 人間関係はエンジニアリングのツール。最高のテストシステムは、論理とコードだけでなく、信頼と人々の足並みをそろえることによって築かれました。
• リーダーシップとは支配ではない。優れたマネージャーは自分のチームを上回ろうとはしません。自分を上回るチームを築くのです。
• EQはかつてないほど重要。エンジニアリングにおいて変わらず存在するギャップは、技術力ではなく心の知能指数です。

ハードウェアエンジニアのインタビューをメールで受け取る

本当の勝負はバックエンドにある

Hardware Rich Developmentのホストとして、私は多くのハードウェアのベテランと話をします。その大半はプロセス志向で、非常に技術的で、極めて実利的です。しかし時折、十分に見て、十分に経験し、十分に振り返ってきたからこそ、稀有な明晰さで語れる人物に出会います。Paul Robinsonはそうした人物の一人です。

Paulは単なるテストエンジニアではありません。35年にわたるキャリアの大半を裏方で過ごし、製造ソフトウェアを書き、診断ツールを作り、ほとんどの人が目にすることはなくても誰もがその恩恵を受けるシステムを設計してきた彼は、実行力とはどういうものかを体現する生きた設計図です。そのキャリアには、Appleでの数十年、AmazonのLab126での勤務、そして製品を期日どおりに出荷するために中国やアイルランドと電話で過ごした数え切れない夜が含まれています。

そして引退したばかりの今、彼は妻とヨーロッパを旅し、これまで取れなかった休暇をようやく楽しんでいます。

以下は、単なる対談の要約ではありません。彼の経験が私に教えてくれたこと、そして次世代のハードウェアエンジニアやものづくりに携わる人々に伝えるべきことについての考察です。

偶然テストの道へ、好奇心とともに成長

Paulは、製造とテストの道を目指していたわけではありません。同世代の多くのエンジニアと同様に、好奇心に従った結果そこにたどり着きました。大学には建築を学ぶために入学しましたが、新任の教授に説得され、代わりにコンピュータ工学に挑戦することにしました。その方向転換により、彼は軍用ドローン向けの通信フレームワークを構築する初期の職に就きました。驚くべきことに、そのシステムは今も使われているかもしれません。

その後、Appleから声がかかりました。テストエンジニアリングの仕事です。

「テストエンジニアリングが何なのかさえよくわかっていませんでした」とPaulは言います。「でも、電気とソフトウェアの両方の経験があったので、うまく合ったのです。」

これはよく耳にする話です。最高の技術キャリアは、複数の分野についてちょうど必要なだけ知っている人々によって築かれます。そうした博識家的な傾向、つまり何でも少しずつ学ぼうとする意欲こそが、誰にも予測できない未来への最良の備えであることが多いのです。

後付けではなく、コミットメントとしてのテスト

テストに対するPaulの考え方は、Appleの文化によって形づくられました。Appleにおいて、テストは最後の形式的な手続きではありません。製品ライフサイクルの成否を分ける段階です。

「何があろうと出荷する。それが考え方でした」と彼は語ってくれました。「機能を削ることはしませんでした。とにかく動くようにしたのです。」

特に印象的なエピソードのひとつは、Apple Watchにまつわるものでした。新しいセンサーには、工場での正確な温度キャリブレーションが必要でした。最初のアプローチは失敗しました。最終的にPaulと彼のチームは、ウォッチをZiplocの袋に密封し、循環する氷水に浸すことでキャリブレーションを行いました。洗練されてはいませんでした。ばかげていました。それでも、うまくいったのです。

キャリアを通じて企業が技術的なストーリーを伝える手助けをしてきた者として、私はこの例が大好きです。エンジニアリングの本当の物語、つまり創意工夫が制約とぶつかり、チームが道を見つけ出す瞬間を捉えているからです。Paulの話は、そうした瞬間に満ちていました。センサーの転用からコストと精度のバランスに至るまで、テストは単なる検証ではないことが明らかでした。それは証明の場なのです。

テスト時間のコスト、スピード感の価値

「テスト時間はお金です。」

それはPaulの信条のひとつであり、私の心に深く響きました。工場では、1秒1秒が重要です。1分のテスト時間は、テスト装置、オペレーター、エネルギー、そしてスループットを意味します。それでも製品サイクルの初期段階では、製品が確実に動作することを確かめるためだけに、惜しみなくコストをかけます。

その後、ときには次の世代で最適化します。テスト時間を60秒から10秒に短縮するのです。利益率はそうやって生まれます。これは、私がこれまで見てきた戦略的負債の最良の例のひとつです。ローンチに必要なことをやり、効率化への投資はその後で行うのです。

対談の中で、私たちがいかに頻繁に最適化を進歩と取り違えているかに気づきました。しかしPaulは、本当の進歩とは、約束した時期に、意図したとおりに機能する製品を顧客に届けることなのだと気づかせてくれました。

リーダーシップとはエゴを手放すこと

インタビューの中で最も人間味あふれる瞬間のひとつは、Paulがマネージャーになりたての頃の話をしてくれたときでした。チームメンバーのバグだらけのコードに苛立った彼は、週末を使って自分で書き直しました。コードはより良く動きました。しかし、それは関係にひびを入れることにもなりました。

「そのとき学んだことがあります」と彼は言います。「マネージャーとしてのあなたの仕事は、最高のコーダーであることではありません。自分よりも優れたチームを築くことなのです。」

その言葉は私の心に残りました。これはマネジメント本からは得られない種類の洞察です。失敗し、誰かに惨めな思いをさせ、チームに信頼されなければ技術的な卓越性など何の意味もないと気づくことで、初めて得られるものです。

技術的な貢献者とチームリーダーの両方の立場で働いてきた者として、私はこの力学が何度も繰り返されるのを見てきました。エンジニアリングにおけるリーダーシップとは、支配することではありません。力を与えることです。あなたはヒーローではありません。乗数なのです。

優れたハードウェアが悪い製品と出会うとき

すべての話がハッピーエンドだったわけではありません。Paulは、AmazonのFire Phoneにも携わりました。堅実なハードウェアを持ちながら、ユーザー体験に深刻な欠陥を抱えた不運な製品です。

「うまくいかないことは、みんなわかっていました」と彼は言います。「使えるようにするためだけに、テスト用の電話にAndroidをサイドロードしていたくらいです。」

私は常々、最高の技術チームは製品そのものを見る力も備えていると考えてきました。内部構造だけではありません。部品表だけでもありません。体験全体です。Paulはそれをわかっていました。若手エンジニアを指導する際には、Fire Phoneを教訓として使うことさえありました。

「昨日うまくいったからといって、今日もうまくいくとは限りません。」

この原則は色あせることがありません。ツールにも、UXパターンにも、社内プロセスにも当てはまります。そしてこれこそが、維持する人とイノベーターを分ける知恵なのです。

AIについての遅い学びと、目を覚まさせてくれるツール

引退前の最後の1年、Paulは大規模言語モデルに抵抗を感じていました。上司は毎週アイデアを求めてきました。彼は反発しました。ところが、彼のチームのエンジニアの一人がLLMを工場データに適用し始め、それまで不可能だった洞察を明らかにしたのです。

「驚きでした。突然、データについて本当の意味での質問ができるようになったのです。」

転機となったのは、技術そのものではなく実演でした。仲間同士で腑に落ちた瞬間、あの連帯感です。

マーケターとして、私はこれを別の角度から見てきました。スライドで納得する人はいません。誰もが納得するのはインパクトです。実物を見せましょう。それが人の考えを変える方法です。

エンジニアに欠けているもの、そして常に欠けていたもの

キャリアの中で数々の技術的な複雑さに向き合ってきたにもかかわらず、Paulは最後に、多くのエンジニアリング組織にいまだに欠けているものについて、極めて人間的な診断を下しました。

「優秀なエンジニアが不足しているわけではありません。欠けているのはEQです。コミュニケーション。全体像を見ること。それが常にギャップだったのです。」

これは、最高のエンジニアリングリーダーたちから繰り返し聞く話です。それでも私たちは、いまだにそのための訓練をしていません。新しい言語やツールには注力しても、合意を形成し、対立を管理し、難しいことを平易な言葉で説明する能力には報いていないのです。

それこそが未来のエンジニアです。そして過去のエンジニアでもあります。際立っていた人々は、常に幅の広さを持っていました。

最後に：出荷をやり遂げた人の感謝

Paulのキャリアは、ハードウェアを出荷することだけではありませんでした。チームを築き、失敗を通じて成長し、働きすぎ、そしてついに人生の残りの部分に「イエス」と言えるようになることでもありました。

彼が最後に感謝を捧げたのは妻のGraceでした。彼が何年も電話に追われ、工場にこもり、コードに没頭している間、子どもたちを育ててくれた人です。

「私は家にいたことがありませんでした。いたとしても、心はそこにありませんでした。それでも彼女は私のそばにいてくれました。」

結局のところ、Paulの物語は完璧な弧を描くものではありません。きれいな成功物語でもありません。それはリアルで、雑然としていて、人間的です。だからこそ価値があるのです。

これこそ、私がHardware Rich Developmentで紹介したいエンジニアリングです。コード、人、そして結果がすべてぶつかり合うエンジニアリング。製品の背後にいる人々が、製品そのものと同じくらい素晴らしいエンジニアリングです。