株式会社IDOM様
顧客体験を追求する
株式会社IDOM様は、「中古車のガリバー」で有名な、中古車買取・卸販売を事業の中核とされてきました。
そこから事業コンセプトを拡大して、自動車に関係する流通システムの会社として事業を拡大されています。
今回は、IDOM様の最大のサイト、221616.comの高速化について、SpelldataのWebパフォーマンスチューニングサービスを導入して頂きました。
サイトオーナーである村田様、高速化プロジェクトを主導された開発セクションの坪田様、制作セクションのディレクターの濱渕様に、IDOM様がどうしてWebパフォーマンスを重要視しているのか、コンサルティングを導入してみての感想や、今後のWebパフォーマンスについて展望などをお伺いしました。
TEAM X 開発セクション
坪田 渉 様
TEAM X 制作セクション
濱渕 祐典 様
マーケティングチーム デジタルマーケセクション
村田 創 様
IDOMの事業
IDOMの事業は、広くクルマの流通に関する事業です。
お客様からクルマを買い取りをさせていただき、そして販売をします。
販売には、卸売りと小売りと2つあります。
創業のころは「ガリバー」という名前でやっておりました。
クルマを売らないお店というのが当時のキャッチコピーです。
クルマを買い取ってお客様へ販売せず、すべて卸売り向けオークションで販売していたのです。
クルマを買い取らせていただいてからオークションで販売すると、大体1週間から2週間でクルマが売れてしまって、凄く回転の速いビジネスでした。
その回転してる２週間の間も勿体無いので、画像で全国の在庫の共有をして小売りできるシステムを構築しました。
それが「ドルフィネット」という画像販売システムです。
その後2007年ごろから、販売へと少しづつシフトしていきました。
ガリバーというお店だけではなく、国内ではガリバーのアウトレットを始め、「LIBERALA」という輸入車専門の中古車のお店を展開し、どんどん拡大して販売のチャンネルを広げています。
それ以外では、海外の事業の方も行なっておりまして、USA・オーストラリア・ニュージランド・タイ・中国という環太平洋エリアにはお店を展開しています。
現地でクルマを仕入れて販売するモデル、そして日本から買い取ったクルマを輸出して販売するモデル、両方やっている状態です。
村田さんのお仕事の内容
わたくしの仕事は国内店舗への送客の半分を占める221616.comというサイトの担当です。
そこの集客からマネタイズの上流のところをやっています。
サイトでコンバージョンした後は、コンタクトセンターでアポイントメントを取って、それから相談に入るという、あと２段階後ろに残っているのですけれども、一番最初のところを預かっているのが私の領域となります。
表示速度改善のきっかけ
きっかけはですね、一番はサイトのリニューアルです。それで前より遅くなるのは分かっていました。
以前はAWSとミドルウェアとしてのCMSの組み合わせではなくて、DBから直だったんですね。
前任者からは、「速いでしょ」とよく言われたものです。
速かったのが、今回間違いなく遅くなるとわかっていましたので、それではどこまで直さないといけないかという課題がありました。
それと世の中の潮流で、去年ぐらいからGoogleさんが「そろそろ速さを考えて下さい」と言い出された。
理由としてはこの2つです。
Spelldataを選んだ理由
実はですね、竹洞さんのSlideshareなのです。（笑）
表示速度に関することで、(インターネット上で)一番出回っているのが竹洞さんの資料だった。
自分で調べてみて、やっていらっしゃるのが実は竹洞さんしかいらっしゃらなかった。
だから日本でその辺のパイオニアなんだろうなというところがあって、ご信用できるかなと。
お会いするまでに何度かメールでキャッチボールさせていただいて、「これは間違いない」という確信を得たところが一番でした。
実は、他社様にもお話聞きました。
が、正直、(Webパフォーマンス高速化という)商品を自分の言葉で語れなかったんですよ。
高速化の感想
速度はやれば間違いなく速くなる、手ごたえがあります。
私はエンジニアではありませんし、ITの人間でもないです。
ガリバーの普通の店長を経て、企画屋さんを経て、今の仕事を預かっています。
そんな人間でも、間違いなく手繰り寄せられるものがあると感じられる位に、前に進めたというのが一番の収穫でした。
一方で、進められにくい・進めにくいということ、プロジェクト途中で右にいったり左にいったりしたこともあって、それだけやっぱり高速化は難しいなと思いました。
今後の展望
監視体制づくり
今この速くしたものを絶対落とさないようにしていく為の体制作りです。
それは実は監視、計測を続けることであり、人を育てることになるかと思っています。
その監視のところは、実はすでに厳しいですね。（笑）
いきなり悪くなっていますからね。
悪くなっている理由を探して、自分がクロールして初めて気づくみたいな…
「ニャロー、これ入れたの誰だ!」みたいな。（笑）
広告だけで試したいタグがありますって言っていたら、間違って全ページに展開してしまっていて。
それだけで８秒遅くなりましたよ、ありえないです。（笑）
即「抜いてくれ!」と指示を出しました。
それをシステムのところで検知してるはずなんですが、アラートが上がってこないのです。
また、習慣にしないとだめなんですよね。
一応、システムのところで1日30分に1回、ずっと回し続けてログを取っているのですけど。
そこから、計測データを見る習慣をまずつけないといけないと…
サイトの品質管理という観点は、竹洞さんが常に仰ってますけど、やはりとても大事なものだということに改めて気が付きましたね。（笑）
だからそういうとこに気を使わないといけない。
フォームの問題
今回、施策中、フロント要件のところで速くなる要素って２つあるなって気づきました。
まず一つは、簡単にいうとフォーム一つ無くすだけで速くなる。
間違いなく速くなる。
でも世の中、ロングランディングページと言われる、フォームがいっぱいあるページを作る。
これ読んだ人に強く伝えないといけないと思うんですが、フォームが無くなればかなり速くなるんだよと。（笑）
広告畑から入ってきた人とかで、そういうことやっていると、もうそれこそキャッチするところがいっぱいあった方が良いんだと言ってフォームをつけたがる。
「いや違う、削った方が、ユーザーにとって良いことの方がある」ってことを、ちゃんと気づいてもらわないといけないって思いました。
LPO(Landing Page Optimization)の問題
あともう一つ、2〜3月の頃だったと思うんですが、後の運用を簡易にするためにLPO(Landing Page Optimization: ランディングページ最適化)のタグをGTM(Google Tag Manager)の中に入れてしまいました。
あれによって500msぐらい遅くなってるんですよね。
あれ、やっぱり直書きの方が良いんじゃないかと今でも悩みます。
結局この半年かけて実施してきたことって、その500msを取り戻す作業だった気もしなくもないと。（笑）
プラスマイナスってどこで見るんだ、みたいなのがありまして…
（コンサルティングに基づく改善の結果）速くはなりました。
DOM Complete(表示完了)は速くなりましたよね。
でも、Render Start(表示開始)は、未だにLPOのツールに影響されています。
Rener Startは、Google Tag Managerに入れて楽して遅くなるか、直書きする面倒さを受け入れて表示開始を高速化するかというトレードオフの関係もあって…
もっと速くするには、結局のところ様々なツールの上手いマネージメントの仕方を考えなくてはいけない。
自分たちのタグだけでなり立っているWebサイトって、どこにもないんですよね。
「サイトの速度」は「ビジネスの速度」
これは、この間竹洞さんの講演(「ネット＆スマートフォンコマース 2017」)でも言われていました。
「色んなもの入れてるよね。いろんなもの入れてるけど、その速度に見合った分だけのリターンだせてるんの？」
それっていうのは、全体のなかで評価するっていうことをしないとならない、ことだと痛感しています。
速さを求めれば求めるほど、入れられるタグには限界がある。
タグを入れた分だけのリターンが出れば良いけど…、ってところまでちゃんと終始・収支を考えないとならない。
経営層は、「ビジネスの速度」が速まることは関心ある。
だけど、「サイトの速度」が速くなることが、実はビジネスに直結していることを理解している方は殆どいらっしゃらない。
そこが一番大事なとこかなと思っていたりします。