シリーズ全体を読む
この記事は、Quilterの物理法則に基づくレイアウト自動化を使い、NXP i.MX 8M Mini搭載コンピューターを再現した過程を詳しく紹介するシリーズの一部です。
「期日どおりに届けること以外に選択肢はありません…機能を削ることはしませんでした。とにかく動くようにしたのです。」 — Paul Robinson（AppleおよびAmazonのテスト・製造エンジニアリングリーダー）
30年以上にわたり、Paul Robinsonは、初期のApple製品からAmazonのFire Phoneに至るまで、世界で最も象徴的なハードウェアの一部を支える基盤づくりに携わってきました。しかし彼がキャリアについて語るとき、心に残るのはアーキテクチャやコードではありません。心構えです。粘り強さです。いつ踏みとどまり、いつ柔軟に折れるべきかを見極める技です。
精度が重要で、完璧さが絶えず動き続ける目標である業界において、Paulの経験は別の種類の教訓を教えてくれます。欠点のない製品を作る方法ではなく、製品を現実のものにする方法です。そして出荷する方法です。
これは、プレッシャーの下での出荷、失敗から学ぶこと、チームの中で信頼を築くこと、そしてエンジニアリングが機械そのものよりもその背後にいる人々に関わるものになったとき何が起こるのかについての考察です。
出荷以外に選択肢はない
ハードウェアエンジニアは、めったに率直に語られることのない真実とともに生きています。製品は工場を出なければならない、という真実です。期日は提案ではありません。ビジネスモデルやサプライチェーン、そしてすでに製品を待っている店頭の棚に組み込まれた制約なのです。
「期日どおりに届けること以外に選択肢はありません。そしてその製品が工場を出て、おかしなハードウェアの問題が起きなかったとき、誇りを感じたものです。」
Paulが語るのは、成功が社内の承認ではなく、ローンチ後の混乱がないことによって測られる世界です。システムが問題なく動き、テストログが退屈なほど平穏で、製品が出荷され、顧客がその裏にある眠れない夜に気づくことがない。それが成功でした。
この世界では、エンジニアは機能を削りませんでした。機能を動くようにしたのです。英雄的な働きは土壇場のハックにあったのではなく、何か月にもわたる静かな先読み、文書化、テストカバレッジ、そして不測の事態への備えにありました。本当の英雄的行為とは、目に見えないものなのです。
テストこそが製品であるとき
Paulの仕事の舞台はテストエンジニアリング、つまり機械をテストする機械が作られる、ハードウェア開発のバックエンドでした。しかし時が経つにつれ、テストそのものが製品となりました。検査対象のデバイスと同じくらい厳密かつ確実に機能しなければならないシステムです。
「製品を期日どおりに出すために、お金を犠牲にしました…すべてのユニットが、工場を出る前にテストされていました。」
開発初期には、テスト時間は通貨のようなものでした。時間をかけるほどカバレッジが広がります。しかし製品が成熟するにつれて、目標は確信を失うことなくスピードを上げることになりました。ラインでの1分は、より多くのオペレーター、より多くの装置、より多くのコストを意味しました。最高のテストシステムは、正確なだけではありませんでした。効率的で、保守しやすく、スケーラブルだったのです。
品質とスループットの間の領域で、Paulはそのバランスの形成に貢献しました。そして多くの場合、その秘訣は反復でした。テストシステムは、評価対象のハードウェアと歩調を合わせて進化しました。リスクと確信の間で繰り広げられる、静かな振り付けです。
人間関係こそがアーキテクチャ
エンジニアはしばしば、アーキテクチャをコードや回路の構造として捉えます。しかしPaulは、より無形で、より重要なものを指摘します。信頼のアーキテクチャです。
「私たちが最も緊密な関係を築いていたのは電気エンジニアたちでした…最初から彼らをテスト設計に巻き込むこと、それが私たちの成功の理由でした。」
最良の技術的成果は、多くの場合、早い段階での率直な対話にかかっています。ファームウェアエンジニアや電気エンジニアを早期にテストのループに引き込めば、後の高くつく再設計を避けられます。しかしそのためには、エンジニアが必ずしも訓練されていないもの、つまり人としての信頼が必要です。
Paulはテストを作っただけではありません。橋を架けたのです。彼は、曖昧な依頼ではなく、しっかりと練り上げた提案を持って同僚に接することを学びました。過重な仕事を抱え、懐疑的になっている相手の言葉で話す方法を理解していました。この世界での成功とは、すべてを知っていることではありません。誰を巻き込み、どうやって一緒に進んでもらうかを知っていることなのです。
Fire Phoneと、凝り固まった思考の危険性
Paulは数々の成功を出荷してきました。しかし同時に、よく知られた製品の失敗も経験しました。Amazon Fire Phoneです。彼はそれについて、正直に、そして苦労して得た明晰さをにじませながら語ります。
「ハードウェアは良かったのです。でもソフトウェアは惨憺たるものでした…使えるようにするためだけに、みんなAndroidをサイドロードしていました。」
Fire Phoneは技術的な失敗作ではありませんでした。設計思想の問題だったのです。Kindleのユーザーインターフェースの論理を、より滑らかで応答性の高いものが求められる領域に持ち込んでしまいました。読書でうまくいったものが、動的なインタラクションの文脈では失敗したのです。
「人は自分の設計に固執してしまいます…昨日うまくいったからといって、それが今日の解決策だとは限りません。」
PaulがFire Phoneを教訓として挙げるのは、エンジニアリングの拙さではなく、惰性に対する戒めとしてです。「実証済み」の設計も、誤った文脈に適用されれば負債になりうることを思い出させてくれます。優れたエンジニアリングには、過去の成功を考え直す勇気も含まれるのです。
マネジメントにおける失敗
Paulが語る中で最も弱さをさらけ出した話のひとつは、マネージャーになりたての頃のものです。チームメイトの不安定なコードに苛立った彼は、週末にそれを書き直しました。コードは動きました。しかし信頼は打ち砕かれました。
「彼はものすごく怒っていました。その関係を修復するのに何か月もかかりました。そもそも修復できたのかどうかもわかりません。」
技術職では、自分で問題を解決したくなるものです。しかしリーダーになると、「修正」が本当の修正になることはめったにありません。長期的な解決策は、たとえ最初は遅く、洗練されていなくても、他の人が最高の仕事をできるよう力をつけさせることにあります。Paulが学んだように、リーダーシップとは、自分がその場で一番賢い人間だと証明することではありません。その場にいる人々を信頼していると示すことなのです。
運は自分でつかむもの
Paulのキャリアには、初期のUAV通信システムからAppleの製造テストフレームワークまで、大きなチャンスが点在していました。しかし彼は、謙虚さと率直さのバランスをすぐに取ります。
「運は自分でつかまなければなりません…でも、そこには常に、適切な時に適切な場所にいるという要素があります。そして、そのチャンスに恵まれない人もいるのです。」
彼のアドバイスは、能力主義の神話に根ざしたものではありません。タイミングや機会へのアクセスといった目に見えない力を認めています。それでも彼は、懸命に働き、良い質問をし、問題ではなく解決策を持って臨むことが違いを生むと強調します。チャンスをコントロールすることはできませんが、チャンスが訪れたときに備えておくことはできます。
引き算としてのリーダーシップ
Paulが最後に語った考えのひとつは、マネジメントについての鋭い洞察です。
「マネージャーとして成功できるのは、チームが自分よりも優れている場合だけです。」
これはスローガンではありません。戦略です。Paulが率いた最高のチームは、彼が自分は代わりがきくと感じられるチームでした。彼のエゴは、自ら手がけることではなく、全体を指揮することにありました。目標は、個人の成果によって価値を証明することではなく、他の人々を通じて卓越性を広げることでした。
仕事をうまくこなしていれば、自分の指紋は消えていく。彼はそう示唆しています。
最後に
Paul Robinsonのキャリアは、派手な発明や世間からの評価の上に築かれたものではありません。ラボで、工場の現場で、深夜のメールや慎重に言葉を選んだ図の中で築かれたものです。テストフレームワークの冷徹な論理と、人と人との信頼という温かな挑戦の中で築かれたものです。
この種のエンジニアリングが見出しを飾ることはありません。しかし、他のすべてを機能させているのはこのエンジニアリングなのです。
ハードウェアを作っているなら、エレガンスや天才性だけを目指さないでください。信頼性を目指してください。明快さを目指してください。最も重要な局面で、何をすべきかを理解しているチーム以外に何の痕跡も残さない、そんなリーダーシップを目指してください。
ここまで読んでくださった方への挑戦です：今週、何かを試作してください。何かを作ってください。荒削りなバージョンを誰かに見せてください。たとえ完璧でなくても、製品を前に進める決断をしてください。完璧でないならなおさらです。
作業台に向かいましょう。対話を始めましょう。そして運が良ければ、Paulのような人々と一緒に働けるでしょう。本気で作ることを求めるだけで、プロセスをより良くしてくれる人々です。
Hardware Rich Developmentは、変化の速い世界で高い完全性を備えたハードウェアを作るとはどういうことかを探る、Quilter.aiのシリーズです。エンジニアリングチームを率いている方、あるいは組織で技術的な意思決定を推進している方で、知見を共有したい方は、ぜひご連絡ください。
私たちは、より良いハードウェア思考を中心としたコミュニティを築いています。
