技術的な背伸びとスコープ — カーマックの回顧から学ぶこと

はじめに — なぜいまカーマックの回顧が話題なのか
事実背景 — Quake開発が残したもの
教訓1 — 一度に大きな冒険は一つだけ
教訓2 — 安定した基盤を選ぶ価値
教訓3 — スコープ管理と技術的負債
教訓4 — 小さなチームの意思決定と人間的コスト
教訓5 — 完成と出荷の規律
- 出荷は野心の試金石だ
- 反復が一度の完璧に勝つ
現代の事例に移してみる — スタートアップの再現
実務適用 — 野心を扱うチェックリスト
よくある質問
落とし穴と批判的視点
おわりに — 野心を管理する方法
参考資料

はじめに — なぜいまカーマックの回顧が話題なのか

2026年のHacker NewsとGeekNewsには、古いソースコードや開発回顧が改めて話題に上る流れがあります。AIがコードを速く吐き出す時代であるほど、逆説的に「うまく作るとは何か」という根本の問いが再び注目されるからです。その中心に、ジョン・カーマック(John Carmack)の回顧が再び語られます。

カーマックはid SoftwareでWolfenstein 3D、Doom、Quakeを作ったプログラマーで、ゲームエンジンとグラフィックスプログラミングの歴史で屈指の人物です。彼は自分の開発過程を比較的率直に公開してきたことでも有名です。とくにQuake開発は、彼が複数のインタビューや公開文章で「野心が現実とぶつかった時期」として回顧したことがあります。

本稿はカーマック個人の伝記ではありません。彼の公開された回顧を手がかりに、すべてのエンジニアリングチームが直面する普遍的な教訓 — 技術的な背伸び、スコープ管理、安定した基盤の選択、小さなチームの意思決定 — を解きほぐす試みです。

なぜほかでもない2026年にこうした回顧が再び注目されるのでしょうか。AIコーディングエージェントがコード生産のボトルネックをほぼ取り除いたいま、多くのチームは「これでもっと多くのことをもっと速く試せる」という高揚に包まれています。ところがまさにその高揚こそ、カーマックが警告した落とし穴 — 一度に多くのことを試みること — へ一直線に向かう道でもあります。コードを速く作れるようになったことが、複数の大きなリスクを同時に背負えるようになったという意味ではありません。むしろ生産速度が速くなるほど、何を試さないかを決める節制がより重要になります。30年前の回顧がいま改めて読まれる理由はここにあります。

重要: 本稿はカーマックとid Softwareに関する公開された報道と、彼自身が明らかにした回顧に基づきます。当事者の口を借りた架空のセリフは一切作らず、具体的な事実引用は慎重に扱います。逸話の細部は出典により異なる場合があります。

事実背景 — Quake開発が残したもの

まず公開的に知られている事実関係を整理します。

id SoftwareはDoomの成功の後にQuakeを作りました。Quakeは1996年に発売された、真の意味でのリアルタイム3Dポリゴンレンダリングとマルチプレイヤーネットワーキングを結合したゲームと評価されます。技術的にQuakeは当時として非常に野心的な目標を複数同時に追求しました。

広く知られている事実を整理すると次のようになります。

QuakeはDoomの2.5D方式を超え、完全な3Dワールドを目標にしました。
カーマックはBSPツリー、事前計算された可視性(PVS)、ライトマップといった技術でリアルタイム3Dレンダリングの性能問題を解きました。
Quakeはインターネットマルチプレイヤーとクライアント・サーバーモデルでオンラインゲームの方向を示しました。
QuakeCというゲームロジック用スクリプト言語を導入し、モッド制作のエコシステムを開きました。

同時に、Quake開発はid Softwareに大きな負担と葛藤を残した時期としても回顧されます。ゲームのデザイン方向が開発途中で変わり、初期構想と最終成果物の間にかなりの隔たりがあった点は、複数の資料で共通して言及されます。この時期を経て、中核人材の一部が会社を去りもしました。

カーマック自身は後日、複数のインタビューや文章で、当時の野心が大きすぎ、一度に多くの新しいことを試みたという趣旨の回顧を残しました。本稿が扱おうとする教訓はまさにこの点、「一度に多くのことを試みることの危険」です。

