ソフトウェア開発は、冷静に見ればただの業務改善や道具づくりにすぎません。ところが現場に入ると、議論は急に熱を帯び、判断は極端になり、関係者の振る舞いまで少しおかしく見えてくることがあります。今回の元記事は、その妙な変化を「ソフトウェアは人を狂わせる」というかなり強い言い方で説明しています。大げさな比喩に見えますが、開発に関わったことがある人なら、どこか身に覚えがある話ではないでしょうか。
元記事の著者は、ソフトウェアには人の感覚を狂わせる条件がそろっていると見ています。速さ、金、複雑さ、抽象度の高さ、そして方針をいくらでも変えられる自由。これらは単体なら扱えるのに、組み合わさると妙な副作用を生むというわけです。著者は、華やかな名称や図に隠れて見えにくいだけで、世の中の多くのソフトウェアは実際には「フォーム、API endpoint、権限、計算、workflow、database」が並んだ地味なもので、せいぜい queue が足される程度だと述べます。そして辛辣に、結局は「格好のいい spreadsheet にすぎない」と言い切ります。
ただ、つくる過程はそこまで素朴ではありません。ソフトウェアの仕事は、変更のコストが目に見えにくいのが厄介だと著者は言います。建物なら、途中で台所を反対側に移すと言えば、配管や板材を壊す現実的な損失がすぐ分かる。けれどソフトウェアでは、そのコストは頭の中やシステムの内部に隠れ、context switching、regression risk、architecture の劣化、失われた momentum、忘れられた前提、そして「足並みをそろえる」ための会議として静かに積み上がる。しかも実際には、変更が本当に安い場合もあるため、「これはすぐできる」という気軽な提案が roadmap にどんどん載ってしまう。
すると会議の中では、「これできるよね」が「やるべきだ」に変わり、最後には「なぜまだ終わっていないのか」となる。著者が問題にしているのは、可能性があることと、実際に着手すべきことの区別がつきにくい点です。ソフトウェアでは、button の見た目、query の速さ、抽象化のきれいさ、onboarding の改善、infra の拡張、隣接市場への進出、pricing の変更まで、次々にレバーが見えてしまう。しかもレバーが多いほど人はそれを引きたくなる。そこに money が加わると、たかが button の話が将来の巨大な利益に結びつき、普通なら適度で済む判断が急に重くなる。
さらに複雑さも拍車をかけます。単純なアプリより、distributed event-driven platform や service mesh、realtime synchronization layer のような仕組みのほうが、いかにも重要そうに見える。しかしその「重要そう」は、しばしば心理的な報酬でもある。設計できる、議論できる、所有できる、最適化できる、図にできる、ベンチマークできる。複雑さは仕事を生み、仕事は重要そうな空気を生み、重要そうな空気は status を生む。そのうちシステムは、組織を支えるために存在し、組織はシステムを支えるために存在するようになる。
著者は、ソフトウェアが人に強い支配感を与えることにも触れます。コードは、やりたいことをかなり正確に書けば、機械がその通りに動いてくれる数少ない場所です。だから現実のあらゆる曖昧さまで debug できる気がしてくる。成長が鈍ければ funnel を変え、顧客が混乱していれば product を再設計し、開発が遅ければ process を変え、process が遅ければ tools を変える。会社が苦しければ reorganize し、それでもだめなら pivot する。そうやって会社そのものが、永久に書き換え可能で、永久に未完成で、永久に refactor の途中みたいに扱われるようになる。著者は、そこで本当に必要なのは速度信仰ではなく「proportion」、つまり物事の大きさに見合った扱い方だと締めくくります。すべてを重大事件として扱わず、すべてのアイデアを roadmap に乗せず、すべての会社が World Domination を目指す必要はない。ソフトウェアは結局、人と生活を少し楽にする道具であって、触り続けること自体が目的ではないのだと。
この文章でいちばん鋭いのは、「できる」と「やるべき」を同じ箱に入れてしまう危うさを、かなり具体的に描いている点だと思う。ソフトウェア業界では、技術的に可能なことがそのまま正当化の材料になりやすい。しかも変更コストが見えにくいので、会議の席では「それ、すぐできますよね」と言うほうが得をする。結果として、意志決定が現実ではなく想像上の摩擦で進んでしまう。
ただ、これはソフトウェアだけの話ではない。管理可能なパラメータが多い仕事ほど、人はつい操作欲に引っ張られる。マーケティングでも組織運営でも、数字を動かせると分かると、つい何かを動かしたくなる。ソフトウェアが厄介なのは、その「動かせる感覚」が非常に強いことだと思う。ボタンひとつ、設定ひとつ、APIひとつで、世界が少し違って見える。だから現場では、慎重さよりも機動力が美徳として語られやすい。だが著者の言う通り、その機動力はしばしば判断の粗さを隠す。速く動けることは、何でも動かしてよい免罪符ではない。
元記事は、複雑な仕組みが重要そうに見える心理をかなり正面から批判しています。これは実務の現場でもよく起きる話で、まだ小さい組織ほど「将来のために作る」という言葉が強く働きます。もちろん、将来を見据えた設計自体は必要です。ただ、将来像があいまいなまま複雑な基盤だけが増えると、それは備えではなく安心感の演出になりやすい。
私が引っかかったのは、複雑さが仕事を生み、その仕事が重要性を生み、その重要性が status を生む、という循環の描写です。これ、かなり痛いところを突いていると思います。大きなアーキテクチャの話をしていると、当事者は「会社を前に進めている」気分になれる。だが実際には、既存の単純な仕組みでも十分に回る場面は多い。そこを見誤ると、platform 化や再構築が目的化する。しかも、いちど組織がその空気に慣れると、「作り直すこと」が「良い仕事」だと信じ込まれやすい。著者が警戒しているのは、技術そのものより、技術を使って自分たちの存在意義を膨らませる振る舞いではないかと思う。
元記事の後半で印象に残るのは、「leave things alone」、つまり、あえて触らない能力を過小評価するなという主張です。これは開発現場ではかなり逆説的に聞こえます。エンジニアは通常、改善すること、整理すること、更新することに報酬を感じやすいからです。でも、すでにうまく動いている database を置き換えない、framework を無理に換えない、onboarding を今週また作り直さない、という判断のほうが、長い目では価値が高い場面は少なくない。
ここで大事なのは、怠けることではなく、変える理由を絞ることだと思います。この記事は「遅くしろ」とは言っていない。そこは誤解したくないところです。著者が求めているのは、速度ではなく比率です。問題の大きさに比べて、どれだけの変更が本当に必要か。外部のノイズに反応して、すべてを再設計の対象にしていないか。成長が鈍いからといって、製品そのものを疑いすぎていないか。そういう問いを持てる組織は、たぶん少しだけ正気を保ちやすい。
私は、この文章を単なる愚痴として読むのはもったいないと思います。著者が言いたいのは、ソフトウェア開発者や経営者が特別に変わっているというより、ソフトウェアという媒体が、人の欲望や不安を増幅しやすいということです。変更できる、測定できる、伸ばせる、やり直せる。その便利さが、逆に節度を奪う。だからこそ、良いチームほど「何を変えるか」だけでなく「何を変えないか」を考える必要がある。
実際、プロダクトが伸びる局面でも、会社が苦しい局面でも、いちばん簡単なのは何かを動かすことです。新機能を足す、構成を変える、基盤を入れ替える、組織図を描き直す。変化は目に見えるし、行動している感じもある。でも、著者が最後に戻ってくるのは、そんな派手な動きではなく、地味に働く道具を地味に作るという原点です。ソフトウェアは世界を支配するための装置ではなく、人の手間を少し減らすための道具だ、という感覚を忘れると、たしかに人はおかしくなりやすいのだと思います。
