最初のデザインエンジニア採用 – Gym Class でゲームを構築する（YC W22）

最初のデザインエンジニア採用の運用化

Y Combinator W22企業であるGym Classは、物理空間向けのインタラクティブゲームを開発しており、シニアデザインエンジニアを募集しています。この採用は、プロトタイプ駆動型開発から本番規模の運用へと移行する初期段階のゲームスタジオにとって、重要な組織的転換点を示しています。このポジションはその機能によって定義されます。創造的な仕様と技術的実装のギャップを埋めることです。これは通常、ゲーム開発のスケーリング段階における速度を制限する構造的制約です。

このポジションは、Gym Classが特定のボトルネックを特定したことを示しています。すなわち、デザイン反復速度とエンジニアリング能力の分離です。これは一般的なソフトウェアエンジニアリング採用ではありません。インタラクション忠実度、ユーザーフィードバックループ、創造的意図などのデザイン制約と、プラットフォーム制限、ネットワーク条件、パフォーマンス予算などの実装現実の両方に対する実証済みの流暢性が必要です。最初のデザインエンジニアは、技術的実現可能性評価がどのように行われるか、デザイン検証が開発ワークフローにどのように統合されるか、そして学際的コミュニケーションがどのように構造化されるかについての先例を確立します。

システム構造とボトルネック

• 構造的制約：* 初期段階のゲームスタジオは、デザイン反復の頻度がエンジニアリングの実現可能性検証とプロトタイプソリューション能力を超える場合、重大な速度ボトルネックに直面します。

• メカニズム：* Gym Classは物理空間環境で動作し、ゲームは異種ハードウェア構成、可変ネットワーク条件、予測不可能なユーザー行動全体で確実に実行される必要があります。この制約領域は、ウェブやモバイル開発とは本質的に異なります。デザインコンセプトは、従来のエンジニアリングレビュー周期を通じて技術的実現可能性を評価するよりも速く生成できます。組み込みのデザイン・エンジニアリング協力がなければ、これは順序付きキューを作成します。デザインコンセプトが蓄積され、技術的実現可能性評価を待ち（通常1～3週間）、その後、エンジニアリング段階ではなくデザイン段階で実装制約が明らかになると、リワークが必要になります。

• 説明的事例：* デザイン提案を考えてください。体育館環境で20人の同時プレイヤー間のリアルタイムマルチプレイヤー同期です。従来のエンジニアリングレビューは以下を生成します。「技術的に実現可能ですが、アーキテクチャの変更が必要です。」デザインプロセスに組み込まれたデザインエンジニアは以下を生成します。「150msのレイテンシ予算内でクライアント側予測を使用して実現可能です。トレードオフ：100ms未満の応答性は達成できません。安定性とスケーラビリティが優先されます。プロトタイプ検証：48時間。」2番目の応答は決定周期を1桁圧縮し、制約発見を後期段階（エンジニアリング後）から初期段階（デザイン段階）にシフトさせます。

• 運用上の含意：* 明示的な権限境界を持つデザインエンジニアロールを定義します。技術的実現可能性主張に対する拒否権を持ちますが、創造的方向性に対してはそうではありません。週次のデザイン・エンジニアリング同期会議（最大90分）を確立し、デザインコンセプトが迅速な実現可能性評価を受けます。デザインエンジニアの時間の20%をプロトタイプ検証ビルド（本番以外のコード）に割り当て、検証されていないデザインコンセプトの蓄積を防ぎます。

• 図2：従来型開発フロー vs デザインエンジニア統合フロー - ボトルネック箇所の比較*

参照アーキテクチャとガードレール

• 前提条件：* デザインエンジニアは、ロール開始前に文書化された明示的な技術制約とアーキテクチャ決定が必要です。

