Hardware Rich Development

日付

著者

Hardware Rich Development

技術リーダーとは何か? デリック・クーパーの答え

日付

初回公開日

August 20, 2025

著者

レビュー担当者

シリーズ全体を読む

/ 6

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

リーダーの仕事は、その場で一番賢い人間でいることではありません。ほかの人が声を上げ、成長し、一歩踏み出せるよう手助けすることです。それには弱さをさらけ出す勇気が要ります。心の安定も要ります。しかしそれこそがリーダーシップの最も重要な部分です。誰かが活躍できる場をつくることなのです。 — デリック・クーパー

私が駆け出しだった頃、壊れた連携部分に一日中かかりきりになっていた私を、あるメンターが呼び止めたことがあります。私は遅くまで残り、すべての部分を自分で掌握しようとしていました。彼は身を乗り出してこう言いました。「君が離れた途端に崩れるなら、それは正しくつくれていないということだ」。

その言葉が本当に腹に落ちるまでには何年もかかりました。良いシステムは、自分が抱え込むためにつくるものではありません。ほかの誰かが運用できるように、そして自分が別の何かをつくれるようにするためにつくるのです。どんな人も、ひとりでシステムを100%の時間操縦し続けることはできません。自分にとってもチームにとっても機能するシステムをつくることが不可欠なのです。 

その記憶がよみがえったのは、デリック・クーパーとの会話の中でした。彼は人生をかけてシステムについて考えてきた人物です。技術的なシステムだけでなく、人間のシステムについても。

潜水艦やCFDから、プロダクトリーダーシップやコーチングまで、デリックのキャリアは静かながら一貫した弧を描いてきました。システムを学び、システムを改善し、そして身を引く。

Derrek Cooper.
デリック・クーパー。

まずは潜水艦から

圧力と不安に満ちた、小さな金属の筒の中から始めましょう。

デリックが初めて本格的にシステムに浸かったのは海軍時代、潜水艦の中でした。周りは必ず動かなければならない機械ばかりです。彼は特に機械いじりが得意というわけではありませんでしたが、飽くなき好奇心を持っていました。そして、限られた酸素とたくさんのバルブに囲まれて海の底にいるときには、そちらのほうが重要な資質だったのです。

「周りはシステムだらけです」と彼は私に語りました。「それを理解していなければ、ほかの全員にとってのリスクになります。だから速く学ぶのです」

激しく聞こえるかもしれませんし、実際に激しいのですが、それはエンジニアリングリーダーシップにとって完璧な訓練の場でもあります。何かがシューッと鳴ったり、うなったり、赤く点滅したりしても潜水艦の中で冷静でいられるなら、おそらく製品のローンチでもチームを率いることができるでしょう。

それはまた、彼の最も揺るぎない洞察のひとつを教えてくれました。技術的なシステムは物語の半分にすぎない。残りの半分は? それを動かす人間です。

QuilterのHardware Rich Developmentへのアプローチに登録する。

流れの中に意味を見いだす

海軍を離れた後、デリックは機械工学を学び、数値流体力学(CFD)に惚れ込みました。方程式で気流や熱交換をモデル化し、数学を使って本来は目に見えないものを可視化できる、素晴らしいニッチな分野です。

ほとんどの人はCFDの教科書を手に取っても、そっと元に戻します。デリックはやり続けました。

「実際につくる前に、製品がどう振る舞うかを見られるという考えが大好きでした」と彼は言います。「それが、世界を理解するための枠組みを与えてくれたのです」

しかしシミュレーションから納品までのどこかで、デリックは少し気まずいことに気づきました。どのプロジェクトでも最も予測できない変数は、流体でも温度勾配でもなかったのです。

それは人でした。

その発見によって、彼の関心は内側へ、そして横へと向かいました。チームを、やがてチームのチームを管理するようになり、方程式では解けないパターンに気づき始めました。ボトルネックは必ずしも技術的なものではありませんでした。会議が新たな故障モードになりました。設計が機会を得る前に、コミュニケーションが壊れていたのです。

そこで彼は注意を払うようになりました。耳を傾け、質問するようになりました。そしてやがて、コーチングに軸足を移しました。

You've got to filter your priorities properly.
優先順位はきちんとふるいにかける必要があります。

図に描けないシステム

「エンジニアリングでは『ソフトスキル』という言葉が使われます」と彼は言いました。「でも私は、それがソフト(やわらかい)だとは思いません。ただ教えるのが難しいだけだと思うのです」