一つはっきりさせておきたいのは、本稿がQuakeを「失敗作」として描こうとするものでは決してないという点です。Quakeは商業的にも技術的にも大きな成功であり、オンラインマルチプレイヤーゲームとモッド文化の土台を築きました。回顧が注目するのは結果の成否ではなく、その過程のコストです。同じ成功に至るのにより少ない痛みが可能だったか、何がその痛みを大きくしたか — これが教訓の焦点です。成功したプロジェクトの過程を正直に振り返ることこそ、最も価値ある回顧です。

教訓1 — 一度に大きな冒険は一つだけ

リスクの掛け算

エンジニアリングプロジェクトで新しいことを試みるのはリスクを伴います。そして複数の新しいことを同時に試みると、リスクは足し算ではなく掛け算になります。

  一度に一つの大きな賭け (推奨)
  +------------------+------------------+
  | 検証された基盤    | 新しい試み1つ     |
  | (安定)           | (リスク)         |
  +------------------+------------------+
  リスク = 1 (管理可能)

  一度に複数の大きな賭け (危険)
  +----------+----------+----------+----------+
  | 新レンダ  | 新ネット  | 新言語    | 新デザイン |
  | (リスク) | (リスク)  | (リスク)  | (リスク)  |
  +----------+----------+----------+----------+
  リスク = 掛け算 (どこで壊れたかさえ分かりにくい)

Quakeが同時に追求したものを思い出しましょう。完全な3Dレンダリング(新しさ)、インターネットマルチプレイヤー(新しさ)、スクリプト言語(新しさ)、そして変化するゲームデザイン(不確定)。それぞれがそれ自体で難しい挑戦なのに、これらが同時に進行しました。

このとき問題が生じると原因を分離するのが非常に難しいです。性能が出ないとき、それがレンダリングのせいか、ネットワークのせいか、スクリプトのせいか、あるいはこの三つの相互作用のせいか見分けにくいです。リスクが掛け算になればデバッグも掛け算になります。

普遍的な適用

この教訓はゲームを超えてすべてのエンジニアリングに適用されます。

新しいプログラミング言語を初めて導入しながら、同時に新しいアーキテクチャを試み、同時に新しいインフラへ移すな。
一つのリリースに新しいデータベース、新しいキューシステム、新しいデプロイ方式を一度に入れるな。
検証されていない技術を複数同時に積めば、問題発生時に原因の隔離が不可能になる。

この原則を破ったとき最初に崩れるのはデバッグ能力です。次の図がその理由を示します。

  新しさが1つのとき (隔離可能)
    問題発生 -> 容疑者1人 -> 速い診断

  新しさが4つのとき (隔離不可)
    問題発生 -> 容疑者4人 + 彼らの相互作用6組
            -> 計10通りの可能性 -> 診断の麻痺

容疑者が増えると単純に足し算になるのではなく、彼ら同士の相互作用まで疑わねばなりません。四つの新しさは四つの単独の容疑者に加えて、六組の相互作用の容疑者を生みます。これがリスクが掛け算になるという言葉の具体的な意味です。

原則は単純です。「一度に大きな冒険は一つだけ」。残りは検証された、退屈な、安定した選択で埋めることです。そうすれば冒険が失敗してもその失敗を明確に識別し対応できます。

リスク予算という考え方

この原則をより実用的に扱う方法は、「リスク予算(risk budget)」として考えることです。一つのプロジェクトが背負える新しさの総量には限界があると見て、その予算を意識的に配分するのです。

  プロジェクトのリスク予算 (例: 100点)

  +--------------------------------------+
  | 核心差別化の冒険1つ     : 60点        |  <- ここに集中
  | 支援領域の小さな新しさ  : 20点        |
  | 残りはすべて検証済み    : 0点         |
  | 余裕分 (想定外のリスク) : 20点        |  <- 必ず残すこと
  +--------------------------------------+
  合計100点 (超過禁止)

この考え方の核心は二つです。第一に、予算が有限だという認識です。新しいものを一つ追加するたびに、別のところでリスクを引かねばなりません。第二に、余裕分を残すことです。すべてのリスク予算を計画された冒険に使い切ると、想定外のリスク(依存関係の問題、人材の離脱、要求の変更)が起きたときにそれを吸収する余力がありません。

Quakeをこの枠で見ると、リスク予算を複数の大きな冒険に同時に配分し、余裕分がほとんどなかったわけです。だからデザイン変更という追加リスクが襲ったとき、それを吸収する余力が不足していました。これは非難ではなく、業界の境界を押し広げるプロジェクトがしばしば払う代価です。

