メニュー

公開日:
更新日:
8 min read
エンジニアリング

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

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

よくある質問 (FAQ)

本番サーバーで何が起きたのか?

PostgreSQL 16から15に勝手にダウングレードされており、事前の連絡や相談なしに環境が変更された。このためシステムにログインできなくなった。

Docker構成で何がおかしかったのか?

WebアプリとDBはDockerで動いているが、リバースプロキシはホストOSで動いている混在構成だった。これはポートマッピングの無駄、ネットワークの複雑化、管理の煩雑化を引き起こした。

なぜこのオフショア開発は制御不能なのか?

日本側の指示を無視し、勝手に環境を変更し、それを報告しないベトナムの開発チームと、それを野放しにする日本のSIerが原因。伝言ゲーム状態で直接コミュニケーションができない。

なぜこのシステムは「生まれた瞬間からレガシー」と言われたのか?

一見機能は満たしているが、アーキテクチャやシステム設計が完全に破綻しており、メンテナンス性や拡張性を全く考慮していない設計で作られているから。

バックアップ・復元で何が問題だったのか?

READMEやドキュメントにDB復元手順の記載なし、データ移行やバックアップの標準手順が未整備、auth_userを使わず独自のuserテーブルを作成など、一般的な企業向けシステムならDBダンプ→リストアだけで完全復元できるのが当然なのに、それができない基本的な運用要件を満たしていない状態。

オフショア開発自体の問題は何か?

オフショア開発自体が悪いのではなく、日本のSIerがオフショアを使いこなせていない。丸投げして品質管理を放棄し、エンジニアリングを理解しない相手に任せきりにすることが問題。

この事例が日本のベンチャー育成に示すものは?

実体のない会社に資金が流れ、丸投げビジネスが「DX」として評価される。エンジニアリングを理解できない投資家が技術を放棄した会社に投資するという、日本のベンチャー育成のレベルの低さを示している。日本側は営業と管理者SEの集団で、開発はベトナムの500人に丸投げしながら「ベトナムと提携」「500人のエンジニアを抱えている」という謳い文句で資金を集めている。

「混ぜるな危険」とはどういう意味か?

技術力がないだけならまだしも、指示を無視し、勝手に環境を変更し、それを報告もしない開発チームは「開発チーム」とは呼べない。教授を馬鹿にする反抗的な学生のような存在で、そのような相手とは協業すべきではないという意味。

前編のあらすじ: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ミリもない、どころか、エンジニアリングという概念自体が存在しない世界だった。

第五章:CRMなのにバックアップが取れない?

さらに調査を進めていくと、もう一つの衝撃的な事実が判明した。

  • READMEやドキュメントにDB復元手順の記載なし
  • データ移行やバックアップの標準手順が未整備
  • auth_userを使わず独自のuserテーブルを作成
  • マイグレーション順序の考慮なし
  • 復元時の手順が複雑化

原因は以下の通り。

  • 開発チームの設計ミス: エンタープライズシステムの基本要件(バックアップ・リストア)を考慮していない
  • ドキュメント不足: 運用手順書が存在しない(運用手順書.pdfはあるが、DB復元手順なし)
  • テスト不足: 本番環境でのDB移行テストが行われていない

結論: 一般的な企業向けシステムなら、DBダンプ→リストアだけで完全復元できるのが当然。 このシステムはそれができない。基本的な運用要件を満たしていない。

まともな思考回路とは思えない。 学生の実習レベルだ。

「動けばいい」の典型。 機能要件だけ満たして、使い勝手は無視。 運用のことなど考えない。

あきれてものも言えなかった。 こんな会社がシステム開発を受託してはいけない。 だが、現実には受託している。 そして、それがビジネスとして成立している。

エピローグ:関わりたくない

もう、こいつらとは関わりたくない。 システムに触らせたくない。

一見、機能は満たしている。 メールは送れる。 データは表示される。 だが、それは「動く」というレベルの話だ。 システムとして、アーキテクチャとして、完全に破綻している。

このシステムは生まれた瞬間からレガシーだった。

オフショア開発が悪いわけじゃない。 だが、今の日本のSIerはオフショアを使いこなせていない。 丸投げして、品質管理を放棄して、エンジニアリングを理解しない相手に任せきりにする。

結果がこれだ。

35年この業界にいて、ここまでひどいものは初めてだ。 怒りを通り越して、もはや悲しい。

次は何が起きるのか?もう想像もつかない。 いや、想像したくない。

そして最も恐ろしいのは、こんな会社が上場を目指してVCが投資しているという事実だ。

日本側は営業と管理者SEの集団。 開発はベトナムの500人に丸投げ。 自社に技術力はなく、品質管理もできない。 それでも「ベトナムと提携している」「500人のエンジニアを抱えている」という謳い文句で資金を集める。

日本のベンチャー育成のレベルの低さを垣間見た。 実体のない会社に金が流れ、丸投げビジネスが「DX」として評価される。 中身を見る目がない。 エンジニアリングを理解できない投資家が、エンジニアリングを放棄した会社に投資する。

だから、この国に将来はないのだ。


警告:これは実話である。 オフショア開発を検討している企業は、この地獄絵図をよく見て、業者選定と品質管理体制を真剣に考えてほしい。 特に、エンジニアリングを理解している管理者の存在は必須だ。