Amazonが今年初めに 紹介料プランを変更したのは周知の事実だが、周知でなかったのは、このプラン変更のアナウンスの時点では、その時点ではシステム変更が完了していなかったことだ。

Amazonアソシエイトの方々はご存じのとおり、2月に入ってから紹介料の統計の表示が何度もおかしくなっていた。紹介料率が「なし」になっていたり、紹介料率の計算が四半期ベースのままだったり。このあたりの表示が「期待どおり」になったのは、本日深夜だった。

しかし、このことは大きな事件とも事故とも捉えられていなかった。「しかるべき時期、すなわち紹介料を決算する頃には間に合うだろう」と構えている人が多かったのだろう。実は私もその一人だ。そして一時的な不具合が出たものの、実際にそのとおりとなった。

この「Amazon泥縄メソッド」は、今後のWeb開発のありように対する重要な示唆を含んでいるように思われたのでまとめてみた。

実装は後回しでもかまわない

だから泥縄なわけだが、泥縄でも泥棒が逃げなければOKであることをAmazonは証明したとも言える。

工事の過程を見せる

そして「なぜ泥棒が逃げなかったか」と言えば、目の前で縄がなわれているところがちゃんと見えたからだ。今回の変更では、まず料率のパーセンテージのところが変更された。これは一月にすでに行われていたので、料率が上がったことはその時点できちんと見えていた。そして二月に入ってから料率が「なし」になったが、それでも商品合計やクリック数はきちんと上がっていた。そして最後に料率計算が四半期ベースから月次ベースに切り替わったのだが、その作業工程がだいたいこちらの憶測どおりだったので、ほとんど不安を感じなかったのだ。

基礎工事は周到にすませておく

今回なぜこの泥縄メソッドがうまく行ったかと言えば、変更点が「データの解釈」のみだったからだ。これがデータベースそのものの変更ともなればこうは行かない。日々集計している生データという基礎がしっかりしていたからこそ、「うわもの」を泥縄で作っても許されたのだ。MVCで言えば、今回の変更はViewであり、そしてViewに関しては泥縄はよいどころか今後の主流と言えるだろう。

不(測|足)の事態は早めにアナウンスする

むしろ今回一番「不安」だったのは、生データの集計更新が一時的に止まった--ように見えた--ことが一度あったことだ。この事故がプラン変更と何らかの関係があるかどうかは不明だが、それでもこちらに関してはAmazonは後手に回っていた。集計はほぼ24時間おきなので、遅くともその倍、48時間後には告知するべきだっただろう。

まとめ

Web2.0づいている人はこの「泥縄メソッド」を見て「なにを今更」と思うかもしれないが、Amazonの規模でもそれがうまく行くというのはやはり心強い。しかし、表面だけ見て何でも泥縄でうまく行くいくと思い込むのは致命的な勘違いでもある。泥縄に出来ないところがきちんと作り込んであったこその泥縄だということも見逃してはならないだろう。

Dan the Amazon Associate