退屈な技術を選ぶ (2015)

2026年8月14日原文(mcfunley.com)

概要

Kellan のリーダーシップの下で技術選定の重要性を学んだ経験
イノベーションのトークン という考え方で、技術革新のバランスを解説
「退屈な技術」 を選ぶことで安定性や運用性を重視する姿勢
全体最適化 と運用コストの観点から技術選定を行う重要性
新技術導入の際の 文化やプロセス の整備の必要性

Kellanのリーダーシップと技術選定からの学び

Kellan の下で働いたことがキャリア最大の転機
技術選定の成果が現れるまで在籍し、多くを学び取った経験
Data Driven Products Now! 執筆の自由を得た背景に、Kellanの的確な技術判断あり
Etsy退職後、再び技術への情熱を取り戻した実感
以降は Kellan流の技術観 のエッセンスを凝縮して紹介

イノベーションのトークン理論

企業には イノベーションのトークン が3枚程度しかないという仮説
NodeJSやMongoDB、最新のサービスディスカバリ導入で1枚消費
独自データベース開発のような過剰な挑戦は危険
本来のミッション （例：グローバルコマースの再定義）から逸脱しない選択が重要
SSHの革新など、限定的なリソースの無駄遣いは失敗のもと

「退屈な技術」の価値

「退屈＝悪」ではない。退屈で悪い技術は避けるべき
MySQL、Postgres、PHP、Python、Memcached、Squid、Cron などは「退屈で良い」技術
これらは 機能や障害時の挙動 が十分に理解されている
既知の未知 と 未知の未知 の違いを意識した技術選定
新技術ほど 未知の未知 が大きく、リスクが高い

全体最適化と運用コスト

退屈な技術 志向は良いが、それだけでは不十分
技術選定は チームや組織全体 に影響
新技術追加は 運用コスト や 認知負荷 を増加
既存のRuby環境にPythonを追加するなど、複雑さ増大の例
「 ベストツール主義」は短絡的で、長期運用コストを軽視
会社の存続 が最優先であり、「最小限の最悪」な選択が現実的

新技術導入のためのプロセス

Java一辺倒も極論であり、 新技術導入の余地 は必要
新技術導入は 社内での議論や可視化 が不可欠
まず「 現状の技術で解決できないか」を検証
新技術が既存技術と重複する場合、 移行計画とコミットメント を明確化
プロセスはシンプルで、 事前課題提出と会議 で十分
このプロセスを通過した新技術なら導入は問題なし

「Just Ship」と運用現実

ポリグロットプログラミング の自由は運用負荷を増大
技術選定の慎重さが 本質的な自由 を生む
技術自体が目的化するのは誤り
Etsy初期にPython技術者のために中間層を無理に作り、 運用負荷と遅延 を招いた失敗例
退屈な技術で構築した機能は 自然にスケールし、長期的な安定 をもたらす
ただし、 全てを退屈な技術で済ませるのは非現実的。必要に応じてSolrなど新技術も導入

まとめ

技術選定は「退屈で良い」技術の活用と、必要最小限の革新 のバランスが重要
運用コストや組織全体への影響 を常に意識した選択
新技術導入には透明性と合意形成 を重視
技術選定の本質は 会社の持続的な成長と安定運用 の実現

Hackerたちの意見

例えば、すべての会社が約3つのイノベーショントークンを持っているとしましょう。これらは好きなように使えますが、供給はしばらく固定です。これは私のお気に入りのブログ記事の一つで、「イノベーショントークン」というアイデアに要約できると思います。PMやエンジニアリーダーとしてのキャリアの中で、最も役立つ概念の一つです。実際に正しいトレードオフをするのに役立ち、同僚にそのトレードオフを説明するのにもさらに役立ちます。めっちゃおすすめです。

└

これに似た、もっと古い投稿があった気がするんだけど、「豆」についてだったかな。エンジニアが問題を解決するために使うやつ。確か「問題を解決するのにコストがかかるのは『豆』で、エンジニアはその『豆』をほとんど使い切るまで問題を解決しようとする」みたいな内容だったと思うんだけど。もしかしたら豆じゃなかったかも？でも、ずっと探してるんだ。

└

「ウィアードネスポイント」も似たようなものだよね。 https://www.lesswrong.com/w/weirdness-points

ソフトウェアは年々使えるものが、決して商品化されたことはない。見た目は退屈だけど、派手な投稿はない。でも、ほとんどの場合、新しいものよりも信頼性を選ぶよ。

└

だから、Goを試すのにこんなに時間がかかったんだ。紙の上では、言語として求めているものそのものに見えたのに。やっと試してみて、楽しんでるよ。

この投稿大好き。意外と物議を醸す内容で、あんまりエンジニアの友達が増えなかったな。

└

履歴書を作るには良くない。マネージャーや従業員は人気のあるものに報酬をもらうから、人気は主に新しさの要素による。だから、（社会的、そして経済的な）インセンティブ構造は、退屈な技術を選ぶこととは逆の相関関係にあるんだ。

└

うん、新しい技術をあれこれ試すのが好きな人にはあまり人気がないよね。でも、個人的にはこれがすごく役立ってきたよ。

この投稿好きだな。エージェントの時代に再訪するのも面白い。記事の言葉を借りるなら、「すべてのイノベーショントークンをエージェントに投入する」のは多分いい選択だと思う。つまり、エージェントが使う技術は全部退屈な技術であるべきってこと。別の言い方をすると、「分布内の技術を使う」ってことだね。もしエージェントがZigよりRustの方が圧倒的に得意なら、たとえZigの方が「良い」とされていてもRustを使うべきだと思う。Zigがどれだけ良いかは、分布内のエージェントがどれだけ優れているかに埋もれてしまうから。（これはRustが実際に良いという主張ではなく、議論のための仮定の話だよ。）

└

AIについて学んだことの一つは、例えばウェブサイトを作るなら、あまり好きじゃなくてもphp/ruby/elixirを選んだ方がずっと良いってこと。パイプラインやデプロイが、非常に一般的なTypeScriptのモノレポよりもずっと簡単で早くなるし、サーバーとクライアント間のコミュニケーションも同様に楽になる。TypeScriptとEffectのファンとして言うけど、phpやrubyに特別な愛着はないけど、速く、うまく、パフォーマンスやツールがすぐに得られる選択肢としては非常に優れているよ。

└

ちょっと脱線するけど、AIがRustの開発にすごく優れているおかげで、Rustプロジェクトを見たときの第一印象が完全に変わったよ。4、5年前なら、2つの選択肢を比べて、1つがRustで書かれていたら、そのプログラムは間違いなくスナッピーで速くて信頼性があって、著者も有能だって思ってた。でも今は、そのプロジェクトは多分「雰囲気でコーディング」されたものだって確信してる。まだ良いものになり得るとは言ってないけど、今は第一印象が全然違う。

└

エージェントは人気のあるものにデフォルトで行く傾向があって、それが退屈なものと重なることが多いけど、もっと退屈な方向に誘導することもできるよね。

Hacker Newsで議論の続きを見る

ハクソク