アパレルEC担当者必見のノウハウが充実

BLOG 通販担当者必見のノウハウや注目事例が満載。あなたのビジネスに貢献する通販ブログ

ポイントはミスマッチの解消!失敗しない通販・ECリニューアルの進め方

2020.01.29:ノウハウ
ポイントはミスマッチの解消!失敗しない通販・ECリニューアルの進め方

どうも!野田(@KURUZE)です。お買い物してますか?

今日は通販サイトのリニューアルで「失敗しない」進め方と題して、リニューアル時に必要な手順やアウトプットのご紹介をしていきます。細かく書いていくと全然終わらないので、「ここだけは押さえておこう!」という大事なポイントのみに絞ってお伝えしていきます。主に事業会社の方がシステム会社とやりとりする際に必要なこと、という視点で書いていきます。

まず最初に「なぜリニューアルについて書こう」と思ったかというお話なのですが、ここ数年、ボクのスコープであるアパレルに絞って考えるとけっこうな頻度でリニューアルの事故が発生しています。当然、規模としては大規模案件の事故が多くリニューアルをしたのはいいけど満足に動かない、動いても売上が半分になった、そんなウソのようなホントの大事故が発生しています。

その原因は通販システムに求められる要件が店舗や物流、基幹などあらゆるシステムとの連携が前提になっており、スコープも要件も高度になっていることがあるのですが、もっと根本的な部分でいうと「情報不足によるミスマッチ」によるとこが大きいと思います。

 

「情報不足によるミスマッチ」とは? 

まずこれらの事故の多くは事前に予想できていました。意気揚々と「今度リニューアルするんですよ!どこどこのシステムで」と教えていただくことも多いのですが、その方の所属しているブランドを聞けば大抵の要件レベルは推測できます。それに対して「どこどこのシステム」がその要件レベルにマッチしているのか? そしてプロジェクトを取りまとめる人がいるのか? というのは、これまでの経験ですぐに分かるので「さすがだな」と思うこともあれば「すでに焦げ臭いなぁ」と思うことも (笑)

そしてこの時に「焦げ臭い」案件は、大概燃えていきます。オープン予定日に前のサイトのままであるとか、ティザー画面から切り替わらないとか、重くて重くてまともに動かないとか。。。

逆を言えば最初の段階で「自社の要件を満たしてくれるシステムであるか?」「ちゃんと要件を取りまとめてくれる人がプロジェクト内にいるか?」この2つさえしっかり押さえて、ミスマッチを防ぐことができれば不幸な出来事は避けられるはずです。

ただしボクたちのように複数のブランドやシステム会社と普段からやりとりを行なっていれば、そのブランドとシステムベンダーさんの名前を聞いた時点でパッと推測できるのですが、事業会社の方の立場でいうと既存のシステム会社とのやりとりしかないという場合もあると思います。

でもご安心ください。そんな方でもこのブログの内容を抑えていけば、このミスマッチをある程度防げるようになるはずです。

 

1. まず最初に「見積もり」はダメ!「どんな」を書き出そう!

まず最初に「システム会社へ見積もり!で相見積もりとってその中から決める!」となるケースがほとんどだと思うのですが、これやめてください。今やかなりの高い確率で失敗するでしょう。見積もりをお願いする上で必要なものは「どんな」通販サイトを作るか?という「どんな」の部分です。

例えば、最初から通販システムに実装されている機能以外にカスタマイズして実装しなければいけない機能が10個と100個のサイトじゃ、作る値段が全然違うのは当然ですよね?

だからまず最初に「どんな」の部分を書き出していきます。その際のポイントとしては「機能」と「業務」に分けて書き出すことです。機能であれば「現状こうだから、こういう機能がほしい」というリニューアルに求めることがあると思うので「こういう機能がほしい」という部分を書き出していきます。

そして業務は通販に関連する現状の業務を書き出して、( リニューアル後は ) システム保守だけなのか?他の業務もなのか?など「どの業務をお願いしたいか?」を分かるようにしていきます。その際の粒度ですが、最低限こんなイメージで書き出すといいと思います。

gixyoumu

業務一覧 ( クリックすると拡大します )


kinou

機能一覧 ( クリックすると拡大します )

ひとしきり完成したら次は要望を書き出します。この要望とは「 バナーの制作は3営業日以内にお願いしたい 」というようなサービスレベルを中心に書き出していきます。他にも「 基幹システム A との連携実績を教えてほしい 」 など、聞き出したい内容があれば一緒に盛り込んでいくと良いと思います。

本当はサポート体制やインフラ面への要求を定義した「非機能要求」と呼ばれる書類を作成した方が良いのですが、相当専門的になるので「 サポート体制は365日24時間対応してほしい 」とか「 システムダウンの際には何時間以内に復旧してほしい 」とか、分かる範囲で構わないので要望一覧に盛り込んでください。