もちろん「リスク予算100点」という数字は比喩にすぎず、実際にリスクを精密に定量化できるという意味ではありません。この考え方の価値は正確な計算にあるのではなく、「自分たちはいまいくつの大きな冒険を同時にしているのか」を意識的に数えさせる点にあります。多くのチームが崩れる理由は、リスクを誤って計算したからではなく、自分がいくつのリスクを背負ったかさえ数えたことがないからです。

教訓2 — 安定した基盤を選ぶ価値

退屈な技術の美徳

カーマックの仕事で一貫した特徴の一つは、派手な部分と退屈な部分を区別し、退屈な部分を堅固に固めた点です。彼はしばしば検証されたアルゴリズムとデータ構造の上に革新を積みました。BSPツリーは彼が発明したものではなく、既存のコンピュータグラフィックス文献から取ってゲームに応用したものです。

ここから普遍的な教訓が出ます。革新はすべての層で同時に起きる必要はありません。むしろうまく動くプロジェクトはほとんどの層を退屈で検証されたもので埋め、本当に差別化が必要な一つか二つの層だけに革新を集中します。

  層            戦略
  -----------   ---------------------------
  核心差別化     革新 (リスクを取る価値)
  支援システム   検証されたパターン (退屈が美徳)
  インフラ/基盤  最も安定した選択 (絶対に冒険禁止)

基盤が揺れればその上のすべてが揺れます。だから最も下の層ほど最も保守的に、最も検証されたものを選ぶべきです。冒険は上の方、ユーザーが価値を感じる差別化地点に取っておきます。

「退屈が美徳」の現代的解釈

この原則は2026年でも有効です。今日「退屈な技術を選べ(choose boring technology)」という助言が広く語られる理由がまさにこれです。新技術は魅惑的ですが、検証されていない新技術を核心基盤に敷けば、そのリスクがあらゆる場所に伝播します。

とくにAIがコードを速く生成する時代にはこの原則がより重要になります。コードを速く作れることが、検証されていない複数の技術を一度に積んでよいという意味ではないからです。生成速度が速くなるほど、何を安定した基盤として固定するかの判断がむしろより決定的です。

革新は組み合わせからも生まれる

ここでよくある誤解を押さえておく必要があります。「退屈な技術を選べ」が「革新するな」という意味ではないという点です。カーマックがBSPツリーを発明しなかったという事実は、彼の仕事がより革新的でないという意味ではありません。むしろ彼は既存の検証された技法をゲームという新しい文脈で組み合わせ応用するところから革新を生みました。

  革新の二種類

  発明型の革新                組み合わせ型の革新
  -------------------         -------------------------
  まったく新しいものを作る     検証されたものを新しく結合
  リスクが非常に大きい         リスクが相対的に低い
  まれにしか成功しない         しばしば成功する
  例: 新アルゴリズムの発明      例: 既存アルゴリズムの巧みな応用

ほとんどの成功した製品の革新は発明型ではなく組み合わせ型です。検証された部品を安定して使いながら、それらを結合する方法で差別化を生むのです。こうすればリスク予算を節約しながら革新できます。「退屈な技術の上の巧みな組み合わせ」こそ、安定性と革新を同時につかむ道です。

この観点はツール選択の負担を大きく軽くします。すべての層で最新技術を追わねばならないという圧力から解放され、「どこで検証されたものを使い、どこで巧みに組み合わせるか」というより生産的な問いへ移れるからです。最も新しいものを最も多く使うチームではなく、新しいものと検証されたものを最も巧みに配置するチームが勝ちます。

教訓3 — スコープ管理と技術的負債

変わるスコープの危険

Quake開発の回顧で繰り返し言及されるもう一つのテーマは、ゲームデザインの方向が開発途中で変わった点です。初期にはより野心的なRPG的要素が構想されましたが、技術的現実と日程の圧力のなか最終形に収束したという記述が複数の資料に共通して出ます。

スコープが開発途中で揺れるのはすべてのプロジェクトの古典的な落とし穴です。とくに危険な組み合わせは「野心的なスコープ + 揺れるスコープ + きつい日程」です。この三つが重なると、チームは際限なく動く目標を追って消耗します。

  スコープリスクの三角形

         野心的なスコープ
            /\
           /  \
          /    \
         /      \
  揺れる ------- きつい
  スコープ        日程

  三辺がすべて長い -> バーンアウトと品質崩壊

