ある観光地の、有名な名所のすぐそばに、小さなギャラリーがある。色彩を専門にしてきた店主が、絵画や工芸品を展示して売る店だ。サイトはすでにあった。既製のホームページ作成サービスで作られたもので、店の紹介としてはよくできている。ただ、そこには売り場がなかった。作品を気に入った人が、その場で買う手段がないのだ。
観光地の店には、旅の途中で立ち寄る客が多い。旅先で見た絵を、家に帰ってからもう一度思い出して、やっぱり欲しいと思う。そのとき受け皿がなければ、気持ちは行き場を失う。せっかく心が動いたのに、買い方が分からないまま日が過ぎていく。展示を見た人の熱を、そのまま受け止められる場所をつくる。サイトを作り直し、オンラインで買えるようにする。それがこの制作記の始まりだった。
大がかりな仕組みは、いらない
ECと聞くと、大きな通販システムを思い浮かべるかもしれない。だがこの店の商品は、原画なら一点物で、点数も十数点ほど。月々の固定費がかかる立派な仕組みは、この規模には重すぎる。身の丈に合わない道具は、使う前から店主の負担になる。
選んだのは、いちばん身軽な作りだった。サイトはただのHTMLの静的なページとして作り、クラウドの置き場（S3）とCDNから配信する。サーバーで動く部分を極力なくせば、費用はごく小さく、壊れる場所も減る。手をかけずに済むぶん、店主は本業に集中できる。小さな店のサイトは、手がかからないことそのものが、静かな価値になる。
カートは、ブラウザの中に
買い物カートは自前で作った。といっても大げさなものではない。カートの中身は、お客のブラウザの中（localStorage）に覚えさせておくだけで、サーバー側には何も持たない。作品を選び、カートに入れ、購入手続きへ進む。この買い物の入口までは、サーバーがなくても動く。裏側を持たないぶん、管理する場所も、守るべき情報も少なくて済む。預かるものが少ないのは、それ自体が身軽さになる。
決済は、リンクを発行する方式に
決済だけは自前で作らない。カード番号を扱うのは、専門の決済サービスに任せるべき領域だ。購入手続きに進むと、裏側で決済サービスに支払い用のリンクを発行してもらい、お客をそのページへ送る。金額は画面上の値ではなく、サーバー側に持たせた商品台帳の価格で発行する。画面の数字を誰かが書き換えても、請求額は変わらない作りだ。安さより先に、まず安全であること。一度でも事故を起こせば取り戻すのは難しく、小さな店ほど、そこは崩せない。
決済がまだでも、店は開けられる
ただし、決済側の口座や設定には店側の準備がいり、こちらだけでは進められない。その完成を待っていては、いつまでも店を開けない。そこで受け口をもう一つ用意した。決済の窓口がまだ設定されていないあいだは、購入ボタンを押すと、カートの中身がそのままメールでの注文リクエストに自動で切り替わる。注文は店に届き、支払いは個別にやり取りすればいい。
この受け口のおかげで、決済の準備を待たずに、七月の頭にサイトを公開できた。整うまで閉じておくのではなく、開けられるところから開ける。決済は、準備ができ次第、裏側に静かに差し込むだけでいい。
次の回は、公開までの道のりでいちばん迷走した、デザインの話を書く。