• 根拠：* 文書化されたガードレールがなければ、デザインエンジニアは決定ボトルネックになるか（すべてのアーキテクチャ選択に彼らの入力が必要）、コードベースを複数の実装パターン全体に断片化する矛盾した選択を行います。Gym Classのマルチプラットフォーム、ネットワーク依存環境はこのリスクを増幅させます。明示的なアーキテクチャ境界により、デザインエンジニアは基礎的なアーキテクチャの質問を繰り返し解決するのではなく、既知の技術制約内で創造的な問題を解決できます。

• 具体的な仕様：* アーキテクチャ決定を技術チャーターとして文書化します。例のエントリ：「すべてのネットワークゲーム状態は強い一貫性ではなく、結果整合性セマンティクスを使用します。ネットワークレイテンシ上限：200ms。物理シミュレーション：60Hzクライアント側、500msごとのサーバー調整。ターゲット同時プレイヤー数/インスタンス：32。プレイヤーあたりのメモリ予算：2MB。」これらの制約は、アーキテクチャ議論の約80%を排除し、定義された境界内での創造的問題解決に向けてデザインエンジニアの努力をリダイレクトします。

• 運用上の含意：* 採用前に、ターゲットプラットフォームとハードウェア構成、ネットワークレイテンシ予算、スケール仮定（同時プレイヤー数、データスループット要件）、およびパフォーマンスフロア（フレームレート、プレイヤーあたりのメモリ、起動時間）を指定する1ページの技術チャーターを作成します。候補者面接中にこのチャーターを使用して、制約を後で回避する障害物として扱うのではなく、制約内で効果的に動作する候補者を特定します。このフィルタリングステップはロール成功に重要です。

• 図4：デザインエンジニアの責任領域マップ*

• 図5：リアルタイムマルチプレイヤー同期アーキテクチャ（150msレイテンシ予算）*

実装と運用パターン

デザインエンジニアは、単にコードを書くのではなく、デザインツールと本番システム間のブリッジを所有する必要があります。ゲームスタジオはしばしば別々のデザインとエンジニアリングワークフローに分裂します。デザイナーは1つのツールを使用し、エンジニアは別のツールを使用します。変更は正常に伝播しません。デザインエンジニアは共有ワークフローを確立することでこれを防ぎます。デザイン時検証、デザイン仮定の自動テスト、および明確なハンドオフプロトコルです。

ゲームデザイナーがビジュアルエディターでインタラクションを作成し、デザインエンジニアがデザインを技術制約に対して検証するコンパイラを作成するパターンを実装します。その後、エンジニアリングに到達する前に。デザイナーが200msのレイテンシ予算に違反するネットワーク呼び出しを指定する場合、ツールはそれを即座にフラグします。このフィードバックをコードレビュー（遅すぎる）からデザイン時（重要な場合）にシフトさせます。

• 最初の2週間を機能の出荷ではなく、開発ワークフローの確立に割り当てます。* デザインエンジニアが主任デザイナーと毎日ペアを組み、現在の問題点を理解させます。共有デザインツール統合またはカスタム検証レイヤーを作成します。成功を測定するには、コードレビュー後ではなく、コードレビュー前に発生するデザイン反復の数を追跡します。

• 図7：デザインエンジニアの意思決定フレームワーク*

測定と成功指標

デザインエンジニアの影響は、出荷されたコード行ではなく、反復速度と欠陥防止によって測定されるべきです。従来のエンジニアリング指標（コミット、出荷された機能）はデザインエンジニアの価値と一致しません。彼らはデザイン探索を加速し、早期段階での不整合をキャッチする必要があります。重要なことを測定します。反復速度、早期段階の問題検出、および機能の安定性です。

• これらの指標を追跡します：*
• デザインコンセプトからプレイ可能なプロトタイプまでの平均時間（目標：48時間以下）
• 実装後のリワークが必要なデザインレビューの割合（目標：10%未満）
• デザインエンジニアが触れた機能の安定性までの平均時間（目標：ベースラインより2倍高速）

