みなさん、こんにちは。
気づけばIT業界とその周辺に身を置いて、30年近くが経ちました。私のキャリアの軸は、実は「ゴリゴリの技術者」ではありません。自分でバリバリとコードを書き、最新のフレームワークを使いこなすタイプではなく、セールスエンジニアやITコンサルタント、プロジェクトマネージャーといった、いわば「技術とビジネスの境界線」に立ち続けてきた人間です。
そんな中途半端（？）な立ち位置だからこそ、見えてきた景色があります。「技術的には正解に見えるのに、なぜか無惨に失敗するプロジェクト」や、「技術スタックは古臭いのに、なぜか強固に生き残り、利益を出し続ける会社」を、嫌というほど見てきました。
昨今はAIブームで、開発のあり方も劇的に変わろうとしています。「古い知識なんて役に立たない」という声も聞こえてきそうですが、私はむしろ逆だと感じています。技術が加速する今だからこそ、変わらない「思考の軸」が生存を分けるのです。
今日は、私のエンジニア人生の指針となった2000年代前半の「古典」とも言える2冊を紹介しながら、今も、そしてこれからも通用するであろう2つの原則についてお話ししたいと思います。
原則① 生き残るのは「賢い」企業ではなく「致命的なミスをしない」企業
一冊目は、タイトルからしてかなり刺激的なこの本です。
『アホでマヌケな米国ハイテク企業』（メリル・R・チャップマン 著）
2004年に発行された本で、現在は絶版。古本屋や図書館でしか見かけないかもしれませんが、中身は驚くほど過激で、かつ本質的です。
著者はMBA出身のいわゆる「スーツ組」ですが、数々のIT企業の興亡を冷徹に分析しています。この本の核となる主張は、以下の「ひとこと」で表現できます。
IT業界で生き残るのは、天才的な大博打に勝った企業ではない。「これをやったら会社が終わる」という致命的な過ちを犯さなかった企業である。
「技術の優劣」と「企業の生存」は別物
本書では、WordStarやBorlandといった、かつて一世を風靡した懐かしい名前が並びます。彼らがなぜ消えていったのか。それは技術が劣っていたからではなく、マーケティングのミス、市場選択の誤り、そして何より「既存ユーザーを切り捨てる」という致命的な判断ミスをしたからです。
唯一致命的な判断ミスをしなかったのが、マイクロソフト。
彼らは決して「最初から最高の製品」を作ってきたわけではありません。むしろバグだらけでリリースし、後から修正していくスタイルで有名でした。しかし、彼らは「市場のスタンダードを握る」という一点において、致命的なミスを犯さなかった。一線を越えそうなところで、踏みとどまる嗅覚があったのです。
AI時代のPoCに潜む「致命傷」
今の時代に当てはめてみましょう。最近、猫も杓子も「AIで何かできないか」とPoC（概念実証）を繰り返しています。 しかし、現場を見ていると、
- AIを使うこと自体が目的化し、既存の優良な顧客体験を壊している
- 技術的な面白さを優先し、法的・倫理的な「致命的な地雷」を踏み抜こうとしている
そんな危ういプロジェクトが散見されます。
「技術的にイケているか」を論じる前に、「これをやって、もし失敗したら会社（事業）は死なないか？」という守りの問い。これが、30年経っても変わらない生存戦略の第一歩なのです。
原則② 「動いているコードを書き直すな」は、AI時代でも絶対の真理
二冊目は、エンジニアなら一度は目にしたことがあるかもしれません。
『ジョエル・オン・ソフトウェア』（ジョエル・スポルスキー 著）
Microsoft OfficeのVBA戦略を支えた伝説的なプログラマ、ジョエルによるエッセイ集です。2000年代のソフトウェア開発のバイブル的存在ですが、私が今でも折に触れて思い出すのは、彼の強烈な主張です。
「どんなに汚く見えるコードでも、それはテストに耐え、現実の業務を支えてきた歴史の塊だ。それをドキュメントがないから、スパゲッティだからという理由でゼロから書き直すのは、ソフトウェア開発における最大の過ちである」
私が経験した「1年半の努力がゴミになった」話
ここで、私の忘れられない現場体験をお話しさせてください。
あるプロジェクトで、10年以上の動作実績がある32ビット版アプリケーションを、64ビット環境へ完全移行することになりました。現場の若手や中堅たちは息巻いていました。「ロジックも古いし、コードも読みづらい。この際、全部捨てて、モダンな設計でゼロから書き直しましょう！」と。
しかし、結果は悲惨なものでした。
2年近くの月日と多額の予算を投じましたが、いざ蓋を開けてみると「仕様漏れ」と「未知のバグ」のオンパレード。実は、汚いコードの一行一行には、過去に発生した特殊なトラブルへの対策や、現場特有の暗黙のルールが「秘伝のタレ」のように染み込んでいたのです。
さらに、元の32ビット版の開発者が「自分の地位が脅かされる」と感じたのか、協力を渋るという政治的な問題も重なりました。コードは公開されていたのに、新しいチームは「古いコードは汚いから読む価値がない」と、動いているロジックをリファレンスとして活用することを怠ったのです。
結局、開発スケジュールは絶望的なまでに遅延し、プロジェクトはキャンセル。2年の努力は文字通り「ゴミ」になりました。「動いているものには、目に見えない理由がある」。このジョエルの言葉を無視した代償は、あまりにも大きかったのです。
「AIがあるから書き直せる」という罠
最近では、「AI（LLM）を使えば、レガシーコードの解析もリプレイスも簡単だ」という声をよく聞きます。確かに、コードを変換するスピードは上がりました。
しかし、AIは「なぜ、そのとき、そのコードが書かれたのか」というコンテクスト（文脈）までは読み取れません。
- 当時のOSのバグを回避するための苦肉の策だった
- 特定の重要顧客の、わがままな運用に合わせるための特殊処理だった
- 数年に一度しか発生しない、レアケースへの対応だった
これらはコードの外側、つまり人間の記憶や現場の空気にしか存在しません。AIに丸投げして書き直すことは、こうした「知恵の結晶」を捨て去るリスクを孕んでいます。AI時代だからこそ、私たちは「既存のコードへの敬意」を忘れてはいけないのです。
30年を経て、私がたどり着いた「コンテクスト思考」
「致命的なミスを避けろ」「動いているものを壊すな」。こう書くと、非常に保守的で、新しいことに挑戦しない後ろ向きな姿勢に聞こえるかもしれません。
しかし、私が言いたいのは「何もしないこと」ではありません。「技術の正しさ」だけで突っ走らず、「背景（コンテクスト）」を理解する努力をしよう、ということです。
エンジニアとして中堅からベテランになり、プロジェクトの命運を握る立場になると、ついつい「最新の技術スタックは？」「パフォーマンスは？」といった、目に見えるスペックに目が向きがちです。
でも、本当に価値を生むのは、
- 同じ機能でも、見せ方や使い方を変えて、現場のストレスを減らす
- できるだけ長く価値を保ち続けるように、あえて「枯れた技術」を組み合わせる
といった、デザイン思考やコンテクストを重視したアプローチだったりします。
今、PoCと本番の狭間で悩んでいる方へ
特に20代後半から30代のエンジニアの方は、現場の最前線で「AIを使え」という上層部からのプレッシャーと、「現場のレガシーな現実」の板挟みになっていることでしょう。
そんなときこそ、今回紹介した2冊の原則を思い出してください。
- それは、事業にとって「致命的なミス」にならないか？（守りの視点）
- 「動いているもの」に敬意を払い、その文脈を理解しているか？（敬意の視点）
この2つのフィルターを通すだけで、自分の提案や判断が、単なる「技術論」を超えて、経営や現場に深く刺さる「本質的な価値」に変わるはずです。
変わらない原則
2000年代前半に書かれたこれらの本は、技術のトレンドとしては「過去」のものです。しかし、人間が組織でソフトウェアを作り、それを社会に提供するという構造が変わらない限り、そこで語られている本質は色褪せません。
- 次の一手を任され、プレッシャーを感じているリーダー
- 「一度全部書き直したい！」という衝動に駆られているアーキテクト
- AI導入のキラキラした成功事例と、泥臭い現場のギャップに悩んでいるPM
そんな方にこそ、古本のページをめくってみてほしいと思います。
- それは、事業にとって「致命的なミス」にならないか？（守りの視点）
- 「動いているもの」に敬意を払い、その文脈を理解しているか？（敬意の視点）
30年この業界にいても、いまだに毎日が勉強です。私自身、この２つの「変わらない原則」という武器を持っているだけで、少しだけ足元が軽く感じられるのです。
本日も最後までお読みいただきありがとうございました。
それでは、よいエンジニアライフを！
