ハードウェアチームの連携：優秀なエンジニア同士がなぜすれ違うのか

ハードウェアチームの連携は、口で言うのは簡単でも、実現するのは困難です。

ほとんどのエンジニアリング組織は、より良いコミュニケーションが必要だということをすでに理解しています。ハードウェア、ソフトウェア、システム、製造、そして経営層のすべてが足並みをそろえる必要があることも分かっています。ドキュメントが重要であることも、プロダクトチームと技術チームが逆方向に進んではいけないことも承知しています。それでもハードウェア開発の現場では、同じ不満が繰り返し浮上します。優秀な人材がいて、意図も正しく、本気で努力しているのに、それでもプロジェクトが漂流してしまうのです。締め切りは延び、優先順位はぼやけ、チームは同じ問題の異なるバージョンを解き始めます。

アンテナ設計、試験、性能解析、インテグレーション、そしてスタートアップでの実務にまたがる経験を持つRFワイヤレスシステムエンジニアのJacob Frekingは、この問題を理解するための有益な視点を示しています。彼の見方では、破綻の出発点は能力不足よりも、むしろ「成功」の定義が食い違っていることにある場合が多いといいます。エンジニアが優秀で、リーダーが真剣で、ステークホルダーが合理的であっても、全員がわずかに異なるものを最適化していれば、プログラムはやはり停滞します。

「そのプログラムのリーダー層が誰であれ、彼らと最終的なステークホルダーとの間にずれがあるように思えます。」

この一文は見た目以上に重い意味を持っています。Frekingは職場のコミュニケーションについてありきたりな不満を述べているのではありません。エンジニアリングにおける特定の失敗パターンを名指ししているのです。ステークホルダーは、速く、役に立ち、そこから学べる程度に十分な出来 のものを求めているかもしれません。一方、より古く硬直的なプログラムで経験を積んだリーダー層は、今も成功を「網羅的なドキュメント、最大限の厳密さ、そして最初から完璧に仕上げること」と定義しているかもしれません。どちらの立場にもそれなりの論理があります。問題が始まるのは、その両方が暗黙のまま、解決されずに同時に作用し続けるときです。

優秀なエンジニアでも、連携の取れていない組織をつくってしまう

Frekingのインタビューで最も価値のある点のひとつは、問題を単純な責任追及に矮小化しない姿勢です。彼はうまくいかないチームを怠惰だとも不真面目だとも表現しません。彼らは矛盾したシグナルを受け取っているのだと説明します。あるグループは素早く動くよう求められながら、同時に、より遅く保守的な環境向けに培われた習慣に沿ってマネジメントされているかもしれません。あるチームは反復が重要だと言われながら、実際には一発で完璧に仕上げることが本当の目標であるかのように評価されているかもしれません。こうした緊張はストレスを生むだけではありません。エンジニアリング上の無駄を生むのです。

「ステークホルダーは素早く仕上げてほしいのかもしれません……動くことは求めていますが、要件の大半を満たすものを素早く手に入れることのほうを重視しているのです。」

「どれだけ時間がかかっても正しく仕上げることに経験を積んできた、レガシープログラム出身のリーダー層を迎え入れれば、それが依然として彼らの目標になってしまうのです。」

そこから問題は下へと広がっていきます。ハードウェアエンジニア、ソフトウェアチーム、システム担当者は、それぞれ異なるインセンティブを通してプロジェクトを捉え始めます。レビューは意思決定の場というより、翻訳の場になっていきます。ドキュメントは増えても、明確さが同じように増すとは限りません。誰かが明らかに間違っているわけではありません。しかし、完全に足並みがそろっている人もいないのです。

Frekingのより大きな論点は、あまりにもありふれているがゆえに居心地の悪いものです。ハードウェアチームの連携が劇的な瞬間に崩れることはめったにありません。多くの場合、ペース、許容できるリスク、そして何をもって「完了」とするかについての、口に出されないずれを通じて少しずつ損なわれていきます。これは、より広いシステムエンジニアリングの現実とも一致します。NASAのシステムエンジニアリングのガイダンスは、システムエンジニアを、複雑なシステム全体にわたる技術・コスト・スケジュールの相互作用のバランスを取りながら、技術チームを指揮し、コミュニケーションを取り、監視し、調整する責任者として位置づけています。同じガイダンスの中でNASAは、システムアプローチではハードウェア、ソフトウェア、そしてヒューマンシステムインテグレーションを別々の関心事として扱うのではなく、統合しなければならないと強調しています。

連携はソフトな話ではない。技術的な話である。