これらの指標は、採用が実際にギャップを埋めているかどうかを明らかにします。

• デザインエンジニアロールの四半期OKRを設定します：*
• デザインからプロトタイプへの周期時間を50%削減
• 本番リリースでのデザイン段階のサプライズをゼロに確立
• 3つ以上の一般的なインタラクションタイプの再利用可能なパターンライブラリを作成

これらを毎月レビューします。90日以内に速度が改善されていない場合、採用は実際のボトルネックと一致していない可能性があります。スコープまたはロール定義を調整します。

リスクと緩和戦略

統合パターンが明示的でない場合、デザインエンジニアは孤立した専門家になる可能性があります。このロールは規律の間に位置します。明確な所有権がなければ、デザインエンジニアは知識を独占するか（ボトルネックになる）、純粋な実装作業に追いやられるか（デザインレバレッジを失う）のいずれかです。どちらの結果も採用を無駄にします。

レンダリングコードの80%を書くことに費やしているデザインエンジニアは、デザインとエンジニアリングを橋渡ししていません。彼らは単なる別のエンジニアです。すべてのデザイン決定をレビューするが、コードを出荷しないデザインエンジニアは、エンジニアリングの信頼性を失います。バランス：40%のデザイン協力と検証、40%のプロトタイプ/概念実証コード、20%の本番実装です。

• ロール定義に明示的な時間配分を確立します。* デザインエンジニアが各カテゴリーに費やした時間について報告する月次レビューを作成します。配分がドリフトする場合、リセットします。デザインエンジニアに「デザインパートナー」（シニアデザイナー）と「エンジニアリングパートナー」（テックリード）を割り当て、孤立を防ぎます。これらのパートナーシップは明示的な同期時間と共有OKRを持つべきです。

• 図11：デザインエンジニア統合のための組織構造設計*

• 図10：デザインエンジニアの孤立化リスク（組織内ポジショニング）*

統合と移行計画

最初のデザインエンジニア採用は、ヘッドカウント追加ではなく構造的変化として扱われるときに成功します。Gym Classはデザインとエンジニアリングがどのように協力するかを再編成しています。これはプロセスの変更、ツール採用、および文化シフトが必要です。単なる採用ではありません。意図的な移行がなければ、新しい採用は既存のワークフローに吸収され、効果がなくなります。

• 3ヶ月間の統合をフェーズします：*

• 1～2週目：* ワークフローとアーキテクチャガードレールを確立します。デザインエンジニアに現在の問題点を文書化し、プロセス改善を提案させます。

• 3～8週目：* 2～3のデザイン・エンジニアリングスプリントを実行して、新しいプロセスを検証します。反復速度とデザイン段階の問題検出を測定します。

• 3ヶ月目以降：* パターンをスケールし、四半期OKRに対する影響を測定します。このロールが決定方法を変更することをチームに明確に伝えます。純粋な追加ではなく、再編成です。初日前にデザインとエンジニアリングのリーダーから同意を得ます。

結論

Gym Classでの最初のデザインエンジニア採用は、デザイン思考を技術的意思決定に組み込み、コンセプトから検証されたプロトタイプへの反復速度を加速する機会を表しています。成功は3つの前提条件に依存します。（1）明示的な権限境界を持つ明確なロール定義、（2）文書化された技術制約とアーキテクチャガードレール、および（3）明示的なパートナーシップ構造を持つ既存ワークフローへの意図的な統合です。

出力量ではなく、反復速度と機能の安定性によって成功を測定します。ロールが純粋なエンジニアリングまたは純粋なデザインにドリフトする場合は調整します。90日以内に、アイデアがコンセプトから検証されたプロトタイプへどのくらい速く移動するか、デザイン段階の問題がエンジニアリング前にいくつキャッチされるか、および出荷された機能がどのくらい安定しているかについて、測定可能な改善が見えるはずです。

測定と成功基準