これらが完成すると、見積もりの際に「機能」「業務範囲」「要望」といったものがシステム会社に明示できるようになります。

このアウトプットを作成する際の注意点としては「ある程度、風呂敷を広げて書いていく」ということです。この段階ではあくまで要望ですので多少背伸びした「こんなことも将来的にはやっていきたいんだよな」という内容も盛り込んでください。この後に出てくる見積もりを確認して、実際の予算との兼ね合いでリニューアル時の仕様は決めていくので、ここでは可能性を広げておいてください。

 

2. 見積もり作成に必要な提案依頼書 ( =RFP ) をまとめる

次は「提案依頼書」を作ります。たまにRFPって言葉を耳にするかもしれませんが、それのことです。

提案依頼書とは、先ほどまとめた「機能」「業務範囲」「要望」を踏まえて「 そもそもこの機能を作れるのか? 業務や要望に対応できるのか? 対応可能な場合どれくらいの費用になるか?」を提案してもらうために必要な書類です。

提案依頼書には最低限、こんな内容を盛り込んでいくと良いと思います。

・リニューアルで実現したいこと
例えば、お客様にとってこういうサイトでありたいという理想像だとか、店舗と通販サイトの在庫・会員情報の一元化みたいな代表的機能であるとか、スタッフの業務負荷を減らすためであるとか、いくつか実現したいことを1P程度に完結にまとめて書き出していきます。箇条書きで全然構いません。

・現状のシステム相関図
これは絶対に入れてください。現状の通販システムがWMSや基幹システムと連携しているのか?していないのか? など、現状のシステム相関図があることで全体像が把握可能にありプロジェクトの範囲が見えてきます。また導入しているソリューションなども記入しておくとよいでしょう。

・リニューアル後のシステム相関図
これも書ける場合はあると良いと思います。当然通販システムのリニューアルに際して他のシステムもリプレイスということもあるでしょう。その場合は具体的なシステム名まで書けなくても構わないのでWMSだったらWMSなど、通販システムが関連するであろうシステム名を書き出してください。

そして大事なことはリニューアルのプロジェクトの範囲も一緒に明記しておくと分かりやすいと思います。今回のプロジェクトでは通販システムのリニューアルだけなのか? 連携するシステムとの連携開発も含まれるのか? はたまた連携するシステムの選定や導入プロジェクトの管理まで含まれるのか?など、相関図に対して対象となる部分を色付けするなどで提案を依頼するプロジェクトの範囲を明記すると良いと思います。

soukan

参考イメージ  ( クリックすると拡大します )

・前提条件
サイトのアクセス数や会員数、売上などのデータを記載していきます。これがないとサイトの規模感が分からないので、必ず記載してください、主な内容を以下にあげていきます。

list

 ( クリックすると拡大します )

・スケジュール
いつまでにサイトをオープンさせるかのスケジュールです。その際に見積もりをいただいてから社内で検討してシステム会社を決定する時期、その後に続くリニューアルプロジェクトをキックオフしたい時期など、ポイントポイントのタイミングを入れると良いと思います。あくまでこの段階では要望ですので、スケジュールも希望を記載してください。

・提案依頼の内容
業務・要望の対応可否。機能の実現可否。初期費用と月額費用。 提案の期日。そういった具体的に提案してほしい内容を記載していきます。これでシステム的な面はある程度カバーされるはずです。

しかし冒頭に「情報不足のミスマッチ」とありましたが、そこでは「ちゃんと要件を取りまとめてくれる人」と記載しました。リニューアルを成功させるためにはシステムだけでは不十分で人も、というか人の方が重要です。そこでプロジェクト開始後の体制や担当者のプロフィールも提案内容に含むように要望してください。

細かく言えばもっと全然あるのですが、最低限この辺が揃えば次のフェーズである「見積もり」に進んでも問題ないと思います。

このフェーズは適当にやらないで数ヶ月かけてでも、じっくり実施してください。内部でここを固めておくことで大枠の方向性と規模感が見えてきますし、その後の進行も早くなります。当然、ある程度やるべきことが明確になっているのでシステム会社とのミスマッチも減り、リニューアルのリスクが大きく軽減します。

早い話が「やる前にやることの全容をつかんでおく」ということです。考えてみれば当たり前の話ですよね? でもここをスルーして全容もなにも把握しないでプロジェクトを進めていくなんて、コンパスも海図もないまま出航するような自殺行為。遠回りなようで結果的には安全に進める近道になるので、1と2の工程はしっかり検討して書き出すようにしてください。

 

3. いよいよ見積もり依頼!「どんな」の内容に合わせて依頼先を絞り込む

