オフショア開発地獄絵図 その３：ログを配列で代用する狂気
よくある質問 (FAQ)
オフショア開発で作られたマーケティングツールの問題点は何でしたか？
通常のマーケティングツールではどのようなアクセス解析が可能ですか？
ログを取らない実装の具体的な問題点は何ですか？
データベース設計の問題点は何でしたか？
第一正規形とは何ですか？
ログがないことで永遠に不可能になることは何ですか？
なぜログの記録が重要なのですか？
プロローグ：新たな絶望
都道府県がランダムに並ぶCRMを修正し、数万件のデータをJSONで送るメール配信機能に呆れ、勝手にダウングレードされたDBに怒りを覚えた。
もう驚くことはないと思っていた。俺が甘かった。
クライアントから新たな相談が来た。DMからLPへの誘導システムについてだ。
「アクセス解析がおかしいんです」
また始まった。今度は何だ？
第一章：マーケティングツールという名の玩具
システムの仕様はシンプルだ。
- 顧客にメールを送る
- メールには顧客を識別できるURLを埋め込む
- 顧客がリンクをクリックしてLPにアクセス
- アクセス件数とアクセスした顧客を表示
どこにでもあるマーケティングツールだ。俺なら30分で設計が終わる。
当然、アクセスログを記録する。タイムスタンプ、顧客ID、リファラ、IPアドレス。基本中の基本だ。表示時はログを集計すれば、いくらでも分析できる。
- 顧客ごとのアクセス回数
- 時間帯別アクセス数
- リピート率
- 滞在時間
マーケティングの基本データが全て取れる。
第二章：ログという概念の不在
コードを見て、俺は言葉を失った。
彼らの実装は、LPにアクセスがあると：
- メール詳細データの顧客IDリストに追加
- アクセス回数をカウントアップ
それだけだった。
ログを取っていない。
つまり、こういうことだ。
- 顧客Aが2回、顧客Bが1回アクセス → 顧客2人、アクセス3回
- 顧客C、D、Eが1回ずつアクセス → 顧客3人、アクセス3回
全く違う状況なのに、見た目の数字は似ている。だが、このシステムでは「誰が何回」という最も重要な情報が失われる。
さらに調査を進めて、俺は怒りで手が震えた。データベース設計を見たのだ。
メール配信テーブル
- mail_id
- subject
- body
- send_date
- count_lp
- contact_ids[]配列フィールド。可変長の顧客IDリスト。これを見た瞬間、俺は確信した。
こいつらはデータベースを知らない。
第一正規形。1970年代にE.F.Coddが提唱した、リレーショナルデータベースの基本中の基本。一つのフィールドには一つの値。これすら守られていない。
なぜこれが最悪なのか：
- 検索不可能：特定の顧客がアクセスしたメールを探せない
- 集計不可能：SQLでGROUP BYができない
- 整合性なし：同じ顧客IDが重複しても気づかない
- スケーラビリティゼロ：配列が大きくなれば死ぬ
さらにcount_lpという冗長なフィールド。配列の要素数と一致する保証はどこにもない。データの整合性という概念が存在しない世界だった。
第三章：「要件は満たしています」
管理者SEに問い詰めた。返ってきた答えがこれだ。
「要件は満たしています。画面にはLPごとのアクセス件数とアクセスしたユーザーが表示されています」
俺は深呼吸した。怒りで手が震える。タバコをやめて20年、また吸いたくなった。
これは要件を満たしているのか？
否だ。
画面に数字が出ることと、システムとして機能することは違う。これは明らかに契約不適合だ。
第四章：失われた可能性
ログがないということは、以下が永遠に不可能ということだ：
- 顧客分析：誰が何回アクセスしたか不明
- 時系列分析：いつアクセスが集中するか不明
- 効果測定：キャンペーンの成果が測定不能
- 問題調査：トラブル時の原因究明が不可能
マーケティングツールとして致命的だ。これは車輪のない自動車、翼のない飛行機と同じだ。
第五章：学生の実習以下
大学の情報系学部、いや、専門学校でも教える。
「ログは必ず取れ」
なぜか？データは後から作れないからだ。集計は後からでもできる。だが、記録していないデータは永遠に失われる。
これは学生の実習以下だ。学生なら「なぜログが必要か」を学ぶ機会がある。だが、彼らにはその機会すらなかったのか、それとも学ぶ気がなかったのか。