「あえて退屈な技術」を選べ――エンジニアが陥る過度な技術追求の罠

エンジニアとして働いていると、つい最新の流行フレームワークや、キラキラした新しい技術スタックに手を伸ばしたくなるものです。しかし、Dan McKinley氏の伝説的な記事『Choose Boring Technology』が説くのは、その逆。「退屈で、枯れた技術」こそが、プロジェクトの成功率を劇的に高めるという真理です。新しい技術は学習コストや未知のバグという「負債」をもたらします。本当に重要なのは技術の面白さではなく、ユーザーに価値を届け続けられる安定したシステムです。保守性の高い、枯れた技術を選択する勇気こそ、一流のエンジニアの証と言えるでしょう。

「どの企業も『イノベーション・トークン』を約3枚持っているとしよう。使い道は自由だが、供給は長期間固定されている」

これ、個人的に大好きなブログ記事の一つなんだよね。本質的に「イノベーション・トークン」という概念に集約されてる。PMやエンジニアリングリーダーとしてキャリアを歩む中で、最も役に立った概念の一つだよ。適切なトレードオフを判断する助けになるし、あらゆる立場の同僚にそのトレードオフを説明する際にもめちゃくちゃ役立つ。強くおすすめするよ。

何年も安定して動き続けるソフトウェアなんて、これまで一度もコモディティ化したことなんてないよ。表面上は退屈に見えるし、派手な記事にもならない。でも、ほとんどのケースにおいて、俺は新しいものより信頼できるものを選ぶね。

この投稿、大好きだよ。意外と物議を醸す内容で、これでエンジニアの友達が増えたかというと、そうでもないんだけどね。

この投稿、大好き。エージェント（AIエージェント）全盛の今、読み返すとまた面白いな。

記事の言葉を借りるなら、「イノベーション・トークンをすべてエージェントに突っ込め」ってのが賢い戦略だと思う。つまり、エージェントが扱う技術スタックはすべて「退屈な技術」にしておくべきってこと。

言い方を変えれば「インディストリビューション（分布内）な技術を使え」ってことだね。もしエージェントがZigよりRustの方が圧倒的に得意なら、たとえZigの方が「優れて」いたとしてもRustを使うべきだろう。Zigが優れている分なんて、エージェントの得意分野かどうかの差で完全に吹き飛んでしまうからね。

（これはRustの方が優れているという主張じゃなくて、議論のための仮定の話だよ）

すごく人気があるみたいだけど、あえて反論させてもらうよ。「イノベーション・トークン」っていう恣意的な概念は好きじゃない。この考え方全体が本質をぼかしていて、どこか真剣味に欠ける気がするんだ。

エンジニアなら要件、リスク、トレードオフ、潜在的な利点を理解するべきだ。新しい技術が最適解になることもあれば、斬新なアプローチが適していることもある。「斬新」とか「新しい」なんて言葉は単なる代用指標（プロキシ）に過ぎないし、それ自体あまり意味がない。

例えば、「新しい」＝「テストが不十分」と決めつけるのはどうなの？もしその新しいプロジェクトがJepsenテストやファジングスイートを導入して、膨大な計算リソースでOracleテストを回していたら？「古いものを選ぶ」んじゃなくて「よくテストされたものを選ぶ」と言うべきだよね。実際、古いソフトウェアでもテストがずさんなものは山ほどある。

「古い」＝「ドキュメントが充実している」という思い込みも同様だ。古いプロジェクトなんて、何年もかけて蓄積された正体不明のレガシーコードや、ドキュメント化されていない厄介なエッジケースだらけのことも多い。

なぜわざわざ比喩に頼る必要があるんだろう？「イノベーション・トークン」という言葉は本当に役に立つのかな？

技術を適切に評価できないなら、そもそもエンジニアとして未熟だし、「退屈な技術を選べ」という言葉に救われることはないだろう。

座って要件を書き出し、候補を挙げて、適合性に基づいて判断する。それだけだよ。「退屈」なんて言葉は無意味だし、曖昧すぎる。 「十分なテストがされているか」「ユースケースに対してパフォーマンスが出るか」「開発者が使い慣れているか」、こうした指標こそが意味を持つんだ。

MySQLは退屈、Postgresも退屈、PHPもPythonもMemcachedもSquidもCronも退屈。

でも、これらすべてが、俺のキャリアの中でめちゃくちゃ面白くて悲惨な障害を引き起こしたことがあるよ。まあ、確かに「退屈」かもしれないけどね。

NodeJSでサイトを作るなら、トークンを1枚消費する。MongoDBを使うなら、また1枚消費する。

もしNodeJSやMongoDBに誰よりも詳しかったら？ なぜその技術が最適なのか、実証可能な根拠があったら？