Autodeskで、デリックは優秀なチームが明確さを欠いたために行き詰まるのを目にしました。コミュニケーションは滞り、対立はくすぶり、燃え尽きが静かに忍び寄っていました。

「エンジニアは機械をデバッグする方法を知っています。でもチームをデバッグするとなると? それはまったく別のスキルセットです」

彼は1on1で違う質問をするようになりました。成果物についてではなく、エネルギーについて。何が彼らを消耗させるのか。何があれば自分がちゃんと見てもらえていると感じられるのか。自分はどんなリーダーになろうとしているのか。

彼が見いだしたことは一貫していました。ほとんどの人は称賛を求めていたのではありません。正直になること、ペースを落とすこと、手に負えないと認めることへの許可を求めていたのです。

より良い質問をし、場をつくるというこの転換が、やがて彼の仕事の核となりました。

ケーススタディ:身を引くことで率いる

あるとき、デリックは彼に頼りすぎるようになった部門横断チームを率いていました。決定はすべて彼の机を経由し、会議では皆が彼を待っていました。

「任せているつもりでしたが、そうではありませんでした。すべての最終段階が依然として私だったのです」

そこで彼は、シンプルで難しいことをしました。すべての質問に答えるのをやめたのです。間を置くことを増やしました。自分の見解を述べる前に、チームにどう思うかを尋ねました。

最初、皆は戸惑いました。やがて、自ら動き出しました。

「すぐにではありませんでした。でも、私が黙っているほど、彼らが主導し始めたのです。知識はずっと彼らの中にありました。ただ、それを自分のものにする余地が必要だったのです」

この経験が彼のリーダーシップ観を形づくりました。すべてを知っている必要はありません。ほかの人が活躍できる条件をつくり出すだけでいいのです。

燃え尽きは設計されている

燃え尽きについて尋ねると、デリックははっきりと答えました。それは必ずしも崩壊のようには見えない、と。ときにはそれは過剰に機能することのように見えるのです。

「すべての会議に出ていました。すべてのメールに返信していました。何にでもイエスと言っていました。自分は欠かせない存在だと言い聞かせていましたが、本当はペースを落とすのが怖かったのです」

やがて彼は、仕事が注意のほぼすべてを奪っている地点に行き着きました。家族、健康、創造性。ほかのすべてが縮んでいっていたのです。

その気づきは崩壊から生まれたのではありません。内省から生まれたのです。

「日記を書き始めました。長いものではありません。うまくいったこと、いかなかったこと、行き詰まりを感じたところを書き留めるだけです。それが、ただがむしゃらに前進するだけでは得られなかった洞察を与えてくれました」

これが転機でした。彼はペンシルベニア大学のポジティブ心理学の修士課程に入学しました。レジリエンス、楽観性、アイデンティティを学び、まず自分自身に、次にチームに応用しました。

そして今、コーチとして、ほかの人たちが同じことをできるよう手助けしています。

A cathode tube array for memory.
メモリ用の陰極線管アレイ。

私に任せてくれたメンター

会話の中で、私はキャリアの初期に任されたあるプロジェクトのことを考えていました。アーキテクチャは未完成で、ドキュメントは乏しく、スコープは刻一刻と変わっていました。私は承認を待って、リーダーに何度も確認していました。やがて彼は私に向き直ってこう言いました。「君ならできる。聞くのはやめて、自分のものにしなさい」。

その転換が、自分でも知らなかった自信を与えてくれました。

デリックは、自身のチームでも同じパターンがあったと語りました。「リーダーシップとは、コントロールを握り続けることではありません。いつ身を引くべきかを知ることです。自分の仕事をきちんとやっていれば、すべての決定にあなたが必要になることはありません」

成長途上のエンジニアにとって大きな違いを生むのは、こうしたさりげなく、任せるリーダーシップです。自分のアイデアや自分なりの仕事への姿勢を追求してよいという、適切な許可を与えてくれるメンターに出会ったとき、あなたはどんな人間だったでしょうか?

考えるための時間をつくる

デリックと私は、時間について長く話しました。どう使うか、どう取り戻すか、どうすれば緊急事項に食い尽くされずに済むか。

「以前は毎時間を埋めていました」と彼は言いました。「やがて、自分の最高の仕事は、自分が守った時間から生まれていると気づいたのです」

彼は今、毎週、議題のない時間をブロックしています。考え、書き、振り返るための時間です。成果物のためではなく、ただ明確さのために。

