ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. EC・通販統合ソリューション NeoSarf / DM
  3. コラム記事
  4. EC構築・運用コラム 第2話
ここから本文です。

EC構築・運用コラム 第2話

第2話 その作業は誰がやるの?移行作業で追加コストが発生

東京は田町の片隅に小さな神社がある。一見パッとしないが、EC担当者の間で「トラブルから救ってくれる」という言い伝えがある神社だ。
今日も「神頼み」へとやってきた、トラブルにあった歴代のEC担当者たちのために、IT守り神からのアドバイスをお届けする。

イメージ:カナ

<今回の相談者>
カナ(女性・31歳)


大手雑貨販売会社EC担当サブリーダー。

順調に進んでいたECサイトのリニューアルプロジェクト。
でも、システム移行で大トラブルが発生して、ベンダーとは対立するし、部長はカンカンだし、もうどうしたらいいかわかりません……。守り神様、どうかお助けください!

イメージ:IT守り神

IT守り神(ビジネス街の片隅にあるIT神社の神様)
なになに? どうしたの?

イメージ:カナ

きゃー。誰ですか?

イメージ:IT守り神

ぼくはIT守り神だけど? 呼ばれたので出てきたんだよ。

イメージ:カナ

あなたが噂の!?(まさかほんとに出てくるなんて)。と、とにかく聞いて下さいよ!
実はシステム移行の件でベンダーと対立しちゃって、大変だったんです。結局はベンダーに追加費用を払うことになったんですが、わたしは部長からさんざん叱られてしまったんですよ。

イメージ:IT守り神

うーん。なんで追加費用を払うことになったの?

イメージ:カナ

システム移行の途中で、他部署の運用担当者から指摘されたんです。
「あのー商品写真が数千点あるけど、これ誰が登録作業するんですか」って話になっちゃって。

イメージ:IT守り神

ありがちだね~。

イメージ:カナ

わたしたちは、その登録作業はベンダーさんがやってくれるとばかり思っていたんですけど、「そんな合意は取っていません」って言われちゃって。
で、社内を見わたしても、そんながっつり作業ができるほど手が空いている人がいなくて、結局高い追加費用を払うことに……。

イメージ:IT守り神

おやおや(笑)。

イメージ:カナ

確かに、社内でその作業を誰が行うかしっかり決めておかなかったのも悪いんです。
でも、ベンダーさんもその辺の役割分担があいまいだったと思うんですよ。
もっと早い時期に指摘してくれればなんとかなったのに、最後になって「どうしてもと言うなら追加作業として費用をいただきます」と言い張るんです。
もうサイトオープンに間に合わないので費用を払いましたけど……。いま、作業してもらってる最中です。

イメージ:IT守り神

どれぐらい追加費用がかかったの?

イメージ:カナ

12人月分ですよ! 完全に予算オーバーで、担当部長はキレちゃって。でも、もうお願いするしかなかったんですもん。

イメージ:IT守り神

うーん。社内共有ができてなかったのは確かにまずかったけれど、いろんな関係部署にきちんと理解してもらうのは、なかなかむずかしいんだよね。

イメージ:カナ

そうなんですよ! プロジェクトの進行状況や、全体の担当分けやスケジュールがわかる資料とかは社内で回すようにしていたんです。
でも、あとから、あとから「ここはどうなってる?」「あれって誰がやるんだっけ?」なんて新しい問題がぽんぽん発生するんです。一番大きかったのが、写真の件なんですけど。

イメージ:IT守り神

まあ、よく聞く話だね。その辺、ベンダーももう少し気がつかなかったのかな。

イメージ:カナ

どうなんでしょう。なんとなく不親切に感じるんです。
これからのこともあるんで、どういう風にベンダーさんを選ぶのがよかったのか、どうプロジェクトを進めればよかったのか教えて下さい。

イメージ:IT守り神

その前に、今回のことを整理してみようよ。

イメージ:カナ

はい。今回のことを整理すると、こういうことですかね

今回の失敗で発生した問題
12人月もの追加作業コスト(社内で対応可能な要員がいなかった)により予算オーバー。

主な原因

  • 要件定義の際、開発工程以外の付帯作業におけるベンダーとの役割分担と作業内容について、両社で合意できていなかった。
  • 社内でプロジェクトに関して必要な情報が共有されていなかった。

イメージ:IT守り神

ベンダーとのコミュニケーションも、社内の情報共有もうまくいってなかったのかもしれないなあ。経験豊富なベンダーなら、そういう社内の情報共有の仕方にもアドバイスをくれると思うんだけど……。
せっかく拝んでくれたことだし、ご利益のあるアドバイスをしてあげよう。

IT守り神のアドバイス

イメージ:IT守り神

Webサイトのリニューアルで忘れてはならないのが旧システムで利用していたデータの移行作業だ。
特にECサイトのリニューアルでは、商品の画像データや会員データ、注文データなど、個人情報も含めた重要なデータが多く含まれるため、慎重に行う必要がある。
自社内の関係部署やベンダーとの役割分担、作業範囲を明確にして進めないと、トラブルが起こりやすいので十分注意が必要だ。

今回のような場合、次の3つがポイントになる。

  1. 移行作業の実務経験豊富な人がいるベンダーを選ぶ
  2. モバイルの切り替え作業経験をベンダーに確認する
  3. 発注側の企業では、誰が何をするのか整理しておく

それぞれについて説明していこう。

POINT1 移行作業の実務経験豊富な人がいるベンダーを選ぶ

