Hardware Rich Development

日付

著者

Hardware Rich Development

設計レビューの先にある航空機システムエンジニアリング:人の相性と、良いエンジニアリングを支える静かな技

日付

初回公開日

August 4, 2025

シリーズ全体を読む

/ 6

この記事は、Quilterの物理法則に基づくレイアウト自動化を使い、NXP i.MX 8M Mini搭載コンピューターを再現した過程を詳しく紹介するシリーズの一部です。 

リーダーたちが、苦労しながら学んだ瞬間について語るのを聞くのが、私はいつも好きです。

劇的な話だからではありません。もっとも、キャロル・エリクソンの場合は、終盤になって発覚した試験の失敗によって、ある衛星プログラムが危うく崩壊しかけたのですが。私が耳を傾けたのは、彼女がそれをあまりにも淡々と語ったからです。「徹底した設計レビューをしていなかったのです」。それほど単純で、それほど避けられたはずで、それほど現実的な話です。

航空機システムエンジニアリングにおけるキャロル・エリクソンの40年間は、失敗を早期に見つけるのはツールではなく優れたレビューであることを示しています。

キャロルは40年近くをNorthrop Grummanで過ごしました。レビューといえば文書を手渡しで届け、設計承認が配達員とともに運ばれていた時代を覚えているほどの長さです。航空宇宙がアナログ基板や熱真空チャンバーの時代から、全面的なデジタル環境へと進化するのを見届けてきたほどの長さです。彼女がシステムの完全性について語るとき、それは理論ではありません。6か月前に誰かがマージンの問題を見落としたために、試験中にセンサーが割れたときのクリーンルームの緊張感を思い出しているのです。

そうした瞬間は、ずっと心に残ります。言葉にすることは少なくても、その後のあらゆるエンジニアリング判断を導く直感を形づくるのです。

早くシミュレーションし、頻繁に話す

キャロルがシミュレーションについて語るときの切迫感は、最近ハードウェアの世界のあちこちで耳にするものと同じでした。ツールは以前より良くなっています。試作の前に熱性能をモデル化でき、PCBのレイアウトすら始まる前にアンテナの挙動をシミュレーションできます。しかし彼女はすぐに、スピードを生むのはツールではないと指摘しました。文化なのです。

彼女のチームは、シミュレーションを使って反復を前倒しにしていました。ソフトウェア上で試験を実行し、アイデアを思いついたその日に設計変更の影響を理解できれば、何週間もの試行錯誤を省けます。ただしそれが機能するのは、人々がアイデアを共有し、進捗を頻繁にレビューし、早い段階で厳しい質問を投げかける習慣を持っている場合に限られます。

彼女は、それを可能にしたツールセットとしてAnsysを挙げました。しかし彼女が称賛していたのはソフトウェアそのものではありませんでした。それが支えるリズムだったのです。短いフィードバックループ。明確な因果関係。考えることとつくることが混ざり合うことを許される場所。

1930s wind tunnel used for the Empire State Building
1930年代にエンパイア・ステート・ビルのために設計された風洞。

思い込みがEMIを最大の問題にする

航空宇宙向けエレクトロニクスにとって、シミュレーションはフローの中の一工程にとどまりません。責任ある設計の骨格そのものです。

シミュレーションが明らかにするもの、特に電磁界ソルバーと組み合わせたときに明らかになるのは、信号の忠実度が物理的な経路に深く依存しているという事実です。層を移る信号は、その戻り電流も一緒に連れて行かなければなりません。隣接する基準プレーンがグランドから電源に変わり、レイアウトが戻り電流に連続した経路を提供できていなければ、電流は別のルートを探さざるを得ません。通常はデカップリングコンデンサや変位電流の経路を通ることになります。高周波の戻り電流は、信号導体に隣接するように振る舞います。基準プレーンの不連続や急な層の切り替えはこの電流を乱し、高周波ノイズ、共振、放射エミッションを引き起こします。これらは机上の現象ではありません。軌道上ではミッションを終わらせる故障なのです。

この迂回によってループ面積が大きくなります。ループが大きいほど、放出されるエネルギーも大きくなります。整然として見えるレイアウトが放射構造となり、モデル化なしには予測が難しいエミッションを生み出すことがあります。こうしたエミッションは、敏感なアナログ回路の誤動作や、重要なセンサー測定値への干渉を引き起こす可能性があります。

こうした見落としの影響は、航空宇宙の環境ではさらに大きくなります。複数のシステムが狭い筐体を共有し、放射エミッションは規格適合だけでなくミッションの性能にも影響するからです。エンジニアは層構成を後回しの事項としてではなく、電流の流れと電磁界の閉じ込めを管理するための主要なツールとして扱わなければなりません。

シミュレーション駆動の設計は、ハードウェアが存在する前に問題を明らかにするのに役立ちます。EMIの問題は、エンジニアが致命的な思い込みをしがちな領域です。「十分に良い」は、多くの場合そうではありません。層構成のわずかな違いでさえ、インピーダンスの不整合やスロットアンテナ効果をもたらします。特に高密度基板では、電磁界シミュレーションはリーダーレベルのリスク軽減のためのツールになります。

