ECリニューアルのアセスメント/要件定義/RFPについて

ECリニューアルの発注準備は、課題の把握、Must/Wantによる要件整理、目的を伝えるRFP作成の順に進めると、提案の精度が高まります。

アセスメントで課題を数値で把握し、要件定義で要望を仕分け、RFPに目的と前提を書きます。全体像はECリニューアルの完全ガイドもご覧ください。

▼全体ガイドの記事
・ECリニューアルの完全ガイド

アセスメント:現状分析による課題の把握

顧客や商品、出荷データの取り込み、問い合わせ、システム運用に関する4つの業務課題をパネルで示した図。
現場の声から、画面だけでは見えない課題も拾えます。

要件定義の前に、現状サイトのアセスメント(現状分析)を行います。「なんとなく古い」という感覚を、データに基づく課題へ言い換える工程です。

アセスメントを省くと、解決すべき問題を取り違えるおそれがあります。だからこそ、リニューアル後も成果が出ない事態を避けるため、目的を定める土台として取り組みます。

アクセス解析とCVRによる課題の特定

客がどのページや購入の流れで離れているかは、数値から読み取れます。分析で確認する主な対象は、ページ、購入導線、端末、競合の4つです。

  • ページ離脱:離脱が多いページの特定
  • 購入導線:カート投入から購入完了までの離脱率
  • 端末別CVR:スマホとPCの差の把握
  • 競合サイト:購入導線や機能から見た不足点と強み

アクセス解析やヒートマップで、表示速度なども確認します。たとえば、表示速度が1秒から3秒に遅くなると直帰率が32%増加するという、Googleのデータもあります。

分析からは、商品検索で目的の商品にたどり着けない、決済フォームの入力項目が多いといった課題も見えてきます。

課題を数値で示しておくと、要件定義の段階で改修の理由を説明でき、ベンダーとも認識をそろえられます。

競合サイトの分析も、アセスメントに役立ちます。競合の機能を参考にしつつ、自社の顧客に必要な改善を見極め、課題の優先順位を決める材料にします。

関係部署のヒアリングと業務課題の整理

データ分析と並行して、ECに関わる部署へヒアリングを行います。現場の声を集めるときは、部署ごとの業務課題を聞き取ります。

  • マーケティング・商品部門:顧客や商品に関する課題
  • 物流・倉庫:出荷データの取り込みで生じる手作業
  • コールセンター:繰り返し寄せられる問い合わせ
  • 情報システム部門:システム運用上の課題

倉庫やコールセンターの課題は、フロントのCVR改善の視点からは見えにくいものです。そこで、各部署の要望を集めるだけでなく、背景と優先度も整理します。

倉庫やコールセンターの業務変更が必要になるなら、合意に関わる人を早い段階から巻き込んでおきます。また、丁寧なアセスメントは要件定義の精度を高めます。

要望の裏にある課題を掘り下げることも大切です。たとえば、管理画面への機能追加を求める声の背景に、手作業による転記ミスが多発している場合があります。

現場の声を起点にしながら、根本の課題を捉えて、目的に照らして要望を取捨選択します。この姿勢が、アセスメントの鍵になります。

ポイント

数値で問題の場所を押さえたうえで、現場の聞き取りで裏づけられた課題を優先して扱います。数値と現場の声の両方で確かめられた課題が、改修の対象として判断しやすい目安になります。

要件定義:Must/Wantによる要件の仕分け

Must(必須)は目的達成に欠かせない要件、Want(希望)は今回なくても困らない要件として、左右に比較した図。
目的達成への必要度が、仕分けの境目です。

課題が明確になったら、それを解決するための要件を定義します。最大の落とし穴は要件の肥大化で、要望をすべて盛り込むと、費用と期間が想定を超えるおそれがあります。

予算が限られるなかでは、要件定義で優先順位をつけることになります。そのため、やりたいことを全部入れず、実施する内容を取捨選択します。

Must(必須)とWant(希望)による優先度の決定

要件の肥大化を防ぐには、Must(必須)とWant(希望)に仕分けます。各要件がどちらに当たるかは、次の基準で判断します。

  • Must:リニューアルの目的達成に欠かせない要件
  • Want:今回なくても困らないが、あると望ましい要件

この仕分けをしておくと、予算が限られていても実装の優先順位がはっきりします。たとえば、スマホの決済フォーム簡略化や表示速度の改善は、CVRに直結するMustの例です。一方で、Wantは初回では見送り、公開後の改善で段階的に追加する方法もあります。

仕分けは、各部署の代表者と合意しながら進めます。ある部署にとってのMustが、全社から見るとWantにすぎない場合もあるためです。

Must/Wantの認識を先にそろえておけば、後から要件を追加する際のトラブルを防げます。あわせて、リニューアルの目的とKPIを共通の判断基準にします。

各要件が売上やCVRにどれだけ貢献するかで見れば、部署間の対立を避けやすくなります。この判断基準を事前に共有しておくことが、円滑な要件定義の土台です。

要件定義・ディレクション費用の位置づけ

