本コラム(前編)は、多くのECシステムのリプレイスを経験してきたコンサルタントが執筆しました。ECシステムは、実は「新規構築」より「リプレイス(リニューアル)」のほうが圧倒的に難しいという事をご存知でしょうか？リプレイスを検討されているEC事業者はぜひ参考にして頂けると幸いです。
【目次】
１．よくあるECシステムのリプレイス失敗例
２．リプレイスに失敗する理由①：EC事業者編
３．リプレイスに失敗する理由②：システムベンダー編
１．よくあるECシステムのリプレイス失敗例
表立って発信する事ではありませんが、EC業界に20年携わっていると、「成功」だけでなく様々な「失敗」経験や、炎上案件の火消し役などもしています。
ここでは、経験してきた中からよくある失敗パターンをご紹介します。
【ケース①：納品されたシステムの品質精度が低い】
システムベンダーから納品されたシステムの動作テスト中に気がつく問題がこれです。
「想定を超えたバグの量にうんざり・・・」
「依頼していた仕様と異なるものが納品された・・・」
「依頼したどおりに動くけど、表示速度・動作速度がものすごく遅い・・・」
テスト納品されるまでに、この予兆(サイン)をつかめるケースもありますが、多くの場合が、テスト納品されるまでこれらの問題に気づく事ができません。
問題が発覚すると、「リリース(公開)までの限られた期間内にどのようにリカバリーすべきか？」の議論“だけ”に奔走する事になります。
【ケース②：スケジュールを守れない】
開発・改修中の期間にスケジュール遅延が何度も発生し、リカバリーできないほどの遅延に至るケースがあります。結果、公開日程の見直しです。
このような場合、経験上、素直に公開日を見直しに応じた方が良いです。ただし、1度だけです。
結果としてダメだったベンダーは、何度もリスケ(スケジュール変更)を繰り返すからです。
また、サイト運営者の強い要望でスケジュールの見直し不可のままリリースに突入してしまうと、結果的に、不具合を把握できずに、お客様に迷惑をかけてしまうケースが発生します。
こちらの回避策として、以下が必要です。
・開発工程における、「詳細スケジュール」の見える化
・「進捗」「遅延状況と原因」の確認(わからなくても可能な限り確認する)
・遅延に対する「リカバリー対策」の有無と、対策内容の「妥当性」の議論
・「予備スケジュール」の定期的な確認と「計画的な進行管理」
【ケース③：最悪の場合は「仕切り直し」に…】
本件は稀なですが、次のようなケースで悩まれている企業から相談を頂いた事があります。
あるシステムベンダーでリプレイスを進めていたところ、納品されたシステムに不具合が多く、弊社に相談頂いたタイミングでは、収束できる状態にありませんでした。
議論を重ねた結果、既存システムベンダーとの契約をリセットして、もう一度ゼロからベンダー選定を行い、再開発の投資を行う事になりました。
ご紹介した失敗例の原因は、システムベンダー側だけではなく、発注したEC事業者にもあると考えられます。次章からは、失敗理由について解説します。
２．リプレイスに失敗する理由①：EC事業者編
ここでは、「EC事業者側」の問題による失敗理由を紹介します。
【失敗理由①：度重なる仕様変更】
最も多いのが、上流工程である「要件定義」「設計」後の仕様変更です。
本来、仕様は「要件定義」「設計」段階で、確定させます。
しかしながら、開発製造後のテスト段階でEC事業者が検収作業をしていると、次から次へと「こうあってほしい」というリクエストが出てしまう事があります。弊社もこれらが原因で炎上した経験があります。
このように、リクエストが後から追加されると、設計段階では存在しなかった仕様が追加され、ツギハギのシステムとなり、条件分岐が広がり、システムそのものに無理が生じます。
結果、不具合の発生確率が高くなり、動作スピード(パフォーマンス等)が悪化しやすくなります。
世の中に存在するシステム案件で、後から発生する要求をゼロにする事は限りなく難しいと思いますが、往々にして、「要件定義」「設計」段階の打ち合わせで「本番を想定した議論ができない事」が、このようなケースを発生させます。
本番を想定できない理由は、ベンダー側(資料や具体的なイメージを想起する提案力等)にも問題がある場合がありますし、発注者(クライアント)側も、「相手はプロだから要求さえ伝えれば良い」と安易に考えている場合があります。
運用メンバーを含め、運用フロー・イレギュラー運用までしっかり考慮した議論ができれば、このような問題を回避できます。
【失敗理由②：複雑な要求】
次に多いのが、複雑な機能を要求し過ぎて失敗するケースです。
ECシステムのリプレイスの場合、今までの運用経験がベースにあるため、既存システムへの憂さ晴らしも兼ねて、複雑な要望をしてしまう事は珍しくありません。
具体的には、売上をあげるための「マーケティング機能(クーポン、ポイント、会員ランク、期間限定価格、セット販売等)」が、クライアント側の都合により、複雑な条件付きで生まれます。
EC経験が豊富な担当者であれば、懸念点などを予め発信して、良い塩梅の着地点を提案できますが、経験が乏しい担当者の場合、クライアント側の重圧に負けて、どうにかできるようにと、無用な頑張りが生まれ、最終的にはバンザイする事になってしまいます。
発注者責任として、「相手はプロだから」「やると言ったから」といった表面的な理由で押し切るのではなく、複雑な要求をし過ぎていないか？という確認を含め、「運用でカバーすべきなのか？」「見送るべきか？」等、適切に両者(EC事業者／システムベンダ―)で議論し、複雑な時は、代替案を含めた提案をもらえるように、導く事が大切です。
【失敗理由③：理解者・経験者が不在】
社内にECシステムを理解した人がいない事、ECシステムの導入・リプレイス経験者がいない事で発生しがちなケースです。
社内で検討や判断ができない場合、システムベンダーに任せっきりになってしまいます。
そのような時、システムベンダーの担当者が常にEC事業者の立場で判断してくれるか？と言うと、そのような認識は誤りです。
理由は2つあります。
1つ目は、ECサイトの運用経験がないから。
2つ目は、システムベンダ―側の都合が少なからず反映されてしまうから。
以上の理由から、あくまでも「別の会社の人」という認識を持つべきです。
プロジェクトの成功を考えるのであれば、営利目的のない第三者をEC事業者に参入してもらう事も一つの案です。
３．リプレイスに失敗する理由②：システムベンダー編
ここでは、「システムベンダー側」の問題による失敗理由を紹介します。
【失敗理由①：下請け・孫請け会社の存在】
IT業界の「あるある」の一つに、二次請け・三次請け等、いわゆる「下請け・孫請け」の悪しき構造があります。
何が問題か？と言うと、コスト面は当然ですが、何より「コミュニケーション不足による認識齟齬や不具合」です。酷い場合は、信頼関係を築けていない派遣社員、SOHO(個人事業主)から技術者だけを寄せ集めしているプロジェクトもあります。ゾッとする体制ですね…。
下請けが存在する際は、まずは、正しい情報を発信してもらう事。そして、下請け企業との意思疎通をどのように実施するのか？を確認したり、重要な打ち合わせには必ず参加してもらう事を要求したり、「システムベンダーへリクエストする事」も大切です。
時間がない・リソース不足といった事を言い訳にして「システムベンダーに全てを任せっきりにするプロジェクト体制」は、リスクが高くなる事を忘れてはいけません。
【失敗理由②：「イエスマン」な担当者】
発注者側のリクエストを全て断らずに「やります！」「がんばります！」の一つ返事ばかりの時は、注意が必要です。
「ラッキー♪」と、何も考えずに乗ってしまうと大変な事になります。
全ては「トレードオフ」です。
要求が増えれば、費用が増え、スケジュールは伸びるのが、誰にでも理解できる原理原則です。
【失敗理由③：経験が浅い担当者】
発注先の企業は経験が豊富でも、担当者の経験が浅い場合、トラブルになりがちなテーマが2つあります。
1つ目は、「データ移行」です。
リプレイス時は、既存システムのデータ(商品、顧客、受注等）を移行する作業が存在します。
これらのデータ移行作業は、リプレイスにおける最も大変な作業の一つです。
経験上、どんなに入念に準備をしてもトラブルはつきものですが、データ移行に関しては、「作業のリハーサル」が必須です。
リハーサルを行う事で、作業工程、メンテナンス作業時間等の見直しを事前に検討できますし、当日発生しそうな問題についても、事前に対応策を検討する事ができます。
2つ目は、「パフォーマンス」に関する問題です。
リプレイス完了後、広告・SNS・メルマガ等で「リニューアル記念」と称したセールを案内する事がよくあります。
この時、多くのお客様が集まる事が想定されるのですが、公開直後にパフォーマンスが悪化するケースがあります。
リプレイス前に、予め「瞬間風速(1秒間のアクセス数)」等を協議し、システム負荷をかけた性能テスト、ストレステストを実施する事で、このような問題を事前に潰す事が可能です。
以上、ご紹介した2つのケースは、経験が浅い人が担当者になってしまった際に生じる例です。
【失敗理由④：ドライな線の引き方】
ECシステムでは、基幹システムをはじめする「他システムとの連携」が必須という案件が少なくありません。
この時、「ここまでは自分たちの領域」「ここからは他システムを提供する企業の領域」と、きっぱり線引きされてしまうケースが少なくありません。
システムベンダー側のリスクを考えると線引きはリスク回避として正しいとも言えます。
しかし、EC事業者内に運用およびシステムを理解したメンバーがいない場合は、「ECシステムベンダー」もしくは「接続するシステム・サービスベンダー」の担当者に連携部分を適切に仕切ってもらい、双方のシステムを理解してもらう事が大切です。
【失敗理由⑤：急な担当者の変更】
最後のケースは、窓口となる担当者の変更です。
長期プロジェクトの場合、担当キーマンが突然異動になるケースも珍しくありません。
また、異動の他に、上流工程(要件定義・機能設計)を終えると担当キーマンが「ほとんど顔を出さなくなる」というケースもあります。
ビジネス上、自分たちのプロジェクトだけに専念してもらうのは難しい、という事は理解できますが、要件定義の途中や仕掛り状態で担当変更になるのは、炎上案件の予兆の一つです。
キックオフ時に案内されていた体制が変わる時は、「引き継ぎがしっかり行われているのか？」を確認すべきでしょう。
今回はここまでです。
前編では、ECシステムリプレイス時によくある「失敗事例」と「理由」、そして「簡単な対応策」について、解説しました。
後編では、より具体的に、今すぐ実践できる「改善方法」を解説します。