技術的負債は意識的な決定であるべき

野心的なプロジェクトで技術的負債は不可避です。日程と野心の間で何かが先送りされ、応急処置が入り、「あとで直そう」が積まれます。問題は負債そのものではなく、その負債が無意識に積まれることです。

健全なチームとそうでないチームの差は、負債の有無ではなく負債の可視性です。

  悪い技術的負債              健全な技術的負債
  -------------------        -------------------------
  無意識に積まれる            意識的に選ばれる
  どこにあるか分からない       リストで追跡される
  返す計画がない             返す時点が決まっている
  複利で膨らむ               利息が管理される

カーマックの回顧が与える教訓を一般化するとこうなります。野心を減らせということではなく、野心に伴う負債を意識し追跡し制御せよ、ということです。どこを削ったか分かれば後で復旧できますが、知らずに削ればそれがある日システムを崩します。

スコープクリープの早期信号

スコープが危険に揺れていることは、たいてい日程が爆発するずっと前に信号を送ります。この信号に早く気づければ対応する時間が生まれます。

  早期信号                      意味
  -------------------------    -------------------------
  「ついでに」が頻発            スコープがじわじわ増えている
  デモが延々と先延ばし          クリティカルパスが不確実
  「ほぼ完成」が繰り返される     90%症候群、最後の10%が終わらない
  見積もりが毎回大きく外れる     問題を十分に理解していない
  中核人材が残業を日常化         人的コストがすでに請求されている

これらの信号で最も危険なのは最後です。日程とスコープの不一致は結局、人の残業とバーンアウトで吸収されるため、「チームが疲れて見える」というのはしばしばスコープ問題の最も正直な指標です。ダッシュボードの数字より人の表情が先に語ります。

対応は単純ですが難しいです。スコープを減らすか、日程を延ばすか、野心を下げるかです。三つのどれも無料ではなく、三つすべてを拒めば残るのは人をすり減らす道だけです。健全なチームはこの三つのうち一つを早く、意識的に選びます。

教訓4 — 小さなチームの意思決定と人間的コスト

小さなチームの両刃

id Softwareは小さなチームでした。小さなチームは速い意思決定、高い結束力、少ない意思疎通オーバーヘッドという強みを持ちます。カーマックのような一人か二人の中核人材が技術の方向を強く引っ張れたのも、小さなチームだからこそ可能でした。

しかし小さなチームには影もあります。中核人材への依存度が高く、少数の葛藤がチーム全体を揺らし、一人のバーンアウトがプロジェクトを脅かします。Quake開発期に中核人材の一部が会社を去ったことは、技術的野心と人間的コストが切り離せない点を示します。

  小さなチームの強み          小さなチームの危険
  -------------------        -------------------------
  速い意思決定               中核人材への依存
  高い結束力                 少数の葛藤が致命的
  少ないオーバーヘッド        バーンアウトに脆弱
  強い方向性                 バスファクターが低い

技術の決定は人の決定だ

ここから最も重要な一般教訓が出ます。技術的な背伸びは純粋に技術問題で終わりません。それは人々に日程の圧力、残業、挫折、葛藤として転嫁されます。野心的すぎるスコープは結局人をすり減らすことで埋められ、そのコストは中核人材の離脱として請求されます。

だから野心と現実のバランスを取る仕事は、単なる日程管理ではなく人の管理です。どの技術を試みるか決めるとき、「これがチームにどんな人間的コストを要求するか」を一緒に問わなければ、技術的に成功してもチームを失いかねません。

強い意見と葛藤の管理

小さなチームのもう一つの特徴は、強い意見を持つ少数がぶつかるとき、その摩擦がただちにチーム全体の問題になることです。大きな組織では意見の衝突が複数の層に分散され緩衝されますが、三、四人の中核で回るチームでは二人の不和がそのまま会社の危機です。

技術的野心が大きいチームほど、強い意見を持つ人々が集まります。これは長所であり危険でもあります。強い意見は良い決定を生みますが、その意見が衝突したとき調整するメカニズムがなければチームは割れます。だから小さなチームほど「意見の不一致をどう扱うか」についての明示的な合意 — 誰がどの領域の最終決定権を持つか、合意できないときどう進めるか — が重要です。技術の方向と同じくらい、葛藤の解消方式も設計の対象です。

