本コラム(後編)は、多くのECシステムのリプレイスを経験してきたコンサルタントが執筆しました。前編では、ECシステムのリプレイスでよくある「失敗事例」を紹介しました。後編では、失敗を回避するための方法を解説します。ECシステムのリプレイスを検討されている人の参考になれば幸いです。
【目次】
１．リプレイスに失敗しないために重要な「RFP」とは？
２．「RFPの作成」に必要な９つのポイント
３．失敗回避に不可欠な５つの重大ポイント
４．終わりに
１．リプレイスに失敗しないために重要な「RFP」とは？
ECシステムを開発する委託先(ベンダー企業)を選定する際、「提案要件」を伝える必要があります。
この「提案依頼書」を『RFP(Request for Proposal)』と呼びます。
システムベンダーに、依頼したい内容を不備なく伝えるための文書です。
ベンダー選定を行う際、こちらの資料を各ベンダー候補へ提示する事で、各社が横並びの提案書を作成できます。
RFPがないと、「どのようなシステムを構築したいのか？」を適切に伝える事が出来ず、「実装機能の漏れ」「異なる仕様の実装」「パフォーマンスが悪い」といった、EC事業の足を引っ張るシステムが納品されてしまいます。
ECシステムのリプレイスを失敗させないために、「RFP」の作成が重要です。
次章ではRFPの作成・準備段階において、抑えるべきポイントを９つ紹介します。
２．「RFPの作成」に必要な９つのポイント
１．リプレイスの目的
２．現状の課題(システム・運用面)
３．現ECシステムの全体像
４．現ECシステムの機能
５．未来を見据えたパフォーマンス
６．移行すべきデータの範囲
７．非機能要件(前提条件)
８．スケジュール
９．予算額
【ポイント①：リプレイスの目的】
RFPにおいて、最も重要なのは「プロジェクト(ECシステムのリプレイス)の目的」です。
明確に、かつ具体的に記載する必要があります。
「目的」は、要件定義・設計段階などで、忘れてしまう時があるため、常に見返す事が大切です。
「目的」を見失ったまま議論が盛り上がっている会議に同席した事がありますが、このような時は大抵、余計な機能や複雑な要求を盛り込んでしまいます。結果、システムのバグを招き、開発コストが膨れ上がります。
【ポイント②：現ECシステムの課題(システム・運用面)】
現ECシステムの課題をリスト化し、優先度を付けます。
この洗い出し作業は、運用に携わっている「より多くのメンバー」から収集すべきです。
現場の声をしっかり拾い上げ、整理する事が重要です。
方法としては、関係者を集めて打ち合わせをしても良いですし、日頃、業務で不便に感じた事を、エクセルやGoogleスプレッドシートなどに入力できる状態を整備するのも一つの方法です。
【ポイント③：現ECのシステムの全体像】
現ECシステムの全体像を描きます。
多くのECシステムは、「決済サービス」「基幹システム」「物流システム」をはじめとした様々な「外部システム・サービス」と連携しています。
利用中のサービスと連携方法を明確に描く事で、システムベンダーがリプレイスの提案や切り替え方法を検討しやすくなります。
【ポイント④：現ECシステムの機能】
日々の運用で利用している機能をピックアップします。
現ECシステムの提供会社から「機能一覧」を共有してもらえる場合は、その一覧表をベースにまとめるとスムーズです。
なお、「業務フロー」を一緒に整備する事をおすすめします。
「機能一覧」の整備だけでは、「目で見えているだけの機能」になりがちです。
「業務フロー」に落とし込む事で、機能を時系列に整理でき、イレギュラー発生時の運用も整理できます。
【ポイント⑤：未来を見据えたパフォーマンス】
想像が難しいかもしれませんが、１年後、３年後、５年後の「売上規模」を伝えます。
「売上」以外にも、「取扱商品アイテム数」「顧客数」「受注件数」「訪問者数」など、具体的な数字に落とし込む事で、「どれくらいのボリュームをさばけるECシステムが必要か？」を要求できます。
受注処理件数が増えると、返品・交換・キャンセル・不正注文など、イレギュラーな運用が発生するので、システムで管理すべき機能を議論してみると良いでしょう。
【ポイント⑥：移行すべきデータの範囲】
現ECシステムから新システムへ引き継ぐべきデータと範囲を要求します。
その際、対象データの項目、データ件数を整理しておく必要があります。
協議すべき主なデータ）
・顧客会員データ(会員情報、アドレス帳、お気に入り、ポイント履歴)
・メルマガリスト(非会員)
・受注データ(定期データを含む)
・決算システムで管理しているカード情報
・発行済みクーポンデータ
・商品データ(テキスト情報、画像データを含む)
・商品在庫データなど
移行すべきデータの範囲を拡げると、リプレイス時のメンテナンス時間、コストにも影響が出るため、「どの範囲まで移行すべきか？」を、冷静に判断する必要があります。
なお、顧客会員データのパスワード情報をはじめとした「暗号化されているデータ」については、「移行できないもの」として考えましょう。※条件によっては移行できるケースもあります。
また、リプレイス時にステータス進行中の「仕掛りデータ(受注データ、ポイントデータなど)」についても、どのようにしたいのか、要求を整理しましょう。
自社で検討出来ない場合は、システムベンダーに最適な方法を提案してもらう事をおすすめします。
【ポイント⑦：非機能要件(前提条件)】
RFPの作成において「非機能要件」の設定は、特に重要な要素のひとつです。
「非機能要件」とは、「システムの動作以外の部分で求められる要件」を指します。
例えば「品質」や「運用手順」などが該当します。
「非機能要件」の設定が甘いと、以下のような問題が生じます。
・現ECシステムから、顧客データを移行できない…
・パフォーマンスが悪く、ページ表示に時間を要する時がある…
・システムが不安定で、応答がなくなったり、エラーが発生したりする…
・セキュリティに欠陥があり、情報漏洩する…
・定期的なメンテナンスが必要となり、その間はサービスが停止する…(ex. 毎週日曜の夜)
「機能要件」だけでなく、「非機能要件」という「品質属性」が備わってはじめて「満足のいくシステム」が生まれます。
以下分類は、独立行政法人情報処理推進機構(IPA)が『非機能要求グレード2018』で定めたものです。
これらを参考にして、非機能要件を設定してみましょう。
(1) 可用性：システムサービスを継続的に利用可能とするための要求
・お客様に支障を及ばさないための稼働時間・メンテナンス予定などの要求
・障害、災害時における復旧に許容できる時間に関する要求など
(2) 性能・拡張性：システムの性能、および将来のシステム拡張に関する要求
・同時利用可能な訪問者数、注文処理数、そのときの表示時間・処理時間など
※現状の想定数、および今後の増加見積り数(ピーク時、通常時など)を設定
(3) 運用・保守性：システムの運用と保守に関する要求
・メンテナンスのしやすさ、保守を目的としたバックアップの頻度
・運用時の役割分担や障害対応時のマニュアル化など
(4) 移行性：システム内の資産の移行に関する要求
・リプレイス後の新システムへの移行スケジュールおよび移行方法
・移行対象資産(顧客データ、受注データ、商品データなど)の種類、および移行量など
(5) セキュリティ：情報システムの安全性に関する要求
・アクセス制限、データの秘匿、機能の権限設定
・不正アクセス、情報漏洩などのセキュリティ対策など
(6) システム環境・エコロジー：システムの設置環境やエコロジーに関する要求
・耐震/免震、重量/空間、温度/湿度、騒音など、システム環境に関する事項
・CO2排出力や消費エネルギーなど、エコロジーに関する事項など
なお、上記だけではなく、以下のテストについても設定・要求できると、より安定的なシステム納品に近づきます。
例）
・性能テスト(想定アクセス数、購入数に耐えられるか？パフォーマンスをチェックする)
・ストレステスト(負荷をかけた状態の異常をチェックする)
・ユーザビリティテスト(直感的に操作できるかをチェックする)
・保守性テスト(維持・管理がしやすいか？ 拡張しやすいか？をチェックする)
・セキュリティテスト(脆弱性診断など)
【ポイント⑧：スケジュール】
実際は、システムベンダーが決定した後に詳細スケジュールを決める事なりますが、
以下のような項目は、事前に案として希望を伝えましょう。
・ベンダー選定のスケジュール(提案書の〆切、プレゼン日、決定/発注日)
・委託開始/リプレイス着手開始日
・新システム公開日
【ポイント⑨：予算額】
ここは、毎度、駆け引きが発生するテーマのひとつです。
始めのうちは、「限界予算の80％ぐらい」で提示する事をおすすめします。
初期提案時に提出される見積は、あくまでも「概算」です。
要件が確定し次第、詳細の見積が提示されるのが通例です。
要求が増えたり、機能の詳細に関する認識齟齬が生まれたりすると、最終提示価格は初期提案時よりも「上振れ」ます。
初期提案時の見積が「大雑把な概算費用」であればあるほど、このズレが大きくなります。
逆に、初期提案時から、可能な限り詳細金額を提示してくれるベンダーは、ズレが小さい、または、予算が増えても機能を削るなどの対応で済みます。
３．失敗回避に不可欠な５つの重大ポイント
最後に、「リプレイスの失敗リスクを最小限に抑えるためのポイント」を、５つ紹介します。
【ポイント①：本当に必要な機能は？】
RFP作成時に要求する機能は「本当に必要な機能」であるか？を再度、確認します。
リプレイスの目的を確認し、再考する事で、優先度を下げられる機能が出てきます。
※優先度を設定しておく事で、予算、スケジュールに見直しが必要な時の検討がスムーズになります。
【ポイント②：日々の「運用」を整理する】
運用に携わっているメンバーに協力を仰ぎ、日頃の運用フローを整理します。
「何もない通常業務」だけでなく、「イレギュラーな運用」についても整理が必要です。
運用フローを整理してみると、無駄な業務が見つかる事もあります（笑）。
【ポイント③：「複雑な要望」は「リスク」とトレードオフになる】
「複雑な要望」は注意が必要です。
機能開発が実現できても、「リスク(コスト増・不具合発生・パフォーマンス悪化など)」とトレードオフになる場合があります。
リスクがある要求事項については、代替案を含めた複数の提案を貰えるように、ベンダーに依頼するのが理想です。
【ポイント④：上流工程(要件定義・設計)後の仕様変更】
上流工程(機能要件、設計)後のフェーズにおいて、機能の見直しをはじめとした仕様変更を実施する事はリスクが高いと考えましょう。
「設計には無いリクエスト」を加えてしまうと、複雑なプログラムにさせてしまう事があります。
結果、バグの発生、パフォーマンス悪化、他機能への影響(干渉)という事態につながりやすくなります。
プロジェクト進行が巻き戻らないように、上流工程フェーズで運用理解者の協力を仰ぎ、進行するのが理想です。
【ポイント⑤：「決断」する勇気】
プロジェクト責任者は、その時々で、仕様・スケジュールなどを考慮した「決断」を迫られます。
「決断」が遅れると、取り返しのつかない「失敗」を招く可能性が高まります。
リプレイスの進捗状況を正しく把握し、勇気をもって、早めの決断をする事を意識しましょう。
４．終わりに
いかがでしたか？
当社「インターネット・ビジネス・フロンティア株式会社(IBF)」は、約20年間にわたり、様々な業種・規模のEC事業者様をご支援する機会を頂きました。
「失敗」も「成功」も、様々なケースを経験できたからこそ、第三者の立場で最適なアドバイスができるようになりました。
もし、ECシステムの導入・リプレイスにおける「コンサルティング支援」を希望される場合は、こちらからお問い合わせください。
本コラムで紹介した内容が、ECシステムのリプレイスを検討されている企業様の「ヒント」になれば幸いです。
※「システムベンダーの選定方法」についても執筆予定です。またの機会をお待ちください。
