ソフトウェアは人を狂わせる

ソフトウェアは人を狂わせる

2026年9月10日

私には、ソフトウェアが人を狂わせるというささやかな仮説がある。

「ハワード・ヒューズのように30分ごとに手を洗う」といった意味ではなく、むしろソフトウェアを取り巻く状況が、普段は常識的な人々を比例感覚を失わせるのに驚くほど効果的である、という意味合いでだ。

私はこの現象を十分な回数、様々な角度から見てきたので、これが完全に性格の問題だとは思わない。

ソフトウェアは、スピード、お金、複雑さ、抽象化、そして考えをすぐに変えられるほぼ無限の自由を組み合わせている。それらは単独では全く問題なく管理できるものだが、それらを組み合わせると、本当に奇妙な副作用が出始める。

ほとんどのソフトウェアは、ブランディングやアーキテクチャ図を取り除けば、驚くほど退屈なものだ。ここにあるフォーム、あそこにあるAPIエンドポイント、権限、計算、ワークフローを散りばめ、どこかにデータベースを配置する。何かをスケールさせる必要があれば（あるいは冒険心を感じているなら）キューを追加するかもしれない。

しかし、たとえそれが厳しく聞こえても、ほとんどのソフトウェアは単なる「飾り立てられたスプレッドシート」に過ぎない。

それにもかかわらず、この種のものを生み出すプロセスは、ごく普通の大人をB級のボンドヴィランに変えてしまうことがある。プロジェクトは決して十分に速く進んでおらず、計画は突然の変化に常に柔軟でなければならず、そして「新しい」機能は常に「それ」になるものだ（しかし、前のスプリントで「それ」になるはずだったものとは違う）。

それが機能するか、スケールするか、十分な速さで進んでいるか、あるいは全く別のことをすべきか、といった新たな懸念が常に存在する。

ソフトウェアの奇妙な点は、これらのアイデアの多くが技術的に可能であることだ。それが問題の一部だ。アイデアとその実装の間には、自然な摩擦がほとんどない。もし家を建てていて、誰かがフレーミングの途中で、キッチンを建物の反対側にしたいと決めたら、誰もがその決定にはコストがかかることをすぐに理解する。

板はカットされ、配管は設置され、人々はすでに固定されたものを分解しなければならない。コストは物理的であるため、誰もそれが存在しないふりをすることはできない。ソフトウェアの場合、そのコストは人々の頭の中や、通常はすでに理解が難しいシステムの中に隠れてしまう。

ソフトウェアでキッチンを移動させることは、「簡単な修正」に見えるかもしれない。作業は依然としてコストがかかるが、実際の費用は静かに蓄積される。コンテキストスイッチング、リグレッションリスク、アーキテクチャの劣化の間で、失われた勢い、忘れられた仮定、そして「連携を取る」ための終わりのない会議が見つかる。

実際の複雑さに関わらず、変更が（ビールのように）無料だったと装うのは簡単だ。なぜなら、目に見えるほこりやスクラップがないからだ。問題は、ソフトウェアの変更が実際に安くできることがある、という事実によってさらに悪化する。

有用な調整は実際に1時間で済むかもしれないが、同様に単純に見える別の要求はシステム全体に波紋を広げ、障害を引き起こす可能性がある。その不透明さは、すべての「クールなアイデア」が緊急性を持ってロードマップに追加されるという危険な習慣を生み出す。

会議で誰かがアイデアを思いつき、アイデアと現実の間にはほとんど抵抗がないことが多い。「この画面の動作を変えられますか？」「ビジネスモデルを変更できますか？」「別の顧客セグメントを追いかけられますか？」「別のワークフローを導入できますか？」「独自のイベントシステムを構築できますか？」

答えはほとんど常に「はい、できます」というバリエーションになる。

やがて、「できる」は「すべき」になり、「すべき」は「なぜまだ終わっていないのか？」となる。ここでソフトウェアは人々の脳に奇妙なことをし始める。すべてが緊急になる。なぜならすべてが迅速に動くことができ、そしてすべての決定が戦略的に感じられるようになるからだ。なぜなら理論上のアップサイドは莫大になりうるからだ。

