失敗しないECシステム刷新のポイントとは？ ネクトラスの中島社長が解説

社内に“分かる人”を

自分自身もリプレースと新規のローンチも含めて大型のシステム刷新は6度たずさわり、結果としては4勝2敗で、その中には一度、旧システムに切り戻してリプレースを延期するという痛い目にもあっている。

新規ローンチはよほどのことでもない限り、多少のトラブルに見舞われても切り抜けられるものだが、リプレースの場合は既存事業を行わなくてはいけないし、すでにお客様がいるので失敗すると大変なことになる。

昔は「1秒たりとも（サイトを）止めるな」とさえ言われていた。今は結構な期間、一旦閉鎖することが前提になっているのに旧サイトへの切り戻しという事態が続いたのは不思議なくらいだ。

トイザらスやジュピターショップチャンネル、三越伊勢丹などでEC事業やオムニチャネルの事業責任者を歴任したネクトラスの中島郁社長

リプレースを行う目的には大きく分けて4つのパターンがある。まず、単純リプレースというものがあり、使っているシステムの保守が切れるなど、システムやソフトウェアが今後使えなくなるといった場合に行う。

本来の改善や構想もないまま今の仕様のままの単純リプレースを行うくらいなら、可能であればベンダーに割増額を払ってでも特別保守をお願いした方がいい。大幅な売り上げ拡大が見込めない単純リプレースでもそれなりの投資は必要だし、もちろんシステムリリースリスクはある。

ふたつ目は、事業規模が大きくなったときにキャパシティーを増やすスケールアップ目的のリプレースで、10億円の売り上げを想定してシステムを作ったら50億円くらいの売り上げが見込めるようになり、だましだまし使っているようなケースになる。元々のプラットフォームの構造が売り上げ規模に準じて作っていたり、商品数やコンテンツが増えてサイト表示が遅くなるなど、単純なハードウェアの追加では解消できない場合だ。こういうケースはほとんどが入れ替えで、旧サイトのベンダーの上位システムを導入することもあるが、違うプラットフォームを入れることも多い。

3つ目が、事業展開に合わせた改修、追加開発が困難になった場合に行う。基本的にECシステムは最初の状態から少しずつ欲しい機能をつけ足したり、改修していくもの。つけ足すことはできなくはないが、蓄積していくとシステム全体のリプレースと同じくらい割高なコストがかかったり、制限される項目が増えたり、全体のパフォーマンスに影響するような場合はリプレースで対応することになる。

最後は、大きな事業の進展や戦略変更、世の中の要求で実現させるべき要件が大きく変わってプラットフォームを変更せざるを得ないケースだ。その他は既存のシステムを作るときに期待していたようなリリースができず、他のシステムに変えたり、次世代のシステムに切り替えたらすごく良くなるという幻想を抱えてリプレースするケースで、これも結構多い。

欲張り過ぎは大失敗のもと

ECシステムのリプレースについて結論から言うと、自社内に知見のある人、エンジニアということではなく、仕組みを含めいろいろなECにまつわることがわかっている人がいないと良いシステムはできない。

また、最初のシステム構築がうまくいかず、不十分な状態で数年間そのシステムを使っていたような場合でも、ベンダー側はその間にコミュニケーションもよくなり、知見を貯めて育ってきているのに、他のベンダーのシステムに切り替えてしまうケースがある。ただ、違うベンダーとリプレースを行うと結局、コミュニケーション面で同じことが起きる。

個人的には最初の悪感情を捨て、せっかく育ったベンダーと協力し、いったんきれいに作り直すことを勧めたい。ただ、各社いろいろな事情があってそうならないことが多い。

リプレースの要件としては、運用費が高くなったり機能も限界で開発費も高くなった、キャパシティーも限界に近づいてきたり、新しい売り方もしたいといった具合に、あれもこれもと社内で盛り上がってしまう。

さまざまなことがリプレースの要素としてあり、それを全部いっぺんにやろうと欲張ってしまいがちだ。システム刷新で失敗するのは欲張り過ぎか、企業の論理がシステムやセキュリティーに先行されたときのどちらか。企業の論理とは、ビジネス上の都合でいつまでにオープンしないといけないなどスケジュール的に無理があったときなどだ。システムは間に合わせようと無理をすると質が落ちる。品質とセキュリティーを犠牲にしては絶対にいけない。

