オフショア開発の闇：掘れば掘るほど出てくる問題

新規システム開発の後始末を引き受けたとき、まさかこれほどの問題が埋まっているとは思わなかった。掘れば掘るほど出てくる。そしてそのすべてが、同じ構造的な原因に根差していた。

npm installが吐き出した警告の山

納品されたシステムのフロントエンド環境を構築するため、npm installを実行した。大量の警告が表示された。

npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory.
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated eslint@8.57.0: This version is no longer supported.

新規開発だ。にもかかわらず、サポートが終了したライブラリやメモリリークを引き起こす既知の問題を抱えたモジュールが使われている。ESLint v8.xは2024年10月にEOLを迎え、すでにメンテナンスが終了している。「動けばいい」で作られた新品のシステムが、納品時点ですでに技術的負債を抱えていた。

管理者SEはこの警告を見ていない。彼らはシステムを自ら構築しない。開発チームが提供した完成品の機能テストのみを行い、「動作確認OK」と報告する。構築過程で表示される警告やエラーには一切触れない。

3環境で3バージョンのPostgreSQL

さらに掘ると、PostgreSQLのバージョン不一致が見つかった。

開発環境: postgres:16.4-alpine
本番定義: postgres:15.2-alpine
実際の本番サーバー: PostgreSQL 14

3つの環境で3つの異なるバージョン。データベースログにはバージョン非互換のエラーが記録されていた。なぜこのようなバージョン管理をしているのか問い合わせたが、返ってきたのは「すいません」の一言だけだった。根本的な改善も説明もない。

HTTPS通信の虚偽説明

そして最も深刻な問題が見つかった。フロントエンドとバックエンド間の通信が暗号化されていない。docker-compose.ymlの設定もDockerfileのUWSGI設定も、単純なHTTP通信を前提としたものだった。リバースプロキシなどの保護層は完全に欠落していた。

開発会社を通じてベトナムの開発チームに何度も確認した。彼らの回答は「サーバーとはSSL接続で通信している」。しかし実際のコードや設定を調べると、HTTP通信であることは明白だった。

さらに「本番環境のデプロイ時にデータベースのコンテナが動かない」という問題に対し、開発会社から返ってきた回答は「local.ymlを使っているためだそうです」。本番環境が開発用の設定ファイルでデプロイされていたのだ。「HTTPSで通信している」という主張と明らかに矛盾していた。

最も深刻だったのは、「どうせ日本人は何もわからない」という前提でベトナムチームが虚偽の説明を行い、それを管理者SEが技術的理解不足から見抜けなかったという実態だ。さらに悲劇的なのは、管理者SE自身が自分がバカにされていることに気づいていなかった点だ。

性善説が生む脆弱性

日本人は「言わなくても最新版を使っているだろう」と考える。海外では「言われたことだけやればいい、バレなければOK」が普通だ。この認識のギャップ自体を日本側が把握していないことが、問題の発見を遅らせている。

経産省の試算によると、技術的負債による経済的損失は年間12兆円規模に達する。東証のシステム停止、KDDIやNTTの大規模通信障害など、すでに「ツケの支払い」は始まっている。

「プログラミングは単純作業」「技術は外注できる」という認識が、技術的な真偽を判断できる人材の不足を招いた。表面的な管理者を増やしてきた結果、虚偽の報告や杜撰な開発を見抜けない組織が出来上がった。この構造が変わらない限り、同じ問題は繰り返される。