すべての技術的な選択もイデオロギー的になる。なぜなら、同じ問題を解決するための数十のもっともらしい方法があるからだ。すべての遅延は危機のように見える。なぜならどこかで、誰かが（おそらく）より速く動いているからだ。業界には、人々が「もう十分だ」と知るための自然なメカニズムがほとんどない。

ソフトウェアには「完了」の明確な定義はほとんどない（この態度をよく示している『ソーシャル・ネットワーク』のクリップを渋々共有する）。

大工は、キャビネットが存在するため、最終的にハンマーを置く。しかし、ソフトウェアは常に改善できる。「ボタン」はより良くできるかもしれないし、「クエリ」はより速くできるかもしれないし、「抽象化」はよりクリーンにできるかもしれないし、「オンボーディング」はより多くの人をコンバートできるかもしれないし、「インフラ」はさらにスケールできるかもしれない。製品は隣接市場に拡大できるかもしれないし、価格設定は変更できるかもしれないし、会社全体がより収益性の高い方向性を発見したと決定するかもしれない。

ポイントは、もしそれが存在することを望むなら、常に手の届くところに別のレバーがあるということだ。

これが、ソフトウェア組織が非常に神経質になる理由の一つだと思う。彼らはレバーに囲まれており、レバーに囲まれた人々は最終的にそれらを引っ張り始める。

時には、本当に問題があるから引っ張る。他の時には、彼らは恐れているから、ボードが成長を求めているから、競合他社が何かを出荷したから、今月の数字が横ばいだったから、あるいは他に何をすべきかわからないから引っ張る。

数日ごとに方向転換する創業者は「市場に対応している」と神話化される。人々をより速く動くよう絶えずプレッシャーをかけるマネージャーは、実行に集中していると見なされ、インフラコンポーネントをいくつか導入するエンジニアは、スケールを考えていると賞賛されるかもしれない。コンバージョンがわずかに低下したため、動作しているインターフェースを再構築するプロダクトチームはイテレーションしており、別のカテゴリが突然ファッショナブルになったため、元のアイデンティティを放棄する会社はピボットしている。

この言語の一部は、根本的な動機が正当であるために存在する。速く動くべき時、ピボットすべき時、そしてアーキテクチャが本当に変更されるべき時がある。ソフトウェアを危険なものにしているのは、取り得る行動の存在と、実際に行動を取る必要性を混同するのがいかに簡単かということだ。

そして、これが十分に悪くないとしても、お金はすべてにガソリンを注ぎ込む。

少人数のグループが部屋に座って数年間（あるいは今ではエージェントを指示して）タイプすることで、数億ドル相当のものを plausibly に生み出せる産業は非常に少ない。その可能性は、伝統的に退屈な仕事（オタクでない人にとって）の感情的な重みを変える。

まともな人々がボタンについて1時間議論するのを見ることができる。なぜなら、会話の奥底で、そのボタンが将来の山のようなお金と結びついているからだ。

それが起こると、通常の判断は投げ捨てられる。仕事は、ボタンが何か有用なものに結びついているかどうかではなくなり、人々が会社がなるかもしれないと望むすべてものの重みを帯び始める。

複雑さは同じギャップを埋めるために殺到する。ソフトウェアは、複雑さを重要に感じさせるのが異常に得意だ。なぜなら、複雑なシステムは通常の問題をより深刻に見せるからだ。

データベースにレコードを保存し、人々が編集できるようにする退屈なアプリケーションは、特に印象的ではないように聞こえる。一方、分散イベント駆動プラットフォーム、サービスメッシュ、リアルタイム同期レイヤーは、NORAD を構築しているように聞こえる。

時には本当に複雑なものが必要になる。ほとんどの場合、おそらくそうではない。しかし、複雑なシステムは、単純なシステムが提供しない心理的な報酬を提供する。それらは人々に設計し、議論し、所有し、最適化し、書き直し、図示し、ベンチマークし、そして話すためのものを提供する。複雑さは仕事を生み出し、仕事は重要性の空気を生み出す。重要性はステータスを生み出し、すぐにシステムは、システムをサポートするために存在する組織をサポートするために部分的に存在するようになる。すべてが、内側から気づくのが驚くほど難しい方法で自己強化される。