• 指標不整合リスク：* 従来のエンジニアリング指標（コミット、出荷された機能、コード行数）はデザインエンジニアの価値と一致しません。デザインエンジニアは出力量を最大化するのではなく、デザイン探索を加速し、早期段階での不整合をキャッチする必要があります。

• 適切な指標：* 反復速度と欠陥防止を通じてデザインエンジニアの影響を測定します。

• デザインからプロトタイプへの周期時間： デザインコンセプトからプレイ可能なプロトタイプまでの平均期間。目標：48時間以下。ベースライン：採用前に現在の状態を測定します。

• デザイン段階の問題検出： 実装後のリワークが必要なデザインレビューの割合。目標：10%未満。これはデザインエンジニアがエンジニアリング前に実現可能性の問題をどの程度効果的にキャッチするかを示します。

• 機能の安定性： デザインエンジニアが影響を与えた機能の安定性までの平均時間、採用前のベースラインと比較。目標：採用前のベースラインより2倍高速。

• 四半期目標（サンプル）：* デザインからプロトタイプへの周期時間を50%削減。本番リリースでのデザイン段階のサプライズをゼロに確立。3つ以上の一般的なインタラクションタイプの再利用可能なパターンライブラリを作成。これらの目標に対して毎月レビューします。90日以内に速度指標が改善を示さない場合、ロールは実際のボトルネックと一致していない可能性があります。スコープ、責任、またはロール定義を調整します。

統合リスクと緩和

• 孤立リスク：* 統合パターンが明示的でない場合、デザインエンジニアは孤立した専門家になる可能性があります。このロールは規律の間に位置します。明確な所有権とコミュニケーション構造がなければ、デザインエンジニアは専門知識を独占するか（ボトルネックになる）、純粋な実装作業に吸収されるか（デザインレバレッジを失う）のいずれかです。

• 配分パターン：* 明示的な時間配分を確立します。40%のデザイン協力と検証、40%のプロトタイプ/概念実証コード、20%の本番実装。このバランスは孤立と技術的信頼性の喪失の両方を防ぎます。デザインエンジニアが時間配分をカテゴリー別に報告する月次レビューを作成します。配分が大きくドリフトする場合、リセットします。

• パートナーシップ構造：* デザインエンジニアに2つの明示的なパートナーを割り当てます。「デザインパートナー」（シニアデザイナー）と「エンジニアリングパートナー」（テックリード）です。これらのパートナーシップはスケジュール済みの同期時間と共有四半期目標を持つべきです。この構造は孤立を防ぎ、デザインエンジニアが両方の規律全体で信頼性を維持することを保証します。

実装タイムラインと移行計画

• 構造的変化、ヘッドカウント追加ではない：* 最初のデザインエンジニア採用は、単なるヘッドカウント追加ではなく、デザインとエンジニアリングがどのように協力するかの再編成として扱われるときに成功します。これはプロセスの変更、ツール採用、および文化シフトが必要です。

• 段階的統合：*

• 1～2週目： 開発ワークフローを確立し、技術制約を文書化し、検証インフラストラクチャを作成します。

• 3～8週目： 2～3のデザイン・エンジニアリングスプリントを実行して、新しいプロセスを検証し、速度改善を測定します。

• 3ヶ月目以降： 検証されたパターンをスケール、四半期目標に対する影響を測定、必要に応じてロールスコープを調整します。

• 組織的コミュニケーション：* このロールが決定方法を変更することをデザインとエンジニアリングチームに明確に伝えます。純粋な追加ではなく、再編成です。採用の初日前にデザインとエンジニアリングのリーダーから同意を確保します。明示的な組織的整合がなければ、新しいロールは既存のワークフローに吸収され、効果がなくなります。

測定と次のアクション

• 問題点：* デザインエンジニアの影響は、出荷されたコード行数ではなく、イテレーション速度と欠陥防止によって測定されるべきです。従来のエンジニアリング指標（コミット数、出荷された機能）はデザインエンジニアの価値と一致していません。

