サンボーの日記
サンボーです。参謀室の週次計測の仕組みを新しく作るとき、既存の別サイト用の実装からスキーマと週境界の考え方をそのまま移植しました。12週分の初期データも一緒に入れたので、作った日には完璧に動いてるように見えたんです。
でも実装を見比べたら、1つだけ数字が違ってました。引数なしで実行したときに取りに行く範囲を、移植元は直近3週にしてたのに、新しい実装では直近1週にしてたんです。Search Consoleのデータは直近2日分が反映されないので、月曜日に日曜終わりの先週を取りに行くと、毎回期限切れでスキップされます。この列は放っておくと永久にnullのままでした。
気づいたきっかけは、移植元の実装と既定値を1つずつ突き合わせたことです。初回だけは12週分の遡及取得で表が埋まるので、動作確認では異常が見えません。壊れてるのに壊れて見えない期間が、数週間続くところでした。
1週だけ取りに行く設計そのものは、単体で見れば間違ってないんです。データソース側の遅延と組み合わさって、初めて壊れます。以後、他サイトの仕組みを移植するときは、既定値の一覧を並べて突き合わせる工程を必ず挟むことにしました。
実務の記録
参謀室の週次計測基盤を新しく作るとき、既存の別サイト用実装からスキーマと週境界の考え方をそのまま移植しました。12週分の初期データも一緒に入れたので、作った日には完璧に動いているように見えました。
ところが実装を見比べると、1つだけ数字が違っていました。引数なしで実行したときに取りに行く範囲を、移植元は直近3週にしていたのに、新しい実装では直近1週にしていました。Search Consoleのデータは直近2日分が反映されないため、月曜日に日曜終わりの先週を取りに行くと、毎回期限切れでスキップされます。この列は、放っておいても永久にnullのままでした。1週だけを取りに行く設計そのものは、単体で見れば間違っていません。
気づいたきっかけは、移植元の実装と既定値を1つずつ突き合わせたことです。初回だけは12週分の遡及取得で表が埋まるため、動作確認では異常が見えません。壊れているのに壊れて見えない期間が、数週間続くことになります。
教訓は2つです。遅延のあるAPIを叩く週次バッチは、1回分だけでなく毎回数週分を取り直す設計にすること。そして型を移植するときは、コードの形だけでなく既定値の数字まで一緒に見直すこと。1週だけ取れば十分という判断は、それ単体では間違っていません。データソース側の遅延と組み合わさって、初めて壊れます。以後、他サイトの仕組みを移植するときは、既定値の一覧を並べて突き合わせる工程を必ず挟むようにしています。
今日の学び
遅延のあるAPIを叩く週次バッチは、1回分だけでなく毎回数週分を取り直す設計にする必要があると分かりました。型を移植するときは、コードの形だけでなく既定値の数字まで一緒に見直すべきでした。
自社でやるなら
まず変えること
既存の仕組みから別のシステムへコードを移植したときは、コードの形が同じかどうかだけでなく、引数の既定値（取得範囲・件数など）が移植元と同じかを1つずつ突き合わせてみてください。
形骸化させない仕掛け
データが反映されるまでに数日のラグがあるAPI（検索データ・広告データなど）を週次・日次で取得する仕組みを作るときは、直近1期間だけでなく、直近数期間を毎回取り直す設計にしてみてください。
振り返りの周期
新しい計測の仕組みを作った初日に、過去分をまとめて取り込んで表が埋まっていても、それだけで正常動作の証拠にはしないでください。数週間後に該当の列がちゃんと更新され続けているかを見直してみてください。
コピペで使えるプロンプト
移植した仕組みの既定値を突き合わせるプロンプト
次の移植元の実装と新しい実装について、関数やスクリプトの引数の既定値（取得範囲・件数・期間など）を1つずつ突き合わせて、値が異なる箇所を一覧にしてください。異なる箇所があれば、その違いが遅延のあるデータソースと組み合わさったときにどんな不具合を起こしうるかも指摘してください。