「いつも反応してばかりでは、明確に率いることはできません。自分の心を観察する余白が必要なのです」

これは生産性向上のテクニックではありませんでした。生き残るための戦術でした。あまりにも多くの方向に引っ張られがちな役割の中で、地に足をつけておくための方法だったのです。

人もまたシステムである

デリックの最も静かでありながら根本的な信念のひとつは、人間はエンジニアリングの例外ではないというものです。私たちはシステムなのです。複雑で、再帰的で、予測不能なのは確かですが、それでもシステムであることに変わりはありません。

この捉え直しが、すべてを変えます。

チームメイトが苦しんでいるとき、励ましの言葉で「やる気を出させる」だけでは不十分です。その人がどんな入力を受け取っているのか。どんなフィードバックループがあるのか。どんな制約の下で動いているのか。それを問うのです。思いやりを持ってデバッグするのです。

「会議で誰かが心を閉ざしているのを見たら、それは安心できていないからかもしれません」とデリックは言いました。「あるいは、そこで使われている言葉の話し方がわからないのかもしれません。それはシステムの問題です」

人間をシステムとして見るようになると、機械のように振る舞えないことを責めるのをやめるようになります。どこで信号が失われたのかを考え始めるのです。

そしてそれこそが、どんな製品ローンチやダッシュボードにも増して、本当のリーダーシップの姿なのです。

まとめ:つくる人とリーダーのための教訓

エンジニア、マネージャー、チームリーダーとして、担当範囲だけでなく明確さの面でも成長したいと考えているなら、デリックの物語から引き出したいくつかの教訓を紹介します。

1. その場で一番賢い人間である必要はない

あなたの仕事は、その場をより賢くすることです。それは、より良い質問をし、より長く耳を傾けることから始まります。

2. あなたなしでチームが回らないなら、システムは完成していない

本当のリーダーシップは持続可能性を生み出します。教え、任せ、そして一歩下がりましょう。

3. あなたは受信トレイではない

時間は取り戻すことのできない唯一の資産です。考えるための時間をブロックしましょう。重要な依存関係のように守りましょう。

4. 書くことは考えること

日記を書き、頭の中を書き出し、振り返りましょう。行き詰まったら、書き始めましょう。ノイズの下にある信号が見つかるはずです。

5. 燃え尽きは、いつも前触れがあるとは限らない

システムがクラッシュする前に、自分自身の状態を確認しましょう。ゆっくりであることは、壊れていることではありません。

結びに

デリック・クーパーは直線的な道を歩んだわけではありません。好奇心に従ったのです。そして彼が発見したのは、私たちの多くが学ぶのにあまりにも時間がかかることでした。コードであれ、気流であれ、人であれ、システムをつくるには明確さと余白の両方が必要だということです。

より良く率いたいなら、すべてを抱え込もうとするのをやめましょう。教え、信頼し、部屋から出ていきましょう。

それは、エンジニアにできる最も人間らしいことなのかもしれません。

複雑なシステムを完全に掌握していながら、同時に本当の意味で制御できているものなど何もないという事実に驚くほど落ち着いている人に出会えるのは、まれな幸運です。

デリック・クーパーはその資質を持っています。

彼は25年近くにわたり、CFDや潜水艦の機械からAutodeskでのプロダクトと戦略のリーダーシップに至るまで、静かに混沌としたエンジニアリングの生態系を渡り歩いてきました。しかし最近の彼は、最適化よりも耳を傾けることについて、スループットよりも気づきについて多く語ります。

そして驚くべきことに、それが実際にうまくいくのです。

彼はソフトウェアをつくり、チームを管理し、今では技術職の人々に、正気もカレンダーも失わずにより良く率いる方法をコーチしています。その過程で、私が何年も前に知っていればよかったと思うことを発見しました。すべてを自分でやる必要はない。実のところ、そうすべきではないのです。

Hardware Rich Development は、変化の速い世界で高い完全性を持つハードウェアをつくるとはどういうことかを探る、Quilter.aiのシリーズです。エンジニアリングチームを率いている方、組織の技術的な意思決定を担っている方で、知見を共有したい方はぜひご連絡ください。

私たちは、より良いハードウェア思考をめぐるコミュニティを築いています。

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

Quilterを実際に試す

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

利用を始める

設計の検証

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

第4回に進む

設計の仕上げ

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

第3回に進む

設計のコンパイル

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

第2回に進む