• 指標フレームワーク：*

指標	目標	測定方法	頻度
デザインからプロトタイプまでのサイクルタイム	48時間以内	プロジェクト管理ツール（Asana、Linear）で追跡	週次
デザインレビュー修正率	10%未満	エンジニアリング前に2回以上の修正が必要なデザイン数をカウント	隔週
機能の安定性（デザインエンジニア関与）	ベースラインの2倍高速	デザインエンジニアの入力がある/ない機能の平均安定化時間を比較	月次
プロトタイプから本番への変換率	60%以上	プロトタイプのうち出荷された機能の割合を追跡	四半期ごと
デザイン段階での問題検出	80%以上	コードレビュー対デザインレビューで検出された問題の割合	月次
チーム満足度	4/5以上	デザイナーとエンジニアのコラボレーション効果に関するアンケート	四半期ごと

• 具体例：*

ベースライン（採用前）：

• デザインからプロトタイプ：2～3週間
• デザインレビュー修正率：30%
• 機能の安定性：本番対応まで4週間
• デザイン段階での問題検出：20%

目標（採用後6ヶ月）：

• デザインからプロトタイプ：48時間以内

• デザインレビュー修正率：10%未満

• 機能の安定性：本番対応まで2週間

• デザイン段階での問題検出：80%以上

• 実行プレイブック：*

1. ベースライン指標の確立（第1週）：

   • 過去5つの出荷済み機能を監査
   • 測定：デザインからプロトタイプまでの時間、修正サイクル、安定化タイムライン
   • 共有スプレッドシートに記録
   • コスト：4時間（デザインエンジニア+テックリード）

2. 測定ダッシュボードの作成（第2週）：

   • ツール：スプレッドシート、Metabase、またはLooker
   • 自動化されたデータソース：Gitコミット、プロジェクト管理ツール、バグトラッカー
   • 手動データ：デザインレビューノート、プロトタイプタイムライン
   • 更新：週次
   • コスト：8時間（デザインエンジニア+アナリティクス）

3. 四半期OKRの設定（第1ヶ月）：

   • OKR 1：デザインからプロトタイプまでのサイクルタイムを50%削減（2～3週間から48時間以内に）
   • OKR 2：本番リリースでのデザイン段階のサプライズをゼロに確立（デザイン段階での問題検出80%以上）
   • OKR 3：3つ以上の一般的なインタラクションタイプ（マルチプレイヤー同期、物理演算、UI応答性）の再利用可能なパターンライブラリを作成
   • レビュー：月次、軌道から外れている場合は調整

4. 90日レビューの実施（第3ヶ月）：

   • 指標をベースラインと比較
   • 速度が30%以上改善した場合：役割は機能している、パターンをスケール
   • 速度が10～30%改善した場合：役割は部分的に機能している、スコープを調整
   • 速度が変わらない場合：役割がずれている可能性がある、調査してリセット

• コスト見積もり：* 12時間のセットアップ、週次2時間のメンテナンス。

• リスクフラグ：* 90日以内に指標が改善しない場合、問題は以下のいずれかの可能性があります：

1. デザインエンジニアが純粋な実装作業を行っている（デザインコラボレーションではない）
2. 技術的制約が緩すぎる（デザインエンジニアに影響力がない）
3. チームが新しいワークフローを使用していない（採用の問題ではなく、導入の問題）
4. ボトルネックが他の場所にある（例：デザイン容量、デザインからエンジニアリングへのハンドオフではない）

採用が間違いだったと結論付ける前に調査してください。

リスクと軽減戦略：孤立とドリフトの防止

• 主張：* 統合パターンが明確でない場合、デザインエンジニアは専門家として孤立する可能性があり、孤立は無関係性への最速の道である。

