要件定義の進め方

はじめに #

ここでは一番重要となる要件定義のフェーズについて紹介します。 要件定義以外のフェーズについては、別途重要なポイントを紹介します。

要件定義

要件定義の進め方 #

一般的なシステムの要件定義に加えて、EC特有の要件定義を検討していく形になります。 その他のポイントとしては、非機能要件の大半についてはクラウドPaaS ECであるCommerble側で担保しますので、検討項目は減ります。

基本情報の確認 #

まず、現状の基本情報を確認します。 下記の項目に限らず、事業を成功させるにあたり必要な事項を話し合います。

  • EC事業者様の企業情報
  • (既にECを行なっている場合)売上高、注文数、商品数、顧客数(移行対象)などの現状値
  • 顧客像の確認
  • 何に特化しているのか
  • 何を苦手としているのか
  • 競合
  • 利益構造
  • 業界情報

構築(リニューアル)の目的 #

RFPの再読み合わせなど、目的を確認するのに必要な

  • RFPや、RFP相当の情報で要求事項のおさらい
  • 構築に当たり目標値の確認
  • コンセプト
  • やりたいことのリストアップ(大小問わず)
  • 既存ECがある場合、既存ECから改善したい事項のリストアップ
  • この場合、ワークショップを行い、より要求を掘り下げる事も可能です。

全体像 #

  • 全体像の確認
  • システム化部分の確認
  • 注文管理システム(OMS)の確認
  • 基幹連携内容の確認
  • 倉庫物流連携内容の確認
  • 外部モール
  • ポイントシステム
  • 会員証、アプリ
  • CRM
  • メルマガ
  • DWH

デザインの進め方 #

デザインの進め方については、EC事業者様が主導するケースと、Commerble側で主導するケースがありますが、どちらの場合も以下のような議題を検討します。

  • コンセプト
  • トンマナ
  • テンプレートを確認し、改修したいポイント検討から始めるやり方
  • ワイヤーからゼロベースで検討するやり方
  • 作業分担
  • ワイヤーまでEC事業者様で対応、もしくはHTML実装までEC事業者様で対応する事も可能です。
  • ただし、HTMLの品質はその後の改善しやすさに直結しますので、弊社側での指示に従って頂くか、弊社側で実装する事を推奨します。
  • 経験の少ない方がHTMLを作るより、弊社側で実装する事を推奨します。

業務フロー #

  • 受注ステータスに伴う業務
  • 受注ステータス表に伴いどのような業務があるか検討します。
  • 注文変更時の業務
  • 明細の変更可否を決めます。変更可にすると、決済やポイントやその他連携先との整合性を調整します。
  • 注文キャンセル時業務
  • 決済のキャンセル、ポイントの戻し、在庫の戻しを検討します。
  • 返品時業務
  • 返品時に必要な業務を検討します。
  • 在庫管理
  • どこから在庫情報が連携されるか、在庫の種類にどのようなものがあるか等を検討します。
  • 商品登録
  • コンテンツ作成
  • バナーなどメンテナンス
  • ビジネス都合のサイト停止
  • ユーザーヒアリング

既存と同じという部分には多くの問題が内在しています。一つは問題があっても気付かずそのままにしてしまうこと、一つは仕様の詳細が適切に伝わらない事があります。この注意点を良く考慮して進めましょう。

現状及び方向性の確認 #

  • 決済代行業者
  • 対応する決済方法
  • 商品情報レイアウト、サンプルデータ(CSVでもRDBでも)
  • 注文情報(現状)レイアウト、サンプルデータ
  • セット商品やバスケット売りの情報
  • 会員情報(現状)レイアウト、サンプルデータ
  • カテゴリ情報レイアウト、サンプルデータ
  • メールテンプレート※注文時や会員登録時のメール
  • キャンペーン(定率定額値引き、プレゼント、誕生月、購入2回目)
  • 送料の計算方法

特殊機能 #

どこまでがEC業務なのかは各社異なる部分があります。ここでは、通常のECから離れた業務や機能を洗い出し、検討します。

  • ECの範囲内に収まるかどうか不明な機能の確認
  • 例)請求書、納品書(物流の場合が多い)

スコープおよびスケジュール #

全ての要件を叶えるスケジュールにするのか、リリーススケジュールを遵守して、リリース後に段階的に機能を追加していくなど、ロードマップを検討します。

非機能要件 #

  • 月間の受注数、閲覧数
  • ピーク時の受注数、閲覧数
  • 連携システムの可用性
  • 連携システムのタイムラグ
  • メンテナンスの有無
  • セキュリティテストの実施

外部機関によってセキュリティテストを行うかどうか検討します。Commerble部分だけではなく連携先も含めてのセキュリティなので、実施を推奨します。

意思決定 #

  • 会議体
  • 役割分担
  • オーナー、参加者
  • 検討方法(Backlog)
  • コミュニケーション(Slack、Teams)

試験 #

  • 結合試験
  • 試験環境(主に連携先)、インフラ制約
  • 受入試験(ユーザー主導)

その他 #

  • 気をつけるべき法令の確認
  • 用語集の作成

稼働後の費用 #

  • 月額保守費用
  • カスタム部分の保守費

*コマーブルでは機能追加で保守費が増えることはありません。*というのも、コマーブルではカスタム部分の保守費を構築費から見積もっていません。問い合わせ件数やシステム間連携の複雑性で見積もります。カスタマイズすると保守費用が増えてしまっては、リリース後の柔軟な対応、良くしていきたいという思いが奪われるため、そのような費用追加は行っていません。

保守費用の増額は、連携先のシステムが不安定でCommerble側の運用負荷が増えた場合や、問い合わせ件数が想定より多い場合に発生する可能性があります。