オフショア開発地獄絵図 その４：オフショアにエンジニア無し

第六章：不安は現実となった

案の定、なぞの現象が起きた。

送信していない顧客IDからLPにアクセスがあったのだ。

過去に一度も送っていない顧客ID。システムには存在する、だがマーケティング記録には送信履歴がない。なぜこの顧客IDがLPにアクセスしているのか？

原因は不明。手掛かりは皆無。

ログがあれば、以下が分かったはずだ：

• タイムスタンプ（いつアクセスしたか）
• 顧客ID（誰がアクセスしたか）
• リファラ（どこからアクセスしたか）
• IPアドレス（どの場所からアクセスしたか）

だが、何もない。ただ「アクセスした」という事実だけが、データベースのカウンターに刻まれている。

バグなのか？システムの手違いなのか？誰かが手動でURLを入力したのか？セキュリティホールなのか？

すべてが憶測でしかない。

第七章：ログ設計の致命的な欠陥

さらに調査を進めて、俺は愕然とした。

送信したメールに含まれる、生成したLPへのURLもDBに記録されていない。

つまり、こういうことだ：

1. メールを送信する
2. 各顧客に個別URLを生成して送る
3. そのURLがどれかを記録しない
4. アクセスがあっても、どのメールから来たのか不明

営業支援システムとして、これは致命的だ。

1. ログ設計の致命的な欠陥

個別アクセス履歴が一切記録されない

• 誰がいつアクセスしたか → 不明
• どのキャンペーンから来たか → 不明
• 効果的な文面はどれか → 測定不可能
• フォローアップのタイミング → 判断不能

2. 業務要件を無視した設計

営業支援システムなのに最も重要な営業データが取得できない

営業にとって必要なのは：

• 「田中さんが昨日の18時にアクセスした」
• 「キャンペーンAの開封率は30%」
• 「水曜日の夜が最もアクセスが多い」

だが、このシステムで分かるのは：

• 「誰かが何回かアクセスした」

これでは営業活動に使えない。電話をかけるタイミングも、フォローアップの優先順位も、何も決められない。

「オフショアでエンジニアリング無視のド素人が作った」

これしか言いようがない。

業務を理解せず、要件の本質を見抜けず、表面的な機能だけを実装する。これがプログラマーとエンジニアの違いだ。

エンジニアなら聞く：「なぜこの機能が必要なのか？」「どう使われるのか？」「何を測定したいのか？」

だが、彼らは聞かない。仕様書の文字を読んで、画面に数字を表示するだけ。システムの目的など、どうでもいい。

そして、間に入っている管理者SEもSEとは名ばかりのド素人だ。

「要件は満たしています」と言い張るが、そもそも要件の意味を理解していない。マーケティングツールがなぜ必要なのか、営業がどんなデータを求めているのか、全く分かっていない。

技術も分からない。業務も分からない。ただ、開発会社と顧客の間で言葉を右から左に流すだけの存在。これでSEと名乗るのは、エンジニアリングへの冒涜だ。

エピローグ：美辞麗句という名の虚構

500人のエンジニア。ベトナムとの提携。DXの推進。

すべてが虚構だった。

GitHubの履歴からメールアドレスを辿れば、彼らの正体は見える。会社のホームページには「優秀なエンジニア数」「日本語取得率」「開発実績数」といった数字が並ぶ。

数字だけは立派だ。だが、コードが全てを物語る。

ログすら理解できない。データベースの正規化も知らない。それでも「要件を満たしている」と言い張る管理者。そして、それに投資するVC。

俺は静かにVSCodeを閉じた。もう修正する気も起きない。このシステムは、生まれながらにして死んでいる。エンジニアリングの墓標だ。

怒りは通り越して、呆れ、そしてまた怒りに戻る。無限ループだ。

次は何が起きても、もう驚かない。底が抜けた樽に、これ以上落ちる場所はないのだから。

警告：これも実話である。「要件を満たす」ことと「システムとして機能する」ことの違いを理解できない開発会社とは、決して契約してはならない。数字に騙されるな。コードは嘘をつかない。

オフショア開発にシステムを依頼していますか？今すぐシステムを点検したほうがいい。

これを建築に例えよう。見た目は立派なビルが完成した。だが、柱の中身は空洞で、基礎は砂の上。地震が来たら一瞬で崩壊する。車なら、外装はピカピカだが、ブレーキは効かず、エンジンは煙を吐く。そんなものに命を預けられるか？

あなたのシステムも、同じかもしれない。