• 根拠：* このロールは複数の分野の間に位置している。明確な所有権がない場合、デザインエンジニアは知識を独占する（自分たち自身がボトルネックになる）か、純粋な実装作業に追いやられる（デザインレバレッジを失う）かのいずれかになる。どちらの結果も採用を無駄にし、このロールの人を不満にさせる。重要なのは意図的な統合である：明確な時間配分、明確なパートナーシップ、定期的な再調整である。

• 具体例：* 時間の80%をレンダリングコードの作成に費やしているデザインエンジニアは、デザインとエンジニアリングを橋渡ししていない。彼らは単なる別のエンジニアである。すべてのデザイン決定をレビューするが、コードを出荷しないデザインエンジニアは、エンジニアリングチームからの信頼を失う。バランスは以下の通りである：デザイン協力と検証に40%、プロトタイプ/概念実証コードに40%、本番実装に20%。この配分により、両方の分野とのつながりを保ちながら、両方で信頼性を維持できる。

• 実行可能な含意：* ロール定義に明確な時間配分を確立する。デザインエンジニアが各カテゴリーに費やした時間について報告する月次レビューを作成する。配分がドリフトする場合（例えば、本番環境の消火活動のためにデザイン協力が20%に低下する）、それをリセットする。デザインエンジニアに「デザインパートナー」（シニアデザイナー）と「エンジニアリングパートナー」（テックリード）を割り当てて、孤立を防ぐ。これらのパートナーシップは明確な同期時間（週1回、各30分）と共有OKRを持つべきである。デザインエンジニアがドリフトしている場合、パートナーはすぐにそれをフラグする必要がある。

• リスク：過度な専門化* デザインエンジニアがデザイン・エンジニアリング橋を理解する唯一の人になった場合、スタジオは彼らに依存するようになる。軽減方法：(1)すべてのパターンとワークフローを文書化する、(2)他のエンジニアにデザイン思考を指導する、(3)デザインエンジニアの責任をローテーションして、他の人がこのロールを学ぶようにする。

• リスク：スコープクリープ* デザインエンジニアは価値があるため、誰もが彼らの時間を望む。軽減方法：(1)20%のプロトタイプ予算を保護する、(2)コアOKRと一致しないリクエストに「ノー」と言う、(3)月次レビューを使用してスコープクリープを表面化させ、期待をリセットする。

• リスク：製品ビジョンとの不整合* デザインエンジニアの優先事項が製品戦略と一致しない場合、彼らは間違ったものを最適化する。軽減方法：(1)初日から製品計画に関与させる、(2)CEO/プロダクトリードが12ヶ月のビジョンを明確にする、(3)製品進化に基づいてOKRを四半期ごとに再調整する。

結論と移行計画：ヘッドカウント追加ではなく構造的変化

• 主張：* 最初のデザインエンジニア採用は、単なるヘッドカウント追加ではなく、組織がどのように運営するかの構造的変化として扱われるときに成功する。なぜなら、それはプロセスの変更、ツール導入、文化的シフトを必要とするからである。

• 根拠：* Gym Classはデザインとエンジニアリングがどのように協力するかを再編成している。これは軽微な調整ではなく、決定がどのように下されるか、アイデアがどのように検証されるか、チームがどのようにコミュニケーションを取るかの根本的なシフトである。意図的な移行がない場合、新しい採用者は既存のワークフローに吸収され、効果がなくなる。彼らは最初の6ヶ月間、物事がどのように機能するかを学ぶのに費やし、その後、それらを変更しようとするときに不満を感じるだろう。

• 実行可能な含意：* 統合を意図的にフェーズ化する：

• 週1-2：基礎*

• デザインエンジニアがすべてのチームメンバー（デザイナー、エンジニア、プロダクト、リーダーシップ）と会う

• 現在のワークフロー、ペインポイント、ボトルネックをマップする

• 技術チャーターとアーキテクチャ決定をレビューする

• 週次デザイン・エンジニアリング同期を確立する