さぁ手元には「機能一覧」「業務範囲」「要望一覧」「提案依頼書」が揃いました。これでリニューアルするサイトが「 どんなサイトか?」その概要が他社の人でも分かるようになります。

あとは気になるシステム会社に声をかけて提案の依頼を行います。できれば複数社に声をかけて、提案内容を精査した上で決めていくと良いと思います。

ここでの注意点は、やたら声をかければ良いってもんじゃないこと。「どんな」サイトにしたいか?のどんなによって、提案を依頼する会社を絞ると良いと思います。

例えば「 システム特化型 」か「 フルフィルメント型 」があると思います。商品登録や問い合わせ対応は中でやるなど、リニューアルに求める範囲が「ECシステム」に限定される場合はシステム提供のみで月額費用が抑えられる「 システム特化型 」の会社を中心に提案を依頼すると良いと思います。反対に問い合わせ対応や商品登録もまとめて外注したいという場合は「 フルフィルメント型 」の会社を中心に提案を依頼すると良いと思います。

そして実際に提案をお願いすると「 どんなサイトか?」という要望は同じなのに、各社でまったく値段が違うことにびっくりすると思います。また資料の理解度や各社のスタンスも鮮明に浮き彫りになります。とある会社は自社の機能をひたすら説明するプレゼン、とある会社は資料の要望を踏まえたプレゼン、そのスタンスは本当にバラバラです。

長い長いリニューアルの工程。その期間を共にするからには費用面以外に要望の理解度や人柄も重要な判断基準に入れて「一緒にやっていけそうか?」という視点を持ち、要望の実現度・実現する上での費用感、これらを総合して最終的なパートナーを選定してください。

ごくごく当たり前のことで「察してよ!」っていう内容でも「書いてないので、できません!」って言っちゃうようなとこもマジであるので、くれぐれもご注意ください。

もう1つの注意点としては、この段階での見積もりはあくまで「概算」であるということ。正式な見積もりはこの後の詳細要件定義を経て決定していきます。

ですので、この段階では「おおよその金額」という目安で判断していくことになります。その際、提案書の段階では少し背伸びして書いた方が良いと言いましたが、大抵の場合予算オーバーで出てくると思います。でもそれで構いません。実際に提出された見積もりには各要望を実現するための費用が「おおよそ」で記載されているので、1つ1つの要望をコストパフォーマンスが悪いものからカットしていき、最終的に予算にはめていけば良いのです。

 

4. いよいよキックオフ!まずは要件整理。ポイントはオープン時に詰め込みすぎないこと!

さぁパートナーが決定して、いよいよプロジェクトがキックオフとなります。ここからプロジェクトを引っ張っていくのは基本的にシステム会社となります。提案依頼書の段階では要望だったものを仕様に落とし込むために定例会議と不定期の分化会を重ねていきます。

そしてまず最初にやらなければいけないのは、提案依頼書に盛り込まれた幾多ある要望を整理して開発のフェーズ分けを行うことです。リニューアル失敗の原因としてよくあるのがオープン時に要件を詰め込みすぎて結果的に炎上するパターン。あるあるですね。

最初の段階では「 以前のサイトからサービスや機能がダウンしない 」くらいに要件を絞って、まずは安全にオープンさせることに注力してください。無理矢理にでもシステム会社の方に要望を押し込んで「自分って仕事できる!」と勘違いしてるイタい人をたまに見かけますが、こういう人が幅をきかせるプロジェクトはほぼ破綻します。

突っ込みたい気持ちは重々理解できますが、新機能1つで売上なんて簡単に爆増しません。それよりリニューアルしてダメになったと思われないように、事故なく安全にシステム移行することが最優先となります。機能の追加はオープンして運用にも慣れたころに、どんどん追加していけばいいのです。

 

5. 要望を仕様に落とし込む詳細要件定義。システム会社と自分たちの業務スコープを勘違いしないように

開発のフェーズ分けが終わり、オープン時の要件が絞り込めたら、1つ1つの要件をみっちりと詰めていく詳細要件定義のフェーズに移ります。このフェーズを行うことで要望が仕様に落とし込まれ見積もりが正式なものに確定していきます。

この段階において注意すべき点は、システム会社主導で決めていく内容は「仕様」であり、通販サイトをオープンするために必要なことに限定されるということ。つまり「売上を上げるために必要なこと」を一緒になって、内部の会議にまで参加して一緒に考えてくれるとは思わないでください。稀にそこまでやってくれる会社もあるのですが、基本的にはその部分は自分たちの仕事です。それくらい割り切って考えておかないとダメです。

あくまで、売上を伸ばすために必要な要件を実現する「通販システムを構築してくれる会社」であって、「売上を伸ばすために必要な要件」を考えるのはボクたち事業会社側に立つ者達の仕事なのです。ここを履き違えて「何もしてくれない」と嘆いている人が本当に多いのですが、売上を伸ばすために必要な要件を出すのは当然ボクたちの仕事なのです。

