オフショア開発地獄絵図 その2:制御不能な混沌と破綻したガバナンス

よくある質問 (FAQ)
本番サーバーで何が起きたのか?
Docker構成で何がおかしかったのか?
なぜこのオフショア開発は制御不能なのか?
なぜこのシステムは「生まれた瞬間からレガシー」と言われたのか?
オフショア開発自体の問題は何か?
この事例が日本のベンチャー育成に示すものは?
前編のあらすじ:CRMのメール配信機能で発覚した、顧客データを毎回送信する天才的なリソース浪費アーキテクチャ。巨大なIDリストの無駄な往復転送、同じSQLの2回実行。常識を完全に無視した摩訶不思議なシステム設計の実態を暴露した。
第三章:勝手にダウングレード
気を取り直して、修正したコードを本番サーバーにデプロイする。
ログインできない。
は?DBはいじってないぞ。
調査開始。 そして判明した事実に、俺は怒りで震えた。
PostgreSQL 16が15に戻されている。
前回、俺が14→15→16とアップグレードした。 開発環境15、本番環境14という狂った構成を正したのだ。 それが、いつの間にか15に戻されている。
連絡なし。相談なし。ただの破壊行為。
「勝手にいじるな」
窓口の管理者SEに伝えた。 そこからベトナムに伝わるはずだった。 だが結果はこれだ。
伝言ゲームで消えたのか、それとも「どうせ日本側にはわからない」と舐められているのか。 いずれにしろ、制御不能な開発初心者集団だ。 教授を馬鹿にする反抗的な学生のようなものだ。
混ぜるな危険。
技術力がないだけならまだいい。 だが、指示を無視し、勝手に環境を変更し、それを報告もしない。 これはもう開発チームとは呼べない。
第四章:Dockerという名の混沌
デプロイ情報の資料がない。 自力で調べるしかない。
WebアプリとDBはDockerで動いている。 当然、リバースプロキシもDockerだろうと思ったら、なぜかホストOSで動いている。
なぜ混在させる?
DockerでWebとDBを動かすなら、リバースプロキシもDockerにして、Dockerネットワークで接続するのが常識だろう。 ポートマッピングの無駄、ネットワークの複雑化、管理の煩雑化。 いいことが一つもない。
エンジニアリングの香りが1ミリもない、どころか、エンジニアリングという概念自体が存在しない世界だった。
エピローグ:関わりたくない
もう、こいつらとは関わりたくない。 システムに触らせたくない。
一見、機能は満たしている。 メールは送れる。 データは表示される。 だが、それは「動く」というレベルの話だ。 システムとして、アーキテクチャとして、完全に破綻している。
このシステムは生まれた瞬間からレガシーだった。
オフショア開発が悪いわけじゃない。 だが、今の日本のSIerはオフショアを使いこなせていない。 丸投げして、品質管理を放棄して、エンジニアリングを理解しない相手に任せきりにする。
結果がこれだ。
35年この業界にいて、ここまでひどいものは初めてだ。 怒りを通り越して、もはや悲しい。
次は何が起きるのか?もう想像もつかない。 いや、想像したくない。
そして最も恐ろしいのは、こんな会社が上場を目指してVCが投資しているという事実だ。
日本側は営業と管理者SEの集団。 開発はベトナムの500人に丸投げ。 自社に技術力はなく、品質管理もできない。 それでも「ベトナムと提携している」「500人のエンジニアを抱えている」という謳い文句で資金を集める。
日本のベンチャー育成のレベルの低さを垣間見た。 実体のない会社に金が流れ、丸投げビジネスが「DX」として評価される。 中身を見る目がない。 エンジニアリングを理解できない投資家が、エンジニアリングを放棄した会社に投資する。
だから、この国に将来はないのだ。
警告:これは実話である。 オフショア開発を検討している企業は、この地獄絵図をよく見て、業者選定と品質管理体制を真剣に考えてほしい。 特に、エンジニアリングを理解している管理者の存在は必須だ。