細かい部分では、ECのシステムリプレース時には社内の人員とベンダー、要件定義ができる人が必要だが、内部にわかる人がいないとうまくいかない。ベンダーが「できる」と言っていてもできないことはたくさんある。会社として経験があっても担当チームに経験がないこともあり、しっかりと確認してから進める必要がある。そうした確認をするのにも、社内にECの仕組みがわかる人がいないといけない。いない場合は経験のあるコンサルタントなどに入ってもらう方がいい。

実際にシステムリプレースを行う際、社内のメンバーは会社の規模や組織にもよるが、情報システム部門の位置づけも関係してくる。できれば、情報システム部門の人や企画部門の人を含め、リプレースの2年くらい前から似たような他社の事例や海外事例も調べて調査や構想を薄く始めてほしい。

その後、ベンダーの提案や説明を受けながら、材料をそろえた上で、商品部、販売部、物流部などのキーマンにプロジェクトチームに入ってもらって詳細の要件定義を作る。その際、ECの仕組みがわかっている人がいなければ、外部から人を採用してある程度のポジションに置いて進める方がいい。しっかり入り込んでくれるコンサルなどを雇うのもいい。

そもそもECシステムのプラットフォームは規模や売り方によって合うものと合わないものがある。合うものを選んだ上で、SI（システムインテグレーション）屋も経験豊富で、経験者をしっかり担当にしてくれるところが選ぶことは外せない。未経験のSI屋や開発チームには怖くて任せられない。

海外のプラットフォームの場合はローカリゼーションが不十分な場合もある。パッケージとしていいものもあるが、国内に事例が少ないと経験のあるエンジニアも少なく、開発するときに時間がかかるし、何かあったときのリソース調達が難しいのがデメリットになる。

トラブル発生時の事前計画を

これはベンダー目線になるが、SI屋はプロジェクトがずるずる延びてローンチが遅くなるよりも、ローンチしてトラブルがあった場合にその原因部分を2週間くらいかけて一気に直す方が結果的に好ましいようだ。ずるずる何カ月もローンチが延びるとリソースを投入し続けなければならず、赤字になってしまう。

それよりも、非常事態があったときにリソースを一気に投入して集中的に解消する方がコストもかからない上に、その期間は大変でもエンジニアの疲弊感も少ない。昨今のリプレース事例は、1カ月以上もサイトを止めているのに、新システムの不具合を解決できていないということで、よほどの問題が起きているということなのだろうかと推測してしまう。

リプレース時には程度の差こそあれ、何かしらのトラブルはあると思った方がよく、トラブルが起きたときの準備を事前に計画しておくことが大事になる。ひとつは、大々的に事前告知をしたり、リリース直後に大型キャンペーンなどを開催するようなことをせず、必ずソフトオープンすることだ。もうひとつは、旧システムへの切り戻しプランを作っておくこと。旧システムをそのままキープしておき、差分がなければスムーズに切り戻せるが、一度蓋を開けてしまうと難しい。いくつものタイミングで、どういう状況であれば、移行を継続するとか、切り戻すなどを決めておくといい。

例えば11月1日にサイトを休止し、20日に新システムで再オープンする場合、新しいシステム側では20日のオープンに向けて新商品やキャンペーンページなどを作っているが、旧システムでは作らない。そうすると旧システムに切り戻したときに、クローズした状態と再オープンするときの差分の情報を埋める必要があり、これにはかなりの時間を要する。これをいつ始めるかなど決めておければなおいい。

切り戻しにはかなりのコストがかかるが、昨今のようなトラブル事例が増えていることを考えると、大きな選択肢のひとつと言える。

まとめとなるが、ECシステム構築の際は初回でもリプレースでも「社内にわかる人を」「経験ある開発者チームを雇う」「欲張らない」「とにかくソフトオープン」「企業の論理に負けない」、そしてできれば「痛い目にあったことのある人をプロジェクトに入れる」ということを実施し、「どんなシステム、プロジェクトでもでもトラブルは起こりうる」ということを念頭に置いて取り組んでもらいたい。