これらすべての下に、さらに深い魅力もあると私は推測する。ソフトウェアは私たちに異常なほどのコントロールを与えてくれる。なぜなら、コードは、あなたが望むものを十分に正確に記述でき、機械がその指示に確実に従うことができる数少ない場所の一つだからだ。現実の残りははるかに協力的ではない。

現実は乱雑で頑固だが、ソフトウェアは、乱雑さ—技術的または概念的—がデバッグされるのを待っている問題であるという印象を与えてくれる。

だから、私たちはソフトウェアの周りのすべてをデバッグしようとし始める。成長は遅いので、ファネルを変更する。顧客は混乱しているので、製品を再設計する。開発は遅いので、プロセスを変更する。プロセスは遅いので、ツールを変更する。会社は苦労しているので、再編成する。そして、もしそれがまだ苦労しているなら（そしてベンチャーキャピタルに依存しているなら）、おそらくピボットする。

操作できる変数は常に存在する。

最終的に、会社自体がソフトウェアのように扱われ始める。永久に可変で、永久に未完成で、そして永久に、リファクタリング一つでまともに動作するようになる。ここで狂気が本当に定着する。なぜなら、誰も何もそのままにしておけないからだ。

物事をそのままにしておくことは、過小評価されているエンジニアリングスキルだ。キャリアのある時点で、驚くほど多くの良い仕事が、すでに機能しているものに触れないことから生まれることを理解し始める。データベースは常に置き換える必要はないし、フレームワークはしばしば大丈夫だし、オンボーディングは今週も再設計する必要はない。

アーキテクチャは10億人のユーザーを予測する必要はないし、ロードマップは誰かがツイートに興奮したからといって変更する必要はない。製品はプラットフォームになる必要はないし、会社は四半期ごとにアイデンティティを再発見する必要はない。時には、そのものはただそこに座って機能する必要があるだけだ。

顧客は製品を見つけるのに時間が必要な場合がある。エンジニアはシステムを理解するのに時間が必要な場合がある。そしてビジネスはビジネスになるのに時間が必要な場合がある。これらのどれも特に深遠には聞こえないが、ソフトウェア文化は忍耐に対して驚くほど敵対的だ。忍耐は無活動と疑わしく見え、速度に夢中になっている業界では無活動を正当化するのは難しい。

だから私たちは活動を作り出す。私たちは出荷し、イテレートし、最適化し、ピボットし、リプラットフォームし、考え直し、そして再発明する。元の問題が、私たちが上に積み重ねたすべてのもののもとでほとんど見えなくなるまで。そして数年後、誰かが静かに元の単純なものを再構築することを提案する（しばしば、その洞察を可能にした導きの光として、彼ら自身の正義感のある知恵を指し示しながら）。

私は、遅く動くことが遅く動くことのためだけの答えだとは思わない。それは単なる別のイデオロギーになるだろうし、ソフトウェアにはすでに十分なイデオロギーがある（神よ、私たちを助けてください）。答えは比例だ。

それは、すべての問題が存在論的であるわけではないこと、すべてのアイデアがロードマップに載るべきではないこと、そしてすべての抽象化が存在する価値があるわけではないことを理解することだ。それは、すべての減速が介入を必要とするわけではないこと、すべての競合他社が重要であるわけではないこと、そしてすべてのソフトウェアがプラットフォームになる必要はないことを受け入れることだ。それはまた、すべての会社が世界征服を求める必要はないことを覚えておくことでもある。

繰り返すが、ほとんどのソフトウェアは、これらすべての装飾にもかかわらず、依然として飾り立てられたスプレッドシートだ。それは侮辱として意図されたものではない。スプレッドシートは有用であり、（実際に）有用なソフトウェアは十分だ。

しかし、もし私たちが実際に何をしているのかを覚えていれば、私たち全員がもう少し健全になるかもしれない：私たちの生活と他人の生活を楽にするためのツールを作っているのだ。Margaritavilleで、いじる必要のないものをいじくり回して浪費するのではなく。