ビジネス関係者にソフトウェア開発が依然として困難である理由を説明する

ビジネスパーソンにソフトウェア開発が依然として難しい理由を説明する

ハッカソンの最終日、午後1時、残り5時間。過去2時間は全く進展がありませんでした。Lovableが生まれた日を呪っています。一つの問題を修正すると、別の問題が現れ、私たちのアプリはかろうじて使える状態です。

スタートは非常に有望でした。私はエンジニアの友人2人とリクルーター3人に加わり、「HoneyCrew」というスマートなリファラルシステムを構築しました（目標は、オープンポジションの候補者候補を毎週従業員に要約して送信することでした。これはオープンソース版です）。リクルーターチームが後で自分たちで保守できるように、Lovableを採用することにしました。

初日、私たちはプロジェクトの90％を完了し、順調に進みました。スクレイピング、スコアリング、Slack連携、管理画面など、ほとんど完成に近い状態でした。

2日目（最終日）、いくつかのマイナーな改善に取り組んだところ、すべてが…完全に壊れてしまいました。バグが延々と発生し、動作は遅くなり、全員が非常にストレスを感じていました。

チームのリクルーターたちは何がうまくいかなかったのか理解できませんでした。私たちは素晴らしい製品を作る軌道に乗っていたのに、デモのために何も準備できない危険にさらされていました。

なぜこうなったのでしょうか？

「インフラ作業」へのアレルギー

私は以前、リファクタリングやインフラ作業という言葉にアレルギーがあると言うシニアリーダーと一緒に働いていました。彼は、なぜ最初から正しく構築できないのか、なぜいつもそんなに遅いのかを理解できませんでした。LLMが登場してからは、さらに悪化しました。彼は常にこう尋ねました。「このタスクをChatGPTに任せることはできないのか？問題は何だ？」

彼の良い点としては、少なくとも私たちの顔を見て質問してくれたことです。多くの非技術系のリーダーは、エンジニアは常に大げさに言ったり、作業が遅すぎたりすると考えていることを私は知っています。これは、先週話したソフトウェアエンジニアリング戦争と同じ種類のものです。

同僚（そして親友）はかつて、これを次のように表現しました。「あなたはコードを書く。それは私が理解できない言語の単語に過ぎない、そうだろう？固定された意味を持つ。そして、あなたは自分が何を言いたいのかを知っている。仕様に従う必要があるのだから。なぜいつももっと複雑になるんだ？」

ふむ。

私はこれを説明するのに苦労していましたが、家を買おうとした時に、あることに気づきました。

ソフトウェアを家だと想像してみよう

昨年10月、私たちは義父母の近くで売り出し中の家を見ました。良い立地、良い隣人、欲しかった庭があり、非常に手頃な価格で、素晴らしい取引のように見えました。小さくて築30年でしたが、低価格のおかげで、リフォームに余分な費用をかけることができました。

そこで、請負業者に尋ねました。「リフォームして、さらに2部屋増築するにはいくらかかりますか？」

彼の返答に、私は笑いを止めることができませんでした。
「お勧めしません。古すぎます。すべてを破壊してゼロから建てる方が、はるかに簡単で安価でしょう」。

彼は素晴らしいソフトウェアエンジニアになれたかもしれません…

私たちはその家を見送りましたが、それ以来、ソフトウェアについて話すときに、家の例えをよく使うようになりました。

家の建築プロセスは何千年もの間知られていますが、それでも新しい家はそれぞれ異なる問題を抱えています。そして誰もが家に住んでいるので、共感しやすいのです。例えば：

なぜ問題を速く修正できないのですか？なぜいつも大きくなるのですか？

屋根が漏れています。床にバケツを置くか、根本原因を見つけるかのどちらかです。それが自分の家なら、どうしますか？

ええ、バケツは数日間は大丈夫かもしれませんが、絶えず空にする必要があり、本当の問題が悪化するリスクがあります。

なぜ「インフラ」なしで、この特定のユースケースだけを解決できないのですか？

新しい家を家族のために建てるとしましょう。予算は1階分しかありませんが、大家族で、数年後には2階も欲しいとわかっています。

2階を支えるインフラを追加することは、実際に2階が必要になったときに追加するよりも、今追加する方がはるかに安価です。

完成しない家

だから、ハッカソンの最終日午後1時、すべてが壊れているように感じられました。

他に選択肢はありませんでした。私たちは気分でコーディングする frenzy を止め、一つずつ慎重に領域を調べ、シンプルなデモ可能なフローが機能するまで作業しました。理解し、計画し、実装する。1日目のペースよりはるかに遅かったですが、少なくとも動作するデモ可能なフローで終わることができました。

このプロセスが良いソフトウェアが構築される方法ですが、前進を急ぐあまり、あまりにも簡単に忘れられてしまいます。そして家とは異なり、あなたは決して建築を終えることはありません。そのため、人々がすでに住んでいる間に、常に設備を更新する必要があります。

今週のお気に入りの記事

1. Stop being the code review bottleneck。コードレビューの疲労を異なる方法で処理するための非常に興味深く実践的なアプローチ（ヒント：より速く行うのではなく、エージェントにすべてを委任するのでもない）。

2. What being "inspiring" actually means。あなたはサウロンと戦う男たちを鼓舞するヴィゴ・モーテンセンではない。あなたはテクノロジー業界のエンジニアリングマネージャーだ。この文脈でインスピレーションを与えるとはどういうことか、ここに説明がある。

3. How tech workers are feeling in 2026: a workforce splitting in two。Lenny's newsletterの非常に興味深い調査。テイクアウェイ#9は私たちにとって特に重要だ。
   非常に効果的なマネージャーを持つ労働者は、効果のないマネージャーを持つ労働者と比較して、約65％高い仕事の楽しみを報告し、燃え尽き症候群が劇的に低下する。しかし、テクノロジー労働者のわずか25.5％がマネージャーを非常に効果的だと評価しているのに対し、36.5％は効果がないと評価している。