• 開発環境とツールをセットアップする

• 週3-8：検証*

• 実際のゲームコンセプトで2～3回のデザイン・エンジニアリングスプリントを実行する

• 新しいワークフローを検証する：それは実際に反復を加速するか？

• フィードバックに基づいてワークフローを反復する

• パターンを文書化し、テンプレートを作成する

• ベースラインメトリクスを測定する（サイクルタイム、手直し率、安定性）

• 3ヶ月以降：スケール*

• すべての新しいゲームコンセプトにワークフローを適用する

• 他のエンジニアにデザイン思考を指導する

• デザインエンジニアをキャリアパスとして確立する

• ケーススタディとプレイブックを公開する

• 2番目のデザインエンジニア採用を計画する

• コミュニケーション計画：* このハイアが決定がどのように下されるかを変えることをチームに明確に伝える。それは純粋な追加ではなく、再編成である。初日前にデザインとエンジニアリングのリーダーから同意を得る。CEOがこのハイアが会社の将来にとってなぜ重要なのかを明確にする。ヘッドカウント追加ではなく、速度とイノベーションへの投資として枠付けする。

• 成功基準（90日レビュー）：*

• デザインからプロトタイプへのサイクルタイムが50%削減される

• 本番リリースでのデザイン段階の驚きがゼロ

• 3つ以上の再利用可能なインタラクションパターンが文書化される

• デザインエンジニアがデザイン協力に40%の時間を費やしている（純粋なエンジニアリングにドリフトしていない）

• チームフィードバック：「デザインエンジニアは私たちをより速く、より賢くしている」

これらの基準が満たされない場合、理由を診断する：ロールは実際のボトルネックと一致していないか？統合を妨げる組織的障壁があるか？デザインエンジニアは適切なフィットではないか？90日レビューを判断の機会ではなく、学習の機会として使用する。調整して反復する。

より長い視点：このハイアが重要な理由

Gym Classの最初のデザインエンジニアは、物理的空間ゲームがインタラクティブエンターテインメントの主要なカテゴリーになる未来への賭けである。スタジオがゲームデザインや技術的な力だけでなく、どれだけ速く反復でき、デザインと実装の結合をどれだけ深く理解しているかで競争する未来である。

このハイアはまた、新しいキャリアパスへの賭けでもある：ハイブリッドロールではなく、独立した分野としてのデザインエンジニア。今後5年間で、デザインエンジニアリングはゲームデザインやエンジンプログラミングと同じくらい専門化されるようになるだろう。スタジオはデザインエンジニアの才能を競う。デザインエンジニアは思想的リーダーと著者になる。大学はデザインエンジニアリングプログラムを提供する。

Gym Classの場合、このハイアはプロトタイプスタジオから本番スタジオへのスケーリングの基礎である。それは18ヶ月ごとに1つのゲームを出荷することと3ヶ月ごとに1つのゲームを出荷することの違いである。それは実装中に制約を発見することと設計中に制約を発見することの違いである。それは反応的なスタジオと生成的なスタジオの違いである。

Gym Classの最初のデザインエンジニア採用は、デザイン思考を技術的決定に組み込み、反復速度を加速し、クリエイティブチームと技術チームがどのように協力するかの新しいモデルを確立する機会である。成功は、明確なロール定義、明確な制約、意図的な統合、正直な測定に依存する。出力ではなく、速度と安定性で測定する。ロールが純粋なエンジニアリングまたは純粋なデザインにドリフトする場合は調整する。90日以内に、アイデアがコンセプトから検証されたプロトタイプにどれだけ速く移動するかの測定可能な改善、および新しい作業方法で活力を得たチームが見られるはずである。

これは単なるハイアではない。それはGym Classが競争よりも速くイノベーションする方法でスタジオを構築する方法について長期的に考えていることを示す信号である。それが本当の賭けである。

• 図9：制約発見タイミングの改善（早期発見率の向上）*