ライアン・グレイ氏は、製品エンジニアリングおよびデザイン企業SGW Designworksの共同創業者兼CEOである。
製品開発に20年以上携わってきた経験から、最も困難な教訓は教科書やプロジェクト計画、事後分析から学ばれることはほとんどないと断言できる。むしろ、遅延、手戻り、疲弊したチーム、逃した機会を通じて、高い代償を払って学ぶものだ。
ハードウェア開発には、最も有能なチームでさえ謙虚にさせる力がある。以下の教訓は理論的なものではない。スタートアップ、既存企業、潤沢な資金を持つベンチャー企業を問わず、繰り返し見てきたパターンである。
ハードウェアは見た目以上に困難、経験豊富なチームでも
最も一貫して驚かされるのは、他業界出身の経験豊富なエンジニア、デザイナー、経営幹部が、物理的な製品を量産可能な状態にするために必要なことを過小評価する頻度の高さだ。
多くのリーダーは、ソフトウェア、サービス、デジタル製品のバックグラウンドを持ち、そこでは反復のコストが低く、可逆性が高い。ハードウェアは異なる。すべての決定が物理的な結果をもたらす。材料、公差、サプライチェーン、認証、工具、製造上の制約がすべて急速に積み重なる。初期段階では小さく見える選択が、数カ月後にコスト、スケジュール、信頼性に波及する可能性がある。
この複雑さを早期に尊重することは、悲観主義ではない。現実主義である。
ハッカー的思考の賞味期限
ハードウェア開発において、ハッカーやメーカーの思考には確実に居場所がある。初期の探索段階では、スピード、創造性、境界を押し広げることが有益だ。この段階は、チームが迅速に学び、前提に挑戦するのに役立つ。
間違いは、その思考を持続させてしまうことだ。
開発が進むにつれて、規律が即興に取って代わらなければならない。反復可能性、文書化、構成管理、リスク軽減が、巧妙さよりも重要になり始める。この移行に失敗したチームは、スケーリング、認証、製造に耐えられない脆弱な設計に終わることが多い。
モードを切り替えるタイミングを知ることは、リーダーシップスキルである。
プロトタイプは目的がある場合のみ価値がある
プロトタイプはしばしば進捗として扱われる。実際には、開発における最大のコスト浪費の1つに静かになり得る。
すべてのプロトタイプは、特定の質問に答えるために存在すべきだ。このアーキテクチャは機能するか？この熱戦略は持ちこたえるか？この組み立ては繰り返し構築できるか？プロトタイプが不確実性を減らさないなら、チームに何ももたらしていない。
規律あるチームは、プロトタイプを成果物ではなく実験として扱う。何がテストされているか、成功がどのように測定されるか、結果に基づいてどのような決定が下されるかを定義する。その規律がなければ、チームは棚いっぱいのプロトタイプと非常に少ない明確性で終わる。
固定スコープ、固定価格はR&Dに不適合
研究開発は本質的に発見に関するものだ。うまく行われれば、チームは当初隠されていた情報を明らかにする。新たなリスクが現れる。古い前提が崩れる。より良い道が現れる。
この現実は、固定スコープと固定価格の契約とはうまく整合しない。これらのモデルは、作業が事前に完全に理解されていることを前提としている。真の開発努力において、その前提はほとんど有効ではない。
ここで多くのプロジェクトが破綻する。その構造は、学習が結果を改善する場合でも、学習を妨げる。エンジニアリングは開発の一部だが、開発自体は柔軟性、判断力、適応を必要とする独自の規律である。
優れたエンジニアが自動的に優れた製品開発者になるわけではない
製品開発には、エンジニアリングスキルを適用する以上のものが必要だ。エンジニアリングはツールセットである。製品開発はオーケストレーションである。
優れた製品開発者は、システムと同様に人々を理解する。彼らは競合する優先事項をナビゲートし、早期に対立を表面化させ、不確実性の下でチームが決定を下すのを助ける。彼らは、線形の問題解決では不十分な時、問題の再定義が必要な時を認識する。
彼らはまた、困難な会話を避けるのではなく、それに向かって走る。ハードウェアにおける進捗は、技術的なブレークスルーよりも、チーム間の整合性と信頼に依存することが多い。
MVPは有用な概念だが、危険な用語
最小限の実行可能な製品という考え方には真の価値があり、リーン原則は確実にハードウェアに適用される。罠は、MVPと言うときに誰もが同じことを意味していると仮定することだ。
実際には、MVPは粗雑な概念実証から、限定的な機能を持つ量産可能な製品まで、何でも意味し得る。その定義が明示されなければ、チームは互いに話が通じず、異なる結果に最適化する。
明確性が重要だ。何が含まれるか？何が意図的に除外されるか？どのリスクが解消され、どれが延期されるか？共通理解がなければ、MVPは焦点ではなく混乱の源になる。
計画は官僚主義ではなく、レバレッジである
最後に、計画は開発努力を成功させるか失敗させるかを決定し得る。
早期に立ち止まってユーザー、ユースケース、最大のリスクについて整合することは、無駄な時間ではない。それは、チームが進捗のない動きの数カ月を避ける方法だ。その整合性がなければ、開発は前進ではなく活動になる。
当社では、これをフェーズ0と呼んでいる。開発作業を定義する重要な構成要素を明らかにし、調整するための規律ある作業体系である。それなしでは、リソースを浪費するリスクが高い。私が見てきたすべての成功したハードウェアプログラムは、この初期段階に意図的に投資していた。
それをスキップするコストは、ほぼ常に後で利子付きで支払われる。
結びの考え
ハードウェア開発は、謙虚さ、規律、明確な思考に報いる。上記の教訓は、迅速に学ばれることはほとんどなく、決して安価ではない。しかし、それらを内面化したチームは、強力な何かを獲得する。容赦のない媒体においてさえ、より少ない驚きでより速く動く能力である。