興味深いことに、この問題への最も一般的な解毒剤は大げさなプロセスではなく記録です。「なぜこの決定を下したか」を短くでも残しておけば、後で同じ論争が繰り返されるのを防ぎ、決定に同意しなかった人もその文脈を理解するようになります。小さなチームは速度のために記録を省きたがりますが、核心的な決定の記録はむしろ葛藤を減らし速度を上げる投資です。

教訓5 — 完成と出荷の規律

出荷は野心の試金石だ

id Softwareが語られるもう一つの理由は、彼らが野心的でありながら実際に出荷したことです。DoomとQuakeは構想で終わらず世に出ました。際限なく野心を膨らませて出荷できないプロジェクトと、野心を現実で止めて出荷するプロジェクトの差は決定的です。

  出荷できない野心              出荷する野心
  -------------------         -------------------------
  「もう少し完璧に」           「これで出荷、残りは次に」
  スコープが無限に拡張          スコープを意識的に凍結
  永遠の90%                   明確な出荷基準
  世の中のフィードバックなし     世の中が検証してくれる

出荷には野心を止める規律が必要です。どこまでが今回のバージョンで、どこからが次のバージョンかを引く決定です。この線を引けなければスコープは無限に増え、製品は永遠に出荷されません。逆説的に、野心を実現する最も確実な方法は、野心の一部を次へ先送りする節制です。

反復が一度の完璧に勝つ

ここからもう一つの教訓が出ます。一度に完璧なものを作ろうとする野心より、速く出荷して反復する野心のほうがたいてい強いです。DoomからQuakeへ、Quakeから次の世代へとつながる発展は、一度の完璧ではなく出荷と学習の反復から生まれました。

これはリスク予算ともつながります。すべての野心を一つのバージョンに詰め込めばリスクが掛け算になりますが、野心を複数のバージョンに分けて入れれば各バージョンのリスクが管理可能になり、出荷のたびに世の中のフィードバックで次の野心を補正できます。一つの大きな跳躍より、何度かの堅実な歩みのほうが遠くまで行きます。

現代の事例に移してみる — スタートアップの再現

これらの教訓が30年前のゲーム会社だけの話ではないことを、よくある現代のスタートアップのシナリオで示します。架空の事例です。

あるシリーズAのスタートアップが野心的なv2の書き直しを決めます。彼らは一度に次のすべてを変えることにします。

  v2で同時に試みた新しさ (リスクの掛け算)
  +----------------------------------------------+
  | 1. モノリス -> マイクロサービス (新アーキ)    |
  | 2. REST -> GraphQL (新APIパラダイム)         |
  | 3. 初めて使う新言語 (チーム経験なし)          |
  | 4. 新クラウドへ移行 (新インフラ)              |
  | 5. 新デザインシステム (変化するスコープ)      |
  +----------------------------------------------+

結果はカーマックの回顧と構造的に似ています。日程は延び続け、どこで問題が起きるか隔離しにくく(五つの新しさの相互作用)、残業が積もり、中核エンジニア二人がバーンアウトで去ります。技術的野心が人間的コストとして請求される同じパターンです。

リスク予算の考え方を適用していたらどうだったでしょうか。「今回のv2の核心差別化は何か」をまず問い、そこにだけ大きな冒険を割り当てたはずです。たとえばマイクロサービスへの移行が本当に核心なら、それ一つだけをやり、残り(言語、API、インフラ、デザイン)は検証済みの既存の選択を維持するのです。そうすれば問題が起きても「マイクロサービスのせい」と隔離でき、余裕予算で想定外のリスクを吸収できます。

この事例の教訓は明確です。書き直しの誘惑は「どうせ作り直すなら全部最新で」という欲を煽りますが、その欲こそリスクを掛け算する最も一般的な経路です。

成功する書き直しはたいてい一度に一つずつ、漸進的に、各段階で検証しながら進みます。一度にすべてを変えるビッグバン書き直しが失敗する統計的理由がまさにここにあります。リスクを一度に背負う代わりに、一片ずつ置き換えて各段階で安定性を確認するチームが、結局より速く、より安全に目的地にたどり着きます。

実務適用 — 野心を扱うチェックリスト

カーマックの回顧から引き出した教訓を実務チェックリストに整理します。

[ リスク隔離 ]
[ ] 今回のプロジェクトで「一度に大きな冒険は一つ」原則を守るか?
[ ] 検証されていない技術をいくつ同時に積んでいるか?
[ ] 問題発生時に原因を隔離できるよう新しさを分離したか?

