「退屈な技術」を選べ：イノベーションのトークンは3つしかない

Linux、Postgres、HAProxy、PHP（またはPython/Django）を備えた2台のベアメタルで、企業が必要とするアプリの99%は完璧に動作します。これは99.99%の稼働率で動作し、Dell/HPEの4時間対応保証（もう一方のサーバーへのフェイルオーバー）があります。また、ある程度垂直スケーリングも可能です（RAM/SSDのアップグレード）。高校を卒業した子供たちでも、これを所有して運用することを教えられます。

しかし.... マルチクラウドのハイブリッド環境で、kubernetes、サービスメッシュ、データレイク/池/海、そしてあらゆるレイヤーに何百万もの派手なテクノロジー用語を使えば、あなたの履歴書は素晴らしく見え、賢く聞こえるでしょう。そしてVPはAWSに6億ドルの予算と600人の開発者、SRE、DevOps、PMOを得ます。物事が動かないわけではありませんが、人間には逆のインセンティブがあります。

ポルノ/アダルト業界の多くは、私が述べたようなセットアップを、ルーマニア人の男がインフラ全体を1万5千ドルから2万ドルで運用していると確信しています。

これは非常に人気があるにもかかわらず、私はこれに反対します。恣意的な「イノベーショントークン」が嫌いで、この概念全体が線を曖昧にし、真面目さに欠けると感じます。

エンジニアは要件、リスク、トレードオフ、潜在的な利点を理解すべきです。新しい技術がそれに適しているかもしれません。新しいアプローチがそれに適しているかもしれません。「新しい」や「斬新」は単なる代理指標であり、弱いものです。

例えば、「新しい」は未テストを意味すると思うかもしれませんが、それは本当ですか？新しいプロジェクトにJepsenテスト、ファジングスイート、大量のオラクルテストを実行する大規模な計算がある場合はどうでしょうか？「古いものを選ぶ」ではなく「よくテストされたものを選ぶ」と言うべきです。多くの古いソフトウェアはテストが非常に不十分です。

「古い」がより良いドキュメントを意味すると思うかもしれませんが、そうでしょうか？多くの古いプロジェクトには、何年にもわたって蓄積された、文書化されていない奇妙なエッジケースや狂ったガラクタがあります。

なぜ比喩が必要なのでしょうか？「イノベーショントークン」がなぜ役立つのでしょうか？

これらの特性の観点から技術を評価できないなら、あなたは真面目な開発者ではなく、「退屈」はあなたを救いません。

座って、要件を書き出し、候補となる解決策を決定し、適合性に基づいて選択してください。「退屈」は何も意味しません。それは曖昧な代理用語です。「よくテストされた」、「私たちのユースケースに十分なパフォーマンス」、「開発者が知っている」などは意味があります。

> MySQLは退屈です。Postgresは退屈です。PHPは退屈です。Pythonは退屈です。Memcachedは退屈です。Squidは退屈です。Cronは退屈です。

文字通り、これらのすべてが陽気で悲惨な失敗を引き起こしました[…]

これは、JavaScriptフレームワークの流行り廃りの時代への反応だったかもしれません。同じ仕事をするための技術が多すぎました。

それらはすべて多かれ少なかれ動作しました。

一方、IBMは集積回路への参入が遅れました。彼らはソリッド・ロジック・テクノロジーを持っていました。これはトランジスタをセラミック基板に配置して小型だが個別の回路を作る自動機械です。それがIBM System/360を動かしました。動作しましたが、メインフレームの価格を高く保ち、ミニコンピュータへの参入を遅らせました。

問題が難しいときのイノベーションはより興味深いものです。米国の長距離爆撃機の歴史を見てください。B-29は効果的でしたが、パワー不足で、満載で離陸するのに多くの問題がありました。そこで、第二次世界大戦後、次の開発はB-36でした。これは「B-29をスケールアップしたらどうなるか？」という質問に答えたものです。[1] 6つのプロペラと4つのジェットエンジン（設計サイクルの後半に追加）がありました。空の艀でしたが、誰も撃墜しようとしない限りは動作しました。飛行可能な機体は残っていません。それが退屈な技術アプローチでした。

その後、B-47が登場しました。これは「ジェット戦闘機を爆撃機サイズにスケールアップしたらどうなるか？」という質問に答えたものです。[2] B-47はすべてジェットで、プロペラはありませんでした。離陸を助けるために固体燃料ロケットブースター（！）と、着陸時に減速するためのドラッグシュートが必要でした。飛行はひどく、運用速度と高度は、失速とマッハバフェットが交わる「棺桶の角」に近すぎました。[3] 飛行可能な機体は残っていません。

その後、B-52が登場しました。新しいエンジン[…]

この投稿が大好きです。エージェントの時代に再訪するのも興味深いです。

記事の言葉を使うなら、「すべてのイノベーショントークンをエージェントに投入する」のが良い動きだと思います。つまり、エージェントが扱う技術はすべて退屈な技術であるべきです。

別の言い方をすれば、「分布内テクノロジーを使う」ということです。エージェントがZigよりもRustにかなり優れているなら、Zigが「より良い」としても、おそらくRustを使うべきです。Zigが優れている程度は、分布内エージェントが優れている程度に圧倒されるでしょう。

（これはRustが実際に優れているという主張ではなく、議論のための仮説的な事実パターンです。）

このアドバイスは有効ですが、留意すべき注意点があります。すぐに思い浮かぶ2つ：

1. かつて私が働いていた会社には、大規模なCassandraクラスターがあり、主に分散型の追記専用ログとして機能していました。この役割は、私が想像できる限りCassandraに完璧に適合しています。認証用の分散データベースが必要になったとき、社内に専門知識があり（「退屈な技術」）、しばらく便乗できるクラスターがあったため、Cassandraを使うことにしました。キーバリューサービス用の分散データベースが必要になったときも、同じ理由でCassandraを選びました。Cassandraには多くの問題がありましたが、詳細は省きますが、Cassandraの得意分野からあまりに逸脱すると、破綻寸前まで追い込まれると言えます。そのため、ダウンタイムや困難な夜がいくつかありました。時には退屈な技術だけでは不十分で、退屈なワークロードも必要です。

2. 私はRustの初期採用者でした。1.0以前は、この言語が何かになるかどうかはほとんどの人にとって不明確でした。私には、形式証明アシスタントがプログラマーの手に渡されるのを見て、明るい未来があるとすぐにわかりました。当時、Rustは退屈な技術ではありませんでした。今では（一部のユースケースでは）そう言えるかもしれません。自信を測定可能に向上させる輝く新しい技術を採用することはリスクではありません。愚かなのは、使いこなすのが難しい、馴染みのある、つまり退屈な技術に慣れ親しんで自己満足になることです。

まあ、これまでHNで公開しようとは思っていませんでしたが、そのような反論があるなら、少なくとも共有を試みるべきでしょう：https://www.iankduncan.com/engineering/2026-08-07-getting-fr...

この種のエンジニアリング文化を何らかの形で審査された企業の求人掲示板があればいいのにと思います。

多くの仕事は「私たちは現実主義者です」と売り込まれますが、実際に行ってみると開発者5人、リポジトリ50個、仕事のほとんどは、x要件を新しいマイクロサービスにすべきかどうかの議論です。製品は通常、10エンティティとAPIを持つWebアプリです。

おそらくそれは人々を雇用し続けることなのでしょう。