航空宇宙のハードウェアは故障と紙一重のマージンの上に成り立っています。シミュレーションが物理とシステム統合を反映するほど、それは単なる承認の一工程ではなく、主要な設計成果物になっていきます。

良いチームの「ケミストリー」

私たちの会話の中で、キャロルと私は、エンジニアリングの世界では十分に評価されていないある言葉の周りを何度も巡りました。それは「ケミストリー(相性)」です。

周期表の化学ではありません。人間同士のケミストリーです。分野と分野の間で交わされる静かなシグナル。熱設計のエンジニアとシステムインテグレーターがようやく腰を据えて話し、食い違いに気づき、それが現場に届く前に修正する瞬間。キャロルはこうした瞬間についてたびたび語りました。彼女はレビューを関門としての作業ではなく、思いがけない会話が生まれ、適切な目が適切なタイミングで適切な問題を捉える場として説明していました。

そうした人と人とのリズムは、プロセスチャートから生まれるものではありません。明確さ、定期的な接点、そして「良い状態とは何か」についての共通理解の上に築かれた文化から生まれるのです。彼女が毎日・毎週のスタンドアップや、誰でもいつでも発言してよいという慣行について語ったのは、フラットな組織図を信奉していたからではありません。疑問が欠陥になる前にそれを口にできるほど人々が安心できると何が起きるかを、実際に見てきたからです。

技術の言葉で語るリーダーシップ

キャロルのリーダーシップのスタイルは、スプレッドシートから管理するものではありませんでした。彼女は細部に深く関わり、さらに重要なことに、細部と細部の間を通訳していました。システム、ソフトウェア、調達について十分に理解していたため、部門を越えて信頼を持って話すことができたのです。そうした解釈の力こそが、少しずつしか進まないプロジェクトと、加速していくプログラムとを分ける境界線になることがよくあります。

彼女はデジタルトランスフォーメーションに情熱を持っていますが、その見方は人に根ざしています。華やかなツールや、全員を新しいプラットフォームに押し込むことが目的ではありません。チームに対して、自分たちの貢献がより大きな枠組みのどこに収まるのかを示すことなのです。調達、試験、設計、製造。いずれも異なるインセンティブ、プレッシャー、言葉を持つ動く部品です。彼女は、これらの部品が自然に揃うことはないと理解していました。人々を何度でも中心に引き戻すリーダーが必要なのです。

そうしたリーダーシップには深い満足感があります。もはや製品を直接つくっているわけではありません。良いエンジニアリングが実際に生まれる環境をつくっているのです。

Women Airforce Service Pilots (WASP)
女性の軍用機パイロットたち。

深いエンジニアリングリーダーシップがもたらす満足感

技術的な仕事をうまく率いることには、特別な喜びがあります。問題を解決するスリルだけではありません。自分ひとりでできた以上にうまく、ほかの人たちが問題を解決できるよう手助けする、静かな満足感が得られるのです。キャロルはまさにそうしたリーダーシップを体現しています。遠くから製品を押し進めているのではありません。チームが自信と配慮、そして共通理解を持って働けるよう形づくっているのです。

そのように率いるには忍耐が必要です。そして愛情も必要です。ツールを愛するだけでなく、トレードオフも愛さなければなりません。製品を愛するだけでなく、レビュー、スタンドアップ、メール、深夜のバグ洗い出しといった、人と人との奇妙なダンスも愛さなければなりません。明確さを愛さなければなりません。締め切りやバージョン管理、調達をめぐる議論の霧の中で、仕事を守ってくれるのは明確さだからです。

キャロルは、自分がその場で一番賢い人間になろうとしているとは一度も言いませんでした。代わりに彼女が語ったのは、賢い人たちが力を発揮できる場をつくることでした。

エンジニアリングとは解釈である

キャロルのキャリアが興味深いのは、製品を動かし続けたからだけではありません。同時に、組織も機能させ続けたからです。

現実には、ひとりで働くエンジニアはいません。どの分野も、隣の分野からは少しずつ誤って翻訳されています。ソフトウェアはタイムラインで動き、機械は容積で、熱は勾配で、システムは構造で動きます。そして誰かが翻訳、つまり解釈という仕事をしない限り、システムは持ちこたえられません。

キャロルはそれを自分の仕事にしました。感動的なスピーチによってではなく、厳密さによって。レビューによって。構造によって。通信系のエンジニアが、熱設計のリードが何を懸念しているかを確実に聞くようにすることで。試作の日程を確定する前に、なぜ調達の誰も部品調達のタイムラインを確認していないのかを問うことで。

彼女はこれを文化の言葉で抽象化しませんでした。エンジニアリングとして扱ったのです。故障モードがどこにあるかを見極め、プロセス、ツール、フィードバックで対処する。

