オフショア開発の闇：プロジェクト環境の不整合がもたらす混乱
前回の記事では、オフショア開発における「動けばいい」という安易な姿勢が技術的負債を生み出す問題について触れました。今回は、具体的な事例として開発環境と本番環境の不一致がもたらした混乱と、それがプロジェクト全体に与えた影響について検証します。
問題の発端：Docker環境でのGit利用
VSCodeでDockerコンテナに接続した際に、Gitが突然使えなくなるという問題から物語は始まります。これは単純な問題のように思えました。コンテナにGitをインストールする必要があったのです。
# Debian/Ubuntuベースの場合
RUN apt-get update && apt-get install -y git
# Alpine Linuxの場合
RUN apk add --no-cache gitまたは、VS CodeのDevcontainer設定ファイルで以下のように指定することも可能でした：
{
"features": {
"git": "latest"
}
}しかし、この単純な問題の解決過程で、より深刻な問題が明らかになりました。
Docker Composeと.devcontainer.jsonの動作の齟齬
開発環境の構築において、docker-compose upとVS Codeのリモートコンテナ接続という二つの方法が混在していました。これらは全く異なる挙動をすることが判明しました：
-
docker-compose upで起動した場合：
- .devcontainer.jsonの設定は反映されない
- 純粋にDocker Composeの設定のみで動作する
-
VS Codeからコンテナに接続する場合：
- VS Code Remote Containerの機能により.devcontainer.jsonの設定が反映される
- 接続時に必要に応じてコンテナが再ビルドされる
この違いを理解していないことで、「なぜコンテナの接続に時間がかかるのか？」という疑問が生じていました。実はVS Codeの接続時に裏でコンテナがビルドされていたのです。
深刻な問題：PostgreSQLのバージョン不一致
しかし、真の問題はPostgreSQLのバージョン不一致でした。データベースログを確認した際に以下のエラーが見つかりました：
PostgreSQL Database directory appears to contain a database; Skipping initialization
2025-01-13 22:27:05.147 UTC [1] FATAL: database files are incompatible with server
2025-01-13 22:27:05.147 UTC [1] DETAIL: The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 15.2.これは致命的な問題でした。開発環境と本番環境で異なるバージョンのPostgreSQLが使用されていたのです：
- 開発環境 (local.yml):
postgres:16.4-alpine - 本番環境 (docker-compose.yml):
postgres:15.2-alpine
さらに驚くべきことに、後日の調査で実際の本番サーバーではPostgreSQL 14が使用されていたことが判明しました。なぜこのようなでたらめなバージョン管理をしているのか問い合わせましたが、「すいません」という返事だけでした。
根本的な問題：開発会社の管理不足とベトナムチームの責任放棄
この事例が示す本質的な問題は、開発会社（日本側）がベトナムの開発チームを適切に管理できていないことと、ベトナム側がそれをいいことに手抜き開発を行っていることの二重構造です。
発注者の代理人として目にしたのは以下のような問題の連鎖でした：
-
開発会社の管理責任の放棄: 本来、開発会社はベトナムチームの成果物の品質を確保する責任があります。しかし実際には、基本的なバージョン管理すら行われていませんでした。
-
ベトナム開発チームの無責任な対応: 問題を指摘されても単に「すいません」と謝罪するだけで、根本的な改善や説明がありません。
-
責任の所在の不明確さ: 最終的に、誰も責任を取らない構造が出来上がっていました。
対応策と教訓
この問題に対する技術的な対応策は比較的単純です：
- 開発/本番で同じバージョンを使用する
- または環境を完全にクリーンアップして再構築する
# 開発環境の場合
docker compose -f local.yml down -v && docker compose -f local.yml up --build
# 本番環境の場合
docker compose down -v && docker compose up --buildしかし、技術的対応だけでは本質的な問題は解決しません。発注者としては、開発会社に対して以下の点を明確に要求する必要があります：
- 開発環境と本番環境の統一基準の確立
- 品質管理プロセスの徹底
- 問題発生時の透明な報告と具体的な改善計画の提示
おわりに：外注管理の重要性
この事例は、オフショア開発を含む外注開発の管理がいかに重要かを示しています。発注者の代理人として、品質管理の責任は開発会社にあり、その役割を放棄していることが最大の問題です。
同時に、ベトナム開発チームの「言われたことだけやる」「バレなければいい」という姿勢も看過できません。こうした二重の問題が、最終的には顧客の負担として返ってくるのです。
次回の記事では、この一連のオフショア開発問題の最終章として、エンジニアリング能力の不足が引き起こす具体的な脅威について詳細を掘り下げていきます。