数兆円が無駄に…巨大ソフト開発が失敗し続けるのはなぜだ？
引用元：https://news.ycombinator.com/item?id=46045085
記事は素晴らしいけど、解決策の部分はちょっと違うかな。俺が思う解決策は、まず小さいものを作って、本番で使ってから機能を追加していくことだよ。例えば、全国規模の給与システムなら、まず小さな町で50人分の給与で試して、バグを直してから徐々に規模を大きくしていくべきなんだ。小さい規模や中規模でちゃんと動くことを確認せず、いきなり大規模なソフトウェアを信頼できる開発プロセスなんてないんだから。
それはプロダクトには通用するけど、ソフトウェアシステムには違うんじゃないかな。段階的に成長させると、プロダクト側がどんどん機能を追加するから、技術的負債が溜まっていく一方だよ。結局、全部書き直したくなるけど、何が重要か分からなくなって身動きが取れなくなるんだ。スケールはProductとEngineeringで別問題だよ。WhatsAppみたいに、最初はシンプルなProductでも、最初から大規模に設計されたEngineeringシステムはたくさんあるんだ。
前のコメントの「徐々に規模を大きく」っていうのに賛成だね。俺は大規模小売チェーンのPOSシステム入れ替えPJで、最初は変な2店舗（社食と余剰品店）に先に導入したんだ。余剰品店は取引が少なくて手動で修正できたし、社食は給与控除だからPCIの問題もなく試せた。そのおかげで期限通りに導入できたけど、それでも10月にやっかいなバグが出たよ。もし最初から普通の店舗でやってたら、とんでもないことになってたと思うとゾッとするね。
原則的には、新しいシステムを既存のシステムと並行して「ダミーモード」で動かせば、同じ結果が出ること確認できたんじゃないかな。つまり、段階的な導入には色々なアプローチがあるってことさ。
PCIの問題があるから、それは簡単じゃないんだ。クレジットカードリーダーとか、バーコードスキャナーみたいな入力デバイス、キーボード入力も全部違ったし、ハードウェアの問題も絡んでくるんだ。古いシステムはDOSベースで専用のFキー配列だったけど、新しいのはLinuxベースでUSB接続だったんだよ。だから、キーボード、スキャナー、クレジットカードのイベントを別のレジに送るなんて無理だったんだ。
PCIって何？ごめん、専門用語には詳しくなくて。
PCIはPayment Card Industry、PCI DSSはData Security Standardだよ。開発環境と本番環境は絶対に混ぜちゃダメ。PCI DSS監査に落ちたら、高額な罰金か、最悪クレカ処理停止で会社が閉鎖されることもあるんだ。開発コードは他人の金に触れないようにすべき。だから、VisaやMastercardを使わずに本番負荷を試せる社食テストは重要だったし、取引が少ない店舗で古いクレカプリンターにフォールバックできたのも大きかった。
https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec…
https://listings.pcisecuritystandards.org/documents/PCI-DSS-…
https://en.wikipedia.org/wiki/Digital_card#Financial_cards
https://en.wikipedia.org/wiki/Credit_card_imprinter
大規模に使うシステムを設計することと、最初から大規模で動かすシステムを構築・導入することは違うんだ。それは災害のレシピだよ。「100人も扱えるか分からないのに、いきなり100万人に使わせよう」なんてね。WhatsAppだってリリース初日から何億人ものユーザーは扱えなかったし、そうしようともしなかった。少しずつ構築して、ちゃんと動くことを確認していくべきなんだ、まともな開発者ならね。
本番システムのログがあるんだろ？それを開発環境に持ってきて実行すればいいんじゃないか。最終結果が同じであることを確認すればいいんだ。実際に開発環境を本番システムの隣に置く必要はないよ。
実カード番号をテストデータとして使うのは絶対無理だよ。本番環境とテスト環境で同じトランザクションを流して比較するのはできない。新しいシステムに価格やUPCを入力して計算が合うか検証はできるけど、それはPOSシステムの基本機能だけ。エンドツーエンドのトランザクションテストは、隔離された環境で合成データを使ってやるべきだね。
再現は多少フェイクになっても気にしなくていいよ。重要なのは、できるだけ良いテストをすることだ。例えば、偽のクレジットカード番号を使い、偽アカウントに紐付けた偽のトランザクションサーバーを用意できる。記録上で残高がないとされない限り、常に十分な残高があるようにね。
WhatsAppは元Yahooの2人がErlangっていう強力なバックエンド技術を選んで作ったんだ。最初のバージョンでは数百万スケールは考慮してなかっただろうけど、彼らは1）何が必要か知っていて、2）最初から数百万ユーザーへスムーズに移行できる良い技術を選んでた。FacebookがPHPからC++コンパイラを作ったような苦労はなかったよ。これは正しいツールとアイデアで始める重要性を示してるね。でも、これはスキルが必要だ。
うん、でもちゃんとやれば、段階的なデプロイメントは比較的素早くスムーズに進むよ。FAANGが大規模なユーザーに新機能や製品を展開する方法だね。実際のロールアウトは、大規模スケールを処理するために最初にアーキテクチャ設計が必要だったことの実装詳細に過ぎないんだ。
「スケーラブルなソフトウェアを作るプロセスはない」っていう君の意見は違うと思うな。UK gov Development Serviceは数千万人が初日から使う巨大システムを何度も作ってるし、Swift bankingも何億人ものユーザーに信頼性の高い機能を提供してる。正直、少人数から始めなくても、堅牢でスケーラブルなソフトを信頼性高く実現してる組織の例はたくさんあるよ。
Linus Torvaldsの言葉が一番的を射てると思う。「大きなプロジェクトを始めるな。小さいプロジェクトから始めて、大きくなると期待するな。もし期待したら過剰設計になるか、その大きさに恐れをなすだろう。だから小さく始めて詳細を考えろ。すぐに解決するニーズがなければ、それは過剰設計だ。人が助けてくれると期待するな。半分くらい役立つものを作れば、他の人が『これ、俺にも役立つかも』と言って参加してくれる。」
「段階的成長は技術的負債を招く」って、なんでソフトウェアの絶対法則みたいに言いきれるんだ？大規模システムをウォーターフォールで作るのが不可能だって話じゃない。可能だけど、失敗率がヒドかったからリーンスタートアップとか「Do things that don’t scale」って哲学が生まれたんだろ。これは単に「ライフスタイル」ビジネス向けの助言じゃなかったんだよ。
こういうプロジェクトが失敗するのは技術的な理由じゃないよ。政治的な思惑や利権が絡んでくるからだ。「数兆円」が無駄になるのは、みんなが何百万ドルも稼ぎたいからさ。「偉い人」がフォントサイズやボタンの位置に口出ししてくるのも、自分が重要だと主張したいからだよ。複数の会社が関われば、責任のなすりつけ合いになる。合理的なアプローチだけじゃ解決しないんだ。
WhatsAppがErlangで成功したのは、Erlangのおかげなのか、それともErlangだったのに成功したのか？一つの事例から確かな結論は出せないよ。もしかしたら、別のプラットフォームの方がもっと良かったかもしれないだろ？
速いバスを作っても月には行けないよ。多くのソフトは初期の小規模スケールが設計のあらゆるレベルに組み込まれてるからダメなんだ。最高のソフトは常に最大スケールから始めて、将来の拡張計画も立ててる。CommVaultみたいにね。小さく始めて大きくなったソフトは、ユーザー選択のドロップダウンみたいな、後で直すのがめちゃくちゃ大変な設計ミスを犯しやすい。ISBNが完全にユニークじゃないように、最初から大規模を想定しないと破綻するんだ。
匿名化された本番データを使えば、開発環境でも本番データを使ってテストできるじゃん？セキュリティルールに従いつつデータを匿名化すれば、DSSにも準拠できるしね。
システム全体を理解する人間がいるのが一番重要だよ。小さくて成功するシステムを作って、ユーザーと開発者両方から支持を得て、お金を払ってもらってシステムを理解し育てていくのが成功の秘訣だね。大規模プロジェクトで「90%失敗」はよくある話で、リスクを考えると着手すべきじゃないってこと。
でも、匿名化データだと現実とどんどんかけ離れちゃうんだよね。カード番号が偽物だと、CVCとかPINも合わなくなるでしょ？それも全部偽物にしたら、結局何をテストしてるのかわからなくなるんじゃない？
政治的な駆け引きや、いろんな人が口出ししたがるのが失敗の原因ってのは、必ずしも間違いじゃないよね。「何兆円も使われた」って聞けば、数億円稼ぎたいって人はたくさんいるでしょ？小さく始めれば、重要な人たちは「つまらない」って言って放っておいてくれるから、何か使えるものができるかもしれないけどね。
リーダー：「あと6週間でリリースだ。何か質問ある？」
開発者：「関連する履歴データをエクスポートして匿名化するコードを書く時間とか、匿名化データを使った並行本番システムを立ち上げる時間をもらって、そこでスケールテストしたいんですけど？」
リーダー：「考えておくよ。とりあえず頼んだ機能を作って。今回は急ぎだからさ。」
って状況、よくあるよね。直接的な成果に繋がらない先行投資は、大体却下されちゃうんだ。
決済処理もたくさんやってきたよ。使ったことがあるシステムは、テスト環境で偽の支払いができるし、Adyenみたいに実際のテスト用デビットカードやクレジットカード、本物のIBANまでくれるところもあるんだ。
彼の例の割引バグは、カード番号は必要なかったはずだよね。顧客情報を含まない偽の取引で発見できたはずだよ。このケースなら、まずは単一店舗で決済処理をテストして、それから複数の他の店舗の売上ログを使ってテストするのがベストだったんじゃないかな。
これは法則だ、エントロピーの法則だよ。どれだけ頑張っても、永遠にエントロピーには逆らえない。この戦いでのミスが溜まって、最終的には圧倒されちゃう。これはどんな生命体にも見られる自然な老化のプロセスだよ。
この法則に反して生命が続くのは「生殖」のおかげだ。独立した個体を増やしていけば、エコシステムは“永遠の”命を得られるんだ。
その代わり、効果的な生殖に多くのエネルギーを注ぎ込まないといけない。
ソフトウェアでは、これはリライトを受け入れるってことだね。リライトに反対して必要ないって言う人たちは、永遠に生きられるって思ってる人たちと同じくらい妄想的だよ。
間違ってるとは言わないけど、ソフトウェア特有の要因って何なんだろうね？航空機とか巨大な橋やビルは、小さく始めずに作れるじゃん。火星に行くような巨大プロジェクトでも、漸進的な開発を提案するの？
でも、ソフトウェアシステムだと、それが最高のやり方だって言われることがあるんだよね。
匿名化されたデータをテスト環境に持ってきて使うのは、こういうケースではすごく一般的だよ。カードプロバイダー側でも、特定のテストカード番号を使えば、常に失敗したり常に成功したりするんだ。
Clojure、git、Linuxがうまくいくのは、システム全体を理解して統制する人がいるからだね。でも、これは技術者向けの話で、非技術者はWindowsやMacを選ぶことが多いよ。MUDゲーム作った知人が「ブラウザクライアントなんて初心者の巣窟になるぞ」って言ってたけど、彼は正しかった。余計なレイヤーを増やすと、時間やお金だけじゃなくて、モチベーションや集中力も失うってことだよね。
もっとコメントを表示（1）
Erlangは、BEAM VMの軽量グリーン・スレッドとか、プロセススケジューラによる並行処理とか、不変データ構造とか、プロセス間のメッセージパッシングとか、チャットシステムには他の言語より圧倒的に向いてるんだよ。
俺が趣味でテックの歴史を調べてて思うのは、ソフト開発者はハード開発者と違って、過去の成功も失敗も全然学ばないってこと。古いシステムをちゃんと見直さないから、新しい世代がまた同じ問題でつまずいてるんだ。
俺が$FANGで働いてるんだけど、プロジェクトはいつも最後は開発者が尻拭いさせられるんだ。レトロスペクティブでも「開発者がどうすればよかったか」って聞かれるだけで、マネジメントやプロダクトは責任を取らない。管理職を批判する報告書は握りつぶされ、結局何も変わらない。開発者の犠牲の上にこのサイクルが続いてるよ。
結局、責任を取るってのは「必要だから」発生するもんで、「こうあるべき」だからじゃない。エンジニアがまとまって動くか、プロジェクトが本当にひどくなるかしないと、何も変わらないよ。「知恵だけで良くなる」なんてことはない。技術の進化が早すぎたり、古いエンジニアリングの真似をしすぎたりしてるから、ちゃんとした基準が作れてないのが課題だね。アジャイルな標準化が必要だよ。
集団行動こそが、 poorなマネジメントの尻拭いをエンジニアがするのを止める唯一の方法だって本当に思うよ。でも、他のエンジニアにそう思わせるのは大変だ。「組合に入ると給料が下がる」なんてデマが多すぎなんだ。
チームの組織やプロセスにすごい力を持ってるくせに、ソフトウェアの中間管理職って、結果に対する責任がほとんどないんだよな。
俺は組合が好きじゃないね。一人でも悪いやつが入ってチームをぶっ壊すリスクを考えると、そいつをクビにできる自由の方が、組合のどんなメリットよりも価値がある。組合って保守的で現状維持が目的だから、プロセスの改善には向いてないんだよ。ILAが自動化を拒んだみたいに、ソフトの組合もそうなるのがオチだと思う。
なんで賢くて有能な人たちが、自分に悪影響があるって分かってるマネジメントの下で働き続けるんだろう？一度なら分かるけど、二度三度と自分の信頼性まで傷つける意味が分かんないよ。
組合が、生産性の成果を measurableに改善した業界ってあるのかな？「マネージャーが無責任」から「誰も無責任」になるのは良くないと思う。上層部での競争を増やす方がいいんじゃない？正直、ほとんどのPMはLLMで代替できると思うけどね。
「組合はダメな社員一人でチームを壊すから嫌い。そいつを排除できる選択肢の方が、組合がくれるどんなメリットよりも価値がある」って意見だけど、他の多くの国には、組合とは関係なく解雇や雇用に関する規制がもっとあるよ。ドイツだと試用期間があって、その間は基本的に理由なしで解雇できる。僕の場合は半年だったけど、その間に新人がチームに合うかどうかが分かるんだ。これは全部組合とは無関係だよ。ドイツの大きな組合はすごく力があるから、例えばただの溶接工だったら、組合なしでは何もできないだろうね。
テクノロジーの入れ替わりが激しいのは意図的なんじゃないかって仮説があるんだ。数年ごとに新しいパラダイム、言語、フレームワークが出てくると、テック業界は常に低賃金の新卒を雇いたがるよね。Xのスキルを持つ人を欲しがってるように見せかけて、実はXをまだ習得していないかもしれないけど、10年の経験があるベテランを雇いたくないだけじゃないかな。これが唯一の理由だとは思わないけど、ソフトウェアが他のエンジニアリング分野と違う扱いをされる一因だと思うな。
「ハードウェアの連中は過去の成功や失敗から学ぶけど、ソフトウェアの連中は学ばない」ってのは、全くもって間違ってるよ。ソフトウェアの連中は、うまくいったものをコピーすることに取り憑かれていて、どんな進歩もすぐにカーゴカルト化するほどだ（マイクロサービスとかね）。ハードウェアとソフトウェアの両方で働いてみたら、表面上しか似てないってすぐに分かる。ソフトウェアは根本的に哲学であって、物理学じゃないんだ。ハードウェアは現実世界の制約を受けるけど、ソフトウェアは極端な場合を除いてそうじゃない。だから、誰もが収束できるような「正しい」やり方が一つもない結果になる。最初の飛行機の翼が今の翼とすごく似てるのは、設計者が“本物のエンジニア”だからとかいうくだらない理由じゃなくて、自然がそうさせてるからだよ。
僕の勘だと、ソフトウェアエンジニアが組合に乗り気じゃないのは、組合が自分たちにとって最も有益な専門組織のタイプから大きく外れていると正しく認識してるからだと思うな。業界がかなり特殊だから、通常の組合モデルはあまり良くなくて、’四角い釘に丸い穴’って感じがするんだ。例えば、組織の役割は賃上げよりもむしろ、屈辱を減らすことにあるんだよ…無駄な仕事とか、先見性のなさ、ひどいマネジメント、恣意的なレイオフとかね。だから、賃金を維持するより、良い慣行で経営陣を統制することの方がずっと重要なんだ。少なくとも今のところ、賃金は一般的に高いからね。アウトソーシングとかに直面した時の雇用や賃金を防御する理由もあるけど、それはほとんど別の問題みたい。たぶん、組合と、切り離された専門基準の両方が必要なのかもしれないな。
これは問題の一部だね。業界で20年以上見てきたもう一つの大きな原因は、ほとんどの大規模プロジェクトが、技術的な成果を出せる技術者じゃなくて、政治的な力を行使する非技術者によって開始され、運営されていることなんだ（必ずしも同じ人物じゃないけどね）。技術的な取り組みで権力の中心が非技術者の手に渡ると、期待通りの結果にはならない。大規模なプロジェクトは、トップが”何を知らないか知らない”状態だと深刻な影響を受けるんだ。
一番有益な専門組織って何だろうね？ 標準はもうあるけど、それを強制するには組合か政府の規制が必要だよ。マジで変えたいと思ってる開発者たちは、選択しないと業界は停滞し続けるだろうね。「組織の役割は賃上げじゃなくて、屈辱を減らすことだ」って意見には同意するよ。そして、それこそが、米国で大量レイオフ（アウトソーシングが原因でね）が4年目に入る今、本当に重要になってくる理由だと思う。それと同時に、”生き残った”人たちの過重労働や、人々を不安にさせるための虐待的なPIP（業績改善計画）も問題だね。
組合が悪い結果につながるって、何十年もプロパガンダされてるからって思い込んでない？ ちゃんと調べたことある？「ほとんどのPMはLLMに置き換えられるはずだ」って言ってるけど、それじゃあPM（や他のこと）に対する理解が浅いって言ってるようなもんだよ。
それは賢くて有能な人たちが、同じ経営陣のもとで歯を食いしばって再チャレンジするよう説得することにはなるだろうね。でも、自尊心のある人がそんなことを何度もするとは思えないな。
組合がマイナスになるとは思わないし、もしかしたら組合結成を思いとどまらせるために、お金をもらった悪意のある工作員による妨害があるんじゃないかって疑うことさえあるけど、PM（プロジェクトマネージャー）がLLM（大規模言語モデル）に置き換えられないって懐疑的な意見には同意できないな。今まで会ったPMのほとんどは何をやってるのか全く分かっていなかったし、それは僕だけの個人的な意見じゃなくて、他の多くの人からも同じような話を聞くよ。でも残念ながら、人間にはっきりと見られる無能さだけが最大の問題じゃないんだ。「もっと現実的な締め切りはありえない」っていうのがもっとひどい問題なんだ。多くのマネージャー、PMだけじゃなくてね、客観的に見てもマイナスなんだ。どんな支配階級もそうだけど、彼らは現状に満足して、ただ自分の意見を押し通せば現実が魔法のように変わると思ってるんだ。
米国とヨーロッパの労働市場は全然違うんだ。米国は仕事が辞めやすいけど、すぐ次が見つかる。ヨーロッパは解雇されにくいけど、仕事を見つけるのも難しいし、給料とかで妥協しなきゃいけないことも多い。どっちがいいかは人それぞれだね。
業界が停滞してるなんて言うのはおかしいよ。客観的に見れば、ソフトウェア業界はこれまで以上に規模が大きくて、影響力もあって、革新的だよ。みんなが文句言ってる問題って、もしかしたらそんなに重要じゃないのかもね。
軍隊を思い出すね。上層部は現場の状況を全然知らないことが多い。上に上がる情報は良い報告に偏っちゃうからね。中間管理職も自分のキャリアに響くから真実を知りたがらない。こんなやり方で、どうやって組織をリードできるって言うんだろ？
PMは何してるか分からんって言う人が多いけど、それはPMの仕事を知らないだけだよ。PMが自分の望むことをしないから、不満に思ってるだけなんだ。
コードを読むスキルがほとんどの人が教わってないのが問題の一部だと思う。昔、大学院でTinyOSのソースコードを1週間読んで理解しろって言われたり、Linux Core Kernel with Commentaryを読んだりしてた。未知のコードベースを理解する能力ってすごく大事なのに、多くの人が持ってないんだよね。
全然関係ない。PMは間違った指標を最適化して、将来の問題回避を全く考えないのが現実だよ。コンサル時代はこれから起こる危機を奥さんと予想するゲームしてたけど、もうそんなの見てても楽しくない。PMにはチームを助けてほしいのに、製品もエンジニアリングも理解してない人の代弁者になって、ただ状況を聞くだけなんだから。
新しいフレームワークや言語で同じものを延々と書き直すのは、見せかけの生産性を生み出し、その存在を正当化してるだけだよ。もし他のエンジニアリングでも同じことしたら、良い釘があるからって家を壊して建て直すようなもんだ。たくさんの建設作業員は雇えるだろうけどね。
反論として、デンマークにはFlexcurityっていう”柔軟性”と”保障”を組み合わせた制度があるよ。伝統的な社会主義経済より雇用も解雇も簡単なんだ。手厚い社会保障があるけど、早く仕事に戻るように時間制限があるんだって。
米国は過去70年間、参戦した軍事紛争で全部負けてるんだよね。やり方を変えるような内部からの圧力もないから、もしかしたら米軍は’勝つこと’を必要だと思ってないのかもね。
PMが間違った指標を最適化してるように見えるのは、あなたが全ての情報を持ってないからだよ。彼らは’あなたの’指標を最適化してるわけじゃないし、今対処できる問題と後回しにする問題で妥協しなきゃいけないんだ。
プログラミングを勉強中なんだけど、成功例と失敗例をどうやって探して学べばいいか教えてくれる？
ハードウェアと違ってソフトウェアは過去の失敗から学ばないって言うけど、俺の経験だと問題はソフトじゃなくて、大規模プロジェクトを管理できる優秀な人材がいないことだと思うよ。経験ないと全体像が見えないから、後でヤバいことに気づくんだ。
まさに『ロード・オブ・ザ・リング』だよ。
もっとコメントを表示（2）
もし前のコメントが常に正しいなら、技術者をリーダーにすれば解決するはずだけど、俺の経験上、それだけじゃ問題は解決しないんだよな。
大規模ITプロジェクトが失敗する原因は、契約相手、働き方、インセンティブにあると思う。技術的な課題を乗り越えても、結局は政治的な問題や環境がデカい。メンバー、リーダー、ベンダー、顧客、投資家のアライメントと能力が大事で、アライメントがズレてると能力も上がらないんだ。
そうそう、ほとんど政治とエゴが原因だよね。ソフトの問題じゃなくて、人の問題だよ。
大規模ソフトウェア開発はいつも人間関係の問題だよ。難しいのはコードを書くことじゃなくて、コミュニケーションなんだ。
コメント4の人へ、キャリア初期に役立った文献や発見があれば教えてくれない？
めちゃくちゃ語れるんだけど、いくつかハイライトね。
Weinbergの要件定義本は必読。DFDはみんなに分かりやすい。GanttチャートやKanbanボードを使いこなして。緊急時は一時的にアドホックな対応も必要だけど、「いつも緊急」はダメ。
コミュニケーションとドキュメントは大事。会議は減らして、集中する時間を確保。個人の評価指標は慎重に。レジュメ駆動開発は正直に話すこと。Infosecはひどい状態だから変えよう。
LeetCode面接はズレた思考を助長するし、低レベルな業界の証拠だよ。
結局、アライメントと正直さがなきゃ何も上手くいかない。
詳しい回答ありがとう！
あと、いつ諦めるべきか、チームのアライメントや正直さが無いとどうわかるか、自分がチームに合わない時やチームがプロジェクトに合わない時ってどう判断すればいい？
チームやプロジェクトが軌道に乗るまで、どのくらいの期間が普通？（ケースバイケースなのはわかるけど…）
ちなみにGerald WeinbergのWikipediaはここね: https://en.wikipedia.org/wiki/Gerald_Weinberg
ブログもまだあるよ: https://secretsofconsulting.blogspot.com/2012/09/agile-and-d…
チームが軌道に乗るまでの期間についてだけど、プロセスは少しずつ作っていけるよ。他社のやり方を持ち込むこともあるけど、状況に合わないこともあるから注意して。
何を作るかは、ユーザーのニーズとビジネスの制約から始めるのが普通だね。
新しい技術を使うなら、並行して試行錯誤する時間も必要だよ。
人が正直かどうかって、最終的には行動でわかるけど、最初は率直に話せば結構本音を言ってくれるもんだよ。変なインセンティブとか傭兵みたいな文化を作ると、みんなすぐ「自分のことだけ」って考えに戻っちゃうから気をつけなよ。まずは正直に接することが大事！
これ、ソフトウェアプロジェクトに役立つアドバイスをものすごくうまくまとめた内容だね！即メモったよ。もしブログとかやってないなら、このテーマで書くべきだよ。
優しい言葉ありがとうね。ブログはまだだよ。以前は「Racket Tactical Field Manual (RTFM)」って本を書いてたけど、Racketに商業的な見込みがなさそうだったからやめちゃったんだ。もしSEのブログがあれば、LeetCodeのしごきみたいな面接じゃなくて、もっと同僚みたいに話せるのになあ。
政府の巨大プロジェクトにコンサルで入ると、最初からダメだってわかるんだ。何百万もの仕様があって、人事、CCTV、害獣監視、医療、採用とか、全然違う機能をたった一つのソフトで全部やろうとするんだから、成功するわけないよ。世界中どこにもそんなソフト作れる会社なんてないって。
さっきの（コメント4の）話をClaude Codeに入れたら、たった5分でコードを完成させて、もう昼食後には30億ドルのARRを稼いでるんだってさ。ははっ。
あー、これ超簡単じゃん！MongoDBで政府の全部のデータを保存して、APIはChatGPTに丸投げ。AI VisionでCCTVから害獣とか従業員の生産性とか病院の設備状況を監視。透明性のためにBlockchainも導入して、害獣発見はNFTにすればいい！2週間でジュニア開発者1人、1万ドルくらいだろ。main.js書こうか？
NoSQLへのジョークには思わず笑っちゃったよ、うまいね！npmの2万5千もの依存関係を書き忘れてるよ。
これ、ドメイン知識の超重要さを突いてるよね。下水管理と幼稚園の先生が全く別のスキルなのはみんなわかるじゃん。ソフト開発も同じで、プログラムに詳しくない人って、お金と仕様を入れればソフトができると思ってるけど違うんだよ。コードを書くスキルと、そのソフトが使われる環境への理解、両方がいるんだよ。
でも、そのソフトはCCTVで患者が倒れそうになったらERに連絡したりできるの？できないなら、入札は却下されちゃうよ！あと、特定の部屋に女性がいる時に男性が多すぎたらアラームを鳴らす、なんていうCCTV監視ソフトの仕様もあったんだ。冗談抜きで、これ本当の仕様だったんだよ！
まあ、政府の入札が全部広範囲ってわけじゃないけど、解決策や技術を知らない人が仕様を書いてて、個人的な利益も責任もないから、何十億ドルの予算でもバカげたことになっちゃうんだよ。ある州の教育省が2000校の光ファイバー配線で、担当者が「契約を1個にする方が楽」って理由でたった1社に発注して、地元業者に頼むより15倍も税金を無駄にした例があるんだ。
ソフトウェアプロジェクトが失敗するのは人間が失敗するからなんだ。最高のプロセスやツールがあっても、使う人がダメなら結果もダメになる。成功には、最高のモチベーションを持った優秀な人材が必要だよ。この状況を変えるには「結果」（consequences）を設けるしかない。例えば、大規模な物理プロジェクトみたいに、プロジェクトの各段階で正しい行動を強制する法律を作り、それを守らなかったら罰則を課すんだ。責任が重いほど、罰も重くするべきだね。公共事業も同じ問題があると思うよ。
35年の経験から言うと、ソフトウェアプロジェクトの失敗は主に人間の問題なんだ。エゴ、衝突、怠慢、無関心、コミュニケーション不足、悪いチーム文化とかが原因で、技術的な問題でダメになったことはほぼないね。成功したプロジェクトは、感情的知性や明確なビジョンを持つ素晴らしいリーダーやエンジニアのおかげだったよ。結局、ハードコアなソフトウェア開発は全て人間に尽きるんだ。
素晴らしいリーダーやエンジニアがプロジェクトを成功させるって意見には全く同感だよ。付け加えるなら、彼らが適切にインセンティブを得て初めて機能するってことだね！モチベーションは大事だ。
プロジェクトの各工程で「結果」（consequence）を重視しすぎたら、誰もリスクを取らなくなっちゃうよ。全てが計画通りに進むなんて保証できないから、大規模プロジェクト自体が立ち上がらなくなるだろうね。だから、ある程度の不確実性や予算オーバーの可能性を許容しながら進めるのが現実的だよ。
ソフトウェアエンジニアが「エンジニア」を名乗りたいなら、エンジニアリングの失敗について学ぶべきだよ。業界全体が実績ある手法を嫌うのは「邪魔」になるからか、責任を負いたくないからなんだ。何十年も経験があるのに、こんなふうに責任を避けて未熟なままじゃダメだね。
きっとマネージャーのこと言ってるんだろ？開発者はみんな正しい方法でやりたいのに、時間がないんだよ！毎週の優先事項に追われててさ！
ここで挙げられてる失敗例は政府のITプロジェクトが多いけど、ソフトウェアだけじゃないんだ。政府の大規模プロジェクト全体が、説明責任の欠如とか「大きすぎて潰せない」って問題で失敗しがちだよ。ベルリン空港やシュトゥットガルト駅の建設遅延もそう。巨額の予算と政治的な意思決定、トップの非現実的な期待が重なって、みんな予算に群がる。ソフトウェア開発手法なんて、これらの根本的な問題に比べたら小さいもんだね。
失敗は政府だけじゃないよ、民間企業にも同じ問題があるんだ。例えば、昔は仮想マシンのプロビジョニングに数ヶ月かかってたけど、それがAWSが大きく成長した理由の一つだね。
政府プロジェクトの失敗が目立つのは、公衆の scrutin (精査) に常にさらされてるからだよ。民間企業なら、何十億ドルも無駄にしてもニュースにはならないからね。政府プロジェクトには、そういう選択バイアスがあるってことさ。
最初の大企業での仕事はひどかったね。労力の30%が「データベースなしでDB機能を作る方法」に費やされてたよ。簡単なサーバ設定変更でさえ、自社でやるよりセキュリティ会社にプロキシを頼んだ方がマシで、しかもメールのやり取りに一週間もかかってたんだ。本当に非効率だった。