多くの技術系の組織文化では、今でも連携を、エンジニアリングの側ではなくビジネスの「人の側」に属するものとして扱っています。Frekingのインタビューはその逆を指し示しています。彼は根っからの技術者という印象を与えますが、彼の最も明快な指摘のひとつは、実行力はチームが本当に同じ「重視すべきこと」を共有しているかどうかにかかっている、というものです。

「要するに、プロジェクトの依頼主が何を重視しているのかを読み解くことなんです。」

「それを明確に定義できていればいるほど、うまく実行できます。」

これはマネジメントの専門用語ではありません。設計上の制約です。あらゆるハードウェアプログラムは、電力、形状、製造性、コスト、スケジュールといった明示的な制約の中ですでに動いています。Frekingは、組織としての明確さも同じカテゴリーに属すると主張しているのです。チームが最適化しているのが学習スピードなのか、リスクの最小化なのか、ドキュメントの完全性なのか、純粋な性能なのかを把握していなければ、技術的な判断は分断され続けます。

彼自身のキャリアが、なぜ彼がこの問題をこれほど明確に見ているのかを説明してくれます。FrekingはRFの仕事を、「あらゆる種類の問題のいいとこ取り」ができ、システム設計の議論において「中心点」となり、組み込みチーム、ソフトウェアアルゴリズムの担当者、信号処理グループ、他のRFスペシャリストと話をする場だと語っています。そうした立場で働く人には、個々の領域の優秀さ以上のものが見えます。インターフェースの質が見えます。引き継ぎがどこで失敗するのかが見えます。チームが互いの声を聞かなくなる場所が見えるのです。

連携が試されるのは反復の場面である

チームの振る舞いに関するFrekingの最も鋭い言葉は、おそらく次のものでしょう。

「最初の一回では、必ず何かを学ぶことになります。そして、それを早く学べば学ぶほど、早く反復して正しい形にできるのです。」

この一文は、ハードウェアチームの連携について真剣に議論するなら、その中心に置かれるべきものです。反復について本当に合意しているチームは、より速く、よりすっきりとした判断を下せます。反復を口にしながら、内心では一発で完璧に仕上げることを基準に自分たちを評価しているチームは、自らの学習ループを締め付けてしまいがちです。

ハードウェアでは、この緊張がさらに悪化します。実際のシステムは高価で物理的であり、ソフトウェアよりも修正に時間がかかることが多いからです。そのため、最初のバージョンを過剰に守りたくなる誘惑が生まれます。成熟したチームはその逆を行います。最初のバージョンが持つ「学びの価値」を守るのです。Frekingは、すべてが最初から完璧に動くという幻想について、「そんなことは決してありません」とはっきり述べています。彼は厳密さを軽視しているのではありません。実行を損なう誤った前提を退けているのです。

インタビューの別の箇所での発言も、同じ考え方を裏付けています。設計の最適化について語る中で彼は、エンジニアはどこで「十分な出来」と判断して次のステップに進むべきかを知っておく必要があると述べています。ハードウェアが決して到達しない現実に向けて過剰に最適化することは、それ自体がひとつの誤りだからです。同じ論理はチームにも当てはまります。連携とは、完璧な組織図や欠点のないプロセスマップをつくることではありません。次の反復から何か有益なことを学べるだけの、共通の方向性をつくることなのです。

ハードウェアの連携はインターフェースで崩れる

部門横断的な連携は、実際のインターフェースに触れるまでは抽象的に聞こえます。しかし触れた途端、痛いほど具体的なものになります。

ハードウェアチームにはあるペースが必要で、ソフトウェアチームには別のペースが必要かもしれません。製造部門はあるカテゴリーのリスクを気にかけ、システムエンジニアリングは別のリスクを懸念しているかもしれません。FrekingとCodyは、ハードウェアチームとソフトウェアチームが異なるテンポや異なる開発目標で動いているケースを含め、部門間のずれというこのより広いパターンについて明示的に議論しています。Codyは、この問題がハードウェア関係者へのインタビューで絶えず話題に上ると指摘し、Frekingも、全員を正しい方向にそろえるには、優れたリーダーには技術的な基盤と、人がどう働くかについての理解の両方が必要だと同意しています。

「全員を正しい方向にそろえるには、ある程度の技術的な経験が必要です。でも本当に必要なのは、その方向が正しい方向だと全員を納得させられることなんです。」

