なぜ「安い」システム開発は高くつくのか - レガシーシステムが生まれる瞬間
よくある質問 (FAQ)
CRMシステムの一括削除バグの原因は何でしたか？
オフショア開発会社の問題解決アプローチの何が問題でしたか？
エンジニアリングとオカルトの違いは何ですか？
なぜ基础的な技術力がない会社が受託できるのですか？
レガシーシステムはどのように「作られる」のですか？
はじめに：2つの事例から見える業界の病理
私が最近立て続けに遭遇した2つの事例を紹介したい。 これらは偶然ではなく、現在のシステム開発業界が抱える構造的な問題を如実に表している。
事例1：CRMシステムの初歩的なバグ
あるCRMシステムで、数十件のデータを一括削除すると一部しか削除されないというバグが発覚した。 調査の結果、以下のような実装になっていた：
- JavaScriptのAjaxで削除処理を実行
- データをまとめて送信せず、ループで1件ずつ削除
- レスポンスを待たずに非同期で連続送信
- キューから溢れた処理は無視される設計
これは初心者が陥る典型的なミスだ。 非同期処理の基本を理解していれば、Promise.allやasync/awaitを使って適切に制御できるはずだ。
なぜこのバグが今まで発覚しなかったのか？CRMの性質上、大量削除するユーザーが少なかったか、削除に失敗しても「操作ミスかな」と再実行していたからだろう。
事例2：オフショア開発の悲劇
別のプロジェクトでは、オフショア開発会社がサーバー間通信で同様の問題を起こした：
- 数百件は処理できるが、数千件でプログラムが停止
- レスポンスを待たずにキューに詰め込む実装
- 「キューが溢れたら再起動すればいい」という対処法
さらに問題なのは、原因調査の姿勢だ。 仕様追加後に問題が発生したため、「そこしか修正してないから、それが原因だ」と主張。 カバレッジ測定（プロファイリング）による処理時間の計測といった基本的な調査すら行わない。
この思考回路は、パチスロで「ハンカチを置いたら花が光ったから、打つときはハンカチを置く」というオカルトと同じレベルだ。 時系列の相関だけで因果関係を断定し、データによる検証を拒否する。
エンジニアリングとオカルトの違いは、再現性と測定可能性にある：
- エンジニア：「なぜ止まるのか？」→ プロファイリング → 「3000件目でメモリ使用量が限界を超えている」
- オカルト：「なぜ止まるのか？」→ 「データチェック追加したから（ハンカチ置いたから）」
実際には、元々限界ギリギリで動いていたシステムが、わずかな負荷増で破綻した可能性が高い。 しかし、測定せずに「原因は明白だろう？」と言い張る。 これはもはやエンジニアリングではない。
なぜこのような事態が起きるのか
1. 技術力を評価できないクライアント
事例1では「安いシステム」とクライアントが自慢していたという。 安かろう悪かろうの実態を理解せず、問題だらけのシステムを購入。 事例2の選定経緯は不明だが、いずれにせよクライアント側に技術を評価する能力がない。
2. 管理者の技術理解不足
技術を理解しない管理者が、表面的な進捗だけを見て「動いているから問題ない」と判断する。
3. 学習しない組織文化
失敗から学ばず、同じミスを繰り返す。 「一生懸命やっている」ことが免罪符になってしまう。 「リソースを駆使して対応している」というが、これはパチスロで「今日は3万円つぎ込んだから、もうすぐ当たるはず」と言っているのと変わらない。 努力の量ではなく、アプローチが根本的に間違っている。
4. 開発会社の技術力不足
基礎的な技術力がないエンジニアが実務に投入される。 非同期処理の基本も理解せず、問題解決はオカルトレベル。 なぜこのような会社が受託できるのか。
5. エンジニアの実装能力が低い根本原因
実装能力が低いのは、つまるところ経験不足と勉強不足だ。 しかし、業界は「エンジニアは若い方がいい」という幻想に囚われている。
皮肉なことに、AIというゲームチェンジャーの登場により、この幻想は完全に崩壊した。 若さの強みとされていた体力、新技術への適応力、処理速度は、すべてAIが圧倒的に上回る。 しかも低コストで、言い訳も屁理屈も言わない。
今こそ必要なのは、AIに適切な指示を出し、その出力を正しく評価できる経験豊富なエンジニアだ。 非同期処理の落とし穴を知り、システム全体の設計を俯瞰でき、過去の失敗パターンから学んでいるエンジニアこそが、AIと協働して高品質なシステムを作れる。
しかし現実は、経験不足のエンジニアが、基礎も学ばずに現場に投入され、オカルトレベルの推論でシステムを破壊している。
レガシーシステムは「作られる」
これらの事例で作られたシステムは、完成した瞬間から「レガシーシステム」だ。 技術的負債を抱え、保守が困難で、いずれ作り直しが必要になる。
皮肉なことに、私のような人間が後から呼ばれて、これらの「新しいレガシーシステム」を刷新することになる。 その費用は、最初から適切に開発した場合の何倍にもなる。
これが炎上プロジェクトの火種だ
これらの事例は、プロジェクト炎上の典型的なパターンだ：
- 技術的負債の蓄積：非同期処理の不適切な実装、キューオーバーフローの放置
- 科学的アプローチの欠如：測定せず、オカルトレベルの推論で原因を断定
- 品質より納期の優先：「動いているから問題ない」という判断
- 学習しない組織：同じミスを繰り返し、根本原因を追求しない
炎上プロジェクトは突然起きるのではない。 こういった初歩的なミスの積み重ね、非科学的な問題解決、学習しない組織文化が、着実に炎上への道を作っていく。
おわりに
プログラミングの実習ではない。 実際のビジネスで使われるシステムだ。 データの不整合は企業の信頼を失墜させ、システムの停止は業務を麻痺させる。
「一生懸命やっている」は言い訳にならない。 プロフェッショナルとして、最低限の技術水準を満たせないなら、受託すべきではない。
技術の進歩とは裏腹に、エンジニアリングの基本を理解しない「エンジニア」が増えている現実に、暗澹たる思いだ。