[ 基盤選択 ]
[ ] 最も下の層(インフラ/基盤)は最も検証されたものを選んだか?
[ ] 革新を核心差別化地点だけに集中したか?
[ ] 「退屈な技術」を選べる場所で選んだか?

[ スコープと負債 ]
[ ] スコープが明確に定義され変更が制御されているか?
[ ] 意識的に負った技術的負債をリストで追跡するか?
[ ] 返す時点と責任者が決まった負債か?

[ 人 ]
[ ] この野心がチームに要求する人間的コストを評価したか?
[ ] 中核人材依存(バスファクター)を減らす方法があるか?
[ ] バーンアウトの兆候をモニタリングする体系があるか?

[ 出荷規律 ]
[ ] 今回のバージョンのスコープ境界(何が次へ先送りされるか)が明確か?
[ ] 明確な出荷基準が定義されているか? (90%症候群の防止)
[ ] 野心を複数の反復(バージョン)に分けて入れたか?

このチェックリストの核心は野心を諦めよということではありません。野心を意識的に、分離して、人を考慮しながら追求せよということです。

よくある質問

Q1. では野心的なプロジェクトはするなということですか?

正反対です。id Softwareが野心的でなかったらDoomもQuakeもなかったでしょう。教訓は「野心を捨てよ」ではなく「野心を一か所に集中し、残りを安定させよ」です。大きな冒険一つにリスク予算を寄せれば、その冒険はむしろ成功する可能性が高まります。四方に分散した野心が危険なのです。

Q2. 何が「核心差別化」なのかどう決めますか?

「これがなければ自分たちの製品が存在する理由があるか」を問うてください。Quakeの場合はリアルタイム3Dがそれでした。その問いに「はい」の領域にだけ大きな冒険を割り当て、「いいえ」の領域(ビルドツール、デプロイ方式、補助ライブラリ)は最も退屈で検証された選択をするのです。

Q3. 技術的負債は無条件に悪いものではないですか?

いいえ。意図的に負った負債は合理的な戦略でありえます。問題は無意識の負債と、返す計画のない負債です。野心的な日程を守るために「ここはひとまず応急処置、出荷後2週間以内にリファクタリング」と明示的に決めて記録するなら、それは健全な負債です。負債そのものではなく、負債の可視性と返済計画が鍵です。

Q4. 小さなチームのバスファクター問題はどう減らしますか?

核心領域を意図的に二人以上が触るようにし(ペアリング、ローテーション)、「なぜこう作ったか」を文書で残すのが基本です。小さなチームほど速度のために一人に集中させたい誘惑が大きいですが、その人が去る瞬間のコストは平時の分散コストよりはるかに大きいです。

Q5. AIがコードを速く書いてくれるいまも、この教訓は有効ですか?

むしろより有効です。AIはコード生産の速度を上げますが、「複数の新しいことを同時に試みると原因を隔離しにくい」という問題はコード生産の速度と無関係です。速く多く作れることが、複数の大きな冒険を同時に背負えるという意味ではありません。リスクの掛け算はAI時代でもそのままです。さらに、AIがコードを簡単に作ってくれるぶん「どうせなら全部新しくしよう」という誘惑は大きくなります。だから節制の必要性は減るのではなく、むしろ増します。

Q6. これらの教訓を一文に縮めると?

「野心は一か所に集中し、残りは退屈に、負債は見えるように、人は気づかい、止まって出荷せよ。」この一文が五つの教訓の圧縮です。

落とし穴と批判的視点

カーマックの回顧から教訓を引き出すときの注意点も整理します。