そして、おそらくそれこそがエンジニアリングにおけるリーダーシップなのでしょう。ストーリーテリングでも、カリスマでもありません。制約の中での明確さ、それだけです。

システムが本当に意味するもの

多くの人は「システム」という言葉を聞くと、正式なチャートや依存関係ツリー、気が向けばSysMLの図などを思い浮かべます。しかしキャロルがこの言葉を使うとき、彼女が意味していたのはもっと地に足のついたものでした。

システムとは、BOMの更新へとつながる一連のメールです。熱ドリフトを起こしやすいコネクタについて、試験技術者が持っている文書化されていない知識です。6週間の遅れを防ぐ5分間の会話です。システムとは、技術的な部品と人間の習慣の総和です。そこにはテストベンチも廊下での雑談も、Jiraのチケットも、誰が何をレビューするかについての暗黙のルールも含まれます。

日々働くエンジニアにとって、システムとは仕事の進め方を形づくるすべてのものです。自分が渡り歩く文脈であり、自分が管理する引き継ぎであり、頼まれなくても黙って埋めている隙間なのです。

キャロルがシステムの改善について語るとき、それはこれらすべてを改善することを意味していました。フィードバックループを短くすること。役割を明確にすること。驚きを減らし、共通理解を増やすこと。彼女は仕事を単純化していたのではありません。複雑さがまとまりを保てるよう、つながりを強くしていたのです。

うまく設計するには、自分が属しているシステムを理解する必要があります。そしてうまく率いるには、その理解をほかの人たちのために広げる必要があります。

物語の中のエンジニア

キャロルの父親は月着陸船の開発に携わっていました。彼女は計算尺や製図台の話を聞いて育ちました。現在の彼女は、シミュレーションスイート、統合試験インフラ、リアルタイムのレビュープラットフォームにまたがるツールチェーンを横断して仕事をしています。それでも、何が最も大切かを振り返るとき、答えはいつも人です。会話です。異なる分野のエンジニアたちが、後で嫌な驚きを避けられるほど早く、明確に話し合うことです。

彼女の一番の思い出は、技術的な完璧さからではなく、ともに乗り越えた困難な瞬間から生まれています。その場に現れ、知識を共有し、ミッションを見失わないことで失敗から立ち直ったチーム。それこそが優れたエンジニアリングリーダーシップです。困難な部分を避けることではありません。その中を率いて進むことです。

彼女は現在、コンサルティング事業を立ち上げ、志と実行の整合性を高める必要がある企業に自らのアプローチを届けています。ブランディングに携わる友人にパンフレットの草稿を見せたところ、彼はワクワクする内容だけれど一言も理解できなかったと言いました。彼女は笑って言いました。「それなら、少し書き直しが必要みたいね」。

今もなお、彼女は解釈という技を磨き続けています。それこそが、彼女が今もエンジニアである証です。

結びに

短い会話の中で、キャロルは私に多くのことを教えてくれました。大げさな教訓という形ではなく、彼女が仕事を語るときの感触を通して。落ち着いていて、明確で、目的がある。静かでいられるほど深いところで営まれるエンジニアリングです。

私の心に残ったのは次のことです。

  • エンジニアリングは部品だけでなく、つながりの中に宿る。
  • 良いレビューは、良いツール以上の価値を生む。
  • コミュニケーションはソフトスキルではない。構造的な要素である。
  • 最良のリーダーシップは、卓越が当たり前になる環境を築く。

そして何よりも、システムは人なしには存在しません。機械をうまく動かしたいなら、ループの中にいる人間がどう考え、どう話し、どう協力するのかを理解したほうがよいのです。

キャロルはそれを理解しています。そしてそれは、彼女がつくるすべてのものに表れています。

プログラムを形づくっていて、その基盤を強くしたいと考えているなら、キャロルはぜひ相談すべき人物です。そして、このような物語、つまり優れたエンジニアリングの文化と技に惹かれるなら、ぜひ引き続きHardware Rich Developmentをフォローしてください。まだまだ続きます。

Quilterを実際に試す

Project Speedrunは、自律的なレイアウトの実際の姿と、Quilterが実現する時間短縮を示しました。次は、ご自身のハードウェアでお確かめください。

利用を始める

設計の検証

仕上げが完了したら、最後に確認するのはハードウェアが動作するかどうかです。電源投入時には電気的な不具合の多くが現れます。エンジニアにとって、緊張と期待が入り交じる瞬間です。

第4回に進む

設計の仕上げ

自律的なレイアウトにより、DRCを実施済みの完成した設計が得られます。仕上げは、製造に向けて最終調整するための短い精密な作業です。

第3回に進む

設計のコンパイル

設計の準備ができたら、次はQuilterに引き渡します。従来のワークフローでは、この段階でエンジニアとレイアウト担当者が設計意図を確認します。Quilterはこの打ち合わせを回路理解のプロセスに置き換えます。プロジェクトをアップロードし、制約条件がどう解釈されたかを確認して、ジョブを実行します。

第2回に進む