技術の真の価値を評価する場を奪うような「シンプル」とか「退屈」といった抽象的な言葉が飛び交うこの界隈の空気感には、正直もう飽き飽きだよ。

こうした傾向の一部は、JavaScriptフレームワークが次々と入れ替わる時代への反動だったのかもしれない。同じような仕事をするための技術が多すぎたんだ。どれもそれなりには機能していたんだけどね。

一方で、IBMは集積回路への参入が遅れた。彼らにはSolid Logic Technologyという、トランジスタをセラミック基板に組み込んで小さくてもディスクリートな回路を作る自動化装置があった。それがIBM System/360の原動力になったわけだ。機能はしたけど、メインフレームの価格を高く維持することになり、結果的にIBMのミニコンピュータへの対応が遅れる原因になった。

課題が難しい時のイノベーションは興味深いものだ。米国の長距離爆撃機の歴史を見てみよう。B-29は効果的だったけどパワー不足で、フル積載での離陸にはかなり苦労した。だから第二次世界大戦後、次の開発としてB-36が登場した。これは「B-29を巨大化したらどうなるか？」という問いに対する答えだった[1]。プロペラ6基とジェットエンジン4基（設計サイクルの後半に追加された）を搭載していた。まさに空飛ぶハシケみたいなものだったけど、誰も撃墜しようとしない限りは機能した。今や飛行可能な機体は残っていない。あれは退屈な技術のアプローチだったね。

その次に登場したB-47は、「ジェット戦闘機を爆撃機サイズに拡大したら？」という問いに答えるものだった[2]。B-47は完全なジェット機で、プロペラはない。離陸を助けるために固体燃料ブースター（！）が必要で、着陸時には減速用パラシュートを使わなきゃいけなかった。操縦は最悪で、運用速度と高度は、失速とマッハバフェットが交差する「コフィンコーナー」に近すぎたんだ[3]。これも飛行可能な機体は残っていない。

そしてB-52が登場した。新しいエンジン、新しい機体、新しい設計[4]。これがハイリスクなアプローチだ。結果としてうまくいった。何百機もの機体が今も現役で、後継機のB-58 Hustler（超音速大陸間爆撃機）、B-70、F-111などのほとんどを長生きして生き残っている。

商業用ではボーイングがあるけど、最も成功した旅客機は1967年に初飛行したB-737の派生型だ。でも、それはまた別の話だね。

いや、今のところこれについてはHNに投稿しようとは思ってなかったんだけど、こういう反論があるなら、少なくとも共有しようかなと思う：https://www.iankduncan.com/engineering/2026-08-07-getting-freaky-in-the-age-of-ai

https://grugbrain.dev/ このトピックについてはこれも似たようなものだな。

このアドバイスは正しいけど、念頭に置くべき注意点がある。思いつく限りで2つほど。

1. 以前、分散型の追記専用ログとして主にCassandraクラスターを使っていた会社で働いていたことがある。この役割において、Cassandraはこれ以上ないほど完璧な適合性だった。認証用の分散データベースが必要になった時、社内に専門知識があったし（つまり「退屈な技術」だった）、しばらく相乗りできるクラスターもあったからCassandraを使うことにした。キーバリューストアが必要になった時も同じ理由で再びCassandraを選んだんだ。Cassandraにはここでは書けないような多くの問題があったけど、あえて言うならCassandraの守備範囲から外れすぎると崩壊の危機に直面するってことだ。そのせいでダウンタイムや辛い夜を何度も経験した。時には「退屈な技術」だけでは不十分で、それに見合った「退屈なワークロード」も必要なんだよ。

2. 私はRustの初期採用者だった。1.0が出る前は、この言語が本当にものになるのかどうか誰にも分からなかった。私には、プログラマーの手元に形式証明のアシスタントが渡されているように見えたし、すぐに明るい未来があることがわかった。当時は、Rustは「退屈な技術」じゃなかった。今では（一部のユースケースでは）そう言えるかもしれないけどね。確実な信頼性向上をもたらす、キラキラした新しい技術を採用するのはリスクじゃない。愚かなのは、使いこなすのが難しいのに「馴染みがある」というだけで、いわゆる「退屈な技術」に安住して妥協することだよ。

こういうエンジニアリング文化を持っているかどうか審査済みの求人サイトがあればいいのに。

「うちは実用主義者ですよ」と売り込んでいる求人はたくさんあるけど、いざ行ってみると開発者が5人しかいないのにリポジトリが50個あって、仕事の大半は「xという要件を新しいマイクロサービスにすべきか？」を議論することに費やされている。プロダクトといっても、エンティティが10個程度のWebアプリとAPIがあるだけなのにね。

まあ、そうやって人を繋ぎ止めているんだろうな。