要件定義にかかる費用と、それを省いた場合に起きることを把握しておきます。投資を判断する際は、次の3点が参考になります。

  • 費用の目安:リニューアル総予算の10〜30%
  • 工程の役割:要件や仕様の整理と、依頼内容の明確化
  • 省いた場合:認識ズレによる手戻りが増えるおそれがある

割合が大きく見えても、曖昧なまま開発に進むと、手戻りで総コストが高くつく場合があります。上流工程への投資は、品質を担保するためのものです。

Must/Wantで要件を整理し、画面遷移や機能仕様を文書にまとめておくと、見積もりの精度も上がります。要件定義の質は、開発の成否を左右します。

文章に加えて、画面のワイヤーフレームや画面遷移図も用意します。「使いやすく」「見やすく」といった言葉は人によって解釈が異なるため、具体的なイメージに落とし込みます。

要件定義書が明確であれば、開発中の仕様確認が減り、工期短縮やコスト削減にもつながります。手間を惜しまず上流で作り込むことが、後工程を楽にする近道です。

ポイント

要件がMustかWantかは、リニューアルの目的達成に欠かせないかで判断します。部署によって見方が分かれる場合は、目的とKPIを共通の基準にして、各部署と合意します。

RFP:提案依頼書に盛り込むべき必須項目

提案依頼書を中央に置き、現状の課題、目的とKGI/KPI、要件一覧、予算と納期、既存システムの連携条件の5項目を周囲に配置した図。
前提情報をそろえると、各社の提案を比べやすくなります。

要件が固まったら、ベンダーに伝えるRFP(提案依頼書)を作成します。RFPは、的確な提案と精度の高い見積もりを引き出すための文書です。

内容が曖昧だと、各社が異なる前提で提案するため、見積もりを比べにくくなります。だからこそ、必要な情報を過不足なく盛り込むことが大切です。

RFPに記載すべき必須項目

ベンダーが提案を組み立てられるよう、RFPには必要な情報を記載します。次の項目がそろえば、自社の前提を伝えられます。

  • 現状の課題(Why):サイトの問題とリニューアルの理由
  • 目的とKGI/KPI(What):達成したい売上やCVRの目標値
  • 要件一覧:Must/Wantで分けた機能・非機能要件
  • 予算と納期:想定予算と公開希望時期
  • 既存システムの連携条件:基幹・WMS・決済などとの連携要件

「なぜリニューアルするのか」「どの指標をどこまで改善したいのか」を共有すれば、ベンダーは目的達成に向けたパートナーとして提案を組み立てられます。

大企業であれば、Webガバナンス、セキュリティ、アクセシビリティの条件も加えておくと、認識のズレを防げます。

既存システムとの連携条件が不明だと、各社の見積もりに大きな差が出ます。そこで、基幹システム、WMS、決済代行サービスとの連携方法を伝えておきます。

同じく、データ移行の対象範囲、件数、移行期限も、提案の精度を左右します。自社の状況を正確に説明し、移行の前提を具体的に示しておきます。

ベンダーの提案を評価する観点

複数社から提案を受けたら、共通の基準で評価します。価格のほかに、提案の中身や実行体制も見て判断します。

  • 課題理解:自社の課題と目的を捉えているか
  • 提案の具体性:解決策が具体的か
  • 見積もり:内訳が明確か
  • 実績・運用支援:EC実績と公開後の改善体制があるか

金額だけで判断すると、安くても要件を満たさず、後から隠れコストが発生するおそれがあります。評価項目ごとに点数の配分を決めておく方法も有効です。

配分の例として、課題理解30点、提案の具体性25点、実績20点、運用体制15点、価格10点と重みづけできます。さらに、複数の関係者が同じ基準で採点すれば、特定の担当者の主観に偏りにくくなります。

不明な点は、質問やプレゼンの機会を設けて確認し、認識を合わせてから決定します。

表面的な機能要件への対応にとどまらず、CVRや売上のゴールに踏み込んで提案できるベンダーは、パートナーとして信頼できます。

riplaは、コンサルティングから開発まで一気通貫で支援します。アセスメントや要件定義、RFP作成、ベンダー評価の観点づくりにも伴走できます。発注準備の進め方に不安がある場合も、上流工程から相談できます。

ポイント

RFPには、課題と目的、要件、予算と納期、連携条件を書き込みます。提案は、価格に加えて課題理解や見積もりの内訳を、共通の基準で比べます。

まとめ

まず、アクセス解析や関係部署へのヒアリングで現状の課題を洗い出します。次に、要望をMust/Wantに仕分けて、要件の肥大化を防ぎます。

要件定義・ディレクションの費用は、総予算の10〜30%が目安です。ここを削ると手戻りで高くつくおそれがあるため、十分な投資が欠かせません。

RFPには、現状の課題と目的、要件一覧などを明記します。予算と納期、連携条件も盛り込みます。ベンダーは、課題理解や提案の具体性を中心に評価します。

現状の課題を数値で示し、要件に優先順位をつけ、目的が伝わるRFPを整えれば、的確な提案を得やすくなります。準備に迷う場合は、上流から伴走できるパートナーに相談する方法もあります。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。