オフショアにエンジニア無し：営業支援システムという名の冗談
130万件を毎回送信するメール配信機能
都道府県の並びを直し、次の機能をテストする。営業支援システムのメール配信機能だ。条件を設定し、件名と本文を入力、配信日時を設定して「送信」をクリック。
「エラーが発生しました」
開発ツールのコンソールを開く。POST 400 (Bad Request)。メールの設定程度でnginxのアップロード制限に引っかかる？
コンソールに大量の配列が表示されている。目を疑った。
このシステムは絞り込み条件を送っているのではなかった。**顧客データそのものを送っていた。**数万件の顧客データがJSONでフロントエンドからバックエンドに送信されている。要件定義書によると現状で130万件の顧客データが存在する。
さらに処理フローを追うと、バックエンドでSQLを実行してIDリストを作成し、フロントエンドに送り、フロントエンドが同じIDリストを送り返し、バックエンドで同じSQLを再実行している。何のためのラウンドトリップだ。
常識的には検索条件だけを送信すればいい。条件は1KB、顧客データ全件は50MB以上。この差が理解できないのか。
しかもこの設計では配信設定が再利用できず、配信時点の最新データも反映されない。営業支援システムではなく、ただの一斉メール送信ツールだ。
ログを配列で代用する狂気
次はDMからLPへの誘導システムだ。「アクセス解析がおかしい」とクライアントから相談が来た。
コードを見て言葉を失った。LPにアクセスがあると、メール詳細データの顧客IDリストに追加し、アクセス回数をカウントアップする。それだけだった。
ログを取っていない。
データベース設計を見て確信した。contact_ids[]という配列フィールド。第一正規形。1970年にE.F.Coddが論文「A Relational Model of Data for Large Shared Data Banks」で提唱した、リレーショナルデータベースの基本中の基本。一つのフィールドには一つの値。これすら守られていない。
検索不可能。集計不可能。整合性なし。スケーラビリティゼロ。
ログがないということは、顧客分析、時系列分析、効果測定、問題調査が永遠に不可能だということだ。データは後から作れない。集計は後からでもできるが、記録していないデータは永遠に失われる。
案の定、送信していない顧客IDからLPにアクセスがあった。原因は不明。手掛かりは皆無。ログがあればタイムスタンプ、リファラ、IPアドレスから追跡できた。だが何もない。
「要件は満たしています」
管理者SEに問い詰めた。返ってきた答えがこれだ。
「要件は満たしています。画面にはLPごとのアクセス件数とアクセスしたユーザーが表示されています」
画面に数字が出ることと、システムとして機能することは違う。営業にとって必要なのは「田中さんが昨日の18時にアクセスした」「キャンペーンAの開封率は30%」「水曜日の夜が最もアクセスが多い」だ。このシステムでわかるのは「誰かが何回かアクセスした」だけ。これでは営業活動に使えない。
エンジニアなら聞く。「なぜこの機能が必要なのか？」「どう使われるのか？」「何を測定したいのか？」。だが彼らは聞かない。仕様書の文字を読んで、画面に数字を表示するだけ。
500人のエンジニア。ベトナムとの提携。DXの推進。すべてが虚構だった。ログすら理解できない。データベースの正規化も知らない。それでも「要件を満たしている」と言い張る管理者。そして、それに投資するVC。
数字だけは立派だ。だがコードがすべてを物語る。
オフショア開発シリーズ: