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

ハッカソンの最終日、午後1時、残り5時間。過去2時間、私たちはゼロ進捗でした。私が「Lovable」が生まれた日を呪っているからです。一つの問題を修正すると、別の問題が現れ、私たちのアプリはほとんど使えません。 スタートは非常に有望でした。私は2人のエンジニアリングの友人、3人のリクルーターと一緒に「HoneyCrew」というスマートなリファラルシステムを構築することにしました（目標は、私たちの募集中のポジションについて、各従業員のネットワークから潜在的な候補者を集めた週次サマリーを送信することでした。オープンソース版はこちらです）。私たちは、リクルーターチームが後で自分でメンテナンスできるように、「Lovable」を採用することにしました。初日、私たちは90％のプロジェクトを完了し、驚異的なスピードで進みました。スクレイピング、スコアリング、Slack連携、管理機能など、ほぼ準備完了に見えました。2日目（最終日）には、いくつかのマイナーな改善に取り組みましたが、すべてが…完全に壊れました。いたるところに終わりのないバグ、遅延、そして全員が超ストレス状態でした。チームのリクルーターたちは何がうまくいかなかったのか理解できませんでした。私たちは素晴らしい製品を作る道を歩んでいたのに、デモのために何も準備できない危険にさらされていました。どうしてこうなったのでしょう？ 「インフラ作業」へのアレルギー 私は、「リファクタリング」と「インフラ作業」という言葉にアレルギーがある、という上級リーダーと一緒に働いたことがあります。なぜ最初から正しく構築できないのか、なぜいつもそんなに遅いのか、彼は理解できませんでした。LLMが登場してからは、さらに悪化しました。彼は常にこう尋ねました。「このタスクをChatGPTに任せることはできないのか？問題は何だ？」彼の功績を称えるなら、彼は少なくとも私たちの顔を見て尋ねました。私は、多くの非技術系のリーダーが、エンジニアは常に誇張して仕事が遅すぎると考えていることを知っています。これは、私が先週話した、古いソフトウェアエンジニアリング戦争のフレーバーです。 同僚（そして親しい友人）はかつてこう表現しました。「あなたはコードを書く。それはあなたが理解できない言語の単語に過ぎない、右？固定された意味を持つ。そしてあなたは、従うべき仕様があるので、何を言いたいのかを知っている。どうしていつももっと複雑になるんだ？」 ふむ。私はこれを説明するのに苦労していましたが、ほとんど家を買うところでした。 想像してみてください、あなたのソフトウェアが家だったとしたら 昨年10月、私たちは義父母の近くで売りに出されている家を見ました。良い場所、良い隣人、私たちが欲しかった庭があり、非常に手頃な価格で、素晴らしい取引のように見えました。小さくて築30年でしたが、低価格のおかげで、リフォームに余分なお金を使うことができました。そこで、請負業者に尋ねました。「それをリフォームして、さらに2部屋増築するにはいくらかかりますか？」 彼の返答に、私は笑いを止めることができませんでした。 「お勧めしません。古すぎます。すべてを破壊してゼロから建てる方がはるかにシンプルで安価です。」 彼は素晴らしいソフトウェアエンジニアになれたかもしれません… 私たちはその家を見送りましたが、それ以来、ソフトウェアについて話すときに家の例えをよく使っています。家を建てるプロセスは何千年もの間知られており、それでも新しい家はそれぞれ異なる問題を抱えています。そして誰もが家に住んでいるので、共感しやすいです。 例えば： なぜ問題を素早く解決できないのですか？なぜいつも大きくなるのですか？ あなたの屋根が漏れています。床にバケツを置くか、根本原因を見つけることができます。それがあなたの家なら、どうしますか？ええ、数日間はバケツで大丈夫かもしれませんが、絶えず空にする必要があり、本当の問題が悪化するリスクがあります。 なぜその特定のユースケースだけを、あの「インフラ」なしで解決できないのですか？ あなたの家族のために新しい家を建てたとしましょう。あなたは最初の階だけを建てる予算しかありませんが、大家族がいて、数年後には2階も欲しいとわかっています。2階を実際に欲しいと思ったときよりも、今、2階を支えるインフラを追加する方がはるかに安価です。 決して完成しない家 ハッカソンの最終日、午後1時、すべてが壊れているように感じます。私たちは他に選択肢がありませんでした。私たちはバイブコーディングの熱狂を止め、一度に一つの領域を注意深く調べ、単純なデモ可能なフローが機能するまで作業しました。理解する、計画する、実装する。初日のペースよりもはるかに遅いですが、少なくともデモ可能なフローを機能させることができました。このプロセスこそが良いソフトウェアが構築される方法ですが、前進を急ぐあまり、それは非常に忘れられがちです。そして、家とは異なり、あなたは決してそれを完全に建て終えることはありません。そのため、人々がすでに住んでいる間に、常に設備を更新する必要があります。 今週のお気に入りの読み物 コードレビューのボトルネックにならないようにする。コードレビューの疲労を異なる方法で処理するための非常に興味深く実践的なアプローチ（ヒント：より速く行うのではなく、エージェントにすべてを委任するのではなく）。 「インスピレーションを与える」とは実際にはどういう意味か。あなたはサウロンと戦うために男たちを鼓舞するヴィゴ・モーテンセンではありません。あなたはテクノロジーのエンジニアリングマネージャーです。この文脈でインスピレーションを与えるとはどういう意味か。 2026年のテクノロジー労働者はどのように感じているか：二極化する労働力。Lenny's newsletterの非常に興味深い調査。特にテイクアウェイ#9が私たちに関連しています。 極めて効果的なマネージャーを持つ労働者は、効果のないマネージャーを持つ労働者と比較して、仕事の満足度が約65％高く、燃え尽き症候群が劇的に低いと報告しています。しかし、テクノロジー労働者のわずか25.5％がマネージャーを非常に効果的だと評価しており、36.5％が効果がないと評価しています。 これを役立てられるマネージャーを知っていますか？ 共有 次号をメールで受け取る エンジニアリングマネージャー向けの週1回のメール。スパムなし、いつでも解除可能。 メールアドレス 登録 あなたにおすすめ 「ネガティブスプリット」ソフトウェアエンジニアリング効果 ソフトウェアエンジニアリングのカロリー：cal.aiは何を言いますか？ AIツールをエンジニアに強制するのをやめる