ベンダーにそもそも「移行作業」の実務経験者がいるかどうか確認しよう。ベンダーが「大手ECサイトでの実務経験がある」と言っても鵜呑みにせず、「移行の時の苦労話でも聞かせてもらえませんか?」とさりげなく問いかけて、安心して頼める実務経験者かどうか判断しよう。
ECサイトならではの移行作業を経験し、規模感なども熟知しているベンダーの担当者に出会えれば心強い。そしてその人がきちんとプロジェクトに参画してくれるかも確認すべきだ。

他社での実例として、移行時に必要なドキュメント(移行計画書など)をサンプルとして見せてもらうようお願いするのも、ベンダー選びのポイントになるだろう。

POINT2 モバイルの切り替え作業経験をベンダーに確認する

ECサイト運営でありがちなのが、モバイル(スマートフォン含む)の検討を後回しにしてしまうことだ。
企業によっては、PCもモバイルも同じ部署で管理・運用することがある。その際、国内では3キャリアの実機検証を行う必要がある。いくらシミュレータで確認できるとはいえ、やはり実機でズレが生じることがあるからだ。
これには、リニューアル後の状態のサイトを本番同様の通信にて検証するといった、特殊な動きが求められる。

ベンダーには、「モバイルの事前確認作業の経験があるか?」といった質問をしてみるといい。
また、社内でもモバイルの対応について早々に判断し、ベンダーに相談するのも1つの手だ。RFP(提案依頼書)に含めてもいいだろう。

POINT3 発注側の企業では、誰が何をするのか整理しておく

ベンダーとのやりとりだけでなく、自社側の問題もある。
システムを移行することで、担当者や作業分担が変わるかもしれない。
それが原因で、作業漏れや「これをやるのは、うちの部署じゃないよね?」などといった認識違いが発生することがあるため、バックオフィス業務におけるそれぞれの機能は、誰がどのような目的で利用するのかを業務フローに基づいて整理しておくことも大事だ。

移行作業で大切なのは、新システムにおける機能が既存システムの何に相当するのかをきちんと把握しておくことだ。
新たに追加される新機能は、実際に誰が使うものなのか、社内で整理しておくことも必要だ。ベンダーに対応シートなどの作成を依頼して、管理しておくのもいいだろう。

良いベンダーの担当者を見分けるためのチェックリスト

  • 移行の実務経験をした「人」が対応することになっているか

移行作業を経験した人は、トラブルが起きやすいポイントを知っている。その人の苦労話などを聞きながら、あなたの会社で起きそうなリスクを予め想定しておこう。

  • 過去の移行計画書を見せてもらえるか

移行作業を担当する人が過去に実施した移行計画書を見て、「いつ」「どのタイミングで」「誰が」「どんな」作業をするか確認しておくことで、予め社内の関係部署などに調整しやすくなるだろう。

  • 要件定義の段階から、移行に向けた役割分担・作業範囲を提示できるか

管理ユーザーデータ、携帯サイト、商品データ登録など、抜けやすいポイントは上述した通りである。そのポイントを把握して、予め分担を提示・確認してもらえるかで、安心して進められるかが大きく変わる。

イメージ:カナ

なるほど……。これを守れば次からはうまくやれそう! 最初からもっとちゃんとやっておけば、あんな悪夢にはならなかったかも。

イメージ:IT守り神

うんうん。当たり前だと思っていたことでも、立場によって認識がぜんぜん違うのはよくあることなんだ。だから「当然のこと」で済ませないで、発注側とベンダーの関係者でよく確認して、お互いの作業範囲や役割分担を明確にしておくべきなんだ。

まとめ:ECサイトならではの移行作業のポイントを確認する

ECサイトのリニューアルにともなう移行作業では、EC担当者の「ユーザー管理」の問題が最後になって現れてくることが多い。
注文データや商品情報、取引先情報(会員情報)などは押さえていながら、管理者側のユーザー移行についてはなにかと後回しになりがち、というのは珍しくない。

ユーザー管理では、既存システムの「ユーザー/パスワード」の暗号化方法が新システムで変わることが多く、その移行方法が問題になることもしばしば。
ベンダーが登録した管理者権限ユーザーを使って、代表するEC担当者が移行する場合もあれば、ベンダーが全ユーザーをまるごと移行することもある。
全ユーザーをまるごと移行する場合、暗号化された「ユーザー/パスワード」はベンダーには理解できないため、既存システム運用におけるベンダーとの調整や役割分担が必要となってくる。

特に、商品マスタ情報を販社に入力代行してもらっている会社では、ユーザー移行で問題が生じることが多い。暗号化された「ユーザー/パスワード」の件はもちろん、販社の数も数百から数千にのぼることもあるため、事前に作業分担や移行方針を整理しておく必要がある。
これらについては、早期にベンダーに相談するのはもちろん、RFP(提案依頼書)に明記しておけば、解決案を提示してくれるはずだ。

また、今回のカナさんのように、「サイトデザインはベンダー側作業と思っていたのに、実装時になって自社側作業と主張された」といった問題も少なくない。
サイトデザインは通常、デザイン会社に担当してもらうことが多いが、そういったシステム開発工程以外の付帯作業(サイトデザイン、移行作業、運用担当者の教育訓練など)についての作業内容や役割分担については、開発前や要件定義で確実に行っておくことが重要だ。

さらに言えば、サイトデザインは店舗のレイアウトを決めるようなもので、システム構築とは別の実績が問われる。
サイトデザインは売上に直結する要素なので、できれば自社で信頼のおけるデザイン会社を選定し、そのデザイン会社とともにきちんと考えることをオススメする。

ページの先頭へ戻る