この考え方は強調に値します。ハードウェアチームの連携は、カリスマ性だけでも、プロセスだけでも解決しません。純粋に対人的なリーダーシップだけでは不十分です。純粋に技術的なリーダーシップだけでも不十分です。Frekingが示しているのは、両者を兼ね備えた能力です。つまり、トレードオフが何を意味するのかを理解できるだけの技術的な理解と、今重要なトレードオフをチームが受け入れられるよう支援できるだけの人間への理解です。NASAのシステムエンジニアリングのガイダンスもこれと近い言葉で捉えており、システムエンジニアリングを、単一分野の視点ではなく広く横断的な視点から、組織・コスト・技術の相互作用のバランスを取る技術であり科学であると説明しています。

エンジニアリング教育はすでにこの方向を示している

この問題が繰り返し起こる理由のひとつは、多くのエンジニアが、協働における一貫性よりも技術的な卓越性のほうを目に見える形で重視するよう訓練されていることです。しかしエンジニアリング教育の基準は、高度な技術的業務にはその両方が必要であることをますます認識するようになっています。ABETの現行の認定基準では、エンジニアリングプログラムは「動的で競争の激しい環境」において「体系的な改善の追求」を育むことを目的としているとされています。

Freking自身の教育に関する考察は、この論点をさらに深めています。彼は、本当のエンジニアリング能力は学部レベルの基礎をはるかに超えるものであり、最も重要な学びの多くは、システム、制約、そして対人関係の現実が避けられなくなる実務の中で起こると主張しています。また、現役のエンジニアは正規の教育を人材形成の終わりとみなすのではなく、継続的に学び続ける必要があるからこそ、独学による道筋にも前向きです。

これらの見方を合わせると、有益な捉え直しが見えてきます。ハードウェアチームの連携は、職場における二次的な美徳ではありません。エンジニアとしての成熟の一部なのです。サブシステム間のインターフェースは理解していても、チーム間のインターフェースを理解していないエンジニアは、依然としてシステムの一部を見落としているのです。

より良いハードウェアチームの連携とはどのようなものか

Frekingは唯一の特効薬を提示しているわけではありません。そしてそのことが、彼の見方の信頼性をむしろ高めています。連携が難しいのは、真剣なプログラムにはどれも、スケジュール、予算、技術的な野心、ステークホルダーの期待、チームの力学といった競合する圧力が含まれているからです。Codyはインタビューの中で、技術リーダーには「使える四半期が5つ」あるかもしれない一方、予算部門は3つ、プロダクト部門は4つを望んでいる、とうまく表現しています。これに対するFrekingの答えは控えめながら示唆に富むものです。その時点で最善のものを選ぶ、というのです。

ハードウェアチームにとって、これはいくつかの実践的な真理を意味します。

抽象的な合意よりも、共有された優先順位のほうが重要です。チームがすべてのトレードオフを気に入る必要はありません。しかし、現在のフェーズを支配しているのがどのトレードオフなのかは理解しておく必要があります。

反復は守られなければなりません。一発で完璧に仕上げることが隠れた基準になると、学習スピードは崩れ落ちます。

インターフェースの責任の所在を曖昧なままにしておくことはできません。ハードウェア、ソフトウェア、システム、経営層の間をつなぐ翻訳層には、誰かが責任を持つ必要があります。

技術的なリーダーシップは、理解できるものでなければなりません。エンジニアは、権限だけでなくその背後にある理由が見えるときに、より進んで判断に従います。

Frekingの話に説得力があるのは、彼が決して実際のエンジニアリングの世界から離れないからです。彼は連携を自己啓発的な言葉に変えることはしません。あくまで実行と結びつけて語り続けます。

Hardware Rich Developmentにとってこれが重要な理由

Frekingのインタビューは、エンジニアリングを物理的なものであると同時に社会的なものとして扱っているため、Hardware Rich Developmentの文脈にしっくりと収まります。ハードウェアは、形状、材料、公差、測定値、電力バジェットでできています。同時に、引き継ぎ、前提、役割の境界、そしてプレッシャーの中でものをつくろうとする人々の間のコミュニケーションの質でもできています。彼の視点が貴重なのは、これらの現実が別々のものではないと理解している点です。それらは同じシステムの一部なのです。

多くのチームが苦しんでいるのは、知性の不足ではありません。口に出されない最適化関数があまりにも多く同時に走っていることに苦しんでいるのです。Frekingはそれを明快に言い当てています。彼はこの問題に技術的な形を与えています。さらに良いことに、本当の解決策を示しています。重視すべきことを定義し、それを軸に足並みをそろえ、そして反復にその役割を果たさせることです。

‍

‍