事後合理化の危険: 回顧は結果を知った後の記述です。「あのとき野心的すぎた」という評価は結果的に難しかったから出たのかもしれず、成功していたら同じ選択が「大胆なビジョン」と称賛されたかもしれません。回顧から教訓を引き出すときは生存バイアスと後知恵バイアスを警戒すべきです。
野心の価値切り下げの危険: 「一度に一つだけ」を過度に適用すると保守主義に陥ります。id Softwareがリスクを取ったからこそDoomとQuakeが産業を変えたのも事実です。すべての冒険を減らせば凡庸さだけが残ります。教訓は「冒険するな」ではなく「冒険を管理せよ」です。
文脈の違い: 1990年代のゲーム開発と今日のソフトウェア開発は、道具、チーム規模、市場がすべて異なります。一人の天才プログラマーがエンジンを書いた時代の教訓を現代のチームにそのまま移すのは難しいです。普遍的な部分(リスク隔離、スコープ管理)と時代特有の部分を区別すべきです。
英雄叙事の罠: カーマックのような人物を中心に置く叙事は「一人の天才」という英雄神話を強化しやすいです。実際の製品はデザイナー、アーティスト、他のプログラマーたちの集合的努力であり、回顧の一人の視点だけで全体を再構成すると歪みが生じます。
出典の限界: 同じ出来事も当事者ごとに記憶と解釈が異なります。本稿が引用する「共通して言及される」事実すら完全な合意ではないかもしれません。単一の回顧を絶対的真実として受け取らない態度が必要です。
成功は選択を正当化しない: Quakeが結局成功したという事実は、その過程の選択が正しかったという証拠ではありません。成功したプロジェクトのあらゆる決定を事後に正当化する「成功の後光効果」を警戒すべきです。もしかするとより少ない痛みで同じ成功に至れたかもしれません。
単純化の危険: 「一度に一つだけ」「リスク予算」といった整然としたフレームは覚えやすいですが、現実の意思決定はそれほど単純ではありません。どの冒険が「一つ」なのかさえ曖昧で、リスクは定量化しにくいです。これらのフレームは思考の出発点であって公式ではありません。

これらの批判は教訓の価値を否定しません。むしろ教訓をより正確に適用するための安全装置です。核心は回顧から普遍的原理を抽出しつつ、その原理を自分の文脈で再び検証することです。良い回顧は答えを与えるのではなくより良い問いを与え、その問いを自分のプロジェクトに投げかける瞬間にこそ教訓が生きてきます。

おわりに — 野心を管理する方法

カーマックのQuake回顧が今日でも語られる理由は、それが単なる昔話ではなく、すべての野心的プロジェクトが繰り返し直面する構造を示すからです。

整理すると次のようになります。

一度に大きな冒険は一つだけ。複数の新しさを同時に積めばリスクが掛け算になり原因隔離が不可能になります。
安定した基盤を選べ。革新は核心差別化地点に取っておき、残りは退屈で検証されたもので埋めましょう。
スコープを制御し負債を可視化せよ。野心に伴う負債を意識的に追跡すれば復旧できます。
技術の決定は人の決定だ。野心の人間的コストを評価しなければ、技術的に成功してもチームを失います。
出荷と反復の規律を持て。野心を複数のバージョンに分けて入れ、止まって出荷することを知ってこそ野心が現実になります。
回顧から教訓を引き出しつつ、生存バイアスと英雄叙事を警戒し、自分の文脈で再び検証しましょう。

AIがコードを速く生成する2026年、何かを作る速度は速くなりましたが、何を作るか、どんなリスクを取るか、そのコストを誰が払うかの判断は依然として人の役目です。カーマックの回顧が与える最も深い教訓はおそらくこれです。偉大な技術は野心から生まれるが、持続可能なチームはその野心を管理する節制から生まれる。

この教訓が特別に響くのは、それが天才の非凡な悟りではなく、誰もが陥る平凡な落とし穴についてのものだからです。私たちのほとんどはカーマックのようにゲームエンジンを発明はしませんが、「どうせなら全部新しくしよう」という誘惑、スコープがじわじわ増えていく経験、野心がチームの残業として請求される瞬間は、ほぼ誰もが経験します。だから30年前のあるゲーム会社の回顧が、今日の私たちのスプリント回顧のように読まれるのです。

結局、エンジニアリングの成熟は野心の大きさではなく、野心を扱う方法に表れます。大きな夢を見つつ、その夢を一か所に集中し、残りを安定させ、人を気づかい、止まって出荷できること。これがカーマックの回顧が30年を越えて私たちに手渡す静かな助言です。

次のプロジェクトを始める前に、たった一つだけ数えてみてください。「いま自分たちが同時に背負っている大きな冒険はいくつか。」その数が一つより大きければ、減らせるものは何かを問うことから健全なエンジニアリングが始まります。

偉大なものを作りたいという思いと、それを持続可能にしたいという思いは衝突しません。二つをつなぐ橋こそが節制です。

改めて強調します。本稿は公開された報道と回顧に基づく一般的教訓の整理であり、特定人物の口を借りた架空のセリフは含みません。