ですので「売上を伸ばすために必要な要件」という頭と、決まったことを仕様として落とし込む頭。この2つを切り替えながらこの時期は過ごすことになるので、なかなか刺激的な毎日をすごすことができます ( 笑 )。

 

6. いよいよ開発へ。あとは作業!作業!作業!テスト!テスト!テスト!

要件を出し切ったら詳細要件を経て随時開発へ流していきます。オープン1〜3ヶ月前くらいに差し掛かるとひたすら作業!作業!作業!テスト!テスト!テスト!となります。規模にもよりますが、テスト画面が解放された後に行うテストでは何千というバグが出てくると思います。

この時期はモニタをレンタルしてでも片方の画面でデバッグシート、片方の画面でテスト画面を表示するなどで、作業の効率化をすると良いと思います。スプレッドなどでリアルタイムに書き込んで、プロジェクトメンバーが各々書き込んでいく。数百行だったものがやがて千になり、やがて数千行になんてことも (苦笑)。この際のポイントとしては、優先度を付けて修正していってください。

クリティカルなものは当然オープン前にすべて解消しますが、例えば行間や字間などオープン後に修正すれば良いものもたくさんこの中には含まるはずです。そういったものは、オープン後に回しても構わないというくらいの気持ちで優先度が高いものから修正していきます。

 

7. ついにオープン!残りタスクを処理して、次フェーズへ移行する

オープン時必須なデバッグを潰し終えて、いよいよオープン日を迎えることとなります。お疲れ様でした!一旦は (笑)。

この後はオープン後に解消すべきバグの解消、そして実際に運用を走らせてみて新システムに合わせて業務を改善すべきところがあれば改善していきます。細かく要件定義をしても、どうしてもイジってみなければ分からない部分も多いので、そこで出てきた課題を解決するためにシステムの改修が必要であれば、フェーズ2 以降に回した開発に差し込んで追加機能開発のフェーズに移っていきます。

 

とはいっても経験がかなり大事。リニューアルの際にはプロと並走するのが得策

よく「家は3回建てないと理想の家にならない」と言われますが、通販のリニューアルもまったく同じだと思います。

正直ここまで書いてきましたが、複雑になった通販システムに求められる要件を事業会社の方だけで出し切って、資料化して、仕様化するために詳細な要件を詰めていく、というのは相当なハードルだと思います。事業会社の方は「通販運用のプロ」であって、リニューアルのプロではないからです。

ですのでリスクを回避するためにも、ボクたちのようなその道のプロに頼むのも必要な時代になっていると思います。それくらい今の通販システムに求められることが複雑化しています。ボクたちは事業会社のサポートを生業としているので、1〜7の工程すべてを事業会社側の立場として入り込み、御社の通販担当者というような位置付けでリニューアルの工程すべてにおいて手厚くサポートしていきます。

1と2の工程では、これまで幾多にも及ぶリニューアル経験から必要であろう機能や業務などもすでに洗い出されているので、社内で要件を出すよりもより広い視野で、今の時代に必要な機能が盛り込まれたアウトプットが実現できると思います。

3の工程においては、特定のシステム会社に肩入れることがない完全中立な第三者ですので、要件に適していると思われるシステム会社に絞り込むことが可能です。

4〜5の詳細要件定義では、システム会社と仕様の定義をご一緒するだけでなく、内部の担当として「売上を伸ばすために必要な要件出し」についてもご一緒して知恵を絞っていきます。

そして6の工程ではオープンに向けて必要なタスクを整理して、一緒に机を並べてバグ出しを行うこともあるでしょう。バグ出しも「毎回ここが怪しい」という経験に基づく部分がかなり多いです。そしてオープン後は、残りの追加開発や売上アップのために一緒に考えていきます。

通販サイトの新規立ち上げやリニューアルは今や社運を賭けた一大イベントです。最適な通販システムを選びたい。事故なくリニューアルをしたい。売上が取れる通販システムを構築したい。そんな願いを叶えたいのであれば、まずはご相談くださいませ。

The following two tabs change content below.
野田 大介

野田 大介

株式会社ファナティック代表取締役
月刊誌Ollie magazineの編集者からキャリアをスタート。その後は、フリーライターとしてhoneyee.comやLightningなどでの執筆、複数のアパレル企業で商品企画、生産管理、店舗/卸営業、通販業務を歴任。現場の最前線で培った通販の運用実積に加え、メディア業界で培ったコンテンツ・マネージメント力、そして長年のアパレル経験と、アパレル通販を運営する上で必要な知識と現場経験の両面を網羅。趣味、というか生きがいは「買い物」

この記事を読んだ方へおすすめ

PAGE TOP